Quote from: Quickseller on September 24, 2018, 04:08:59 AM

Quote from: aliashraf on September 23, 2018, 09:55:55 AM

Obviously, it would be much safer for a community to take care of one implementation with fewer lines of codes.

I don't think it is necessarily best to rely on the "community" to ensure that each implementation of a bitcoin node is secure/safe to use.

Members of the community might have, at most a few million dollars worth of bitcoin of their own money at stake, but even if they make a mistake, they are unlikely to personally lose any money. On the other hand, there are several bitcoin related businesses that have billions of dollars worth of customer money, and hundreds of millions (and in some cases billions) of dollars of equity who have serious incentives to ensure these types of bugs don't pop up with software in production, and they have incentives to have fail-safes in place to prevent any actual losses if/when these types of bugs make it through the cracks.

I would point out that I am not aware of any major exchange "pausing" deposits and/or withdrawals immidiately after this bug was discovered, however anyone running the relevant software would have taken some time to stop deposits/withdrawals to upgrade their nodes (which would include reviewing the code). This leads me to believe that the majority of exchanges/businesses are running their own custom node software, maybe not exclusively, but this is at least part of what they are running.

I thought we are done with multiple implementations proposal and it was why I brought up my software bloat diagnosis for the issue. Now I see we are recycling the same idea again and again and it is really disappointing and makes me paranoid.

Why? Why should one continue pushing for a false idea like this? How is it possible to have 10 million lines of code safer than 100K?

I suspect most of the people who are insisting on this idea, multiple implementations, are just taking advantage of an incident to retaliate against Core team. I'm sure about you not being such a person but I afraid you don't completely get how irrelevant and dangerous is this proposal.

Satoshi's original software was just like 3K lines of code, now we have bitcoin core with 100K lines and every software engineer knows what does it mean and how inevitable is having bug issues. Actually it is very impressive that an unexploited bug is the worst incident of its kind after like 10 years and Core guys deserve a lot of kudos for the job they have accomplished till now.

Now instead of a decent technical discussion about how and why this bloat happened and what measures should be taken to manage the risks involved, we are watching biased actors who are seeking more power in the community or suppose a weakened developer community is better for them are suggesting the oddest solution ever: using even more lines of code! I made a prophecy regarding this situation:

Quote from: aliashraf on September 23, 2018, 07:27:40 AM

I understand there are many people with various incentives mostly not in the best interests of bitcoin who may find such an event a good opportunity to take advantage in an irresponsible and unproductive way. Although I have a reputation on this forum to be somewhat discontented with Core devs, I hope my statements here other than being helpful in the context of this topic, would show how committed I'm to bitcoin as a liberating movement instead of blindly opposing and fighting with specific parties.

The most sophisticated reasoning behind multiple implementation idea could be something like this:

Quote from: RHavar on September 24, 2018, 04:11:45 AM

One thing I've always wanted to do -- but have never had the energy for -- was to run multiple implementations of bitcoin (e.g. btcd and bitcoin core) and only transact while they are in agreeance.

For most bitcoin businesses, a few hours of not processing deposits/withdrawals is actually not a big deal, and happens pretty regularly anyway (for no fault of bitcoin itself). While on the other hand transacting after an accidental chain-split could really be devastating.

(which you, @quickseller, have merited by the way)
But it is not a matured idea as I have argued against it before:

Quote from: aliashraf on September 23, 2018, 07:27:40 AM

Firstly, it implies a new kind of consensus system, with no theoretical support.

Bitcoin consensus system is based on game theory (rational behavior of players with divergent incentives) it is NOT about fault tolerance regarding software bugs. Putting such a layer on top of bitcoin is not a trivial job because we are not talking about low level control systems and alike.

From a software engineering point of view, once we are concerned about bugs in a system, software bloat is the most important problem that we should take care of. As I have discussed in my previous post in this topic , for bitcoin, this bloat is not a mistake of an architect or a programmer it is a direct consequence of the very fact that bitcoin is a new class of system and is not (and should not be) governed traditionally, it escalates a case-by-case development process and institutional conservatism in the community according to which devs define their role as guardians.

Bitcoin has grown from 3,000 lines of code to 100,000 all the way with soft forks, i.e. downward compatibility (somehow). It is the source of the bloat
and the critical vulnerability to bugs, this situation should be reconsidered radically if there is a real motivation to do anything other than taking foolish temporary political advantages of a serious threat that should be addressed asap and before everything is lost.