Re: The duplicate input vulnerability shouldn't be forgotten
⭐ Merited by Quickseller (2)
Greg Maxwell,
I truly appreciate your responsible presence here, but let me to shed a different light on this issue. The way I understand the problem we have multiple factors involved:
1- Bitcoin has seamlessly grown from an experimental project to a mission critical system. A critica vulnerability exploit is totally intolerable and will cause serious damages to a large population. It is what have agitated and reminded us about the critical aspects of the issue and has made theymos to start this topic.
2- Although as a consensus based protocol bitcoin is a social contract that inherently resists change and treats it as an existentially paradoxical subject, evolution is inevitable just like any other live system. It suggests the probability of an unusual development process beyond common practices familiar in software engineering.
3- As the first widely adopted decentralized system which surprisingly happened to be implemented in one of the most sensitive fields ever: monetary systems, bitcoin is an unprecedented social experiment. As much as it is exciting, there exist consequences with the most critical one being the ambiguity in governance.
4- Any system with governance problem is suspected to lose direction and being subject to technocratic decision makings. Lack of vision and strategy escalates spars, discreet developments which are typically reduced to pure technical processes.
5- Both as a result of decentralization and governance issues on one hand and because of a tradition based on immutability of blockchain data as an initial requirement in bitcoin on the other hand, the client software is supposed to be downward compatible, the original blockchain is to be maintained and bootstrapping fresh nodes from genesis block to the whole chain should be supported. As a result, developers and contributors use sophisticated techniques to comply with this requirements.
6- Because of the last two factors, bitcoin now suffers from a software engineering problem: software bloat. Through years, incremental developments plus efforts for keeping system downward compatible and insisting on soft forks against hard forks has ended to a situation in which bitcoin code is becoming more and more complicated and hard to understand/contribute and maintain.
I know you can argue in favor of softforks or downward compatibility or bootstrapping very persuasively but everything comes with a price and if bitcoin was a simple centralized system with no governance issues, we would have it completely redesigned and rewritten from scratch 2 or 3 times in almost 10 years after its first release, in the most conservative scenario. So, it is not about how good is downward compatibility, we are just used to suppose there is no other option.
Now we are here. We can't disrupt governance situation but there are definite reconsideration opportunities that we have to embrace. For instance suppose somebody (a reckless person like me
) suggests maintaining blockchain since Genesis and bootstrapping from it is not necessary and we could use a snapshot of UTXO which after being confirmed by like 10,000 blocks cumulatively, the historical data behind it would become relaxed.
As a common practice and before CVE-2018-17144 It would be a controversial proposal and won't get any support because nobody was aware of the critical situation with code from a software engineering point of view and the impact of such a proposal on making code an order of magnitude more elegant and straightforward would not be weighed properly.
Now, in post CVE-2018-17144 era, we have to be ways more open to any proposal that helps making/keeping the code as smart and compact as possible. It is a general paradigm shift, we should embrace it and help it to happen with the least possible casualties and disasters. In this new era code simplicity and beauty comes first, and we MUST put it in the top of our priority list.
I truly appreciate your responsible presence here, but let me to shed a different light on this issue. The way I understand the problem we have multiple factors involved:
1- Bitcoin has seamlessly grown from an experimental project to a mission critical system. A critica vulnerability exploit is totally intolerable and will cause serious damages to a large population. It is what have agitated and reminded us about the critical aspects of the issue and has made theymos to start this topic.
2- Although as a consensus based protocol bitcoin is a social contract that inherently resists change and treats it as an existentially paradoxical subject, evolution is inevitable just like any other live system. It suggests the probability of an unusual development process beyond common practices familiar in software engineering.
3- As the first widely adopted decentralized system which surprisingly happened to be implemented in one of the most sensitive fields ever: monetary systems, bitcoin is an unprecedented social experiment. As much as it is exciting, there exist consequences with the most critical one being the ambiguity in governance.
4- Any system with governance problem is suspected to lose direction and being subject to technocratic decision makings. Lack of vision and strategy escalates spars, discreet developments which are typically reduced to pure technical processes.
5- Both as a result of decentralization and governance issues on one hand and because of a tradition based on immutability of blockchain data as an initial requirement in bitcoin on the other hand, the client software is supposed to be downward compatible, the original blockchain is to be maintained and bootstrapping fresh nodes from genesis block to the whole chain should be supported. As a result, developers and contributors use sophisticated techniques to comply with this requirements.
6- Because of the last two factors, bitcoin now suffers from a software engineering problem: software bloat. Through years, incremental developments plus efforts for keeping system downward compatible and insisting on soft forks against hard forks has ended to a situation in which bitcoin code is becoming more and more complicated and hard to understand/contribute and maintain.
I know you can argue in favor of softforks or downward compatibility or bootstrapping very persuasively but everything comes with a price and if bitcoin was a simple centralized system with no governance issues, we would have it completely redesigned and rewritten from scratch 2 or 3 times in almost 10 years after its first release, in the most conservative scenario. So, it is not about how good is downward compatibility, we are just used to suppose there is no other option.
Now we are here. We can't disrupt governance situation but there are definite reconsideration opportunities that we have to embrace. For instance suppose somebody (a reckless person like me
) suggests maintaining blockchain since Genesis and bootstrapping from it is not necessary and we could use a snapshot of UTXO which after being confirmed by like 10,000 blocks cumulatively, the historical data behind it would become relaxed.As a common practice and before CVE-2018-17144 It would be a controversial proposal and won't get any support because nobody was aware of the critical situation with code from a software engineering point of view and the impact of such a proposal on making code an order of magnitude more elegant and straightforward would not be weighed properly.
Now, in post CVE-2018-17144 era, we have to be ways more open to any proposal that helps making/keeping the code as smart and compact as possible. It is a general paradigm shift, we should embrace it and help it to happen with the least possible casualties and disasters. In this new era code simplicity and beauty comes first, and we MUST put it in the top of our priority list.