Adding transaction data - finite effect on proof-of-work?

[darren-a]

Location: https://bitcoin.org/en/developer-guide#proof-of-work

quote
The block header provides several easy-to-modify fields, such as a dedicated nonce field, so obtaining new hashes doesn’t require waiting for new transactions. Also, only the 80-byte block header is hashed for proof-of-work, so adding more bytes of transaction data to a block does not slow down hashing with extra I/O.
/quote

Adding new transaction data would involve recreating the Merkle Tree, no? I realize that the rate of new tx being added, and even created in the network, is several orders of magnitude lower than the number of hashes that are tried on each "stable" block header but nevertheless there would be some I/O, would there not if a miner decides to add new txs?

I raise this for two reasons:

1. Reading this (great) documentation is really helpful to understand how Bitcoin works, so if I'm correct it seems to be worth mentioning, if only for pedagogical reasons.
2. In the future if/when the tx/s reaches, say, Visa levels and BTC generation is at or near zero, will there be a tension between running hashes on a fixed set of txs and deciding to add more txs (at some finite cost of computing power) in order to compete to win more tx fees?

[harding]

@darren-a thanks for the complement! In response to your comments:

1. Yes, updating the merkle root does require extra I/O. However, the merkle root (and the rest of the header) stays the same size no matter how much transaction data there is in the block---so the same amount of I/O is used to generate and check each header hash regardless of the transaction data size. I'll see if I can rephrase the text slightly to make it more clear.
2. I don't think I understand what you're asking. Updating a merkle root for a miner, and verifying the merkle root for a validation node, is extremely cheap even if a block includes tens of thousands of transactions. (My laptop's CPU does ~1 million SHA256(SHA256()) hashes per second on a single core.) Considering other factors like the speed of ECDSA signature validation and large-block propagation delays, I doubt we'll ever see transaction volume bound by merkle root generation. Perhaps it's better to ask this question on Bitcoin StackExchange or the BitcoinTalk forums.

[darren-a]

1. Thank you for considering that.
2. You're right, I'll ask this on StackExchange (if needed). Just to close the loop here though - I didn't see it as bounding factor, more wondering about potential disincentives to adding transactions but it seems these are more than overcome by: a) cheapness in processing terms, even at very high transaction rates, b) potential additional fee income, and c) the fact that "abandoning" trials to hash a block with n transactions to begin on a new trial block with n+x transactions loses nothing due to the memoryless property of the distribution.

[saivann]

How about "Also, only the 80-byte block header is hashed for proof-of-work, so including a large volume of transaction data in a block does not slow down hashing with extra I/O, and adding additional transaction data only requires the recalculation of the parent hashes in the merkle tree."

[harding]

@saivann I prefer to say "ancestor" rather than "parent" to help make it clear that multiple levels of hashes in the merkle tree might be affected. Otherwise, the revision sounds good to me. Do you want to push a commit with the revision, or shall I?

[saivann]

@harding Sounds good, yes I'd be glad if you commit what you think is appropriate if you have time, thanks!

[saivann]

@harding Thanks! And thanks @darren-a for the useful feedback.