Published on: 2015-12-29T13:00:45+00:00
In December 2015, a discussion took place on the bitcoin-dev mailing list regarding the use of short-circuit evaluation and potential complaints that may arise. Jonathan Toomim suggested that humans possess the ability to respond to new situations without predetermined rules and algorithms, and this ability should be utilized at times. However, concerns were raised about complaints and the necessity of establishing general consensus rules as a social contract.To address these concerns, Jonathan Toomim proposed announcing the intention to perform a soft fork a couple of months before it becomes active. By doing so, they could ensure that nobody complains about the soft fork destroying their secret stash. This approach, according to Toomim, would minimize the likelihood of complaints arising.During the discussion, the possibility of someone having a timelocked big transaction with a lost private key was also brought up. Toomim considered this scenario to be unlikely, emphasizing the importance of establishing consensus rules as a social contract to prevent breaking them without exceptional circumstances.The conversation emphasized the significance of considering potential issues and establishing clear rules and communication when making changes to the bitcoin network. It highlighted the need for proactive measures to address concerns and maintain the integrity of the system.Another member of the mailing list, jl2012, expressed doubts about the scenario involving a timelocked big transaction with a lost private key. To address this concern, Peter Todd suggested telling people not to engage in such practices. He proposed a fix for the quadratic CHECK(MULTI)SIG execution time issue by limiting only SignatureHash() to return true if the transaction size is less than or equal to 100KB. This solution allowed for a future soft-fork that could properly address the hashing issue without impacting all transactions or counting sigops.Todd's proposed solution offered ease of implementation and quick deployment in case of an attack by a major miner exploiting slow-to-propagate blocks. He provided a link to related discussions for further reference.To implement a soft-fork that resolves the quadratic CHECK(MULTI)SIG execution time issue, the suggested approach is to limit SignatureHash() to return true only if the transaction size is 100KB. While this solution technically allows transactions, it prevents them from spending coins that are cryptographically secured. This fix could be deployed as a soft-fork within a matter of days, making it an effective solution in case major miners exploit slow-to-propagate blocks to harm their competitors.Overall, the discussion on the bitcoin-dev mailing list highlighted the importance of considering potential issues, establishing clear rules and communication, and implementing proactive measures to maintain the integrity of the bitcoin network.
Updated on: 2023-08-01T17:18:54.610038+00:00