theymos

Legendary



Offline



Activity: 3892

Merit: 7919







AdministratorLegendaryActivity: 3892Merit: 7919 The duplicate input vulnerability shouldn't be forgotten September 22, 2018, 07:47:55 AM Merited by mishax1 (10), Foxpup (9), Cøbra (6), suchmoon (4), LoyceV (2), bones261 (2), qwk (1), Velkro (1), ETFbitcoin (1), HeRetiK (1) #1 really bad. IMO it was the worst bug since 2010. If it had been exploited in a 0-day fashion, significant & widespread losses (due to acceptance of counterfeit BTC) would've been likely, and Bitcoin's reputation would've long been tarnished. Furthermore, since a ton of altcoins are based on Bitcoin Core, this would've affected a huge swath of the crypto space all at once.



Everyone's human, and secure software engineering is largely an unsolved problem. The Bitcoin Core devs have done a remarkably good job over the years; in fact, in this case they were able to recognize that a bug report for a DoS attack was actually a critical consensus bug, and then they managed to roll out a fix in a way which ending up protecting Bitcoin. I am thankful for their work and diligence. However, the fact that this bug was introduced and then allowed to exist from 0.14.0 to 0.16.2 was undeniably a major failure, and if all of Bitcoin Core's policies/practices are kept the same, then it's inevitable that a similar failure will eventually happen again, and we might not be so lucky with how it turns out that time.



Finger-pointing would not be constructive, but neither would it be sufficient to say "we just need more eyes on the code" and move on. This bug was very subtle, and I doubt that anyone would've ever found it by actually looking at the code. Indeed, the person who found it did so when they were doing something else and ended up tripping the assertion. Furthermore, this bug probably wouldn't have been found through standard unit testing, since this was a higher-level logic error. (By my count, something like 18% of the entire Bitcoin Core repository is tests, but that still didn't catch it.)



Perhaps all large Bitcoin companies should be expected by the community to assign skilled testing specialists to Core. This vulnerability could've been detected through more sophisticated testing methods, and currently a lot of companies don't contribute anything to Core development.



Perhaps the Core release schedule is too fast. Even though it sometimes already feels painfully slow, there's no particular "need to ship", so it could be slowed down arbitrarily in order to quadruple the amount of testing code or whatever.



Perhaps there should be more support and acceptance for running older versions, or a LTS branch, or a software fork focused on stability. The are a few hundred people still using 0.13.2, and they were the only Bitcoin users completely safe from this vulnerability.



I do not think that it would be constructive to turn to any of the full node total-reimplementations like btcd, which are very amateur in comparison to Bitcoin Core.



I don't know exactly how this can be prevented from happening again, but I do know that it would be a mistake for the community to brush off this bug just because it ended up being mostly harmless this time. The bug fixed in Bitcoin Core 0.16.3 wasbad. IMO it was the worst bug since 2010. If it had been exploited in a 0-day fashion, significant & widespread losses (due to acceptance of counterfeit BTC) would've been likely, and Bitcoin's reputation would've long been tarnished. Furthermore, since a ton of altcoins are based on Bitcoin Core, this would've affected a huge swath of the crypto space all at once.Everyone's human, and secure software engineering is largely an unsolved problem. The Bitcoin Core devs have done a remarkably good job over the years; in fact, in this case they were able to recognize that a bug report for a DoS attack was actually a critical consensus bug, and then they managed to roll out a fix in a way which ending up protecting Bitcoin. I am thankful for their work and diligence. However, the fact that this bug was introduced and then allowed to exist from 0.14.0 to 0.16.2, and if all of Bitcoin Core's policies/practices are kept the same, then it's inevitable that a similar failure will eventually happen again, and we might not be so lucky with how it turns out that time.Finger-pointing would not be constructive, but neither would it be sufficient to say "we just need more eyes on the code" and move on. This bug was very subtle, and I doubt that anyone would've ever found it by actuallyat the code. Indeed, the person who found it did so when they were doing something else and ended up tripping the assertion. Furthermore, this bug probably wouldn't have been found through standard unit testing, since this was a higher-level logic error. (By my count, something like 18% of the entire Bitcoin Core repository is tests, but that still didn't catch it.)Perhaps all large Bitcoin companies should be expected by the community to assign skilled testing specialists to Core. This vulnerabilitybeen detected through more sophisticated testing methods, and currently a lot of companies don't contribute anything to Core development.Perhaps the Core release schedule is too fast. Even though it sometimes already feels painfully slow, there's no particular "need to ship", so itbe slowed down arbitrarily in order to quadruple the amount of testing code or whatever.Perhaps there should be more support and acceptance for running older versions, or a LTS branch, or a software fork focused on stability. The official maintenance policy says that the current and previous major release is supported, but that doesn't seem to be closely followed. In this bug, backports were written for 0.14.x and 0.15.x, but as of this writing no binaries have been released for those, even days after 0.16.3's release. SegWit didn't have any backports when it was released, even though users would've needed to enforce SegWit in order to achieve full security if SegWit had activated as quickly as originally hoped. Sometimes fixes are backported to an old version's git branch but no release is actually made. If 0.13.x is not currently supported, then there was no supported version without the vulnerability. This might indicate that the maintenance period isn't long enough; therea few hundred people still using 0.13.2, and they were the only Bitcoin users completely safe from this vulnerability.I dothink that it would be constructive to turn to any of the full node total-reimplementations like btcd, which are very amateur in comparison to Bitcoin Core.I don't know exactly how this can be prevented from happening again, but I do know that it would be a mistake for the community to brush off this bug just because it ended up being mostly harmless this time. 1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD

piotr_n



Offline



Activity: 2040

Merit: 1062





aka tonikt







LegendaryActivity: 2040Merit: 1062aka tonikt Re: The duplicate input vulnerability shouldn't be forgotten September 22, 2018, 08:50:24 AM

Last edit: September 22, 2018, 09:02:26 AM by piotr_n Merited by klondike_bar (1), pawel7777 (1), Kupsi (1) #3



Just try to not ban me from all your forums by that time Since I might be the only person running an actual alternative, bitcoind independent implementation of a node, I promise to let you know when someone mines a broken block and all your software won't realize it.Just try to not ban me from all your forums by that time Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.

PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E

aleksej996



Offline



Activity: 490

Merit: 329





Do not trust the government







Sr. MemberActivity: 490Merit: 329Do not trust the government Re: The duplicate input vulnerability shouldn't be forgotten September 22, 2018, 01:05:01 PM #6 I agree with DooMad completely. Diversity is the only real solution to network security.



We have to deal with the fact that bugs are found in absolutely ALL software.

Only thing we can hope is that it is: A) rare that bugs are found in all software at the same time and B) that no single entity will likely have all of these bugs at that time.



You can put million top tier devs on the code and they will still let a bug go through every few decades,

Security of the entire Internet isn't that there is low level code that is perfectly secure, but that there are many different systems and implementations running it. You need to have more implementations to have any chance of long term survival.

achow101

Legendary





Offline



Activity: 2254

Merit: 3456





bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl







ModeratorLegendaryActivity: 2254Merit: 3456bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl Re: The duplicate input vulnerability shouldn't be forgotten September 22, 2018, 03:15:32 PM Merited by Foxpup (6), DooMAD (2), LoyceV (2), ETFbitcoin (1) #7 Quote from: DooMAD on September 22, 2018, 09:28:57 AM 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.

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. GitHub | GPG Key Fingerprint 0x17565732E08E5E41 Bitcoin Core contributor | Tip Me!: bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl

Quickseller

Legendary



Offline



Activity: 2226

Merit: 1953







Copper MemberLegendaryActivity: 2226Merit: 1953 Re: The duplicate input vulnerability shouldn't be forgotten September 22, 2018, 03:24:16 PM #8 Quote from: theymos on September 22, 2018, 07:47:55 AM If it had been exploited in a 0-day fashion, significant & widespread losses (due to acceptance of counterfeit BTC) would've been likely,

I am weary of this assertion. Many bitcoin related businesses use custom implementations of Bitcoin that are based on the underlying consensus rules. The same is true for the miners today (even if they broadcast they are using other implementations), so I doubt a single malicious actor could have gotten counterfeit BTC more than a small number of confirmations.



I would echo what DooMAD said in that the solution is to encourage more implementations, and for each implementation to not have a high percentage of overall nodes.



At the end of the day, the Bitcoin network is nothing more than a bunch of consensus rules that everyone follows.



Quote from: achow101 on September 22, 2018, 03:15:32 PM 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.



The solution to this is simple, and it is that the blockchain (whose tip contains the most cumulative work) that follows all of the consensus rules is the Bitcoin blockchain, and any fork of this is not (in many cases, it would be an altcoin intentionally created).



The incentive to attack an implementation that is used by 10%-20% of the Bitcoin network is much smaller than the incentive to attack an implementation that affects 90% of the network. The further would be a minor hiccup, while the later has the potential to actually steal large amounts of money, and cause serious disruptions. I am weary of this assertion. Many bitcoin related businesses use custom implementations of Bitcoin that are based on the underlying consensus rules. The same is true for the miners today (even if they broadcast they are using other implementations), so I doubt a single malicious actor could have gotten counterfeit BTC more than a small number of confirmations.I would echo what DooMAD said in that the solution is to encourage more implementations, and for each implementation to not have a high percentage of overall nodes.At the end of the day, the Bitcoin network is nothing more than a bunch of consensus rules that everyone follows.The solution to this is simple, and it is that the blockchain (whose tip contains the most cumulative work) that follows all of the consensus rules is the Bitcoin blockchain, and any fork of this is not (in many cases, it would be an altcoin intentionally created).The incentive to attack an implementation that is used by 10%-20% of the Bitcoin network is much smaller than the incentive to attack an implementation that affects 90% of the network. The further would be a minor hiccup, while the later has the potential to actually steal large amounts of money, and cause serious disruptions. The head executive of the executive office of the department of the redundancy departments office

bones261



Offline



Activity: 1806

Merit: 1823









LegendaryActivity: 1806Merit: 1823 Re: The duplicate input vulnerability shouldn't be forgotten September 22, 2018, 04:01:05 PM #9 Quote from: theymos on September 22, 2018, 07:47:55 AM If it had been exploited in a 0-day fashion, significant & widespread losses (due to acceptance of counterfeit BTC) would've been likely,



I am uncertain how any miner would have been able to spread counterfeit coins effectively, since the other aspect of the bug was to cause nodes to crash. Wouldn't this have hampered the transfer of coins on the renegade chain? The only strategy that I can see for an attacking miner would have been to implement shorts before the attack, and somehow close the shorts after the bad news has spread, but before the exchange(s) freeze the trading. They would then have to transfer the ill gotten funds off the exchange(s) in a hurry, before the victim exchange(s) caught on and froze their account. I am uncertain how any miner would have been able to spread counterfeit coins effectively, since the other aspect of the bug was to cause nodes to crash. Wouldn't this have hampered the transfer of coins on the renegade chain? The only strategy that I can see for an attacking miner would have been to implement shorts before the attack, and somehow close the shorts after the bad news has spread, but before the exchange(s) freeze the trading. They would then have to transfer the ill gotten funds off the exchange(s) in a hurry, before the victim exchange(s) caught on and froze their account.

achow101

Legendary





Offline



Activity: 2254

Merit: 3456





bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl







ModeratorLegendaryActivity: 2254Merit: 3456bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl Re: The duplicate input vulnerability shouldn't be forgotten September 22, 2018, 05:27:33 PM Merited by suchmoon (4), Foxpup (2) #10 Quote from: Quickseller on September 22, 2018, 03:24:16 PM The solution to this is simple, and it is that the blockchain (whose tip contains the most cumulative work) that follows all of the consensus rules is the Bitcoin blockchain, and any fork of this is not (in many cases, it would be an altcoin intentionally created).

The complexity comes in ensuring that the network is no longer partitioned and that everyone has received the blockchain with the most cumulative work.



Quote from: Quickseller on September 22, 2018, 03:24:16 PM The incentive to attack an implementation that is used by 10%-20% of the Bitcoin network is much smaller than the incentive to attack an implementation that affects 90% of the network. The further would be a minor hiccup, while the later has the potential to actually steal large amounts of money, and cause serious disruptions.

I disagree.



Suppose there is an exchange that happens to be connected to some nodes that are vulnerable to some kind of attack. Or perhaps they aren't connected directly to those nodes, but connected to node which are connected to those nodes. Suppose this attack causes those nodes to go offline or otherwise become disconnected from the network. Even if there are a very small number of these vulnerable nodes, if they happen to form a ring around the exchange, an attacker can attack those nodes and cause the network to partition. It would break into at least two pieces: the chunk containing the exchange, and the rest of the network. The attacker, if he has some hashrate, can now be mining a fork of the blockchain specifically created so that he can attack this exchange. Since this is a fork for a part of the network that is no longer receiving the rest of the blockchain, this attacker has 100% of the hashrate for that fork and can do everything with it that anyone with >51% of the hashrate can do. This kind of attack does not need a large number of nodes to be vulnerable, it just needs enough so that an attacker can partition the network. The complexity comes in ensuring that the network is no longer partitioned and that everyone has received the blockchain with the most cumulative work.I disagree.Suppose there is an exchange that happens to be connected to some nodes that are vulnerable to some kind of attack. Or perhaps they aren't connected directly to those nodes, but connected to node which are connected to those nodes. Suppose this attack causes those nodes to go offline or otherwise become disconnected from the network. Even if there are a very small number of these vulnerable nodes, if they happen to form a ring around the exchange, an attacker can attack those nodes and cause the network to partition. It would break into at least two pieces: the chunk containing the exchange, and the rest of the network. The attacker, if he has some hashrate, can now be mining a fork of the blockchain specifically created so that he can attack this exchange. Since this is a fork for a part of the network that is no longer receiving the rest of the blockchain, this attacker has 100% of the hashrate for that fork and can do everything with it that anyone with >51% of the hashrate can do. This kind of attack does not need a large number of nodes to be vulnerable, it just needs enough so that an attacker can partition the network. GitHub | GPG Key Fingerprint 0x17565732E08E5E41 Bitcoin Core contributor | Tip Me!: bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl

piotr_n



Offline



Activity: 2040

Merit: 1062





aka tonikt







LegendaryActivity: 2040Merit: 1062aka tonikt Re: The duplicate input vulnerability shouldn't be forgotten September 22, 2018, 06:21:27 PM

Last edit: September 22, 2018, 06:31:29 PM by piotr_n Merited by aleksej996 (2) #11 Fork would be much less of a problem than building block chain with blocks that inflate the coin supply without anyone realizing.



Existence of an unexpected fork is a serious alarm signal that the entire system can act upon, e.g by stopping any economic activity until the situation clears up.



But what are you going to do upon realizing that e.g. for the past week someone has been mining blocks that increased the amount of coins in his wallet by 10% of the extra BTC supply?



Obviously, as soon as you realize the screw up you make sure everyone upgrades the software.

But how are you going to handle the existing damage?

Well, I think in such case you basically end up with only two choices:



1) You let the guy keep the money he created out of a thin air, most of which he probably already spent anyway - all the expense of all the other bitcoin holders.



2) You invalidate all the blocks (transactions) from the past week - pushing the damage on the ones that accepted any payments during that time.



You can also think of invalidating the coins that were "added illegally", kind of like ethereum did with DAO hack (although they invalidated a reallocation of coins, not creation of new ones).

But assuming that the guy who came out with the exploit wasn't an idiot, they are long spent already and mixed with a "legal" coins, so that's not really an option.



My point is: whenever such a catastrophic event happens we want to know about it as soon as possible, to try preventing the damage.

That is why having only one software implementation is a very bad idea. Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.

PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E

piotr_n



Offline



Activity: 2040

Merit: 1062





aka tonikt







LegendaryActivity: 2040Merit: 1062aka tonikt Re: The duplicate input vulnerability shouldn't be forgotten September 22, 2018, 07:19:02 PM #14 Quote from: achow101 on September 22, 2018, 07:09:43 PM Quote from: piotr_n on September 22, 2018, 06:21:27 PM My point is: whenever such a catastrophic event happens we want to know about it as soon as possible, to try preventing the damage.

That is why having only one software implementation is a very bad idea.

That's why I said in an earlier post that having the same person run multiple software is good. I don't think that if everyone was running different software that the problem would be noticed significantly faster than if everyone were using the same software. That's why I said in an earlier post that having therun multiple software is good. I don't think that if everyone was running different software that the problem would be noticed significantly faster than if everyone were using the same software.

It doesn't have to be the same person.

Like in this case, if such an event happened that there was a block that was trying to spend the same input twice, my node would just not let it through and got stuck on one block, which would make me to analyze why, which would maybe trigger an alarm.

It's obviously better if more people run the node like mine. Because sometimes I'm busy It doesn't have to be the same person.Like in this case, if such an event happened that there was a block that was trying to spend the same input twice, my node would just not let it through and got stuck on one block, which would make me to analyze why, which would maybe trigger an alarm.It's obviously better if more people run the node like mine. Because sometimes I'm busy Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.

PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E PGP fingerprint: AB9E A551 E262 A87A 13BB 9059 1BE7 B545 CDF3 FD0E

aleksej996



Offline



Activity: 490

Merit: 329





Do not trust the government







Sr. MemberActivity: 490Merit: 329Do not trust the government Re: The duplicate input vulnerability shouldn't be forgotten September 22, 2018, 10:19:05 PM #16 Yeah, what are the chances of this never happening again?

Very small, we need to accept it. Better a fork then a complete failure.



The way I see it we need to start doing 2 things as a community:

1) Operators that are running full nodes that want to contribute more to the network should start running more nodes with different implementations.

2) We should connect our nodes to nodes running different implementations and have warnings pop up in case of a chain-split.

3) We need more good quality implementations.



Even this will not protect us 100% from a potential network-wide vulnerability, but it is a hell of a lot better.