Converting Litecoin M-addresses to a more commonly accepted format

You cannot convert an M prefix to an L prefix as they are different types of addresses, the first being a P2SH address and the latter a P2PKH address.

You can, however, convert it to a 3 prefix address using https://litecoin-project.github.io/p2sh-convert/, a convertor built by the Litecoin Foundation for this exact purpose.

Originally, Litecoin used the 3 prefix for their P2SH addresses. However, this caused an overlap with Bitcoin, which also uses a 3 prefix, and led to many people sending funds to incorrect addreses. Litecoin then changed their prefix, but since it is simply an encoding change, you can convert it back to the original prefix for wallets that have not yet update their integration to respect the new prefix.


I don't know what this frequency analysis technique would do, so this answer corresponds to the second question you asked:

Blockchain.info connects to hundreds of nodes:

http://www.blockchain.info/connected-nodes

The IP address Blockchain.info shows is the address of one of those nodes that they happened to be connected to which first saw that transaction.  A node where privacy is desired does not allow incoming connections and only connects to trusted nodes that won't violate privacy expectations.


The situation you describe cannot happen / would lead to a routing failure. I have created an 11 minute video explaining how htlcs are used in onion routing. Parts of the video (rather at the end) explain how fees are encoded within the sent onion. I think watching that video is the quickest way to understand the fee model of the lightning network.

A tl;dw (too long didn't watch) answer looks like that:

If a node decides to maliciously collect a larger fee and forward the onion. The next hop will not be able to collect the fee as it advertised and will fail the routing process. In your setting this means charlie decrypts his onion and sees which amount to forward and sees from the incoming htlc that it would only receive a fee of 80 / 50 or 0 Satoshi instead of the advertised 100. As said charlie would fail the onion but not be able to blame Bob. Actually obs behavior would confuse Alice as she chose the correct fees. Alice could assume Bob was a bad routing node and elect a different part. However this mechanism is as far as I know not implemented yet.


Just use a testnet dns seeder.

Type this into your terminal:

dig A testnet-seed.bitcoin.jonasschnelli.ch

or

dig A seed.tbtc.petertodd.org

for IPv6

dig AAAA testnet-seed.bitcoin.jonasschnelli.ch


Why are P2WSH addresses larger than P2SH addresses?

Because P2SH addresses are too short to provide typically desirable levels of security security level we expect from Bitcoin, against certain attacks. On top of that, they use bech32 encoding rather than base58, which means they're slightly longer for the same amount of data, but are case insensitive instead.
For any kind of "multi party" address (that is, an address constructed by multiple distinct and distrusting participants that each have their own key, such as multisig), a particular collision attack exists that has runtime O(2bits/2), where bits is the number of bits of entropy in the address.
P2PKH, P2WPKH, and P2SH addresses have 160-bit hashes in their addresses. For P2PKH and P2WPKH this is fine, as it only supports single-party construction. However, as P2SH supports multisig and other multi-party constructions, it means an ~280 attack is possible(*). Bitcoin typically has a 2128 security target for attacks, so this is insufficient. That doesn't mean such a collision attack is practical - it's just far weaker than what the rest of the system provides, and as computing performance increases it may become feasible for well-funded parties.
To address this, P2WSH introduced a multi-party-capable address that contains a 256-bit hash, so it has ~2128 collision security.
In the upcoming Taproot upgrade, a new P2TR address type is introduced. It has the same length as P2WSH addresses, and also contains ~256 bits of entropy. Due to the nature of Taproot, which merges P2PKH and P2SH style spending into one, this means even single-party addresses are 256 bits in it.
For details of the attack, see https://bitcoin.stackexchange.com/a/54847/208.
(*) There are ways to avoid the collision attack problem, even with short hashes. They significantly complicate address construction and spending however. So the choice to provide a 256-bit script hash mechanism is really just to make sure multi-party address construction isn't needlessly complicated.


How can transactions be verified without the private key?

Bitcoin transactions are not encrypted, they are cryptographically signed.

You can use a public/private keypair 2 ways:
(massive simplification warning)

Encrypt a message using a public key and then decrypt it with a private key
Sign a message using a private key and validate the signature with the public key

The second method is the one that is used by Bitcoin. A message is placed in the distributed ledger that bitcoins have been sent from X to Y (and typically Z), and signed by the private key of X. X is the source bitcoin address, Y is the destination, and Z is the change address.


Bitcoin core How do I get the transaction fee while using sendtoaddress

I think you want estimatesmartfee or estimatefee it takes one argument which is the confirmation target in blocks.  You can also select from Economical or Conservative fee modes which may affect the suggested fee rate.


What is the "Count" column in the order book on Bitfinex?

It's because the Total column is not the cumulate sum of the column Count but of the column Amount. In your example, at the line for price 1612, Total=6.0 and indeed if you do the sum of all amount of the price above 1612 it gives you : 0.3+1.2+1.7+2.8 = 6


How do miners avoid transactions getting dropped?

Miners have mempools where they store all transactions they consider to include in future blocks. They don't put transactions they received into their blocks, right away.

But they don't put them into their mempool right away, either. The transactions in each miner's mempool are valid and worth the miner's effort (pay at least a certain amount of fee).

They can't even include all of the transactions they know about in their blocks, at the moment. Blocks can at most be 1 MB in size and because there currently are many transactions, the mempools of miners are much bigger than 1 MB.

At point 0 in time, the mempools look like this:

mem_M1 = {A, B, C, D}
mem_M2 = {A, B, C}

When M2 solves the block, they remove all transactions they included in their block from their mempool:

mem_M1 = {A, B, C, D}
mem_M2 = {}

M2 then sends the block to M1 who validates the newly received block. If M1 considers the block valid, they remove all transactions in that block from their mempool:

mem_M1 = {D}
mem_M2 = {}

Note that D is still in there. M1 doesn't flush their mempool. Only the transactions included in the newly received blocks have been removed.

They then receive more transactions:

mem_M1 = {D, E, F, G}
mem_M2 = {D, E, F, G}

Next, M1 solves a block and removes the transactions they included from their mempool:

mem_M1 = {}
mem_M2 = {D, E, F, G}

After M1 sends their newly mined block to M2, M2 removes all transactions included in that block from their mempool:

mem_M1 = {}
mem_M2 = {}

All transactions have been included in blocks.


How to determine right address from address hash

Your address 32feVAD9Haq1CtfT6JCLTt4L5qef3UnVpY is a P2SH mainnet address, with a 05 address prefix and represents the base58 encoding of the following data:

[05][20-byte hash][4-byte checksum]

So, the [05] prefix tells your wallet that your address represents a P2SH embedded script presage (20B).

On the other hand, a [00] prefix tells your wallet that the 20B digest represents a Public-Key-Hash, and that funds should be sent to a P2PKH (Pay-2-Public-Key-Hash) output.

The version number therefore gives your wallet the necessary information to produce the correct output type when sending funds, so that the recipient has the private keys (P2PKH) or presage (P2SH) to spend them.

The 05 prefix translates to a 3 in base58 encoding, which is why your addresses begin with 3. I cannot comment on what the embedded script type is though, since the P2SH has is simply the 20B hash-digest thereof. Perhaps a P2SH(P2WPKH) script type.

Amended Answer:

To determine the address version appropriate for a specific output from a transaction, simply look at the output script in question.

P2PKH: "hash160 [20B] equal" -> version 5
P2SH: "dup hash160 [20B] equalverify checksig" -> version 0
P2WPKH: "[00] [20B]" -> bech32 address


If I'm reading correctly, your input transaction is  7bd31512076520e5fb2ee1cef9b6e63f0571cbd05d26676c7df336b4e0323e3f.  This transaction is not found by a search on blockchain.info.  I would guess one of the following is true:

The transaction id is incorrect
The transaction was never broadcast
The transaction was broadcast, but was never confirmed, and so much time has passed that  blockchain.info stopped keeping track of it.

So, check that the id is correct, and if it is, try (re)broadcasting the transaction.


Private key to WIF compressed: which one is correct?

It seems that #1 is correct and not #2.

Yes, #1 is correct. The encoder will add the 01 flag byte to the end of the private key for you. By doing that manually in #2, you will result in the private key having an additional byte which is incorrect.


How do I spend my Bitcoins without waiting for Bitcoin-Qt to sync?

If you use an iPhone, give bread wallet a try, the Blockchain app is cool, too. On Android I'd probably use mycelium.

All of those have nice and clean interfaces. Send some coins back and forth to get a feeling for it.

It's better for the network to run a full node (=use a client that downloads the whole 20Gig blockchain) but you don't necessarily need to, to send and receive BTC. All the apps I mentioned before dont require you to download the blockchain.

Technically Blockchain (the company) is an online wallet, which means they hold and secure your private keys (= the keys that allow sending money) while with bread wallet and mycelium you hold the private keys.

Blockchain = the company

the blockchain = the public ledger of Bitcoin


What is the mechanism to ensure execution of contract parameters specified in a contract reference transaction?

The trigger transaction only specifies the contract reference name. This contract reference name is unique per account. It is possible for a different contract runner to use different contract runner account with different contract reference names. Which means that the same trigger transaction can trigger different runners to load and run a different version of a contract from the blockchain or even a completely different contract depending on the reference.

Having said that, a trigger transaction most likely will set its recipient to a specific account, triggered contracts should first check if they are the recipient of the trigger transaction and ignore it if they are not.

There could be variations on this, for example a contract can choose to process a trigger  transaction for which its contract runner account is not the recipient. Perhaps the contract runner account has set specific account properties on a group of accounts it would like to consider when they are a recipients of a trigger transaction.

Having said that, in most cases I expect that only one contract runner will process a trigger transaction and the rest will ignore it.


Should the BIP 39 mnemonic sentence checksum be eliminated from the standard? Does it do more harm than good?

No, I don't think the checksum should be removed or made optional. It doesn't do more harm that good.
Bip39 is a simple way to copy computer-generated randomness from the computer onto, eg a piece of paper. This Bip39 mnemonic sentence can then be used to restore your wallet, should you lose your computer. The checksum provides some degree of certainty on the correctness of the mnemonic you enter.
However, lately, people have begun to explore how to create their own randomness when creating a new wallet. This can be done with dice, coin-flips, etc. You might want to do this for example if you don't trust that the computer's random-number generator is doing its job well.
Since most wallets offer a way to restore a wallet using bip39 mnemonic sentences, people are trying to use that feature as a way to create new wallets from manually generated randomness. This is where the problem lies.
Actually, it's stated in the Motivation section of bip39:

This guide is meant to be a way to transport computer-generated randomness with a human-readable transcription. It's not a way to process user-created sentences (also known as brainwallets) into a wallet seed.

So we're actually using bip39 in a non-intended way, and that's why it's so awkward. The solution to this is not to modify bip39, but to acknowledge that we're doing it wrong.
Instead of entering manual randomness into a computer through bip39, we should invent other means of transferring the manual randomness into the computer. Some wallets already offer this. For example, ColdCard lets you input dice rolls one by one until you think you have enough randomness and then the device will provide you with a bip39 mnemonic sentence for you to backup on paper. That's one way to do it.
As you may have noticed, since writing about this on Twitter (cited in Michael Folksons's answer), Mastodon, and Reddit, I've changed my mind about this. I no longer think that making bip39 checksum optional is the solution. The solution is to not use bip39 to input randomness into a computer. The purpose of BIP39 is to transfer computer-generated randomness to a human, not the other way around.


Why was the Oct 2015 Transaction Malleability event possible in spite of BIP62/66?

Canonical DER signature implemented in BIP 66 fixes issue #1 of BIP 62 ( Non-DER encoded ECDSA signatures )

Amacilin's code exploits issue #5 in BIP 62 ( Inherent ECSDA signature malleability ),  and is explained here : https://github.com/bitcoin/bitcoin/commit/a81cd96805ce6b65cca3a40ebbd3b2eb428abb7b

This issue was fixed by requiring signatures to have low-S encoding in pull request 6769 : https://github.com/bitcoin/bitcoin/pull/6769 . Note that this fix only prevents mutated transactions from being relayed (transactions without low-S encoding can still be mined into blocks).


The latest version of Abe supports getdifficulty, so you could run it yourself or convince the explorer administrator to upgrade.  But this will be the difficulty as of the last solved block.  I would expect "litecoind getinfo" to give a more accurate number during difficulty adjustments, and this does not require Abe or a website.

As for the block reward, Abe lacks bcperblock.  Perhaps the easiest route is to get the current block number (also available via getinfo) and calculate the reward.  According to litecoin.org, the reward starts at 50 LTC and is halved every 840,000 blocks.  In Python:

def reward(blocknumber):
    return 50.0 / (2 ** int((blocknumber + 1) / 840000))

Adding 1 to the block number gives you the next block's reward, which is what matters to miners.


Can you add value to a Casascius physical coin?

Yes, you can add value.  The block chain only knows public keys. It doesn't care how or where the corresponding private keys are stored.


Sorry Alex, but you're wrong on the question being asked.  It's trivial to put bitcoins "beyond use" so that they can never be spent again.  All you would have to do is send the bitcoins to a made up address, which no one would have a key to.  This has already been done, since coins have been sent to addresses which are almost certainly unowned (like the lowest possible hash that is a valid address).

So specifically in your situation, the BTC2 people could use a public method of creating an address that no one owns the private keys to, then design their system to credit people who send BTC1 bitcoins to that address.  One reason someone might want to do this despite the open-source nature of Bitcoin would be to create a new, incompatible protocol that grabs some of the user base of BTC1 without forcing anyone to leave, allowing the two to coexist and compete quite fairly.


How do I investigate an address or transaction?

The simplest way to get information about the transaction is to use the Blockchain web site.  They have some easy-use-tools that can show you which transactions the funds came from, and the submitting IP address.  Use the URL http://blockchain.info/tx/transactionid.

For example: http://blockchain.info/tx/cc4ffa39d766fadfc6bd48a2144492e6e7b07c9b4046f7edbad3ec63869dd071

I don't think you'll get much information about the IP address, because addresses are not part of the transaction information.  A Bitcoin host only knows the address of the peer that relayed a transaction, which usually isn't the originating address.

You can trace what other transactions your donation came from, but putting a name to a bitcoin address can be difficult.  Your best bet might be to do a Google search for the address of some of the upstream transactions.  If someone used their well-known address for donating, then you might be able to find them.  But if the originating addresses were never put onto a web page by their owners, then you're out of luck.

If you are a government and the funds originated through one of the currency exchanges, you could use a warrant to get whatever information the exchange has on a transaction.  Given the state of privacy rights these days... well don't get me started.


BIP67 + importmulti + multisig descriptors

No, the descriptors language currently doesn't support BIP67.

It would be easy to add a multi_bip67 or so to the language if there is a need for it.


What's the difference between a bitcoin client and wallet?

A wallet is the collection of data needed in order to receive and spend bitcoins. Usually this includes key-pairs (private key, public key and the address that may be inferred from the public key) and funds associated with each key-pair in the form of spendable outputs.

The client on the other hand is the interface to the network. It handles all the communication, updates the wallet with incoming funds and uses information from the wallet to sign outgoing transactions.

While theoretically the wallet could be implemented in a way that is client-agnostic, currently each client implements its own wallet format, blurring the distinction between wallet and client. There are however several projects that attempt to standardize the wallet format so that it can be used in several clients.


How do I find out the miners fee for my transaction using Blockchain.info API?

There really isn't a standard fee value. Various clients implement different amounts. For example on my MultiBit installation it's currently set to 0.0001 BTC per 1000 bytes of transaction size.

You must include a fee otherwise miners won't confirm your transaction.

For Blockchain.info's case, using their API, if you don't have the $fee parameter, Blockchain.info will automatically add 0.0005 BTC in fee, which is the default value.

  All transactions include a 0.0005 BTC miners fee.

So if you send 0.01 BTC with their API, and don't specify the $fee parameter, it will add a 0.0005 fee to your transaction.

EDIT This means you actually need at least 0.0105 BTC (0.01 + 0.0005) in your wallet to make the transaction. If you want to send all of the 0.01 BTC, you have to actually send 0.0095, otherwise the transaction won't go through.


Electrum is a Bitcoin only application. This is directly stated by Electrum where it says it is a Bitcoin wallet. It does not say that it is a wallet for any other cryptocurrency. You cannot use Electrum for Bitcoin Cash.

To get your Bitcoin Cash, you will need to export your private keys from your Electrum wallet and import them into a Bitcoin Cash wallet. This may be easiest to do with Electron Cash which is a fork of Electrum but modified to work with Bitcoin Cash.


Is it possible to transfer BitCoins from BlockChain to CoinBase?

You can transfer bitcoin from anywhere to anywhere! Simply log in to coinbase and click "Request" and then submit the blank form (this is one way to find your bitcoin address) and then send the coins there. Historically, coinbase has allowed selling coins as soon as they see them, not requiring confirms like most exchanges do.

One note about using web wallets or other types of deposit withdraw accounts is that sending coins between them is bad practice. If there is any chance your coins will be sent back by the receiving wallet, you should always use your own client, such as any you find on bitcoin.org.

The reason so is that exchanges and other web wallets will not necessarily send the coins which you had sent to your address in order to withdraw your funds. So if a coin will be sent back, it will show up on an address not registered to you and you will not be credited the coins back.


Do bitcoin exchanges based outside of the US who serve US customers have to register with FinCEN as MSBs?

The short (slightly oversimplified) answer is that most consumer protection oriented laws (including Money Services Business and Money Transmitter laws) apply to the consumers themselves. So if you serve customers in the US, you must comply with the laws that protect those customers.

IANAL, YMMV, etc. Consult an attorney specializing in MSB/Money Transmitter laws for an more accurate application of the laws to your business model.


Learning as I go but needing help understanding the concept

You can get bitcoins by mining them. This is currently done by special mining hardware. You can mine alone or as a part of a larger mining pool. Before that you should buy this relatively expensive hardware (for example AntMiner S9).

The usual way to get bitcoins is buying them with regular (so called fiat) currencies (like USD, EUR...) through bitcoin exchanges. More on the process: https://www.investopedia.com/terms/b/bitcoin-exchange.asp. To get more details you should check on particular exchanges mentioned in the article (like for example: https://www.kraken.com/).


I found this link the other day that shows where you can use bitcoins https://www.spendbitcoins.com/places/?place_type=service  mostly for hosting companies, some poker sites/online casinos & many computer co's that i'm sure most people would never use right now.
Saw an article that a restaurant in NY wanted to accept them soon but probably its a marketing gimmick before the crash to get some free publicity.
there is also that article of the guy in Canada wanting to sell his house for bitcoins. I'm sure he's going to need much more bitcoins now after the 2 day crash unless bounces back.

Many have used them on Silk road for buying drugs too but I'm sure gov't going to crack down on that . Heard they caught some guy in Australia recently for Silk Road.

Hope that helps


Can Ripple Unique Node Lists (of validators) be weighted?

I have information from the #ripple IRC channel that 'unique' nodes are weighted equally in the current implementation.


What does message "Server is lagging (9 blocks)" mean in Electrum?

The message informs you that the Electrum server your wallet client is connected to is not in sync (not up-to-date) with the blockchain. In the message you quote it is 9 blocks behind.

This can happen when a server has been rebooted after maintenance or, in some cases, if the server is malfunctioning. Hence, there is no guarantee that the problem will resolve quickly.

While the server is lagging the blockchain, it is unable to provide your connected wallet with an accurate transaction history.

By default, Electrum connects to a random Electrum server on the network. To connect to another server simply exit and restart your wallet, or you can go to Tools > Network and manually specify a preferred server.


sha is a function where you give a message and it takes the ascii
  codes of the message and does the math operations on these codes.

Wrong. sha256 is a hash function. This means it takes data of (fairly, there can be a granularity) arbitrary length and returns data of constant length. In the case of sha256, the granularity is 1 bit (though the granularity of most implementations of it is 1 Byte; Thank you, dave_thompson_085) and the data it returns is always 256 bit = 32 Byte. No ASCII encoding required.

You feed your hash function the wrong data. You feed it a string containing the ASCII-encoded hexadecimal representation of the data you're supposed to feed into the function.

If you have a hexadecimal representation encoded in ASCII, you first have to convert it to the data it represents and then feed that into the hash function.


Error - Electrum wallet RPC method not supported

There are two problems with your command.

First, any method you call should not be prefixed by wallet. or suffixed by ().

Also, there is no RPC method create_new_address. If you have a look at lib/commands.py you will see that the internal python method create_new_address() is called by the RPC method getunusedaddress, and only when the parameter force=true is given.

With the above in mind, try this:

curl --data-binary '{"id":"curltext","method":"getunusedaddress","params":{"force":true}}' http://127.0.0.1:7777

The equivalent shell command would be

electrum getunusedaddress --force

I tried this on electrum 2.8.3. Sadly, it always returns the same address. This is because the address remains unused.


You cannot do that.

The txid is not "chosen"; it is defined as the double-SHA256 of the transaction data (excluding the witness, when it is a segwit transactio ). Every node computes the txid independently.


Can I store the whole blockchain yet keep my actual wallet with bitcoins offline?

Yes you can,
https://bitcoin.org/en/developer-reference#importaddress

What you need to do is to create a watch-only address on your online computer.
This can be done by "importaddress" in console and use no rescan. Rescan, after you have imported all the addresses to get their respective balances.

To spend BTC from your offline computer, you need to sign the raw-transaction offline( created on your online computer).
Take a look here how-to: https://bitcointalk.org/index.php?topic=651344.msg7306076#msg7306076

If you use Electrum wallet, all these steps can be simplified a lot.


Why same output address is invalid in a transaction on Bitcoin Core?

It is not invalid.

The code you are looking it is unrelated to validation and relay of actual transactions. You are looking at the code for RPCs which are just things for users. The RPC disallows sending to an address multiple times because this is not efficient and usually a mistake by the user.

But this is only for creating a raw transaction using the Bitcoin Core RPC. A transaction received over the network or in a block that has dupllicate addresses in the outputs would not be rejected or be invalid in any way.


Most miners today simply use sort transactions by fee/byte and include them in blocks. This is optimal strategy for revenue maximization(ignoring the knapsack errors).

When the nonce space is exhausted, miners can either change the timestamp of the header or they can use the additional space in the first transaction(called coinbase) where they can put random data. Changing this random data changes the merkle root, on which you try out 2^32 nonces.

So, to answer your question miners don't necessarily try to find new transactions that will find the solution, they can mine the same set of transactions with a little change in first transaction that does not affect the outputs any transactions in the block.


blockcypher shows much higher amount transacted

I am making the presumption that localbitcoins.com does as many web wallet providers do, amalgamate transactions.

Most likely your transaction was combined by the wallet provider with some others before being broadcast. No, you cannot claim the additional value of the transfer.


I think you're confusing a few things.
A SHA-256 hash is a single value that is 64 hexadecimal characters long. This hash can be seen as simply a very long number.
A target hash in cryptocurrencies is the maximum value that a successful block hash should be. Miners are aiming to generate a block where the hash, when seen as a large number, is a smaller number than the target hash.
The entire thing 000000000000000000084bc771b929b0780276b1c31cec10a96921b1e53b970a is a block hash. It is a SHA256 hash, and just happens to be a number that contains a lot of zeroes.
If you want to see how the block hash is calculated, take a look at this article: https://en.bitcoin.it/wiki/Block_hashing_algorithm


what is meant by DEFAULT_ANCESTOR_LIMIT in child pay for parent?

Bitcoin Core by default does not forward a transaction to its peers, when the full tree of its ancestor transactions contains more than 25 unconfirmed transactions or 101 kvB of unconfirmed transaction data. This limit helps curb spam attacks using long chains of unconfirmed transactions.

Example1:
If you have no unconfirmed transactions associated with your wallet, and then send a single transaction, you may spend the unconfirmed change output of the first transaction in a second transaction. This second transaction would now have one ancestor transaction for the purpose of the above described metric.

Example2: Alice sends funds to you and Bob, but Alice's transaction itself spends outputs from two other unconfirmed transactions. If you use the transaction output sent to you by Alice, you will have an ancestor count of 3. If Bob then also spends his output in yet another transaction, his ancestor count is also 3. Your transaction is not part of Bob transaction's ancestry.

Unless you create a lot of transactions in rapid succession or always pay minimum fees even when there is a large queue of transactions waiting to be confirmed, you will not usually get to 25 ancestor transactions.


What are the parts of a Bitcoin Transaction "Input" script?

3045022100d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5022057880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d01

Is a DER encoded ECDSA signature. I'll break it down:

  30

indicates that a compound structure follows (ECDSA signatures are treated as a compound of 2 integers, r and s)

  45

is the total length of the compound structure (excluding the 2 header bytes, 30 45), 69.

  02

the start of the contents of the compound structure, 02 indicates an integer (the signature's r value)

  21

of 33 bytes

  00d52330113ccd033ccb1aaa3b759e9696c216e802922e5f1902cd5ada69c612e5

the integer's value encoded in 33 big-endian bytes. The first byte is zero, as without it, it would be interpreted as a negative number (see 2's complement notation).

  02

another integer follows (s)

  20

of 32 bytes

  57880205319dccb05eebbe34323a852ee82653f09f81253ddccd08a810e9d42d

the 32 bytes encoding the s value

  01

this is a sighash byte appended by Bitcoin, and is not technically part of the ECDSA signature. As such, it's not counted as part of the length 69 (byte 45) at the start. It indicates what fields of the transaction are signed. 01 means "all".


Is there a way to query the blockchain locally if I am running a full node?

If you want to query your full node, you should use the JSON-RPC API. Note that by default, you'll only be able to get blocks, and transactions from your own full node wallet. If you want to be able to query any transactions, you have to add txindex=1 to your configuration file. And compared to using blockchain.info, you won't be able to query balances of addresses.


A fee is added per kilobyte of data. That means 1000 bytes or 1024?

According to the Bitcoin.it-wiki page on Transaction fees are dependent on multiples of 1,000 bytes  (rounded up).

The above page cites Gavin Andresen's post on 0.8.2 Release notes:

  The default fee for low-priority transactions is lowered from 0.0005 BTC
  (for each 1,000 bytes in the transaction; an average transaction is
  about 500 bytes) to 0.0001 BTC. [emphasis mine]


How to earn Bitcoin without any investment

You always invest something (time for services, money for compute power, ...) when you want get something so the question does not make that much sense. "There is no free lunch."


Bitcoin Pay-to-PubKeyHash (P2PKH) in multi-sig addresses

Can we send Pay-to-PubKeyHash (P2PKH) to an address which starts from 3

No.

  How can I send transaction to address which starts from 3 ?

Construct scriptPub as OP_DUP OP_PUSH(bytes20) OP_EQUAL where bytes20 decoded from 3-address


How can I determine my cryptocurrency exchange rate according to demand and supply by programmatically?

Price of bitcoin is determined by the traders
Suppose there are 2 Traders Person X and Person Y
Then consider the following use case.

  1.If person X has N amount of bitcoins and then he can choose to sell them at P amount of price.

  2.Person Y wants to purchase the Bitcoin then he can choose to bye N amount of bitcoins for price P1.

  3.If P=P1 then N amount of bitcoins are transferred to account of Y.

  4.In the same way if the Buyers are decreasing the price and continuously finding the sellers for descried price then the price
  goes on decrising

  Vise-versa if the sellers are incising the sell price and continuously finding the buyers for increased price then the price of
  bitcoin goes up.
  The third condition which rarely occurs is If sellers trade and buyer trade is not matching then the price of bitcoin is determined to
  the midpoint of lowest sell order and highest buy order.

  ie. If highest bye order is for 10L/BTC and lowest sell order is for
  15L/BTC then the price will be set to 12.5L/BTC and users will trade
  according to that.


Brother died and I am sole survivor..just found out he has a wallet. How do I go about getting his bit coins I have no info

I have no info..

Without information, you cannot get control of any Bitcoin your brother possessed.
You need some details of his wallet or of his account with a Bitcoin exchange.

How do I retreive

If he looked after his own money in a Bitcoin wallet on a computer or phone, you need to be able to log in to that device and run the wallet program and enter any password he set on the wallet. He may have kept a note of his wallet's "private key" or its 12, 18 or 24-word "recovery phrase" written down somewhere safe. E.g. on paper or stamped metal in a safe. If so, you can use this information on a different computer to create a new wallet that controls the same money.
If he had an account with a business that looked after his money for him, you'll need to find out the name of that business and his login details. It is possible you would find some details in his old email messages.

I have death certificate.

That might be of use if his money was in an exchange and you know his account name but not his account password. You or the executor of his estate would need to contact the exchange  directly about this.

You will be contacted by people offering to help you. 99% of these will be scammers intending to trick you into trusting them with any details you find, or who will trick you into paying invented recovery fees but who will never give you access to your brother's money. Be very very careful.


Absolutely! Generate your public and private keys using a wallet, save your keys somewhere, you can even print them on a paper and put it in a save place. I think this is the higher level of security.

Additionally you can split your coins in 10 wallets and print them separately. That way if you need only 0.2 bitcoins you can take two keys and import them in your wallet. This gives you flexibility.


Tthe empty string "" is for the default account, not for all accounts in your wallet. Whenever you add a label to an address, what you are really doing is adding it to an account. If you want to be able to spend from all of your addresses, you will need to move all of your addresses into the same account, i.e. remove their labels and make them the same label.


GREP help: Bitcoin address/key buried as text somewhere on hdd

[^13][a-km-zA-HJ-NP-Z1-9]{25,34}$.

...

  I removed the ^ and $ from the ends after when I realized that there is no reason to think it's at the beginning or end of a line ...

As you noted, the trailing dollar sign ($) anchors the search expression to an end-of-line (e.g. LF on Linux) - you probably do not want to do that.

However the [^13] does not anchor the search to start of line, inside square-brackets, the caret ^ means not. So [^13] means look for a string whose first 8-bit character is not a 1 nor a 3. It would match strings that begin with any other character - that is probably not what you want. If you want a string that begins with a 1 or a 3 just use [13]. If you wanted to anchor that to the start of a line you'd use ^[13] not [^13].

  ... (if I properly understand what that even means).

The expression ^[13][a-zA-Z0-9]{25,34} matches these lines:

1234567890123456789012345 is my secret code
3aklsdjlajkjvcnbxuxcjvhhkjhgtresds

where the 1 or 3 immediately follow a prior LF character (or are the first character in a file).

but does not match either of

my secret code is 1234567890123456789012345
    3aklsdjlajkjvcnbxuxcjvhhkjhgtresds


Reindexing of blockchain using bitcoin qt v8.5 using 427% of Macbook CPU

When you're synchronizing from network, you're most likely limited by the rate of fetching blocks. When you're reindexing blocks that are already present on disk, only CPU is the bottleneck.

The algorithm to decide where and when to request blocks is relatively stupid, slow, and easy to confuse. This is why during synchronization from network, you rarely use all bandwidth available. This is being worked on, but it's not a simple problem, if you want to avoid many problematic edge cases. EDIT: bandwidth usage should be a lot better since Bitcoin Core v0.10.

When reindexing block on disk, the reference client will by default use all CPU cores available, to speed up the process. You can put par=1 in bitcoin.conf to restrict the validation operation to a single core. As of 0.9 (not yet released), you'll also be able to change this value in the GUI configuration.


A question about CTransaction::UpdateCoins() in 0.8.6

Looks for pcoinsTip->Flush(), which batch updates the underlying database CCoinsView.

It is not called for every update as that would require many writes. The way it is implemented now means many outputs can be added and marked spent entirely without needing to hit disk. The result is a disk database that is slightly out of data with the memory version, which means more work to redo when a node crashes, but this case is rare, and having faster block relay is more important.


bitcoind: incorrect rpcuser or rpcpassword (authorization failed)

Despite I run both bitcoind and bitcoin-cli as the same user, it for some reason fails to find my personal config file located in standard location:

$HOME/.bitcoin/bitcoin.conf

So I have set up an alias:

bitcoind -daemon -datadir=/raid1a/bitcoind/ -conf=/home/user/.bitcoin/bitcoin.conf

Case solved.


bitcoin-cli very slow to respond to RPC calls (Raspberry Pi)

I have the same set up and getinfo for me takes about 10-20s initially but then takes ~5s there after. (I need to restart the daemon periodically as it crashes for some reason). I'm running 0.11.1 and haven't made any special tweaks. gettxoutsetinfo takes around 12 minutes. CPU, RAM and Swap comparable with what you have as well.

Hardware is probably the most obvious limitation. You could overclock the Pi CPU but I doubt it will drastically reduce the response time though.


How does Bitcoin Core know it's on the longest chain?

First of all, finding the longest chain is not the goal, but the chain with the most accumulated proof-of-work [1]
Now, finding the most-work chain is the entire goal of the full node. The whole meaning of its existence is finding the most-work chain, and so you can pick almost any line out of the networking and validation modules of the code and explain it in those terms.
To be a bit more specific:

The full node connects to at least 8 peers. More recent versions connect to 2 extra peers in 'blocks only' mode. Peers are chosen to be as diverse as possible (by IP subnet or AS map). If a new block has not been added within a certain timeout (I think it's 40 minutes) Bitcoin Core adds one more outgoing peer.
The full node sends a getheaders request to each peer and keeps track of the best block each peer knows about.
If a peer has a valid block header with greater accumulated work than our current tip, we ask it for the corresponding blocks. If those blocks are valid, it becomes our new chain tip. A reorganization may or may not be necessary to get to that state.

If you understand conceptually how headers-first sync works, the function FindNextBlocksToDownload() is the next step. This is where the node decides if a peer has headers with greater work than its current chain tip, and requests those blocks from that peer.
So all we can do is connect to a lot of peers and assume that at least one of them knows about the most-work chain. This makes peer discovery and choosing which peers to connect to of critical importance.


What else can bitcoin inventory vectors be used for?

Inventory vectors are a collection of inventory items, the ones that are described to be either of type block, transaction or error. Inventory items of type transaction and block are references to actual block or tx messages being available for retrieval.
As such they are used in two places in the protocol:

The inv message to communicate the availability of the respective full message
The getdata message to ask for the full message

The inventory item is implicitly limited to 32 bytes in payload (hash) and a 4 byte type. Currently they are not used besides the original two hash types, but there were a few ideas flying around about getting inner Merkle-Tree nodes as a support for SPV clients to query the current state of the system.

Basically you can use anything you want in there, as long as you manage to stay inside the 32 byte + 4 byte limit, but preferably you'd keep the semantics of the hash + type being a reference to a retrievable item on the sender side.


best way to generate btc wallet with mnemonic phrase

You can click 'Generate' on this page (although I highly don't recommend using the online version, see below for more) to generate mnemonic phrases and use them. The site supports several languages, multiple currencies not just Bitcoin & more.
The site is also open source and I highly recommend using this offline than the online one for obvious security reasons: https://github.com/iancoleman/bip39


Slushpool Miner Hashrate always Lower than Local Hashrate

I believe that whatever is showing up on your dashboard is probably the most accurate picture of hashrate that you're contributing. Because you're mining to a pool, there will inherently be some, slight mismatch.

I wouldn't consider fluctuations a major issue unless it says you're producing far below the advertised hashrate.

I do know that Slushpool uses a "scoring hash rate," and if you want to know how that works in some more depth, here's a link to an article that Slushpool released. Hope this helps!

https://blog.slushpool.com/effective-hash-rate-af9c90529f6d


No, you can import your private key in another wallet software. Under the import/export option in Blockchain you can export the private key, and you'll be able to import elsewhere. It also works the other way around. If you create an address somewhere else, you can also import it on the blockchain website.

So no, you do not always have to check your wallet with blockchain.


Is there a PoW system that shows cumulative work without an ever-increasing proof size?

There's a suggested change to Bitcoin (adding skiplists to the header) that would make that quite possible. See Appendix B of Blockstream's sidechains paper,  Efficient SPV Proofs:

  The inspiration for compact SPV proofs is the skiplist [Pug90], a probabilistic
  data structure which provides log-complexity search without requiring rebalancing (which is good
  because an append-only structure such as a blockchain cannot be rebalanced).
  We require a change to Bitcoin so that rather than each blockheader committing only to the
  header before it, it commits to every one of its ancestors. These commitments can be stored
   in a Merkle tree for space efficiency: by including only a root hash in each block, we obtain a
  commitment to every element in the tree. Second, when extracting SPV proofs, provers are allowed
  to use these commitments to jump back to a block more than one link back in the chain, provided the
  work actually proven by the header exceeds the total target work proven by only following direct
  predecessor links. The result is a short DMMS which proves just as much work as the original
  blockchain.

  [...]

  Therefore if we want to skip the entire remaining chain in one jump, we expect to search only
  halfway; by the same argument we expect to skip this half after only a quarter, this quarter after
  only an eighth, and so on. The result is that the expected total proof length is logarithmic in the
  original length of the chain.
  For a million-block chain, the expected proof size for the entire chain is only log2(1000000) ≈ 20
  headers. This brings the DMMS size down into the tens-of-kilobytes range.

Also see Mark Friedenbach's Email on the bitcoin-dev mailing list concerning compact SPV proofs: http://sourceforge.net/p/bitcoin/mailman/message/32111357/


What does Bitcoin policy language offer the developer that Miniscript doesn't? What is the difference between Bitcoin policy language and Miniscript?

Both answers by James C. and sanket1729 are very good, but I wanted to give a very high-level answer:

Miniscript is an intermediate more structured representation for actual Bitcoin Scripts. It is useful as a toolbox because it simplifies static analysis of scripts, and things like generic signing.

The policy language is intended to simplify designing Scripts for humans.

The fact that Miniscript has a textual notation that looks similar to the policy language is probably confusing, but it is not primarily intended to be written by humans. The textual form exists to permit including Miniscript expressions inside output descriptors, and easily communicate them. To actually construct a Miniscript expressio  for a particular purpose, you'd generally use the policy language and compile it.


Integrating bitcoin with php to accept donations

https://en.bitcoin.it/wiki/PHP_developer_intro

This site shows all you need to get going. You'll need to run a dedicated bitcoind wallet on a server, which can accept JSON-RPC to call the various functions of bitcoind, which will respond back with a JSON object.


Can we experiment on Signet with multiple proposed soft forks whilst maintaining the ability of full nodes to validate the Signet chain?

The way Signet will likely address this is to have two classes of Signet full nodes. The first class of Signet full nodes will stay on a stable Signet version and only update once the proposed soft fork is activated on mainnet. The second class of Signet full nodes will run experimental Signet versions and as a result will need to update every time a new proposed soft fork is added or a change to an existing proposed soft fork is added. If they don't they risk being forked off the Signet chain. This is similar to full nodes needing to update immediately assuming there were regular hard forks.
As an example (credit to AJ Towns for this explanation), imagine there were three classes of full node.

Doesn't enforce Taproot at all
Enforces the current Taproot rules from block 800
Enforces a future new set of Taproot rules from block 2400 (assuming R tie breaker changes)

Class 1 is able to validate the entire chain by ignoring the new soft fork restrictions in the same way as pre-SegWit versions of Bitcoin Core on mainnet can treat SegWit spends as anyone-can-spend. Once the proposed soft fork is activated on mainnet these Signet full nodes can safely upgrade to what would likely be a new stable and non-experimental Signet version.
Class 2 though does start enforcing Taproot rules from block 800. When those Taproot rules change at block 2400 unless the Class 2 nodes update they will start rejecting transactions following the new Taproot rules as they won't recognize them. They will evaluate those transactions according to the old Taproot rules and they won't be valid Taproot spends according to those old rules.
Therefore Class 2 Signet full nodes will need to upgrade every time there is a new experimental Signet version. Obviously this isn't ideal but it seems a reasonable trade-off given that the whole purpose of Signet is experimentation and testing with no real value on the line. If you can't test things for fear of hard forking Signet it isn't providing the testbed and staging ground that is required before changes are considered for mainnet with hundreds of billions of dollars on the line.


If a transaction is not confirmed, your coins are still in your own "wallet". Money is transferred only when the transaction is confirmed and are part of the blockchain.


What happen if a popular channel hub turns dishonest?

What would happen when a large hub turns nefarious and change the transaction state dishonestly?

They can't do that. In order to change the channel state, both parties in the channel MUST sign the commitment transaction that does so. A hub is not some centralized node that has full power over all of their open channels. In order for any actions to occur in a payment channel, both parties must agree to it and sign the transactions.

  Since bitcoin fee is dynamic and blocksize is limited, what happen if the fee to settle a channel exceed the value of the channel itself? Wouldn't that mean a huge amount of fund would be deadlocked?

The fee rate paid in the commitment transactions are decided beforehand and locked into place before any transactions are made. If the fee rate were to change, then the parties in the channel can agree to increase the fee rate by using the update_fee message.


Where are transactions to be confirmed stored?

Full nodes keep a "mempool" of unconfirmed transactions, so yes, but every full node chooses its own rules for how many transactions it keeps in the mempool, e.g. minimum fee, maximum number of transactions, amount of time before the transactions drop out, etc. So not every full node keeps every unconfirmed transaction. If a node doesn't have a transaction in its mempool when a block is mined, it will just request that transaction.


Unconfirmed transaction: does the receiver know about it?

depends on the software. yes, the receiver is able to know this information


What is currently the fastest way to buy a large amount Bitcoin?

This might be your best bet... https://localbitcoins.com/


What happens if a transfer is made to a unused address from the keypool?

As long as the key is mathematically valid, which it will be, then it will be recognized.  The blockchain simply keeps track that someone sent coins to that address. It doesn't need to know anything else about it--the address isn't "registered" somewhere in advance Your wallet will contain the private key for that address which means that you will be the only one able to receive and spend the bitcoins which belong to that address.


Is there an easy way to give people a Bitcoin address?

Here are a few tips to help you distribute your addresses on a more readable form:

Firstbits.net shortens your address to (usually) less than 7 characters. To get the full address just enter the firstbits at the website (ex: http://firstbits.net/?a=1kk5k)
Use vanity generator to create a more customized address. You can try to create an address that has your name on it or any other word that you like. Bear in mind that this will still be a long address with many 'strange' characters (ex: 1stDownqyMHHqnDPRSfiZ5GXJ8Gk9dbjL)
If you use an e-wallet service, there are usually shortcodes that allow users to transfer bitcoins instantaneously between users. You can only use this if the other person uses the same e-wallet as you (ex: check Flexcoin, TradeHill or CampBX)
If you want to print your address into a business card, I suggest using QR Codes. They can easily be scanned with a smart phone.


How do mining-pools prevent work duplication?

No, there's not a need. The "work" generated by the pool includes the time, transactions, transaction order, and a completely unique coinbase. All of this information is hashed once with SHA256 and then sent to the client for them to do the POW calculation on. There is absolutely no chance of two pools creating the same work, and indeed pool software is designed to make work unique to each user. Protocols like GBT and Stratum also generate work items locally so the pool server is even less involved.


Why was transaction malleability fix required for Lightning network?

Alice creates a multisig transaction sending 100btc to a shared Alice-Bob output–one that requires both signatures–and signs it. We’ll call this transaction Tx0. And she only reveals Tx0 to Bob after:

Alice and Bob each sign a timelocked transaction for 30 days from now, sending 100btc back to Alice. This is not committed to the blockchain, and opens a “channel” between them.

Uncommitted transaction has dependency over Tx0. After Alice reveals Tx0 to Bob, if Bob successfully changes the transaction hash for Tx0 on blockchain, then uncommitted transaction will become invalid and Alice will not be able to claim 100btc back.

If, in addition to requiring the refund Tx, Alice also requires Bob to sign Tx0 before she does so that only she can submit Tx0 to the blockchain, this attack would not work.


You're correct that anybody could just replace the outputs and take the funds for themselves.  This script has no authorization needed on the spender's part, so once the redeemscript is known, it's practically become an anyone-can-spend script.

Assigning an RBF enabled sequence (or not) on the transaction makes no difference (perhaps only for relay policy), since any sequence set can also be replaced by anybody.


The statements are not on the stack, they're in the script. They start immediately after the OP_IF. They end at the first OP_ELSE or OP_ENDIF, assuming there isn't a nested OP_IF or OP_NOTIF. So it looks like this

// script to put a number on the stack
OP_IF
// script that runs only if the number isn't zero
OP_ENDIF
// script that runs no matter what

or:

// script to put a number on the stack
OP_IF
// script that runs only if the number isn't zero
OP_ELSE
// script that runs only if the number is zero
OP_ENDIF
// script that runs no matter what

You can read a bit more about in this chat transcript.


How does Bitcoin figure out what time it is?

It takes the median time of the other clients connected, but only
 1. if there are at least 5, and
 2. if the median time does not differ from system time by more than 70 minutes.

For specifics, we look at AddTimeData, in timedata.cpp.

Note: I have edited it down for length

void AddTimeData(const CNetAddr& ip, int64 nTime)
{
    int64 nOffsetSample = nTime - GetTime();
    // Add data
    vTimeOffsets.input(nOffsetSample);
    if (vTimeOffsets.size() >= 5 && vTimeOffsets.size() % 2 == 1)
    {
        int64 nMedian = vTimeOffsets.median();
        // Only let other nodes change our time by so much
        if (abs64(nMedian) < 70 * 60)
        {
            nTimeOffset = nMedian;
        }
        else
        {
            nTimeOffset = 0;
        }
    }
}


How does the architecture prevent someone taking over by running a several billion clients?

The majority needs to be trusted, but not weighted by their number of software instances, but by either computational power or economic power, depending on the context.

The main technical assumption is that the majority of hashrate is not trying to attack the network. So an attacker would need to purchase and operate more hashrate than the rest of the network combined; this isn't easy.


How does the node system understand which ledger is the latest before updating their own ledger?

How does a new user realizes which is the correct copy of the ledger to be used when initially updating(downloading) the ledger

They find the highest-work valid blockchain. This is not the same thing as the most popular blockchain - if 999 nodes tell your node they're on a chain, but one node tells you about a longer chain, you will prefer the longer chain.

If you do not see the longer chain at least once, you will not switch to it. However, even if you start mining on the shorter chain, you will switch to a longer chain after it appears.

  How does one understand if the two ledgers are the same?

You compare the block hash of the chain tip. If they are equal, both nodes have identical blockchains. If they are not equal, the nodes have different blockchains.


C# How to determine if a bitcoin address was generated by a BIP32 pub key?

There is no such algorithm.

You need to know the path.


How can I validate that an XRP address is valid?

Ripple addresses, like Bitcoin and most other currencies, are Base58Check encoded. As long as an address validates against the base58check algo, it is a valid address on the ripple network.

Do note that it is possible to generate valid addresses without knowing their corresponding private key. You should take steps to ensure you have the private key for an address before sending funds to it.


What would happen if two blocks had the same hash?

Blocks are identified by their hash.

This means that in your story, in Jan 2017, when B gets broadcast, any node that it is advertized to will think "I already have this block", and ignore it.

However, when we consider block hash collisions to be a realistic situation, there is another issue that may arise:

If two blocks with the same hash and the same parent are produced ~simultaneously, one of which is valid, and the other is invalid (but does have valid proof of work), some nodes in the network will see one first, and others will see the other first. Those who see the invalid version first will mark the block as permanently invalid, and they won't bother even trying to learn about the valid one when another block builds on top. This would lead to a permanent chain fork between the nodes who saw the invalid block first and those who saw the valid one first.


Send addresses in Bitcoin Wallet for Android

There is no option in Bitcoin to control which address transactions are sent "from". The Bitcoin client will use one (or more) of your addresses which have previously been sent sufficient funds to cover your new transaction.

To make this clearer, consider an example. Somebody (person A) sends you (person Y) some coins.

A -> Y1 [2 coins]

Now somebody else sends you more coins:

B -> Y2 [3 coins]

Suppose you want to pay person B 4 coins. What happens is your Bitcoin client will create a transaction with the following three parts:

Y1 -> B [2 coins]
Y2 -> B [2 coins]
Y2 -> Y3 [1 coin]

Since you must always spend the entire amount allocated to an address, your client arranges the transactions so the 3 coins of Y2 are fully spent. Y3 is a new address created by your client for the change, which comes back to you and remains in your wallet.

If you then spend your remaining 1 coin to person C, your client will create

Y3 -> C [1 coin]

The address Y3 was created internally by your client and you don't have an option to choose what it is.

For more information, see:

How does change work in a bitcoin transaction?
Why do outputs need to be spent entirely?


How often does peercoin minting pay out?

Minting is random. There is no guarantee that you will get 1% in a year, you could get 0% or 75%. You will get them when you successfully mint a block.


How can I find out the address my payment will come from?

There is a patch for the client available to let you choose specifically which addresses to use when spending.
 - http://github.com/bitcoin/bitcoin/pull/415


How much energy will the Bitcoin network eventually consume?

The upper boundary for energy usage can be described with a function of the profit and energy costs. Miners won't ever pay more for energy than they get from profits. The actual energy usage formula will also have to count for the hardware costs.

The formula will look something like this :

max energy usage = (profit - hardware costs) / energy cost per unit
profit = exchange rate * generated btc
generated btc = transaction fees + block creation bonus

As you can see, the energy usage depends on the following factors:

Energy cost per unit (kWh)
Hardware costs
Block creation bonus (currently 25, some day 0)
Transaction fees (currently hardly relevant, some day very important)
Exchange rate

And, of course :

How much money the miners want to keep
Taxes?

[edit]

$10,000 a coin times 52560 (blocks per year) times 25 (coins per block) gives $13,140,000,000 mined USD a year. Yes, that's thirteen billion USD in mining profits. If we divide this by $0.20 per kWh, then the upper boundary for energy use will be 52,560,000,000 kWh (52 TWh), roughly 2/1000 of the total energy consumption of the USA. Of course, if we assume that 90% of the money goes to hardware and not energy, the actual energy usage will be more like 5TWh. (Link to the calculation)


How to enable wallet encryption from the command line?

The command is: bitcoin-cli encryptwallet mypassphrase.

The list with all commands exposed through bitcoind's RPC API can be found here: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list or can be fetched with the command: bitcoin-cli help.

It's worth noting that the encryptwallet command will not show up in bitcoin-cli help's results once your wallet is encrypted, instead you will get three new commands: walletlock,
walletpassphrase and walletpassphrasechange.


Which KYC solution providers are used by Bitcoin companies?

Jumio is used by a few companies, including SnapSwap, CoinMKT, etc. Their notable products include NetVerify and BISON.
miiCard is used by Bylls and Bittylicious.
Sphonic is used by Bitnet.


Are P2PKH or P2SH transactions malleable?

Yes. Many of the malleability sources listed in BIP 62 still exist today. Most (if not all) are not standard, i.e. most nodes will not relay transactions that exploit them, but they are not consensus rules. So a miner can still perform malleability attacks.


Split BCH out of BTC and then BSV out of BCH?

All fork coins are tied to same private key. Simply import your private key to a multi-currency wallet like Exodus. This will unlock funds from all chains in one place.


The market decides. If people can obtain the coin easily themselves then they will mine it rather than buying it on an exchange.

But the coin needs a use, function, purpose or reason for people to have the coin.

Basic supply and demand. If people do not buy the coin at a high price then the price gets lowered to see where people might consider buying it.

Crypto coins generators realized this and tried to tweak the parameters on the coins so that rewards are high at the start, a fast rising difficulty make the coin look rare and highly sought after, in reality the coin has just been pumped ready to dump


How to change the wallet on the fly with bitcoin-qt

First thing: encrypt that Dedicated server's entire hard drive.
Secondly: encrypt that wallet.dat file
Thirdly: use EVERY possible method of attack defense you can. Use googleauth for 2 step log in. disable root access. If you must run SSH, run it under a random port. NOT port 22. use tripwire mod_sec/mod_evasive, if you think it might be good... add it. use UFW firewall. Use insane settings. If you only plan to sell to one country: block ALL IP's that are not within that country
Disable ALL error notifications and disable any information that may allow the attacker to gain any information about what the server is run on (no "this server run on apache centos" etc). I do assume you do know this, but im just giving fair warning.
Host as few applications beyond the bare minimum. (so no minecraft servers).
I personally recommend not keeping funds in a hot wallet because ~/.bitcoin/wallet.dat is the most searched for thing by hackers

Now... How can you have two different wallets on the same machine? well. there's a few ways to do it... If you want to keep generating infinite new addresses (using infinite seeds) all the time and have a good contingency plan in place for your wallet.dat file (like hourly back up etc), you could run 2 instances of bitcoind. (commandline version is what you want for this) Two instances can be run by changing the listening ports on one of the two bitcoind instances and running each instance on its own user account. you can then (depending on which user you are paying to) have php connect to the respective bitcoin client and request an address for payment.
Another idea i would propose could be using one bitcoin client and having accounts. If you are okay sharing one wallet and one daemon, but need your own account for accounting balances, its a breeze

Side note
there are a few projects that actually are pretty good. I started writing a basic bitcoin escrow system based off of my own coding and using  "The Bitcoin Shopping Cart Interface package" and "The Bitcoin Shopping Cart Interface package"

http://sourceforge.net/projects/bitscrow/
I use to have a much more advance version i built for FreiCoin but the wonderful people over at FDCServers destroyed my development server on me (thanks guys). So I am pretty far behind again. However you should at least have an idea of maybe a general direction to start
This version requires no  bitcoind at all which is pretty unique. But if you want a wallet, then you may need to integrate that yourself.

you could also consider installing drupal and modifying the source to have a two different plug ins going to the two different daemons.

there are many options.
you can even start from scratch, good documentation is available here.
https://en.bitcoin.it/wiki/PHP_developer_intro

Please let me know if this was useful or not, and let me know if there is further clarification needed. If you want to truly have your own page it's a lot of work...

Also, check out https://github.com/Bit-Wasp/BitWasp

I have been playing around with it and its been pretty cool so far.

thanks for giving me the information i needed to try and respond as best i can


Creating Base58 public key & private key in Java?

com.google.bitcoin.core.ECKey key = new com.google.bitcoin.core.ECKey(); // keypair
byte[] pub = key.getPublicKey(); // byte array

String prv;
prv = key.getPrivateKeyEncoded(com.google.bitcoin.core.NetworkParameters.prodNet());


Yes, Bitcoin Core can and will change the blk*.dat files, which, as has been told to you many times before, can be different for all nodes. Once Bitcoin Core has validated a block, it updates its chainstate database so that it knows what its current blockchain tip is. It also updates that database with the most recent UTXO set. So once this is done, the block can be thrown away as we have now recorded that we validated it. This is what pruning does; it throws away old blocks that we have already validated. Having the correct chainstate (UTXO set and blockchain tip) is all that matters.


Multi-signature and "pay to script hash" vs "pay to pub key hash"

Sorry, my English is poor, I'll try to explain. Feel free to comment and ask.

First, terminology. There are no "pay to pub key hash msig txs". There are

bare multisig outputs
p2sh outputs

In bare multisig output i create a list on [N] pubkeys and choose [M]. The output script will look like [push M] [push key1] [push key2]... [push keyN] [push N] [checkmultisig]

Every person can check this set. If he has [M] keys he will be able to redeem this output. If he has less than [M] keys he will be able to partially sign the redeem transaction and pass it to another person (this passing step can not be done within bitcoin network, because nodes do not relay partially signed transactions). When the transaction gains at least [M] signatures it can be mined. Have a look to https://gist.github.com/gavinandresen/3966071

p2sh gives more functionality. I can write my own redeem script and calculate its checksum. To redeem p2sh output you should know the script itself (blockchain contains only the hash of it) and you should create scriptSig for it. Usually p2sh outputs used for multisig transactions, but there are exceptions. https://bitcointalk.org/index.php?topic=293382.0

Update:
One more useful link: What are multi-signature transactions?


Can someone post an explanation of how to get the input/output addresses?

in general: I have added a sample tx, which explains the details:

VERSION
 01000000
TX_IN COUNT [var_int]: hex=02, decimal=2
 TX_IN[0]
  TX_IN[0] OutPoint hash (char[32])
  BC8361DEC060BFE1D481BDA60B3127524B8FF65F307221DE105E9DDB3F3B6053

--> this is the previous tx, which contains funds to move

  TX_IN[0] OutPoint index (uint32_t)
  hex=01000000, reversed=00000001, decimal=1
  TX_IN[0] Script Length (var_int)
  hex=6A, decimal=106
  TX_IN[0] Script Sig (uchar[])
  4730440220128487F04A591C43D7A6556FFF9158999B46D6119C1A4D4CF1F5D0AC1DD57A94022061556761E9E1B1E656C0A70AA7B3E83454CD61662DF61EBDC31E43196B5E0C10012102B12126A716CE7BBB84703BCFBF0AFA80283C75A7304A48CD311A5027EFD906C2

--> this script has the signature, and the following public key (starting with 02B12126...) - this is where the funds were signed with, and would be the source address (you would need to convert the pub key first to the bitcoin address - see references in my comments)

  TX_IN[0] Sequence (uint32_t)
  FFFFFFFF

--> and here follows a second input, from which this transaction moves funds... same rules as before.

 TX_IN[1]
  TX_IN[1] OutPoint hash (char[32])
  A75B4B6369ABC4A5F0A95FF714460BFA33802A2C422FD06D7B28771570C4520E
  TX_IN[1] OutPoint index (uint32_t)
  hex=00000000, reversed=00000000, decimal=0
  TX_IN[1] Script Length (var_int)
  hex=6B, decimal=107
  TX_IN[1] Script Sig (uchar[])
  483045022100A428348FF55B2B59BC55DDACB1A00F4ECDABE282707BA5185D39FE9CDF05D7F0022074232DAE76965B6311CEA2D9E5708A0F137F4EA2B0E36D0818450C67C9BA259D0121025F95E8A33556E9D7311FA748E9434B333A4ECFB590C773480A196DEAB0DEDEE1
  TX_IN[1] Sequence (uint32_t)
  FFFFFFFF

and here follow the outputs...

TX_OUT COUNT, hex=02, decimal=2
 TX_OUT[0]
  TX_OUT[0] Value (uint64_t)
  hex=9025730000000000, reversed_hex=0000000000732590, dec=7546256, bitcoin=0.07546256
  TX_OUT[0] PK_Script Length (var_int)
  hex=19, dec=25
  TX_OUT[0] pk_script (uchar[])
  76A914FCA68658B537382E27A85522D292E1AD9543FE0488AC

--> this pk_script defines the conditions, under which the funds can be spend. It is encoded in bitcoin's script language, and would finally translate to an address: 1Q2tmgphDqFJxhFFYNrjBr5o8XKSSDKtXv

 TX_OUT[1]
  TX_OUT[1] Value (uint64_t)
  hex=9838110000000000, reversed_hex=0000000000113898, dec=1128600, bitcoin=0.01128600
  TX_OUT[1] PK_Script Length (var_int)
  hex=19, dec=25
  TX_OUT[1] pk_script (uchar[])
  76A9146AF1D17462C6146A8A61217E8648903ACD3335F188AC

and this is a second script (usually a return address), which translates here to: 1AkUKA3NNQt4gs3GGexhacnkSMcmYHsN3S

 LOCK_TIME
00000000

Hope this helps, as mentioned before, Ken Shirrifs link is probably best to quickly follow.


How to import address to a wallet which runs in pruned mode

Form bitcoin-abc I have found this

# Enable pruning to reduce storage requirements by deleting old blocks.
# This mode is incompatible with -txindex and -rescan.
# 0 = default (no pruning).
# 1 = allows manual pruning via RPC.
# >=550 = target to stay under in MiB.
#prune=550

So, the command import address should call the -rescan (in Bitcoin core yes), for reconstruct the story of the private key.
So from the moment of your error message, I believe the correct answer is.

No you cannot import a private key in prune mode


If Bitcoin is not stolen from an address for some months does it suggest that malware did not capture the key?

It is a fallacy of the alternative disjunct to assume that your private key is in fact private, just because a potential other party has not used it: The two events "somebody has gained access to my private key" and "nobody has used my private key" are not disjunct.

If you are uncertain whether your private key has been compromised, you should move your bitcoins to a securely created new address.


How are transactions verified with only the Bitcoin address, not the public key?

When you spend from a Bitcoin address, your transaction includes both the public key corresponding to the hashed address you're trying to spend from, as well as a signature that can be verified with that public key.
Your link is to a block, which is not signed itself. However, let's look at a transaction from your block: https://www.blockchain.com/btc/tx/b8f925d09c647904e428d902c8404fc91e5dbe53773b82d717cf13374785ca20
Scroll down to 'inputs', and under Sigscript, 3045022100c89735ddbb5e231044610590c086d41f1e871067987087ed48e041f8999314830220011deba08ad9a67ddafe51dc530f3f60c8974373bf2f25953a89c139d238216201 is the ECDSA signature, and 023aa5b3f24a2b8fc8f64b69ba383b148892deef94cf060288cc99e81be0f9722e is the public key corresponding to the address.


Can I use single address for all my transactions?

If you are to receive a transaction with address A, you need A's private key in order to spend it and nothing more.

If you want to require two or more addresses to be used to spend money you receive, you would need to use a multisig address. After that, you would need to use m-of-n private keys to spend the coins, with m and n being predefined when you create the multisig address.

There are other ways one could restrict coins from being spent - say requiring a password or allowing anyone to spend them, but they are a lot more obscure and generally not used by anyone.


Are sellers more vulnerable to fraud than buyers when doing business?

My interpretation is more that, since sellers are the ones receiving money, they are the ones who stand to be protected by an improved and non-reversible payment system.  I don't think Satoshi particularly thought that protecting buyers (who are receiving goods) was less important or that they were less vulnerable, but that it simply wasn't within the scope of the problem he was trying to solve.  He thought that "routine escrow mechanisms" were already appropriate to the task, and in a decentralized currency, these mechanisms can be decoupled from the payment transfer system.


Is there any way l can recover the funds

No.

No key No bitcoin

To recover control over funds associated with an address, you need the seed-phrase (AKA recovery phrase) or private-keys.

An address imported into a wallet allows you to see money belonging to someone else (or to another wallet of yours, perhaps an offline wallet). It does not give you control over that money and there is no way to get control if you only have the address.

Custodial wallets

Some wallets are called custodial wallets (though not by the wallet providers) and are more like an account with a business that looks after your money for you and issues you with a kind of IOU. The business is the actual owner of the money. For this kind of wallet you should contact the money owner (the business).

Some businesses of this sort offer both custodial wallets and normal non-custodial wallets. Blockchain.com might be one of these. In that case what to do next depends a lot on exactly what sort of wallet you have.

Scams

Imported addresses are a favourite trick of scammers. If someone else helped you create your wallet, you may have been a victim.


In Mac OS X 10.7, Apple wants you to use their own crypto library instead of OpenSSL. This is pretty unlikely to ever be done by the bitcoin devs, so here's how to turn the warning off:

Edit your ./configure file, and add this to CXX_FLAGS

-Wno-deprecated-declarations

I don't actually own a mac; could someone try this and see if I got something wrong?


Can a brainwallet passphrase be derived if an attacker has obtained the private keys of an empty wallet.dat file?

Sorry to hear you were robbed.

An attacker cannot reverse engineer a private key to obtain the original mnemonic phrase.

What essentially happens is just another multitude of hashes with an algorithm (SHA256). Different approaches to this are taken by different deterministic wallet generators.

As SHA256 is considered secure. So is your mnemonic phrase


How do we talk to bitcoind in a PHP plugin?

First, run bitcoind on your server. Set up bitcoin.conf to have the correct RPC port and a password and etc.

Then, include the jsonRPCClient.php file:

include('jsonRPCClient.php');

Then, instantiate an object like so:

$bitcoind = new jsonRPCClient("http://$YOUR_RPC_USER:$YOUR_RPC_PASS@$YOUR_RPC_HOST:$YOUR_RPC_PORT/");

You can now run commands from the RPC using this object.

$bitcoind->getnetworkhashps();
$bitcoind->getrawtransaction($txid);

So if you want a new address:

$newaddr = $bitcoind->getnewaddress();


does Lightning Network can work and solve Bitcoin scalability problem?

as far as predictions into the future can be right or wrong, only future will tell!
When it comes to the author of the article, he is a deep proponent of the idea, that lightning is a bad thing for the future of bitcoin. You can read alot more about his position and corresponding posts on bitcointalk.

There are two things that get repeated over and over again (mostly by proponents of the bcash world): bitcoin cannot scale with lightning, and lightning is centralized ("banking hubs").

The current reality looks a lot different: there are more than 2500 nodes and more than 6000 channels open, and for a beta phase software for micro payments I think this is a huge success. I am convinced it can help to solve bitcoin scaling issues. For sure! It might not solve everything, but there are others activities next to lightning, and that's good. But look, this is only my personal opinion.

Hence I propose to close the question, as it is mostly opinion based, and only time will tell, what becomes true.


Accept payments on someone else's behalf without being able to spend them

This is entirely possible with an optional additon to Bitcoin called BIP32. Unfortunately, BIP32 is not implemented by the standard client, but there are other clients that do implement it.

Ask your customer to download the latest version of Electrum, then have them give you their extended public key.

(As I said above, there are multiple clients that can do this, I'm just most familiar with Electrum.)
Include this code in your BitcoinJ application:

String serialized_xpub = "xpub.....";
unsigned int address_num = 4;
NetworkParameters params = MainNetParams.get();
DeterministicKey root_xpub = DeterministicKey.deserializeB58(null, serialized_xpub, params);

// Derive m/0/<n>, Electrum's BIP32 path
DeterministicKey receiving = HDKeyDerivation.deriveChildKey(root_xpub, new ChildNumber(0, false));
DeterministicKey new_address_key = HDKeyDerivation.deriveChildKey(receiving, new ChildNumber(address_num, false));
String new_address = new_address_key.toAddress().toString();

You will generate the same address as long as you use the same xpub and address_num. Make sure that you don't skip five or more addresses, though. If you do end up doing this, then your customer can generate addresses until they see the new payments.

Also, note that you don't have the private key for this address. If your customer loses their wallet, those coins are gone.
Put that address on the invoice.
The money will show up in their wallet.

Best of luck with your application!


Are there scientific studies related to the Bitcoin technology?

Bitcoin is a relatively new phenomenon and the peer-review process takes a while, so there is not much out there yet.

The most notable is a network analysis of bitcoin transactions done around the alleged "allinvain" theft earlier this year.

http://arxiv.org/abs/1107.4524

Other than that, there are currently a few articles published in academic journals that focus on bitcoin (as well as pop-sci and pop-compsci articles in various places)

For example

Grinberg, Reuben, Bitcoin: An Innovative Alternative Digital Currency (April 21, 2011). Available at SSRN: http://ssrn.com/abstract=1817857

The best answer may be to do this in the form of a community wiki where articles published in academic journals can be posted by subject, as if bitcoin survives it will obviously start to receive a lot of attention.


Transfer BTC between two wallet in two different devices?

It might be possible to export the private keys from your PC wallet and import them into your tablet's wallet. The details and practicality of this would depend on which wallet software you are using at each end.

It would certainly be easier just to create an address on the tablet and send all the coins there. You may have to pay a transaction fee (most people don't call it "commission") but it's not likely to be more than a few pennies.


Blockchain.info - How to reply to a sender in a callback?

You would need to fetch the transaction using the /rawtx call and use one of those inputs.

However you should not send a refund back to the the sending address unless the user has specifically told this is what will happen as shared wallets cannot receive coins back to the sending address.


Why was an insecure merkle tree implementation chosen?

As with many things in Bitcoin, it is likely simply because it worked well enough, and such an attack was not immediately obvious.

Several of the choices made in the early days of Bitcoin don't have a full justification behind them, and were simply made because it worked at the time without any major, obvious shortcomings. This is one such scenario, as far as I'm aware.


Why is the Block Header txn_count field always zero?

The headers message is sent in response to a getheaders message.

The txn_count is always 0 simply to make the parsing of this packet compatible with the parsing of the block message.

getheaders is designed to be used by a simplified client, however since there is no way to get partial merkle branches using the standard protocol this cannot actually be done.


Can attackers change transactions during a 51% attack?

No. A 51% attack cannot modify transactions or those transactions become invalid. Blocks do not dictate whether a transaction is valid. Transactions have their own validity rules and if a block includes an invalid transaction, then that block is invalid, regardless of the Proof of Work.

Changing a transaction's details as you suggest requires producing a new signature. Only the original creator of that transaction can do that. So attackers cannot just arbitrarily change people's transactions as they do not have the private keys necessary to create those signatures. Thus any modifications they make will result in invalid transactions.

All that an attacker could do is remove transactions from history and insert their own transactions. They could only replace their own transactions. The danger of a 51% attack is that the attackers can replace their own transactions paying someone else with a double spending transaction that pays themselves thereby undoing a transaction.


Undo files format change and reorg process question for v0.19

NOTES:
Heigh and Version fields
Fields height and version are needed to identify Outputs if they are last spent in the Transaction outputs. In older revxx.dat files, only if Output was last unspent in a Transaction it's height will be there together with it’s Transaction’s Version. If it's a regular Output then the height field will be 0 (00 HEX in Varint format ) and there will be no Version field
In newer revxx.dat files height is written for every Output and the Version field is 0 (00 in HEX) to be backward compatible. I did not check the revxx.dat files myself if it’s so, so please test this note first.
Calculation of Height from the Field Value:
To compress the Amount of Statoshis this field uses the following logic:
If the amount is 0, output 0
First, divide the amount (in base units) by the largest power of 10 possible; call the exponent e (e is max 9)
if e < 9, the last digit of the resulting number cannot be 0; store it as d, and drop it (divide by 10)
call the result n
output 1 + 10*(9n + d - 1) + e
if e==9, we only know the resulting number is not zero, so output 1 + 10(n - 1) + 9
(this is decodable, as d is in [1-9] and e is in [0-9])
Then store it as a VARINT
nValue field(Amount)
To compress the Amount of Statoshis this field uses the following logic:
If the amount is 0, output 0
First, divide the amount (in base units) by the largest power of 10 possible; call the exponent e (e is max 9)
if e < 9, the last digit of the resulting number cannot be 0; store it as d, and drop it (divide by 10)
call the result n
output 1 + 10*(9*n + d - 1) + e
if e==9, we only know the resulting number is not zero, so output 1 + 10*(n - 1) + 9
(this is decodable, as d is in [1-9] and e is in [0-9])
Then store it as a VARINT
Calculation of nValue field(Amount):
To decode this amount go through the operation backward:
First, decode it from VARINT. Then use the following procedure(taken directly from the Bitcoin core implementation):
uint64_t DecompressAmount(uint64_t x)
{
    // x = 0 OR x = 1+10\*(9\*n + d - 1) + e OR x = 1+10\*(n - 1) + 9
    if (x == 0)
        return 0;
    x--;
    // x = 10\*(9\*n + d - 1) + e
    int e = x % 10;
    x /= 10;
    uint64_t n = 0;
    if (e < 9) {
        // x = 9\*n + d - 1
        int d = (x % 9) + 1;
        x /= 9;
        // x = n
        n = x\*10 + d;
    } else {
        n = x+1;
    }
    while (e) {
        n \*= 10;
        e--;
    }
    return n;
}

ScriptPubKey size and SriptPubKey fields
Current Bitcoin serialization is using a compressed format to store common types of scripts:

Pay to Pubkey Hash (P2PKH) is encoded to – 20 bytes
Pay to Script Hash (P2SH) is encoded to – 20 bytes
Pay to Pubkey (P2PK) is encoded to – 32 bytes

Other script types are serialized using the general rule shown in the table:

scriptPubKey size
scriptPubKey data

Where script size is a VARINT field of len(scriptPubKey data) + number of special cases, where the number of special cases is int(6), then goes the regular scriptPubKey data.
The compression algorithm is removing all OP_CODE values from the common types of scripts and leaves only the Key, KeyHash, or ScriptHash intact. Then it is using the  field to indicate the type of script in the next field.

P2Pk cases: 0x02, 0x03 identify compressed Public Key and show how which Y coordinate to use to reconstruct the full key. 0x04, 0x05 identify uncompressed Public Key, but the value in the  is still in a compressed format and, and the size value shows which Y coordinate to use.
For other script types be sure to keep in mind that  is VARINT(len(scriptPubKey size) + int(6))
A small addition to the script compression, while you be looking through the Bitcoin core compress.cpp/.h files you may find that during compression either 20 bytes or 33/65 bytes are being manipulated that are not identified as any opcodes.
That's because of in bitcoin scripting if a field(4-bit hex value) is smaller than OP_PUSHDATA1 = 0x4c=76 is interpreted as an instruction to push the following number of bytes (the exact value of this field) onto the stack – this is called an immediate push.
As I'm not that good in modern C++, it was much easier for me to follow the compression algorithm when it was done in Golang:
https://github.com/btcsuite/btcd/blob/master/blockchain/compress.go
and in VarInt logic in Python:
https://github.com/christianb93/bitcoin/blob/1241778dc51bd39022611916f90f1bfaf07ee331/btc/serialize.py#L54
Greg did a really really nice explanation of Var Int, that I found so easy to follow. Thank you.
https://learnmeabitcoin.com/guide/varint
Yes, everything is in the code of original BitcoinCore implementation, I think maintainers and developers are doing an epic job to keep it nice and clear. It's because I was lacking some C++ skills I could not understand it properly from the beginning and had to spend some time on it. I just hope my notes will help someone to speed their learning process. Good luck.


testnet3 is deprecated.  The development version is now on testnet4 and it appears this will be in the v0.14 release.

https://github.com/litecoin-project/litecoin/pull/285


I'm not sure about Nbitcoin node's API, but I could help you on a blockchain explorer API.

I would recommend Blockr.io, they are fast and trustable. Use the following code to check for confirmed transactions: (output is in json)

http://btc.blockr.io/api/v1/address/balance/198aMn6ZYAczwrE5NvNTUMyJ5qkfy4g3Hi,1L8meqhMTRpxasdGt8DHSJfscxgHHzvPgk?confirmations=1

Change the confirmations tag to whatever amount you want. I highly advise against 0.


How to convert a transaction into hex before using the sendrawtransaction API?

You cannot convert json string to hex representation. Transactions have their own binary format (you can read in wiki: https://en.bitcoin.it/wiki/Transactions). To create transaction in hex format, you can use bitcoin-qt (or bitcoind) function createrawtransaction. Example of using:

createrawtransaction
'[
    { "txid": "10d5b7f61be2fa2e5979043a7071d3dbd371bc72cefea22e43b2dd54a6e27a99", "vout": 1 }
]'
'{
    "14rbFswzZfkPGkbFZ7Ffj2qhQA1omvgiUx": 0.099
}'

This call will return raw transaction in hex:

0100000001997ae2a654ddb2432ea2fece72bc71d3dbd371703a0479592efae21bf6b7d5100100000000ffffffff01e00f9700000000001976a9142a495afa8b8147ec2f01713b18693cb0a85743b288ac00000000

After that, you must call signrawtransaction:

signrawtransaction 0100000001997ae2a654ddb2432ea2fece72bc71d3dbd371703a0479592efae21bf6b7d5100100000000ffffffff01e00f9700000000001976a9142a495afa8b8147ec2f01713b18693cb0a85743b288ac00000000

This call will return raw transaction in hex, which you can send to network using sendrawtransaction.

Note: be very careful, you can make mistake in amount, and lose your bitcoins.


How does the computational cost of verifying transactions scale with the number of total transactions?

As more transactions are added to the block chain, does each individual transaction (ie. I send a bitcoin to a friend) get more expensive (in terms of FLOPS) to verify and commit to the chain?

No, it does not get more expensive in terms of anything. It especially does not get more expensive in terms of FLOPS because there are no floating point operations in Bitcoin.

The only cost of verifying a transaction is that it may cause the UTXO set as a whole to become larger, and as the UTXO set becomes larger, it becomes slightly harder to pull the necessary information from it to verify transactions. It does become harder to sync the blockchain as the UTXO set grows. Otherwise there is no compounding cost of verifying transactions as more transactions are added to the blockchain.


Bitcoin rig setup, connecting a Butterfly Labs unit using USB

I don't think it will make a difference.  If you are using the Anker 10-port "power bar" style USB hub (that's what it sounds like you have, based on your description of it + the fact that this hub is very commonly used with USB bitcoin miners), that is a pretty robust hub.  One of my mining rigs (which doubles as my media center) has 8 block erupters + USB fan + an external USB hard drive on it, and all devices function without any difficulty.


I'm not sure what simplified variant you're referring to, but this is a great question.

There are a number of reasons.

First, RFC6979 is not cheap and fairly complex. Computing a single candidate nonce costs 22 invocations of the SHA256 compression function. Hashes are fast, but this actually corresponds to hashing 1400 bytes which isn't trivial anymore compared to the time of signing. It serves a purpose - it's instantiating a well-knowing PRNG to generate the candidate nonces - but this is overkill for us. secp256k1 has the interesting property that its group order is negligibly close to 2256. So instead no PRNG is needed at all - a single hash suffices, which is lower complexity, and obviously constant time as well.

A simpler alternative is the one used by Ed25519, where a single SHA512 invocation generates a 512-bit number that is reduced modulo the curve order. Our construction is different, but is inspired by this. There are some changes though:

We don't need a 512-bit hash and a modulo reduction, again because the curve order is close to 2256, so we can use a 256-bit hash directly without reduction instead.
We're concerned about implementations where the public key of the signer is taken from untrusted input (something most signing APIs don't seem to protect against, as it's a performance penalty to recreate the public key from the private key instead). Greg Maxwell started a discussion on this cryptography mailing list about this problem: https://moderncrypto.org/mail-archive/curves/2020/001012.html, which received comments from DJB and others. We address this issue by including the public key into the nonce generation.
We're trying to protect against fault attacks and differential power analysis attacks by encouraging synthetic nonces (which incorporate actual randomness when it is available). RFC6979 also has a variant that supports this, but it appears that due to our use of linearly derived private keys (through BIP32, and through Taproot), DPA attacks are much harder to protect against, and standard solutions may not apply. See the bitcoin-dev mailinglist discussion here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-March/017711.html (where I agreed with OP that some of our design choices are not well explained in the BIP yet)


How to find if two transactions in mempool are conflicting?

Firstly, there is no "the mempool". There is no global mempool. Rather each node maintains its own mempool and accepts and rejects transaction to that mempool using their own internal policies. Most nodes have the same policies, but due to different start times, relay delays, and other factors, not every node has the same mempool, although they may be very similar.
When it comes to doublespends, the typical node policy is that if a transaction conflicts with another transaction, it will not be accepted by that node, thus the conflicting transaction doesn't enter that node's mempool. So unless you modify your node to accept conflicts, your node's mempool will never contain conflicting transactions.


Bitcoind only scrapes the blockchain for a few transaction types: Pay-to-pubkey, pay-to-pubkey-hash, and pay-to-script-hash. If you check https://en.bitcoin.it/wiki/Script you'll see many more script operators that can be used, so the protocol isn't just those three script types.

Since the scripts have a very definite form, your client will look for the cases where the payments are to address YOU own instead of others.

OP_DUP OP_HASH160 <20 byte hash> OP_EQUALVERIFY OP_CHECKSIG

If bitcoins were sent to this script but with other script operations at the end, your node wouldn't report them as spendable.

Verifying this yourself is easy if you already have a working and completely correct script interpreter. You could look for non-standard outputs, since they do get mined on occasion.

However, reproducing bitcoind's script interpreter, with bug-for-bug compatibility is tricky. Certain clients have been forked from the blockchain by not following every quirk in the reference implementation.

But if you have this, you could write your own node if you liked. Listen for new blocks from the network, or just from bitcoind. Use your script interpreter to ensure that transactions in new blocks are valid, are correctly signed, and so on. Once you're confident the blockchain you end up with is correct, you can parse for the cases that bitcoind ignores and spend them if you can.


Binance API SIGNED GET request error code -1100 on signature parameter

As per @Marc Alexander's comment I have to sign (HMAC SHA256) the query parameters (in my case timestamp=##################) and add that as signature parameter in the request. It works using the following code:

Sub GetBalances()
    Const apiKey As String = "[insert API key]"
    Const secret As String = "[insert API secret]"

    Dim totalParams As String
    totalParams = "timestamp=" & BinanceTime()
    Signature = Base64_HMACSHA256(totalParams, secret)
    sUrl = "https://api.binance.com/api/v3/account?" & totalParams & "&signature=" & Signature
    Dim oRequest As WinHttp.WinHttpRequest
    Dim sResult As String

    On Error GoTo Err_DoSomeJob

    Set oRequest = New WinHttp.WinHttpRequest
    With oRequest
        .Open "GET", sUrl, True
        .SetRequestHeader "Content-Type", "application/json; charset=UTF-8"
        .SetRequestHeader "X-MBX-APIKEY", apiKey
        .Send "{}"
        .WaitForResponse
        sResult = .ResponseText
    End With
    Set JsonResponse = JsonConverter.ParseJson(sResult)
    Debug.Print(

Exit_DoSomeJob:
    On Error Resume Next
    Set oRequest = Nothing
    Exit Sub

Err_DoSomeJob:
    MsgBox Err.Description, vbExclamation, Err.Number
    Resume Exit_DoSomeJob

End Sub

Public Function BinanceTime() As String
    Dim oRequest As WinHttp.WinHttpRequest
    Dim sResult As String

    Set oRequest = New WinHttp.WinHttpRequest
    With oRequest
        .Open "GET", "https://api.binance.com/api/v1/time", True
        .SetRequestHeader "Content-Type", "application/json; charset=UTF-8"
        .Send "{}"
        .WaitForResponse
        sResult = CStr(.ResponseText)
    End With
    Set Json = JsonConverter.ParseJson(sResult)
    BinanceTime = Json("serverTime")
End Function

Public Function Base64_HMACSHA256(ByVal sTextToHash As String, ByVal sSharedSecretKey As String)
    Dim asc As Object, enc As Object

    Dim TextToHash() As Byte
    Dim SharedSecretKey() As Byte
    Set asc = CreateObject("System.Text.UTF8Encoding")
    Set enc = CreateObject("System.Security.Cryptography.HMACSHA256")

    TextToHash = asc.Getbytes_4(sTextToHash)
    SharedSecretKey = asc.Getbytes_4(sSharedSecretKey)
    enc.Key = SharedSecretKey

    Dim Bytes() As Byte
    Bytes = enc.ComputeHash_2(TextToHash)
    Base64_HMACSHA256 = ByteArrayToHex(Bytes)
    Set asc = Nothing
    Set enc = Nothing

End Function

Private Function ByteArrayToHex(ByRef ByteArray() As Byte) As String
    Dim l As Long, strRet As String

    For l = LBound(ByteArray) To UBound(ByteArray)
        'strRet = strRet & Hex$(ByteArray(l))
        strRet = strRet & WorksheetFunction.Dec2Hex(ByteArray(l), 2)
        Debug.Assert l = Len(strRet) / 2 - 1
    Next l
    ByteArrayToHex = strRet
End Function