Topic: The duplicate input vulnerability shouldn't be forgotten - page 4. (Read 2332 times)

It would be more productive if you were specific instead of vague. The vague allegations, devoid of context, just come across as toxic themselves-- a character attack, rather than a complaint about something specific that could be handled better.

I believe my suggested improvements to you above-- subscribe to the list, look for things things you can do to help-- were specific, actionable, well justified, and hopefully not at all personally insulting.

In general people ignore "test" things, they just don't interact with them at all unless the thing in question is on rails that will put them somewhere critical reasonably soon.

We see this pattern regularly, when people put up complex PRs and explicitly mark them as not-merge-ready they get fairly small amounts of substantive review, and then after marking them merge ready suddenly people show up and point out critical design mistakes. Resources are finite so generally people prefer to allocate them for things that will actually matter, rather than things that might turn out to be flights of fancy that never get finished or included. They aren't wrong to do it either, there are a lot more proposals and ideas than things that actually work and matter.  You can also see it in the fact that far more interesting issues are reported by users using mainnet rather than testnet.  This isn't an argument to not bother with pre-release testing and test environments: both do help. But I think that we're likely already getting most of the potential benefit out of these approaches.

"testing" versions also suffer from a lack of interaction with reality. Many issues are most easily detected in live fire use, sadly.  And many kinds of problems or limitations are not the sort of thing that we'd rather never have an improvement at all than suffer a bit of a problem with it.

Additionally, how much delay do you think is required? This issue went undetected for two years. Certainly with lower stakes we could not expect a "testing" version to find it _faster_.  Sticking every change behind a greater than two year delay would mean a massive increase in exposure from the lack of beneficial changes, not to mention the knock on cultural effects: I should have cited it specifically, but consider the study results suggesting that safety equipment like bike helments or seatbelts sometimes result in less safe behavior. Checklists can be valuable, for example, but have also been showen to cause a reduction in personal responsibility and careful consideration. "I don't have to worry about reviewing this thing, because any issues will be found by the process and/or will be someone elses problem if they get through".

As I said above, if we had a series of concerning issues being found shortly after releases it might be a good case for going more slowly, generally. But isn't the case. With only few exceptions when we find issues that are concerning enough to justify a fast fix they're old issues.  We do find many issues quickly, but before they're merged or released.

I've generally found that for software quality each new technique has its own burst of benefit, but continued deeper application of the technique has diminishing marginal returns. Essentially, any given approach to quality has a class of problems it stops substantially while being nearly blind to other kinds of issues. Even limited application tends to pick the low hanging fruit.  As a result its usually better to assure quality in many different ways by many different people, rather than dump inordinate effort into one or a few techniques.

I'm disappointed, I think I explained directly and via analogy as to why this is the case but it doesn't seem to have been communicated to you. Perhaps someone else will give a go at translating the point, if its still unclear.

I think I did speak to it some.

More directly: Rather than shy from danger we must continue to embrace it and manage it.

The safest change is a change that you think is dangerous but is actually safe, the next most safe is a change that is dangerous and you know is dangerous, and least safe is one you think is safe but is actually dangerous. There is pretty much no such thing as a change you think is safe and actually is safe. There is also no such thing as a failure to change something that should be changed that is safe, because the world doesn't stay constant and past reliability doesn't actually mean something was free from errors.

Obviously danger for the sake of danger would be dumb, so we should want to make a reasonable number of known dangerous changes, which are clearly worth it, and that justify the review and testing needed to make them safe enough which will, along the way, find issues we didn't know we had too.

If instead people feel burned by this issue and shy even further away from dangerous changes the activity wouldn't justify due care and eventually we get burned by a safe change that isn't actually safe.

As mentioned, even the complete absence of changes isn't safe, since without changes old vulnerabilities, and security relevant short comings don't get addressed (e.g. I mentioned multisig, hardware wallets, but there are many others).

Not to point fingers-- especially as there was no casual relationship in this instance, but it occurs to me that in many recent posts you've advocated for radically reducing the interblock interval-- an argument that is only anything but laughable specifically because of a multitude of changes like 9049 that introduced this bug, squeezing out every last ounce of performance (and knocking the orphan rate at 10 minutes from several percent to something much smaller).  If our community culture keeps assuming that performance improvements come for free (or that the tradeoffs from load can be ignored and dealt with later) then they're going to keep coming at the expense of other considerations.

As far as concrete efforts go, it's clear that there needs to be a greater effort to go systematically through the consensus rules and make sure every part of the system has high quality testing-- even old parts (which tend to be undertested), and that as needed the system is adjusted to make higher quality testing possible. To achieve that it will probably also be necessary to have more interaction about what constitutes good testing, I'll try to talk to people more about what what we did in libsecp256k1 since I think its much closer to a gold standard. I am particular fond of 'mutation' style testing where you test the tests by introducing bugs and making sure the tests fail, but it's tricky to apply to big codebases, and is basically only useful after achieving 100% condition-decision test coverage. Here is an example of me applying that technique in the past with good results (found several serious shortcoming in the tests and found an existing long standing bug in another subsystem as a side-effect).

I think there is also an opportunity to improve the uniformity of review but I'm not quite sure how to go about doing that: E.g. checklists have a bad habit of turning people into zombies, but there are plenty of cases where well constructed ones have had profoundly positive effects. Unfortunately we still just don't have enough really strong reviewers.  That cannot be improved too quickly simply because it takes a lot of experience to become really effective. We have more contributors now than in the past though, so there is at least the potential that many of the new ones will stick around and mature into really good reviewers.

We also shouldn't lose perspective of the big things that we're getting right in other ways and the limitations of those approaches.  So for example, 9049 introduced a fault in the course of speeding up block propagation.  One alternative we've used since 2013 is implementing fast propagation externally: Doing so reduces the risk that new propagation stuff introduces bugs and also lets us try new techniques faster than would be possible if we had to upgrade the whole network.  Bitcoin Fibre has a new, radically different, ultra-super-mega-rocket science approach to propagating blocks. Fibre protocol's implementation has also been relatively chalk full of pretty serious bugs, but they haven't hurt Bitcoin in general because they're separate.  Unfortunately, we've found that with the separation few parties other than Matt's public fibre network run it, creating a massive single point of failure where if his systems are turned off block propagation speed will drop massively.  To address that, we've been creating simplfied subsets of that work, hardening them up, making them safe, and porting them to the network proper-- BIP152 (compact blocks) is an example of that.  A gap still exists (fibre has much lower latency than BIP152) and the gap is still a problem, since propagation advantages amplify mining centralization (as well as make selfish mining much more profitable)... but it's less of one.  This is just one of the ways we've all managed the tension between a security driven demand to improve performance and a security driven demand to simply and minimize risky changes. There just isn't a silver bullet.  There are lots of things we can do, and do do, but none magically solve all the problems. The most important thing is probably that we accept the scope of the challenge and face it with a serious and professional attitude, rather than pretending that something less than a super-human miracle is good enough.

I think this discussion is getting away from the general topic, but you were recently someone who would attack other development teams trying to "improve the world" in their own way with even more harsh terms and toxic insults. I don't think polite discourse is your strong suit either when you are known for pointing fingers at people that fork your project.

What I seem to be getting from your posts is that mostly every change is a consensus risk, and that development should move faster or at the same pace, but not slower. You claim that moving slower would potentially result in less testing, which makes no sense. You can simply have a feature or optimization on a test branch, encourage users to mess with it (by actually interacting with the feature, as awemany was doing), possibly even with some sort of bounty scheme, and once sufficient time has passed and lots of different people and companies in the industry have tried to break it, you merge it in. I can't fathom how moving slower wouldn't help here.

I suggest we are done with both multiple competing implementations and alert system. Aren't we?

If yes, it is time to ask the critical questions once again:

What is there to be learned from CVE-2018-17144 incident? What measures should be taken hereafter?

I'm not used to it but exceptionally, I agree with Greg Maxwell here, multiple implementations is a stupid idea and removal of alert system in bitcoin was a correct decision, imo,  but I think it is more about what is right and what to do rather than rejecting false ideas and pointing out what should not be done.

 

The announcement of the new release and fix was sent to it.  You mean the guy who controls bitcoin.org isn't subscribed to it? That' s pretty ... suboptimal, if you ask me.

It's easy to point fingers and assert that the world would be better if other people acted according to your will instead of their own free will,  harder to look at your own actions and contemplate what you could to to improve things.  To risk making the same mistake myself: Instead of calling people who owe you nothing incompetent, you could offer to help...  Just a thought.  It's the advice that I've tried to follow myself, and I think it's helped improve the world a lot more than insults ever would.

https://bitcoincore.org/en/2016/03/15/announcement-list/

Apparently, according to Luke-jr who's subscribed, Bitcoin Core still hasn't even bothered to use their announcement mailing list (specifically set up for security issues and new releases) to warn about CVE-2018-17144 yet (a security issue fixed in a new release no less!). That's pretty incompetent if you ask me.

https://twitter.com/LukeDashjr/status/1043917007303966727

The fact that it created real vulnerabilities that could have been used to cause massive funds loss, even for people who removed the code, suggests otherwise!  Something doesn't have to be part of consensus rules directly to create a risk for the network.

The general coding style in Bitcoin makes RCEs unlikely, or otherwise I would say that I would be unsurprised if the ALERT system didn't have one at least at some point in its history... It was fairly sloppy and received inadequate attention and testing because of its infrequent use and because only a few parties (like the Japanes government ... ) could make use of it.

and I say this as one of the uh, I think, three people to have ever sent an alert.

Bitcoin is the consensus rules and protocol, which Bitcoin Core implements, but Bitcoin is not synonymous with everything in Bitcoin Core. The alert system was never part of the consensus rules, and therefore doesn't have anything to do with Bitcoin, so being excessively concerned with decentralization makes no sense in this context.

Maybe the previous implementation of an alert system was flawed, with the crashing bugs, and the alert key being controlled by dubious people, but this doesn't make alerts in and of themselves a terrible idea. The unlikely event of the alert key being abused are overcome by having a "final" alert broadcast, any harm an attacker could do is minimal. The benefits far outweigh the risks here. But somehow allowing for thousands of users to unknowingly be put into situations where they're running insecure financial software is acceptable for you so long as you believe it improves some vague notion of decentralization (it doesn't). Let's be glad this bug wasn't something that could be exploited to hack into nodes remotely and steal funds, like a buffer overflow or use-after-free.

I believe slower would potentially result in less testing and not likely result in more at this point.

If we had an issue that newly introduced features were turning out to frequently have serious bugs that are discovered shortly after shipping there might be a case that it would improve the situation to delay improvements more before putting them into critical operation... but I think we've been relatively free of such issues.  The kind of issues that just will be found with a bit more time are almost all already found prior to release.

Quadrupling the amount of (useful) testing would be great.  But the way to get there may be via more speed, not less. You might drive safer if you drove a bit slower, but below some speed, you become more likely to just fall asleep while driving.

Imagine a bridge construction crew with generally good safety practices that has a rare fatal accident. Some government bureaucrat swings in and says "you're constructing too fast: it would be okay to construct slower, fill out these 1001 forms in triplicate for each action you take to prevent more problems".  In some kind of theoretical world the extra checks would help, or at least not hurt.  But for most work there is a set of optimal paces where the best work is done.  Fast enough to keep people's minds maximally engaged, slow enough that everything runs smoothly and all necessary precautions can be taken.  We wouldn't be to surprised to see that hypothetical crew's accident rate go up after a change to increase overhead in the name of making things more safe: either efforts that actually improve safety get diverted to safety theatre, or otherwise some people just tune out, assume the procedure is responsible for safety instead of themselves, and ultimately make more errors.

So I think rather, it would be good to say that things should be safer _even if_ it would be slower. This is probably what you were thinking, but it's important to recognize that "just do things slower" itself will not make things safer when already the effort isn't suffering from momentary oopses.

Directing more effort into testing has been a long term challenge for us,  in part because the art and science of testing is no less difficult than any other aspect of the system's engineering. Testing involves particular skills and aptitudes that not everyone has.

What I've found is that when you ask people who aren't skilled at testing to write more tests when they generally write are rigid, narrow scope, known response tests.    So what they do is imagine the typical input to a function (or subsystem), feed that into it it, and then make the test check for exactly the result the existing function produces.  This sort of test is of very low value:  It doesn't test extremal conditions, especially not the ones the developer(s) hadn't thought of (which are where the bugs are most likely to be),  it doesn't check logical properties so it doesn't give us any reason to think that the answer the function is currently getting is _right_, and it will trigger a failure if the behaviour changes even if the change is benign, but only for the tested input(s). They also usually only test the smallest component (e.g. a unit test instead of a system test), and so they'll can't catch issues arising from interactions.  These sorts of tests can be worse than no test in several ways: they falsely make the component look tested when it isn't, and they create tests that spew false positives as soon as you change something which both discourages improvements and encourages people to blindly update tests and miss true issues. A test that alerts on any change at all can be appropriate for normative consensus code which must not change behaviour at all, but good tests for that need to test boundary conditions and random inputs too. That kind of test isn't very appropriate for things that are okay to change.

In this case, our existing practices (even those of two years ago) would have been at least minimially adequate to have prevented the bug. But they weren't applied evenly enough.  My cursory analysis of the issue suggests that there was a three component failure: The people who reviewed the change had been pre-primed by looking at the original introduction of the duplicate tests which had a strong proof that the test was redundant. Unfortunately, later changes had made it non-redundant apparently with realizing it. People who wouldn't have been snowed by it (e.g. Suhas never saw the change at all, and since he wasn't around for PR443 he probably wouldn't have easily believed the test was redundant) just happened to miss that the change happened, and review of the change got distracted by minutia which might have diminished its effectiveness. Github, unfortunately doesn't provide good tools to help track review coverage. So this is an area where we could implement some improved process that made sure that the good things we do are done more uniformly. Doing so probably won't make anything slower.  Similarly, a more systematic effort to assure that all functionality has good tests would go a long way: New things in Bitcoin tend to be tested pretty well, but day zero functionality that never had tests to begin with isn't always.

It takes time to foster a culture where really good testing happens, especially because really good testing is not the norm in the wider world.  Many OSS and commercial projects hardly have any tests at all, and many that do hardly have good ones. (Of course, many also have good tests too... it's just far from universal.)  We've come a long way in Bitcoin-- which originally had no tests at all, and for a long time only had 'unit tests' that were nearly useless (almost entirely examples of that kind of bad testing). Realistically it'll continue to be slow going especially since "redesign everything to make it easier to test well" isn't a reasonable option, but it will continue to improve. This issue will provide a nice opportunity to nudge people's focus a bit more in that direction.

I think we can see the negative the effect of "go slower" in libsecp256k1.   We've done a lot of very innovative things with regard to testing in that sub-project, including designing the software from day one to be amenable to much stronger testing and had some very good results from doing so.  But the testing doesn't replace review, and as a result the pace in the project has become very slow-- with nice improvements sitting in PRs for years. Slow pace results in slow pace, and so less new review and testing happen too. ... and also fewer new developments that would also improve security get completed.

The relative inaccessibility of multisig and hardware wallets are probably examples where conservative development in the Bitcoin project have meaningfully reduced user security.

It's also important to keep in mind that in Bitcoin performance is a security consideration too.  If nodes don't keep well ahead of the presented load, the result is that they get shut off or never started up by users, larger miners get outsized returns,  miners centralize, attackers partition the network by resource exhausting nodes.  Perhaps in an alternative universe where it in 2013 when it was discovered that prior to 0.8 nodes would randomly reject blocks under ~>500k if the block size were permanently limited to 350k we could have operated as if performance weren't critical to the survival of the system, but that it's what happened. So, "make the software triple check everything and run really slowly" isn't much of an option either especially when you consider that the checks themselves can have bugs.

You do realize that you're lamenting the removal of a back door key that could be used to remotely crash nodes?   Even without the crash it inherently meant that a single potentially compromised party had the power to pop up to all users of the software potentially misleading messages-- like falsely claiming there were issues that required replacing the software with insecure alternatives. At least when people get news "from the internet" there are many competing information sources that could warn people to hold off.

No thanks.

No one who wants that power should by any account be allowed to have it.  Not if Bitcoin is to really show its value as a decenteralized system.

I doubt doubt that better notification systems can be done... things designed to prevent single bad actors from popping up malicious messages, but even there there is no reason to have such tools directly integrated into Bitcoin itself.  I'd love to see someone create a messaging system that could send message in a way that no single compromised party could send a message or block publication, that messages couldn't be targeted at small groups but had to be broadcast even with the help of network attacks, where people could veto messages before they're displayed, where messages displaying would be spread out over time so users exposed earlier could sound the alarm for a bad message... etc.  But there is no reason for such a system to be integrated into Bitcoin, it would be useful far beyond it.

But it just goes to show that for every complex problem there is a simple centralized solution and inevitably someone will argue for Bitcoin to adopt it.

Just responding to this particular fork of discussion now,


They would create more risk. I don't think there is any reason to doubt that this is an objective fact which has been borne out by the history.

First, failures in software are not independent. For example, when BU nodes were crashing due to xthin bugs, classic were also vulnerable to effectively the same bug even though their code was different and some triggers that would crash one wouldn't crash the other. There have been many other bugs in Bitcoin that have been straight up replicated many times, for example the vulnerable to crash through memory exhaustion due to processing loading a lot of inputs from the database concurrently: every other implementation had it to, and in some it caused a lot more damage.

Even entirely independently written software tends to have  similar faults:

(source)

More critically, the primary thing the Bitcoin system does is come to consensus:  Most conceivable bugs are more or less irrelevant so long as the network behaves consistently.  Is an nlocktime check a < or a <= check? Who cares... except if nodes differ the network can be split and funds can be taken through doublespending the reorg.  Are weird "hybrid pubkeys" allowed? Who cares... except if nodes differ the network can be split and funds can be taken through doublespending the reorg.  What happens when a transaction has a non-nonsensical signature that indicates sighash single without a matching output? Who cares... except if nodes differ the network can be split and funds can be taken through doublespending the reorg. And so on.  For the vast majority of potential bugs having multiple incompatible implementations turns a non-event into a an increasingly serious vulnerability.

Even for an issue which isn't a "who cares" like allowing inflation of the supply adding a surprise disagreement between nodes does not help matters!  The  positive effect it creates is that you might notice it after the fact faster but for that benefit you don't actually need additional full implementations, just monitoring code.  In the case of CVE-2018-17144 the sanity checks on node startup would also detect the bad block. On the negative, they just cause a consensus split and result in people being exposed to funds loss in a reorg-- which is the same kind of exposure that they'd have in a single implementation + monitoring then fixing the issue when detected, other than perhaps the reorg(s) might be longer or shorter in one case or another.

In this case ABC also recently totally reworked the detection of double spends as a part of their "canonical transaction order" changes which require that double spending checks be differed and run as a separate check after processing because transactions are required to be out of their logical casual ordering.  Yet they both failed to find this bug as part of testing that change and also failed to accidentally fix it.

Through all the history of Bitcoin, altcoin forks copying the code, other reimplementations and many other consensus bugs, some serious and some largely benign,  this is the first time someone working on another serious implementation that someone actually uses has actually found one.  I might be forgetting something, but I'm certainly not forgetting many. Kudos to awemany. In all other cases they either had the same bugs without knowing it, or accidentally fixed it creating fork risk creating vulnerability without knowing it. It also isn't like there being multiple implementations is new-- for the purpose of this point every one of the 1001 altcoins created by copying the Bitcoin code count as a separate implementation too, or at least the ones which are actively maintained do.

Having more versions also dilutes resources, spreading review and testing out across other implementations. For the most part historically the Bitcoin project itself hasn't suffered much from this: the alternatives have tended to end up just barely maintained one or two developer projects (effectively orphaning users that depended on them, -- another cost to that diversity) and so it doesn't look like they caused much meaningful dilution to the main project.  But it clearly harms alternatives, since they usually end up with just one or two active developers and seldom have extensive testing.  Node diversity also hurts security by making it much more complicated to keep confidential fixes private. When an issue hits multiple things its existence has to be shared with more people earlier, increasing the risk of leaks and coincidentally timed cover changes can give away a fix which would otherwise go without notice. In a model with competing implementations some implementers might also hope to gain financially by exploiting their competitions bugs, further increasing the risk of leaks.

Network effects appear to have the effect that in the long run one one or maybe a few versions will ultimately have enough adoption to actually matter. People tend to flock to the same implementations because they support the features they need and can get the best help from others using the same stuff. Even if the benefits didn't usually fail to materialize, they'd fail to matter through disuse.

Finally, diversity can exist in forms other than creating more probability disused, probably incompatible implementations.  The Bitcoin software project is a decentralized collaboration of dozens of regular developers.  Any one of the participants there could go and make their own implementation instead (a couple have, in addition to).  The diversity of contributors there do find and fix and prevent LOTS of bugs, but do so without introducing to the network more incompatible implementations.   That is, in fact, the reason that many people contribute there at all: to get the benefit of other people hardening the work and to avoid damaging the network with potential incompatibilities.

All this also ignores the costs of implementation diversity unrelated to reliability and security, such as the redundancy often making improvements more expensive and slow to implement.

TLDR: In Bitcoin the system as a whole is vulnerable to disruption of any popular implementation has a consensus bug: the disruption can cause financial losses even for people not running the vulnerable software by splitting consensus and causing reorgs. Implementations also tend to frequently reimplement the same bugs even in the rare case where they aren't mostly just copying (or transliterating) code, which is good news for staying consistent but means that even when consistency isn't the concern the hoped-for benefit usually will not materialize. Also network effects tend to keep diversity low regardless, which again is good for consistency, but means but bad for diversity actually doing good. To the extent that diversity can help, it does so primarily through review and monitoring which are better achieved through collaboration on a smaller number of implementations.

Cheers,

I think the problem is that Core has too many developers, but not enough review/testing, and there's simply too much going on at once. When a lot of the changes are optimizations, refactoring, and the occasional networking/consensus touching stuff, it's inevitable you will get situations where a scary bug like this slips through due to all the emergent complexity. It's not like all these guys are doing GUI features. I like the idea of a fork with only necessary consensus changes (as these are very well tested). There should be two choices between reference implementations; "safe but slow" and "slightly more risky but fast". The more I think about it, the more a LTS version with only consensus changes and critical bug fixes makes a lot of sense in the context of Bitcoin.

To be honest, some really strange decisions get made at Bitcoin Core. For example, right now, a huge majority of the network is running vulnerable software, but because the alert system was removed, there's no way to reach them and tell them to upgrade. We just have to pray they check certain sites. Makes no sense. Some sort of alert feature in software that handles money is a necessity, it could have been enabled by default with an option to disable it. Satoshi was so smart and practical to add that.

I think I can guess where this is heading.     

---

Perhaps not everyone would need to.  If we adapt theymos' idea that larger Bitcoin companies should effectively place a small percentage of their employees on secondment with Core, what if instead they ran a Core node but also maintained a second node with their own business-oriented implementation?  Something that might focus more on features for merchants, for example.  Then they can report any inconsistencies and issues like would be far less likely to go unnoticed for 18 months?  I'm unsure how many companies it would take for the idea to be effective, but if it worked, that would help create a decent safety net.

I agree both problems you are mentioning are very crucial but I afraid they are not relevant in this context.

Definitively bitcoin is a protocol and as a protocol it should be implemented somehow. One might buy a closed source or code down to the metal a proprietary software and participate in the protocol but when people use an open source implementation for this, things become a bit more complicated. In other cases it would be users own responsibility  to take care of their safety but for open-source software it is community's credit that is being spent and ensures users about their security.  

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

As I understand, your concern is governance, but it is another topic (an unsolved one, I suppose) and there is no guarantee we could have an optimized solution for both immunity to software bugs and governance at the same time in one single package, at least right now.

As of your assertions about the limited value of running a full node, I do agree again, but when it comes to an implementation used by a significant number of users, this value accumulates to sensitive levels and people may lose both considerable amounts of money and (more importantly) their faith in the whole ecosystem.

This comes down to one's central belief as to what 'Bitcoin" is.....is Bitcoin  a collection of consensus rules? Or is it a software maintained by a very small group of people?

If your argument is that Bitcoin is a software run by a small group of people (eg. those who decide what gets published every time there is an upgrade), then Bitcoin is much more centralized than most central banks.

This also comes down to another important question as to who exactly should be running a full node? It is my belief that businesses and those who are going to receive bitcoin prior to giving anything of value to their trading partners are those who should run a full node. Anyone who sends valuable property to someone prior to receiving bitcoin is already at risk of outright not receiving bitcoin in return, so the value of running a fully validating node is minimal. Further, it is the responsibility of those who are running a full node to personally ensure the software they are running is going to preform as they believe it will, and to not rely on third parties for this.

It seems to me that would be very simple to know immediately when a double spend occurs.

Every node knows the length of the blockchain, every node knows which blocks generate 50 / 25 / 12.5 btc, then the sum of all bitcoin in the UTXO set is a simple function of the blockchain's length: s = f(length).

If my node receive a block and the total of bitcoin in my UTXO set grows more than 12.5 btc,  I will detect immediately a double spend.

It is very encouraging to see a prominent figure like OP starts a topic about this event admitting that there are lessons to be learned and measures to be taken. kudos theymos.  

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.

Seemingly, the "multiple implementations proposal" is trending right now in this thread. I don't know to what extent it could be considered a healthy proposal with good intentions but I'm sure it is neither correct nor practical to be considered an effective measure against vulnerabilities to implementation bugs. On the contrary it seems to be more dangerous rather than a helpful strategy.

Being decentralized does not change the fact that bitcoin is an integrated meta-system. Running multiple implementations of code in such a system is not recommended because it adds another complexity factor: Multiple implementations means more lines of code and hence more bugs. It will cause frequent chain splits and encourages a new range of sybil attacks.

Suggesting that no implementation should be used by a majority, besides its impracticality (who is in charge of imposing this rule?) does not seem to be of much help with this idea:
Firstly, it implies a new kind of consensus system, with no theoretical support. I'm not aware of any serious work covering a decentralized consensus based system that uses heterogeneity of implementations as a main or auxiliary security measure e.g. for immunity against software bugs.

Secondly, it is very unlikely that such an evenly distributed heterogeneity might help in damage control by localizing bugs. Nodes have to validate blocks independently and they don't apply longest/heaviest chain rule unless they have validated both chains beforehand. It is impossible for a wallet to feel something is wrong with its own code and decide to follow the majority blindly. One possible solution for such a schema would be running multiple implementations by a single federated node that uses a BFT algorithm to make final decisions. It has been suggested up-thread somehow and is infeasible because of  exaggerated costs and complexities involved.

Thirdly, adversaries would find it feasible to identify flaws in a single implementation and targeting its users (which typically are a minority) without compromising the whole ecosystem explicitly. In this scenario, although bitcoin won't collapse dramatically but the scammers might consider it an advantage as the funds they steal, preserve their value.

Conclusively, I would say this proposal, encouraging development and hiring multiple implementations of bitcoin protocols, shows negative indications and should be dropped as a serious proposal.

Hence the issue remains open: What happened and what measures should be taken to mitigate such disruptive problems?

I have something to suggest in this regard but for now I think it is more convenient to close the case with the multiple implementations proposal before proceeding any more.

Exchanges generally do not advertise the details of their nodes, so an attacker would not know that a specific vulnerability affects xx exchange. Further, an exchange may build their own implementation that may be very similar to another implementation.

In regards to your sybil attack, businesses customize their node software to ensure that their nodes connect to multiple implementations, and if block information varies between multiple implementations, they would know to troubleshoot to figure out what is going on. I also suspect that most exchanges handling significant amounts of money are using multiple nodes using multiple implementations already.

Even if what you say is true, which as I mention above, I disagree with, this would only affect individual businesses, not the entire network. Today, businesses get hacked on a fairly regular basis, and confidence is generally not lost as a result of this.

I think that I am misunderstanding what exactly this means.


Are they talking about the double spend input, that uses a previously created UTXO? Or are the talking about the newly created UTXO that had two double spend inputs and now has a block built on top of it?

Edit: I understand this better now. This answer on slack helped clear things up for me.  https://bitcoin.stackexchange.com/questions/79481/how-does-the-most-recently-found-critical-vulnerability-cve-2018-17144-work

Did you read the full disclosure? 0.14.x would always crash, but 0.15.0-0.16.2 could in some circumstances not crash, accepting the creation of counterfeit BTC as if it were normal.