Let's deploy BIP65 CHECKLOCKTIMEVERIFY!



Summary:

The discussion is about the potential risks associated with a soft fork deployment and miner adoptance. The overwhelming supermajority of hashpower makes bad confirmations unlikely, but old nodes might still see a bad confirmation occasionally during such a transition. Therefore, old nodes and SPV clients should either require more confirmations or upgrade. Clients can be warned if the block version is unrecognized to prevent anyone from accepting bad blocks. However, SPV security necessarily relies on miners to validate for them.Eric Lombrozo notes that measuring miner adoptance is important. It is an adoption metric for what is presumably a fairly uncontroversial upgrade. If there's contentious controversy amongst miners, all bets are off. Real hashpower supermajority would make attacks hard to pull off in practice. However, our current mechanisms are imperfect in this regard as miners have deliberately disabled checks despite signaling adoption in their blocks.Jonathan Toomim agrees with Anthony Towns that a soft fork that only forbids transactions that would previously not have been mined anyway should reduce the likelihood of old miners building newly invalid blocks to a vanishingly small probability. However, he disagrees with the paragraph stating that upgraded bitcoin nodes, non-upgraded bitcoin nodes, and SPV clients all continue to work fine during the upgrade. He explains how attackers can create transactions that exploit the difference in validation rules as long as miners are still on the old version to mine them. Attackers never have to risk actual losses. This can be done as long as miners continue to mine old-version blocks, regardless of their frequency.


Updated on: 2023-06-10T23:07:47.717517+00:00