Published on: 2019-03-13T01:34:21+00:00
In an email exchange, Russell O'Connor and Matt Corallo discuss the possibility of removing certain aspects of the Bitcoin protocol through a soft-fork. O'Connor suggests classifying nSequence numbers, NOP1-NOP10, and extra sighash types as redundant and removing them. However, Corallo argues that even carve-outs for OP_NOP may not be sufficient in some cases. He believes soft forks should invalidate unused bits of the protocol, similar to OP_NOPs. While sighash bits are less likely candidates for soft-forking, Corallo sees no issue with removing them if they are redundant and not in use.O'Connor disagrees, stating that these bits are unsuitable for soft-forking within legacy Script. He argues that random bits inserted into locked-for-more-than-a-year transactions are not sufficient reason to not soft-fork them out. He points out the lack of precedent for soft-forking out working transactions unless the security of the Bitcoin protocol itself is at risk. O'Connor believes crossing this line should only happen under existential threats.Corallo suggests that the reason these bits are not seen in use on the blockchain could be because users trying to use them are caught up in the fact that they are not being relayed by default and violating SCRIPT_VERIFY_STRICTENC. He argues that making transactions non-standard and then using their lack of usage to justify a soft-fork is unacceptable.O'Connor counters with examples of users whose funds are tied up due to other changes in Bitcoin Core's default relay policy. He believes permanently destroying their funds before their transactions have a chance to get mined would be unfair. The exchange highlights the debate around whether certain aspects of the Bitcoin protocol should be removed via soft-fork and the potential consequences of doing so.The discussion also touches on default relay policies and how changes to them can affect users' ability to use certain transactions. Ultimately, there is disagreement between the two individuals on whether the potential harm caused by removing these bits outweighs the benefits of simplifying the transaction format.In addition to the debate on removing certain bits, there is a discussion on disabling unused bits within the sighash type byte. The author proposes that since these bits are not in use, they could be soft-forked out without significant impact, comparing them to OP_NOPs. However, O'Connor argues that the sighash type byte is useful for storing ancillary data during signatures. He suggests that some users may have unbroadcast transactions in cold storage with UTXOs whose private keys may have been lost, making disabling these sighashes risky. O'Connor proposes an alternative proposal of caching the just-before-the-last-byte sighash midstate instead.The sighash type byte plays a crucial role in signature evaluation during Bitcoin scripting operations. However, if this byte is anything other than specific values, script execution fails. Despite this limitation, some users have been utilizing the sighash type byte to store additional data during signatures. This usage means that there may be unbroadcast transactions in cold storage with UTXOs whose private keys are lost. While the risk of disabling these sighashes may seem low, O'Connor argues that it could put people's funds at risk. He suggests considering an alternative proposal of caching the just-before-the-last-byte sighash midstate before implementing any changes to the Bitcoin protocol.
Updated on: 2023-08-02T00:37:12.107474+00:00