20

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 ...


13

Yes! The trick is to count each input with its effective value rather than its nominal value. Transactions are composed of three parts: the overhead, the inputs and the outputs. Outputs: The size of the output scripts is determined by the recipient addresses, so their size is given by the transaction instructions. We do not know whether we will need a ...


9

There are a lot of good answers, but I want to point out the most obvious answer. Say you have 1 bitcoin and you send 0.2 bitcoin to me and the design leaves it so that you still have 0.8 bitcoin in the same place as the 1 bitcoin you had originally. What stops someone from simply processing that transaction again? You still have the funds. Designing the ...


9

You must reveal the secret in order to spend the output, else there is no way other users could verify that your hash is indeed the correct one. Once you reveal that secret, anybody could attempt to create a competing transaction which spends to a different output - miners in particular would be able to confirm this transaction into a block and ignore your ...


7

This is implementation dependent, but in Bitcoin Core there is not just a single UTXO set: The UTXO set on disk in the chainstate/ directory in a database. It corresponds to the state as of the last flushed block (and does not include the effects of any mempool transaction, or of any block since the last flush). The in-memory coins cache is a cache on top ...


7

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/...


6

There is no "the mempool". Each node has its own mempool. So in your example, each node would receive each of the transactions, possibly in a different order, and at different times. It is physically impossible for all three transactions to reach every single node at the exact same time. If we assume that none of the transactions signal for RBF and all of ...


6

At the protocol level, Bitcoin has no concept of "balances" or "addresses", and their common interpretation isn't relevant during verification. Every transaction spends "coins" and reforges them into new "coins" (called UTXOs). Every UTXO has a value (in number of satoshis) and an locking script. UTXOs are always spent ...


6

Yes, but only if A -> B is placed before B -> C in the list of transactions. Here is a graph of the percentage of transactions spending each other in the same block, it is usually around 10%.


6

First of all, what is the goal? The Bitcoin consensus rules already completely eliminate the possibility of an "double spend" within any individual version of history ("chain"). The concern is about individual wallets accepting a transaction as a fullfilled payment, before it is certain that that transaction will end up in the winning ...


5

When a sender creates a transaction, they explicitly define which pieces of bitcoin they spend. We call such pieces of bitcoin Unspent Transaction Outputs (UTXO) and you can think of the UTXO Set as the distributed ledger of Bitcoin's balances. The state of UTXO is ternary: they either don't exist yet, are available for spending, or have been spent. So, you ...


5

Because unlike addresses, hex raw transactions aren't meant to be seen or used by end-users. Hex is easy to encode and decode (every two character in hex represents one byte*, whereas in base64 one character is 3/4 byte and Base58 is log(58)/log(256) = 0.7322476244 bytes) so it is convenient if you want to debug your implementation. *: which means if you ...


5

And if so, why don't you just send 0.4 BTC in the beginning? Bitcoin was designed to allow single-in multi-out or multi-in multi-out payments. In Ethereum, only one address fills the whole "to" field of transactions. (This doesn't apply to contracts. Does that mean, in Ethereum, users are 2nd class citizens?) If you were Satoshi and you were to ...


5

Kind of, but coin selection is hard in general. The idea is that inputs pay for themselves. It is easy to compute how much in fees you will need to pay for an input at a given fee rate. So when you do coin selection, instead of selecting on the actual value of the input, you use the value of the input minus the fees it will pay. This is known as the ...


5

This is intentionally not possible. If a transaction would be valid in block X, we want it (absent double spend) to remain valid in any successor of X. This guarantees that (temporary, otherwise harmless) forks that result in small reorgs will never invalidate unrelated transactions - and they will just be able to be mined again in the new branch. It also ...


5

That's a question about Ethereum, a system that's notoriously difficult to accept payments with due to some incredibly bad design decisions. Ethereum has operational costs for making new addresses which make this sort of poor engineering attractive. We have no need to do anything ridiculous like that to try to distinguish payments, we can just make a new ...


5

This is normal. Here you can see a chart of average transacted value every day: https://blockchair.com/bitcoin/charts/average-transaction-amount-btc There are 2 things that contribute to this: The very large transactions skewing the numbers. This becomes more apparent if you take a look at the median transaction values, which are around the 0.02-0.03 BTC ...


4

The scriptPubKey is the script as it is placed in the transaction output. The redeemScript (P2SH only) is the script pushed as the last scriptSig item. In P2SH scripts, the scriptPubKey is equal to OP_HASH160 <Hash160(redeemScript)> OP_EQUAL. The witness script (P2WSH only) is the script in the last witness stack position. The witness program is ...


4

The transaction digest alone would take around 2 days of non-stop work: http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and-paper.html That's before you even start the 32-byte multiplication required to compute an ECDSA signature. It might be humanly possible if the UTXO you are spending does not require a signature. An "anyone-can-spend" ...


4

The Bitcoin transaction fee depends on : The size of the transaction The current feerate The transaction fee in $ depends in addition on the price of a bitcoin in dollar. Simply put, the size of the transaction basically depends on the number of time you received bitcoins in the past (if you want to send 350$ the transaction size will be higher if you ...


4

Since the very beginning. Transactions have had the nLockTime field since Bitcoin 0.1.0.


4

Eventually all messages are put in a sequence. The key word is "eventually". Let's say there are two users A and B trying to spend a transaction at the same time. A's transaction reaches Node1 and B's transaction reaches Node2. Both nodes include the two different transactions in a block and are able to mine the block using those transactions. Further, ...


4

What would happen if me and my friend broadcast transaction with same input at the same time to a different nodes ? Some network nodes will have your transaction in their mempool, while other will have your friend's one. If your transaction is really basic (no batch, not signaling RBF, not spending another unconfirmed transaction) then (unmodified [*]) ...


4

Can it safely be said that the first input in the inputs of the transaction is the sender's? No, no such ordering exists. Transactions consume UTXOs as inputs, and create new UTXOs as outputs. A transaction can have multiple inputs from one person, or inputs from multiple people. In some cases, more than one person can own an input. So there isn't really ...


4

If you create a raw transaction yourself, then that is the raw transaction. Whatever you put in it is exactly what the transaction will be, in the same order. There are some conventions around output ordering. Some software will randomly permute the outputs; other software uses BIP69 which specifies a deterministic ordering. There is however no requirement ...


4

Blocks do not contain transcation ids at all, they contain the full transactions themselves. If you are using the getblock rpc and seeing txids, that's just because showing the details of all of the transactions is extremely verbose, so only the txids are output. You can see the full transaction details of a block by setting the second argument to 2.


4

This cannot happen. Every block contains at least a "coinbase" transaction that distributes the subsidy and fees to the block's miners. Blocks without coinbase are invalid, even if the subsidy were 0.


4

As @chytrik already described, address reuse does not solve your problem for UTXO-based coins, each transaction output must be individually referenced regardless. When your users deposit into your site, you want to give them separate addresses, so that you can track whose internal balance should be credited. After that, the funds are in your custody, though. ...


4

It is the position of your txo in the outputs array of the transaction that created it. You can see that this transaction created 2 outputs and that your output is the first one (0). This index is also sometimes refer to as vout.


4

The Bitcoin network uses the blockchain to form consensus on the journal of transactions. The blocks commit the network to a specific order of events and guarantee propagation. Blocks are found roughly every ten minutes and are limited to 4,000,000 weight units (or 1,000,000 vbytes). Said blockweight limit and cadence of blocks are what limits network's ...


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