Bitcoin Forum
July 23, 2019, 06:49:39 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1] 2 3 4 5 »  All
  Print  
Author Topic: The duplicate input vulnerability shouldn't be forgotten  (Read 1908 times)
theymos
Administrator
Legendary
*
Offline Offline

Activity: 3458
Merit: 6005


View Profile
September 22, 2018, 07:47:55 AM
Merited by mishax1 (10), Foxpup (9), Cøbra (6), suchmoon (4), bones261 (2), LoyceV (2), qwk (1), Velkro (1), ETFbitcoin (1), HeRetiK (1)
 #1

The bug fixed in Bitcoin Core 0.16.3 was 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 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; there 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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
1563864579
Hero Member
*
Offline Offline

Posts: 1563864579

View Profile Personal Message (Offline)

Ignore
1563864579
Reply with quote  #2

1563864579
Report to moderator
1563864579
Hero Member
*
Offline Offline

Posts: 1563864579

View Profile Personal Message (Offline)

Ignore
1563864579
Reply with quote  #2

1563864579
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1563864579
Hero Member
*
Offline Offline

Posts: 1563864579

View Profile Personal Message (Offline)

Ignore
1563864579
Reply with quote  #2

1563864579
Report to moderator
ETFbitcoin
Legendary
*
Offline Offline

Activity: 1708
Merit: 1872

Use SegWit and enjoy lower fees.


View Profile WWW
September 22, 2018, 08:09:49 AM
Last edit: September 23, 2018, 08:25:23 AM by ETFbitcoin
 #2

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.

I doubt this will happen since some exchange/services hacked because security hole which isn't related with Cryptocurrency directly. This might work on DEX which is open source and a bug would be fatal.

Perhaps there should be more support and acceptance for running older versions, or a LTS branch, or a software fork focused on stability.

LTS branch/version should work well since some open-source software/OS use similar way and it works well. IMO Newer LTS version only need to be released when there's major upgrade such as P2SH, SegWit and Schnorr.

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.

Surely it's very risky since there's higher chance accidentally make new bug, especially if it's done on different language. But that doesn't mean i'm against alternative implementation/client.

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.

From this bug and 0.8 upgrade bug, IMO there should be draft/plan to upgrade/backroll the network quickly in case critical vulnerability is found or exploited.

piotr_n
Legendary
*
Offline Offline

Activity: 1988
Merit: 1048


aka tonikt


View Profile WWW
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

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 Smiley

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
DooMAD
Legendary
*
Offline Offline

Activity: 2044
Merit: 1314


Leave no FUD unchallenged


View Profile WWW
September 22, 2018, 09:28:57 AM
Last edit: September 22, 2018, 09:38:59 AM by DooMAD
Merited by bones261 (2), aleksej996 (2), mprep (1), pawel7777 (1), ETFbitcoin (1)
 #4

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.

LeGaulois
Copper Member
Legendary
*
Offline Offline

Activity: 1134
Merit: 1135

Bitcoin Ninja Unregulated Banker Unbanking Folks


View Profile
September 22, 2018, 11:54:53 AM
 #5

Quote
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.


Why companies should contribute to Core? To get the possibility in the future to say "Powered by <insert company name>" ?

There are a lot of people who won't trust cryptocurrency anymore, especially the newbies and the people who weren't interested in crypto. And the fact that the bug has been "accidentally" found is not so reassuring. Who knows what would have happened if the bug would not be fixed? Maybe in 2010 it wasn't a big deal since but in 2018, the results could be a lot different (I am not talking technically)


aleksej996
Sr. Member
****
Offline Offline

Activity: 476
Merit: 327


Do not trust the government


View Profile WWW
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
Moderator
Legendary
*
expert
Offline Offline

Activity: 1834
Merit: 2558


bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl


View Profile WWW
September 22, 2018, 03:15:32 PM
Merited by Foxpup (6), DooMAD (2), LoyceV (2)
 #7

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.

Quickseller
Copper Member
Legendary
*
Offline Offline

Activity: 1848
Merit: 1717



View Profile WWW
September 22, 2018, 03:24:16 PM
 #8

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.  

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.

Click Here to See Alex Morgan Twerking||2nd Video
(Videos Suchmoon doesn’t want you to see)
bones261
Legendary
*
Offline Offline

Activity: 1624
Merit: 1662


KnowNoBorders.io


View Profile
September 22, 2018, 04:01:05 PM
 #9

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.

   ▄▄██████▄▄
  ████████████
███▄▄
 ██████████████▀▀▀██▄
████████████████   ▀██▄
████████████████     ▀██
██████████████       ██▌
██████████████        ▐██
██▌▀▀██████▀▀         ▐██
▐██                   ██▌
 ██▄                 ▄██
  ▀██▄             ▄██▀
    ▀██▄▄▄     ▄▄▄██▀
      ▀▀█████████▀▀





█████████████████████████
███████▀▀       ▀▀███████
████▀   ▄ ▀███▀ ▄   ▀████
███  ▄████▄ ▀ ▄████▄  ███
██  ▄ ▀███▀ ▄ ▀███▀ ▄  ██
█  ▄██ ▀▀ ▄███▄ ▀▀ ██▄  █
█  █▀ ▄█ ███████ █▄ ▀█  █
█   ▄███▄ █████ ▄███▄   █
██  ████▀ ▄▄▄▄▄ ▀████  ██
███  ▀ ▄ ▀█████▀ ▄ ▀  ███
████▄  ▀▀▄ ███ ▄▀▀  ▄████
███████▄▄       ▄▄███████
█████████████████████████
████████     INDUSTRY LEADING CRYPTO SPORTSBOOK     ████████
PARTNER OF
WATFORD FC
LIVE
STREAMING
DAILY PRICE
BOOSTS
FAST & SECURE
PAYMENTS
█████████████████████████
███████▀▀       ▀▀███████
████▀  ▄█▄  ▀  ▄▄   ▀████
███  ▄  ▀    ▀█████▄  ███
██  ▀█▀   ▀█▄   ▀▀██▄  ██
█  ▄    █▄  ▀██▄▄  ▀█▄  █
█  █▀ ▄  ▀█▄  ▀███▄  ▀  █
█    ▄██  ▀██▄  ▀███▄   █
██  ▀████  ▀███▄  ▀█▀  ██
███  ▀████  ▀████▄    ███
████▄   ▀▀█▄  ▀▀▀   ▄████
███████▄▄       ▄▄███████
█████████████████████████
█████████████████████████
███████▀▀ █████ ▀▀███████
████▀    ▄█████▄    ▀████
█████▄▄█▀▀ ▄▄▄ ▀▀█▄▄█████
██▀███▀ ▄███▀███▄ ▀███▀██
█   █ ▄██▀     ▀██▄ █   █
█   █ ██         ██ █   █
█   █ ▀██▄▄█ █▄▄██▀ █   █
██▄███▄ ▀██▄▄▄██▀ ▄███▄██
█████▀▀█▄▄ ▀▀▀ ▄▄█▀▀█████
████▄    ▀█████▀    ▄████
███████▄▄ █████ ▄▄███████
█████████████████████████





.
..WIN WITH US!..




How To
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 1834
Merit: 2558


bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl


View Profile WWW
September 22, 2018, 05:27:33 PM
Merited by suchmoon (4), Foxpup (2)
 #10

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.

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.

piotr_n
Legendary
*
Offline Offline

Activity: 1988
Merit: 1048


aka tonikt


View Profile WWW
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
Coding Enthusiast
Hero Member
*****
Offline Offline

Activity: 647
Merit: 928


Novice C♯ Coder


View Profile WWW
September 22, 2018, 06:49:00 PM
 #12

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.

But you just described Sybil Attack which can happen with or without multiple implementations of bitcoin. It doesn't even need a vulnerability or hashrate to happen.

I do say we need more implementations of bitcoin from scratch. It won't be a perfect solution and it will take time for the software to reach maturity of bitcoin core but the benefits of it are more.

Projects List+Suggestion box
Donation link using BIP21
Bech32 Donation link!
BitcoinTransactionTool (0.9.2):  Ann - Source Code
Watch Only Bitcoin Wallet (supporting SegWit) (3.1.0):  Ann - Source Code
SharpPusher (broadcast transactions) (0.10.0): Ann - Source Code

achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 1834
Merit: 2558


bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl


View Profile WWW
September 22, 2018, 07:09:43 PM
 #13

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.

But you just described Sybil Attack which can happen with or without multiple implementations of bitcoin. It doesn't even need a vulnerability or hashrate to happen.
It's easier to perform this type of attack when you can get other people to voluntarily be your sybil nodes. That's what multiple implementations do in this situation: other people are voluntarily being the sybil nodes.

piotr_n
Legendary
*
Offline Offline

Activity: 1988
Merit: 1048


aka tonikt


View Profile WWW
September 22, 2018, 07:19:02 PM
 #14

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.

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 Smiley

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
Coding Enthusiast
Hero Member
*****
Offline Offline

Activity: 647
Merit: 928


Novice C♯ Coder


View Profile WWW
September 22, 2018, 07:27:09 PM
Merited by aleksej996 (2)
 #15

But you just described Sybil Attack which can happen with or without multiple implementations of bitcoin. It doesn't even need a vulnerability or hashrate to happen.
It's easier to perform this type of attack when you can get other people to voluntarily be your sybil nodes. That's what multiple implementations do in this situation: other people are voluntarily being the sybil nodes.
I may be wrong about this but the way I see it, like everything else such as block size this is purely about what is less bad.

On one hand we have a network of nodes that all run one implementation that if that has a vulnerability which is exploited the whole network will be crippled and the damage will be big.
On the other hand we have new different implementation(s) that might have vulnerabilities and might introduce attack surfaces that will not cripple the network and we have ways to fight these attacks to some extent. So any damage done won't be near as big.

What is the damage of this sybil attack? Some exchange and the traders losing money? That is not new.
What is the damage of a vulnerability like this being exploited? We would be forced to do a "roll back" and lose immutability of bitcoin.

Projects List+Suggestion box
Donation link using BIP21
Bech32 Donation link!
BitcoinTransactionTool (0.9.2):  Ann - Source Code
Watch Only Bitcoin Wallet (supporting SegWit) (3.1.0):  Ann - Source Code
SharpPusher (broadcast transactions) (0.10.0): Ann - Source Code

aleksej996
Sr. Member
****
Offline Offline

Activity: 476
Merit: 327


Do not trust the government


View Profile WWW
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.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 3458
Merit: 6005


View Profile
September 22, 2018, 11:36:01 PM
 #17

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.

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
bones261
Legendary
*
Offline Offline

Activity: 1624
Merit: 1662


KnowNoBorders.io


View Profile
September 23, 2018, 12:45:12 AM
Last edit: September 23, 2018, 04:40:16 AM by bones261
 #18

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.

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.

I think that I am misunderstanding what exactly this means.

Quote
However, if the output being double-spent was created in a previous block, an entry will still remain in the CCoin map with the DIRTY flag set and having been marked as spent, resulting in no such assertion.

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

   ▄▄██████▄▄
  ████████████
███▄▄
 ██████████████▀▀▀██▄
████████████████   ▀██▄
████████████████     ▀██
██████████████       ██▌
██████████████        ▐██
██▌▀▀██████▀▀         ▐██
▐██                   ██▌
 ██▄                 ▄██
  ▀██▄             ▄██▀
    ▀██▄▄▄     ▄▄▄██▀
      ▀▀█████████▀▀





█████████████████████████
███████▀▀       ▀▀███████
████▀   ▄ ▀███▀ ▄   ▀████
███  ▄████▄ ▀ ▄████▄  ███
██  ▄ ▀███▀ ▄ ▀███▀ ▄  ██
█  ▄██ ▀▀ ▄███▄ ▀▀ ██▄  █
█  █▀ ▄█ ███████ █▄ ▀█  █
█   ▄███▄ █████ ▄███▄   █
██  ████▀ ▄▄▄▄▄ ▀████  ██
███  ▀ ▄ ▀█████▀ ▄ ▀  ███
████▄  ▀▀▄ ███ ▄▀▀  ▄████
███████▄▄       ▄▄███████
█████████████████████████
████████     INDUSTRY LEADING CRYPTO SPORTSBOOK     ████████
PARTNER OF
WATFORD FC
LIVE
STREAMING
DAILY PRICE
BOOSTS
FAST & SECURE
PAYMENTS
█████████████████████████
███████▀▀       ▀▀███████
████▀  ▄█▄  ▀  ▄▄   ▀████
███  ▄  ▀    ▀█████▄  ███
██  ▀█▀   ▀█▄   ▀▀██▄  ██
█  ▄    █▄  ▀██▄▄  ▀█▄  █
█  █▀ ▄  ▀█▄  ▀███▄  ▀  █
█    ▄██  ▀██▄  ▀███▄   █
██  ▀████  ▀███▄  ▀█▀  ██
███  ▀████  ▀████▄    ███
████▄   ▀▀█▄  ▀▀▀   ▄████
███████▄▄       ▄▄███████
█████████████████████████
█████████████████████████
███████▀▀ █████ ▀▀███████
████▀    ▄█████▄    ▀████
█████▄▄█▀▀ ▄▄▄ ▀▀█▄▄█████
██▀███▀ ▄███▀███▄ ▀███▀██
█   █ ▄██▀     ▀██▄ █   █
█   █ ██         ██ █   █
█   █ ▀██▄▄█ █▄▄██▀ █   █
██▄███▄ ▀██▄▄▄██▀ ▄███▄██
█████▀▀█▄▄ ▀▀▀ ▄▄█▀▀█████
████▄    ▀█████▀    ▄████
███████▄▄ █████ ▄▄███████
█████████████████████████





.
..WIN WITH US!..




How To
Quickseller
Copper Member
Legendary
*
Offline Offline

Activity: 1848
Merit: 1717



View Profile WWW
September 23, 2018, 06:43:42 AM
 #19

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.
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.

Click Here to See Alex Morgan Twerking||2nd Video
(Videos Suchmoon doesn’t want you to see)
aliashraf
Hero Member
*****
Offline Offline

Activity: 854
Merit: 643


View Profile
September 23, 2018, 07:27:40 AM
Last edit: September 23, 2018, 07:38:51 AM by aliashraf
Merited by dbshck (2), vapourminer (1)
 #20

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.  Smiley

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.


Pages: [1] 2 3 4 5 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!