83

Note: I went out and learned about how the OP_RETURN opcode works at the byte level in a bitcoin transaction. I’m writing it here so that others can learn quickly. First, a brief history of why we’re even talking about OP_RETURN. Back in 2013 different players in the bitcoin ecosystem were trying to include bits of information into transactions so that they ...


59

The idea (as I understand it) is that the Merkle tree allows for you to verify transactions as needed and not include the body of every transaction in the block header, while still providing a way to verify the entire blockchain (and therefore proof of work) on every transaction. To understand this, first understand the concept of a tree. Consider an 8 ...


48

Step-by-step description: We start creating a new transaction which we hash and sign. Add four-byte version field: 01000000 One-byte varint specifying the number of inputs: 01 32-byte hash of the transaction from which we want to redeem an output (reverse order): be66e10da854e7aea9338c1f91cd489768d1d6d7189f586d7a3613f2a24d5396 Four-byte field denoting the ...


46

First of all two matching scripts are used in two different transactions, one that transfers funds to an address (Transaction A) and one that spends those funds (Transaction B). The scriptPubKey is created by the user that creates Transaction A. It basically adds a claiming condition to the output that is being created. A user may only claim and thus spend ...


39

The input of every transaction refers to an output of a prior transaction. An input can't be defined by only the transaction hash. A transaction consists of 1 or more outputs if you only specify the transaction hash there is no way to know which output is being spent.** Since these types of questions often come from a larger misunderstanding of how the ...


37

The definition of dust is client-specific and not a network rule. Bitcoin Core considers a transaction output to be dust, when its value is lower than the cost of spending it at the dustRelayFee rate. The default value for dustRelayFee is 3,000 satoshi per kilobyte, which results in the same dust values as the dust definition used before Bitcoin Core 0.15.0. ...


36

147krm8yWUcVq9Ta25h679TCpsEznzgvRz is the change from the transaction. There was more than one output because you didn't have any previous transactions (sometimes thought of as "coins") that added up the exact amount of the transaction. So your client picked some coins that added up to at least that amount and then created a new address to receive the ...


31

The fee goes to the miner who mines the block that includes your transaction. The fee is based on the size (in bytes) of the transaction and the age of its inputs (how long ago the coins spent were received). Transactions get big if they have to "pull in" a lot of outputs from previous transactions and that raises the fee. So if you got a lot of small ...


29

Most clients on the network have a transaction pool in their memory. The same basically applies to miners: they just dump the top 500KB (or some other value) transactions into a block, sorted by transaction fee (descending, of course). When there aren't many transactions, maybe because of a series of block in a short amount of time, it will be confirmed ...


28

I couldn't find the results of the Coin Selection written out anywhere, and just finished piecing it together from the code. It works as David mentioned, but here are more details. The Coin Selection Algorithm logic to transfer Target amount If any of your UTXO² matches the Target¹ it will be used. If the "sum of all your UTXO smaller than the Target" ...


28

I'm not sure there is an exact definition of dust. The Armory client wiki says: Sending less than 0.01 BTC to any recipient — The network considers these small outputs to be “dust,” and discourages them by requiring a fee. If it was not discouraged, someone could take 1.0 BTC, and create 1,000,000 transactions of 0.000001 BTC each, for free, which would ...


27

Enable txindex=1 in your bitcoin.conf (You'll need to rebuild the database as the transaction index is normally not maintained, start using -reindex to do so), and use the getrawtransaction call to request information about any transaction (it won't work for the genesis block's coinbase transaction though, it's a special case). Note that this will only give ...


26

"Figure 7-2. Calculating the nodes in a merkle tree" from Mastering Bitcoin shows the Merkle Root (HABCD) of a list of four transactions: Tx A, Tx B, Tx C, and Tx D: To verify that a transaction—for example, that with hash HK—is a valid transaction (i.e., part of a list of, in this example, 16 transactions with hashes HA, HB, … HP), one need only perform ...


24

You were probably trying to pay on the blockchain itself. That's like trying to pay for lunch by moving dollars through the Federal Reserve. You should use some system designed to move small quantities of bitcoins cheaply such as Coinbase. We don't yet have good decentralized payment systems for bitcoin, so currently bitcoin is primarily being used as a ...


23

Spending money from a paper wallet is the hardest part. Making the wallets themselves is easy but spending the coins is harder than it should be. Here's a guide on how to do it safely: Create a NEW wallet on blockchain.info. Keep in mind that you will only use this wallet for the express purpose of emptying your paper wallet. You will not reuse the paper ...


23

You can send any number of bitcoins to anyone, even 1 satoshi (see exceptions below), which is 0.00000001 BTC (about 0.00001031 USD) However for such small amounts you may not want to include a transaction fee. There is no minimum transaction fee. However if you send a transaction without any fee you can expect a significant delay in it getting into the ...


22

Note that the accepted answer is outdated. Currently, sequence numbers are mainly used for signaling RBF - replace-by-fee - that allows you to resend a transaction with a higher fee. See https://bitcoincore.org/en/faq/optin_rbf/ , https://github.com/bitcoin/bips/blob/master/bip-0125.mediawiki


21

Bitcoin follows a Unspent Transaction Output (utxo) model. Our modern banking systems follow an account model - you're assigned a bank account number (similar to an address), and send and receive money from it. Any incoming funds increase your total account balance, and any outgoing funds decrease it. The bank does not keep track of which funds came from ...


20

The maximum transaction size is the size of the block. Source. // Size limits (this doesn't take the witness into account, as that hasn't been checked for malleability) if (::GetSerializeSize(tx, SER_NETWORK, PROTOCOL_VERSION | SERIALIZE_TRANSACTION_NO_WITNESS) * WITNESS_SCALE_FACTOR > MAX_BLOCK_WEIGHT) return state.DoS(100, false, REJECT_INVALID, "...


20

Bitcoin transactions have a transaction id (txid) formed as a hash over the data involved in the transaction. That suggests that it is a unique identifier for a transaction. However, the tx-id of a transaction is only unique once the exact data in the transaction has been finalized by being incorporated into the blockchain (and confirmed). Until then, there ...


20

If a person sends a transaction to another person, and Bitcoin is a peer-to-peer application, how will the transaction get to the rest of the Bitcoin community? Think of it like how gossip would spread. There are a bunch of people (nodes), and when one of them knows something, they tell it to the few (8 or so) people they are near (connected with), and ...


19

The big advantage on the Bitcoin side is that its technology is now well-proven. Ripple's consensus system is the newcomer. Ripple was designed by people who had the benefit of seeing exactly what Bitcoin was doing and its strengths and weaknesses. Ripple's consensus process can validate a transaction such that irreversibility is reasonably assured much ...


19

The 51% attack is emergent behavior of the system. It's not because there's a "50%" buried somewhere in the protocol that can just be changed to 60% or 75%. Someone with more hashing power than everyone else combined can, given enough time, always build a longer chain than everyone else.


18

While the other answers are slightly true, there's another reason. Addresses which have been spent are inherently less secure than unspent addresses. This is because, when spending on an address, you reveal the public key to the address. This means that in order to steal those funds, you only need to find the private key, whereas normally you'd need to break ...


18

It depends on your risk model. If you can trust the person paying you, you can accept payment on 0/unconfirmed if you want. As a merchant or trader, you want to use the configuration that is more secure (no incoming connections permitted, explicity connect to well-connected nodes). With zero confirmations you are vulnerable to the race attack and the ...


18

The choice between the UTXO model and the balance model is primarily one between privacy incentives and apparent intuitiveness. If one follows the standard advice of not reusing addresses/outputs/scripts, as to not gratuitously reveal which coins belong to the sender and which belong to the receiver, the two models are actually equivalent. In this case ...


18

I like to suggest a mental model where the network is a metals forge: You have a 1 oz gold coin stamped with your key on it, with your transaction you send it to the forge to be melted down and re-formed to two new coins, a .22 with Alice's key stamped on it and a .77 with a key of yours on it, and then the forge keeps the remainder for their fee. You can'...


17

The information in David's answer is correct, but it may not answer the actual question -- it's unclear whether the question is about change in general, or specifically sending change to a new address. If the latter, nothing needs to be added. If, however, the question was about the practice of change in general, then yes, it is necessary. The reason for ...


17

No. If you create one, it won't be relayed or mined by Bitcoin Core. If it gets into a block, it will be rejected. From the source code for Bitcoin Core (tx_verify.cpp:164): if (tx.vout.empty()) return state.DoS(10, false, REJECT_INVALID, "bad-txns-vout-empty"); However, you can create a vout with 0 satoshis. That isn't a "standard" transaction, so it ...


17

No, you were not defrauded because you did not lose anything real. You did not lose 10 BTC. You did not lose $1,556.76. You lost potential, yet unrealized gain as a result of the delay in processing your order. You may have not had access to either amount for a period of time because of the flag thrown on your transaction. AFAIK, Coinbase does not publish ...


Only top voted, non community-wiki answers of a minimum length are eligible