Author: Gregory Maxwell 2015-09-30 22:59:22
Published on: 2015-09-30T22:59:22+00:00
The discussion at hand involves the term SPV and its meaning in relation to Bitcoin. The term was coined by Mike Hearn, who claims to know exactly what it means as he wrote bitcoinj. Full nodes are expected to run scripts correctly, which is crucial for users who rely on them. A soft fork does not change this. The system could have been designed in a way that wasn't full of compatibility features and improvements could have been made with hard forks instead of soft forks. However, this is not the case, and there is likely to have been fewer improvements if hard forks were used. The conversation then moves on to P2SH and the fact that it was implemented into code that no one was using. It's pointed out that there was significant opposition to implementing it from some people. While some argue that this was stonewalling, others point out that this was likely due to engineering priorities.Despite this opposition, P2SH was eventually implemented and tens of thousands of transactions per day now use it. While there are criticisms of bitcoinj for lacking features, it's important to remember that those who criticize have likely not written as much code as someone like Mike Hearn has. Hearn also notes that he has likely spent more time unpaid creating software for others than his critics have. Ultimately, the goal is to deliver software that meets user needs without compromising privacy or security.The author of a Bitcoin article has discussed the advantages of soft-forks in that it allows for software to lack features which means that participants who code only on evenings and weekends are free to continue participating with the priorities they choose. Allowing soft-forks takes away the freedom to make that trade-off and reduces the collection of fixes and upgrades we could potentially deploy, because there will always be implementations out there like BitcoinJ in 2012 that didn't have the resources (or interest) to fully implement certain features right away.However, this should be okay because for many things, they simply don't have to. The writer also notes that unexpected things can occur with a soft fork, but users are informed, and free to look at what is going on and decide how to handle it, or just accept that the new thing is almost certainly something they don't care about. Furthermore, even if there is a difference between the security level before and after an upgrade, they're free to decide on the cost tradeoff with upgrading, and they're not forced onto an upgrade hamster wheel that disenfranchises their role in the system. The author argues that if there are specific generalised security implications, they have failed to state it. In terms of support threshold, 75% is a fine activation threshold. By definition, if support is at 75%, then bigger blocks are "winning", but if support fell, then the SPV wallets would just reorg back onto the 1mb-blocks chain. A 75% measurement doesn't actually mean 75% support, due to variance. Even ignoring that, the situation is no worse for an SPV client for a soft-fork; and it's better because convergence is still guaranteed with exponential probability.Finally, the author discusses demonstrated track record and states that more recent soft-forks have reduced the incidence of invalid blocks by substantially increasing the threshold, including better notification in Bitcoin core, communicating directly with miners more, and making non-conforming transactions non-standard in advance. These mitigations have been effective in practice; and we have not seen the same behaviour. However, it's unfortunate that people proposing hard forks have not learned the same lessons, even though the stakes are higher, and the self-resolution of the system is greatly diminished.
Updated on: 2023-05-19T22:01:04.436795+00:00