Bitcoin Forum
November 16, 2024, 10:32:24 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Are we still in risk?  (Read 231 times)
MadGamer (OP)
Legendary
*
Offline Offline

Activity: 1568
Merit: 1031


View Profile
October 16, 2018, 09:43:45 AM
 #1

A couple of weeks back, I've read on the forums what is on the top right now. I didn't bother to read because I use hardware wallet. However, lately, I started to see people in both Reddit and the forums telling that this could lead to a chain split so I'm not sure If this is the usual FUD or It's actually something serious? If that is possible, are we out of the danger zone? do we have enough nodes with 0.17.0, 0.16.3, 0.15.2 or 0.14.3?
AdolfinWolf
Legendary
*
Offline Offline

Activity: 1946
Merit: 1427


View Profile
October 16, 2018, 02:29:01 PM
Last edit: October 16, 2018, 04:36:40 PM by AdolfinWolf
Merited by dbshck (2), LoyceV (1), MadGamer (1)
 #2

A couple of weeks back, I've read on the forums what is on the top right now. I didn't bother to read because I use hardware wallet. However, lately, I started to see people in both Reddit and the forums telling that this could lead to a chain split so I'm not sure If this is the usual FUD or It's actually something serious? If that is possible, are we out of the danger zone? do we have enough nodes with 0.17.0, 0.16.3, 0.15.2 or 0.14.3?

I've looked into the the error, and correct me if i'm wrong -- It's basically that Bitcoin Core was unable to detect correctly whether a transaction had been double-spend, or not.
Quote
Thus, in Bitcoin Core 0.15.X, 0.16.0, 0.16.1, and 0.16.2, any attempts to double-spend a transaction output within a single transaction inside of a block where the output being spent was created in the same block, the same assertion failure will occur (as exists in the test case which was included in the 0.16.3 patch). 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. This could allow a miner to inflate the supply of Bitcoin as they would be then able to claim the value being spent twice.
This vulnerability seems pretty huge, but not huge enough for a mining company to let their entire reputation go to waste.

Although, that brings me to another question -- If there was no such "assertion" anymore, could a user somehow doublespend a transaction without the miners being able to identify that it is infact a  ‟double-spend‟ - and thus it being possible that said miners didn't know they were including an already spend transaction?

Code:
CCoin map with the DIRTY flag set and having been marked as spent
Or would this prevent that?

Quote
“This could lead to a chain split“...
Whether it is still possible or not by network rules to accept/validate a block containing such a transaction -- I'm pretty sure that if any miner right now would mine/include/build such a block, it will be quickly orphaned, as the majority of the miners are not malicious, and the reputation of said miner destroyed.

Therefore it seems pretty unlikely to happen - if it still is even possible in the first place. (Which i'm pretty curious about? Is it? There's a fairly large share of nodes still running older versions.)

You can see the amount of nodes # per version here, https://bitnodes.earn.com/nodes/

seoincorporation
Legendary
*
Offline Offline

Activity: 3346
Merit: 3123



View Profile
October 17, 2018, 02:08:53 AM
 #3

Reddit and the forums telling that this could lead to a chain split...
A chain split... Those are hard words my friend, people could think you are talking about bitcoin fork. A chain split already happen and the result was called Bitcoin Cash, but personally, I like more the chain split from ETH, that was like create an universe parallel where a hacker win his game, and the result was ETC A.K.A. The classic one.


do we have enough nodes with 0.17.0, 0.16.3, 0.15.2 or 0.14.3?
I have bad news for you, there is only one node and all those versions are upgrades, the problem was related to a big vuln, but with the upgrade comes the solution, to read more information about it please take a look to this link https://bitcointalk.org/index.php?topic=5034070.0

▄▄███████▄▄
▄██████████████▄
▄██████████████████▄
▄████▀▀▀▀███▀▀▀▀█████▄
▄█████████████▄█▀████▄
███████████▄███████████
██████████▄█▀███████████
██████████▀████████████
▀█████▄█▀█████████████▀
▀████▄▄▄▄███▄▄▄▄████▀
▀██████████████████▀
▀███████████████▀
▀▀███████▀▀
.
 MΞTAWIN  THE FIRST WEB3 CASINO   
.
.. PLAY NOW ..
bones261
Legendary
*
Offline Offline

Activity: 1806
Merit: 1828



View Profile
October 17, 2018, 04:06:16 AM
 #4


Whether it is still possible or not by network rules to accept/validate a block containing such a transaction -- I'm pretty sure that if any miner right now would mine/include/build such a block, it will be quickly orphaned, as the majority of the miners are not malicious, and the reputation of said miner destroyed.

Therefore it seems pretty unlikely to happen - if it still is even possible in the first place. (Which i'm pretty curious about? Is it? There's a fairly large share of nodes still running older versions.)

You can see the amount of nodes # per version here, https://bitnodes.earn.com/nodes/

It's possible that a miner could include this into a block, and temporarily fool the vulnerable nodes that are not upgraded. However, if the miner does not have 51% of the hash rate, the bad actor's chain will be reorganized by the vulnerable nodes as soon as the legit chain has the most work again. I really can't see how a miner could take advantage of this double spend, since the miner will not have much time to do much damage. The bad actor would have to find someone stupid, who will accept the double spend transaction with 1 or maybe 2 confirmation.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!