I think the way it works is good because when the number of variables matches the number of degrees of freedom then the system can't be overdetermined or underdetermined and it can't be inconsistent or ambiguous. Yes, the code could check for it and prevent inconsistencies it but it seems cleaner to have it inherently consistent.
The same reason inputs do not specify the amount, but rather allow the amount to be specified by the txout that they refer to.
An implementation could decide to cache these values if there is a performance benefit for doing so.
Topic: How are tx fees implemented in the byte stream? (Read 784 times)
Quote
That would require the miner to later gather all those outputs into one transaction in a separate step to spend them, bloating that transaction. Consider if each of 12 transactions has a .005 fee, do you want to spend them as one 50.06 bitcoin transaction input or as a 50 btc input and 12 .005 btc inputs? It's much more elegant to do it in the mined block already.
Excellent point.
I would expect one of the hashtypes to allow for the last TxOut to be left out of the signature, and then the miner can inject their own script that transfers that last output to themselves, without breaking the signature. Then a coinbase transaction requires no verification beyond the fact that the block is valid, and then the Tx fee looks any other TxOut.
That would require the miner to later gather all those outputs into one transaction in a separate step to spend them, bloating that transaction. Consider if each of 12 transactions has a .005 fee, do you want to spend them as one 50.06 bitcoin transaction input or as a 50 btc input and 12 .005 btc inputs? It's much more elegant to do it in the mined block already.
I'm not saying any of this is a bad idea or we should use shortcuts. It just surprises me because it seems like a "sloppy" way to do/enforce the calculation. Almost everything else in the specification is extremely explicit, so it just seems a little out of place that you need to collect the crumbs from a bunch of unrelated transactions to find the answer.
I would expect one of the hashtypes to allow for the last TxOut to be left out of the signature, and then the miner can inject their own script that transfers that last output to themselves, without breaking the signature. Then a coinbase transaction requires no verification beyond the fact that the block is valid, and then the Tx fee looks any other TxOut.
But it works as is, so I'm not proposing changes. Thanks for the clarification.
I would expect one of the hashtypes to allow for the last TxOut to be left out of the signature, and then the miner can inject their own script that transfers that last output to themselves, without breaking the signature. Then a coinbase transaction requires no verification beyond the fact that the block is valid, and then the Tx fee looks any other TxOut.
But it works as is, so I'm not proposing changes. Thanks for the clarification.
You would need to process all other transactions to verify the coinbase anyway, since the coinbase is invalid if it is within an invalid block.
Yep. Shortcuts are a bad idea. The security properties of the bitcoin scheme work because every client fully validates every block, using precisely the same tests, before it accepts it. This is part of what is necessary to determine that a block is in fact part of the public hash chain.
You would need to process all other transactions to verify the coinbase anyway, since the coinbase is invalid if it is within an invalid block.
So, this is not a modification of the transaction at all... if a sender explicitly puts more total inputs than outputs in his transaction, they miner can simply declare the leftover his by adding it to his coinbase transaction?
Doesn't this complicate things considerably, by creating dependencies between unrelated transactions? i.e. in order to verify the validity of a coinbase transaction, you need to add up all the other transactions in the same block...?
Doesn't this complicate things considerably, by creating dependencies between unrelated transactions? i.e. in order to verify the validity of a coinbase transaction, you need to add up all the other transactions in the same block...?
Third-party transactions are never modified by miners. Miners simply add the leftover BTC to the value of their generation outputs. Other than existing in the same block, the coinbase transaction is not connected to the transactions that provide its fees.
So far, I have found no information about how transaction fees are included in a transaction, other than the higher-level description found on the wiki:
https://en.bitcoin.it/wiki/Transaction_fees
All it says is that the outputs add up to less than the inputs, so that the miner can include themself for the "leftover" output. However, after finally understanding OP_CHECKSIG, I don't see how this possible with SIGHASH_ALL hash code. SIGHASH_ALL includes all output scripts in the TxCopy that is serialized and signed by the sender, so the miner cannot modify/add any outputs without breaking the signature. But I also heard that the other hash codes are not used. Even if they were used, I'm having a tough time figuring out what they do.
Can anyone clarify how this is handled?
https://en.bitcoin.it/wiki/Transaction_fees
All it says is that the outputs add up to less than the inputs, so that the miner can include themself for the "leftover" output. However, after finally understanding OP_CHECKSIG, I don't see how this possible with SIGHASH_ALL hash code. SIGHASH_ALL includes all output scripts in the TxCopy that is serialized and signed by the sender, so the miner cannot modify/add any outputs without breaking the signature. But I also heard that the other hash codes are not used. Even if they were used, I'm having a tough time figuring out what they do.
Can anyone clarify how this is handled?
Jump to: