The duplicate input vulnerability shouldn't be forgotten

[Hueristic]

...I am one of the only project contributors who actually takes the time to even try to communicate with people who seem to be significantly confused. 99.9% of the time other people will just ignore them completely. I don't think it helps improve the level of discourse if everyone puts themselves in a high castle and doesn't even hear out their opposition or respect them enough to even argue the case.  But at least when I'm critical of your actions I'm willing to be precise enough that you can defend or contextualize them... or even admit a mistake.  I've certainly made mistakes, but at least I've tried to do something good. I fee like your comments here-- with name calling like "incompetent"-- are saying that you'd prefer a world where no one does anything (except maybe insult and conspiracy theorize about others), because if the they do enough good things you'll ignore all that and attack them for the few things that could be improved.  If that isn't what you're going for, I'd really like you to help me understand where you're coming from....

OT:
I would just like to point out that I, and I'm sure there are many others, appreciate the effort you put into responding even though we do not insert ourselfs into the conversation because we know that we are not well enough versed in the code and/or game theory. For everyone in the conversation there are thousands that did not ask the same question no matter what it was. So I'm just posting that it is appreciated that you spend the time to do so. I also appreciate the fact that when I go back and research something I usually find a post from you and that is a post that I can take to the bank. Ok, enough brown nosing, keep up the good work.

[1714038279]

1714038279

[1714038279]

1714038279

[1714038279]

1714038279

[Quickseller]

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. 

[RHavar]

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.

[gmaxwell]

run multiple implementations of bitcoin (e.g. btcd and bitcoin core) and only transact while they are in agreeance.

Monitoring that way can be interesting (use old versions too)... but running them anywhere near proximity to production machines may increase the risk of RCEs and resource exhaustion attacks. Though since you only need a yes/no from the monitoring it could be isolated without too much trouble.  If this were considered a best practice, though, it would further increase the barrier of entry for participation.

You are a lot more advanced than many Bitcoin using businesses: you actually report bugs and help test fixes. For many others, it's remarkable if they do anything more than call out to a bc.i api. Someone on IRC was pointing out the rather disappointing number of bitcoin sites that were currently managing to expose the bitcoind rpc to the public internet. 

[btc_enigma]

I know this is probably the last argument most people want to hear, but is this not a case where more independent implementations would result in less risk?  If you maintain that one particular client should form the "backbone of the network", you have to consider what happens if that backbone breaks.  If there were a wider variety of clients being run, there may have been less of a threat to the network overall?

Core have done exceptional work, but at the end of the day, they're still only human.  Assigning more people to keep an eye on one codebase might help mitigate faults, but if there's only one main codebase, there's still going to be an issue if an error slips through the net.  Hence my belief that more codebases would create a stronger safeguard.

What many people do not realize is that having people run different implementations makes it easier for attackers to partition the network and thus harder to resolve situations where vulnerabilities are exploited. Network partitioning can cause multiple blockchain forks which is a much harder situation to resolve than a single fork or an entire network shutdown.  It is not just that some nodes will go down and the rest are up and the network is still running. If the attack is directed in a certain way, miners will be separated and no longer connected to each other which then causes forks. Network partitioning is a serious issue, and running different implementations makes it easier for attackers to partition the network. So having multiple implementations and recommending that people run alternative software is really not a good thing.

That being said, having multiple implementations is good for the individual who runs multiple nodes with different implementations. With multiple nodes each with different software, attacks exploiting critical bugs lets them know if an attack is going on. If everyone ran multiple nodes with different implementations, then multiple implementations are fine. The network would not shutdown and there wouldn't be any network partitioning. But not everyone is going to do that.

Excellent point here. Totally agree the risk of managing multiple forks is much greater

What I also wanted to add is why this bug was not detected in testnet3 ? While we don't expect all bug to be detected during code review, most network/consesus related bugs should be detected in testnet

Perhaps the less use/importance of testnet is a cause of worry. If testnet3 mirrors mainnet in size and traffic, and  we give 6 months staging time for each release on testnet, we could have a more robust protection.  

[kain134]

* kain134 eating popcorn.

Maybe it's time to promote more Bitcoin Knots and other node software that is not Core? Seems to me like having multiple implementations that are not forks of another another will provide a resilience against bugs.

[AGD]

I hope we will end up with a solution, that is focused on more testing AND the advancement of new coding talents, by the regulars - maybe through Bitcoin specific coding challenges/training, bounties etc.
Also, if coders are being paid by a company, that is depending on a healthy Bitcoin network, this is obv. good for everyone in the network.

I also see an extended testing as the best solution to the intentional injecting of bad code by infiltrated state/organisation/company actors, which is probably already taken place at this time.

[_biO_]

* kain134 eating popcorn.

Maybe it's time to promote more Bitcoin Knots and other node software that is not Core? Seems to me like having multiple implementations that are not forks of another another will provide a resilience against bugs.

1) Bitcoin Knots *is* Bitcoin Core plus some enhancements and perhaps different defaults, AFAIK.

2) Read the thread. Multiple implementations *increase* risk.

[Lauda]

I know this is probably the last argument most people want to hear, but is this not a case where more independent implementations would result in less risk?

No. This is nonsense that has been pushed by those actively trying to co-opt the network (or propagated by trolls such as franky). Sure, it would be beneficial to have some competition on e.g. the p2p code but that's about it. More implementations as a side-effects can (and undoubtedly will) lead to even more problems, which will most certainly be harder to solve once multiple node implementations of the network start disagreeing due to whatever reason (be it a bug in this case). <- this is given that you completely ignore that any attempt at a secondary implementation so far has been amateurish at best.

Multiple implementations *increase* risk.

^

Someone on IRC was pointing out the rather disappointing number of bitcoin sites that were currently managing to expose the bitcoind rpc to the public internet.  

Sadly, yes. Project idea: a open-source, complete web implementation (frontend and whatnot).

Back on topic, I think there's two sets of Core users: those who run their node and rarely update it, and the more enthusiastic ones who keep up with upgrades. It might make sense to have a LTS version with more thoroughly tested and vetted consensus critical code (that's proven itself), and a regular version. I think more choice and flexibility could be useful here.

LTS version adoption would make it significantly harder to do a fork bugfix/upgrade whenever it gets needed though.

[DooMAD]

I know this is probably the last argument most people want to hear, but is this not a case where more independent implementations would result in less risk?

No. This is nonsense that has been pushed by those actively trying to co-opt the network  

Slightly OT, but can a consensus based system ever really be co-opted, though?  Everyone seems to have their own slightly different ideas of what makes Bitcoin what it is.  If you find yourself on a minority fork, it's because you aren't following consensus.  It's the numbers that matter, not what any one person believes Bitcoin "should" be.  Even though we might disagree with them, many BCH users will argue that Bitcoin has already been co-opted, but the simple fact remains they don't have the numbers behind them to do anything with that assertion.  So they have to settle for being an altcoin.  That's just how it is.  A day may come where you find yourself on the wrong side of consensus.  If that day comes, you would then find yourself deciding whether it's more important to stick with what you think it should be, or to accept it for what it is.  Maybe that's all getting a bit philosophical, though.

Back to the main purpose of the thread, though.  Yes, there are definitely some issues with multiple implementations if it's done in the wrong way.  It seems there's no simple answer to this one.  Aside from the things gmaxwell and achow101 mentioned, I suspect one of the primary flaws with multiple implementations is that much of the code would simply be copied from other implementations anyway.  It wouldn't necessarily ensure catching any present faults, even if people were taking the effort to run two different clients to compare results.  If they've inadvertently duplicated the bug, it won't make any difference.  Much like how any of the altcoins that may have been affected didn't spot duplicate inputs either.

[piotr_n]

It seems to me that what we're observing here is central planers trying to defend their monopoly.
And need I to remind you that the very reason for Bitcoin to exist, being such a phenomenal success, is breaking a monopoly of central planners?

I'm not even trying to convince anyone that this monopoly is a bad thing, simply because I think that it isn't going to matter. If Bitcoin is here to stay, it is just a matter of time before the market players build alternative implementations, customized for their own needs. And the fact that central planners have been stating for quite long that they "don't care about miners" is most likely only going to accelerate the process.

I know for a fact that making a new implementation is not as hard as the legends say. With a proper team it can be done for a reasonable amount of money and the money invested is meant to pay back later.

Let's be honest, the current bitcoin core software/implementation is a direct inheritance of the prototype made by Satoshi. Some components were upgraded or replaced, but the general architecture has not changed since its inception. It's hardly the best architecture for any possible application, maybe even not the best architecture for any specific app.

So if Bitcoin is here to stay, new implementations coming into existence are inevitable. Not only because there are better ways to do what bitcoin core does, but also because there is (will be) too much money at sake and the stakeholders will not be willing to risk their money by relying on only one software implementation and the responsiveness of one team of people who don't even work for them.

And no matter how much you'd want to, you can't stop anyone from running a compatible yet alternative implementation of a bitcoin node.

[Lauda]

It seems to me that what we're observing here is central planers trying to defend their monopoly.

If you believe that there are central planers and a monopoly, then you don't understand Bitcoin.

And the fact that central planners have been stating for quite long that they "don't care about miners" is most likely only going to accelerate the process.

Miners are often idiots and don't decide anything (they shouldn't anyways).

So if Bitcoin is here to stay, new implementations coming into existence are inevitable.

Many have tried.

this is given that you completely ignore that any attempt at a secondary implementation so far has been amateurish at best.

And no matter how much you'd want to, you can't stop anyone from running a compatible yet alternative implementation of a bitcoin node.

If you want to, then you're free to swim in second-grade garbage.

[piotr_n]

It seems to me that what we're observing here is central planers trying to defend their monopoly.

If you believe that there are central planers and a monopoly, then you don't understand Bitcoin.

And the fact that central planners have been stating for quite long that they "don't care about miners" is most likely only going to accelerate the process.

Miners are often idiots and don't decide anything (they shouldn't anyways).

So if Bitcoin is here to stay, new implementations coming into existence are inevitable.

Many have tried.

this is given that you completely ignore that any attempt at a secondary implementation so far has been amateurish at best.

And no matter how much you'd want to, you can't stop anyone from running a compatible yet alternative implementation of a bitcoin node.

If you want to, then you're free to swim in second-grade garbage.

No, sir. Your jealous comments are amateurish at best.

My software might not have been tested as much as satoshi's code base, but its proven to be working very well, has an excellent performance and it's very easy to work with because of its brilliant architecture.
Plus, most of all, it would not have accepted a block with a transaction that spends the same input twice, nor crash upon it. Which is what all this thread is about.

[Lauda]

No, sir. Your jealous comments are amateurish at best.

My software might not have been tested as much as satoshi's code base, but its proven to be working very well, has an excellent performance and it's very easy to work with because of its brilliant architecture.

Who exactly was talking about your software? Classic deflection.

Plus, most of all, it would not have accepted a block with a transaction that spends the same input twice, nor crash upon it. Which is what all this thread is about.

Lucky.

[piotr_n]

No, sir. Your jealous comments are amateurish at best.

My software might not have been tested as much as satoshi's code base, but its proven to be working very well, has an excellent performance and it's very easy to work with because of its brilliant architecture.
Plus, most of all, it would not have accepted a block with a transaction that spends the same input twice, nor crash upon it. Which is what all this thread is about.

Who exactly was talking about your software? Classic deflection.

You were:

any attempt at a secondary implementation so far has been amateurish at best.

[Lauda]

No, sir. Your jealous comments are amateurish at best.

My software might not have been tested as much as satoshi's code base, but its proven to be working very well, has an excellent performance and it's very easy to work with because of its brilliant architecture.
Plus, most of all, it would not have accepted a block with a transaction that spends the same input twice, nor crash upon it. Which is what all this thread is about.

Who exactly was talking about your software? Classic deflection.

You were:

any attempt at a secondary implementation so far has been amateurish at best.

No; stop using this thread as a means to promote an implementation that has 0 active reviewers (and probably 0 users; excl. the creator).

[piotr_n]

No; stop using this thread as a means to promote the implementation that has 0 active reviewers and probably 0 users.

You stop judging implementations that you haven't even made an effort to see.

Number of reviewers doesn't mean shit.
We've just seen that all it takes is one celebrity saying "it's safe" and none of the dozens of reviewers is even going to question that.
Behavior of the crowd is a bitch. That's why I prefer to work alone.

[Lauda]

You stop judging implementations that you haven't even made an effort to see.

I don't need to see it; you've already described it as a one-person (garbage) project.

Number of reviewers doesn't mean shit.

When it comes to 0 reviewers vs. decent number of reviewers, that's objectively false.

That's why I prefer to work alone.

That's obviously better for everyone.

[spartacusrex]

Base Protocol needs to be set in stone.

Very hard to write multiple implementations of a moving target.

[piotr_n]

You stop judging implementations that you haven't even made an effort to see.

I don't need to see it; you've already described it as a one-person (garbage) project.

Then you know very little about software development, my friend.
In my life I've made many one-person projects and those who paid me for them were never disappointed.
And unlike you, they weren't idiots.

Number of reviewers doesn't mean shit.

When it comes to 0 reviewers vs. decent number of reviewers, that's objectively false.

Obviously not always, as the event we're talking about clearly proves.

Code created entirely by one person has an advantage of that person understanding it better.
Which generally lowers a chance of that person making a mistake while changing it.