Bitcoin Forum
December 11, 2016, 02:43:04 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 [2]  All
  Print  
Author Topic: Bitcoin in danger!? Received <Sent!?!  (Read 4452 times)
payb.tc
Hero Member
*****
Offline Offline

Activity: 812



View Profile
February 10, 2012, 05:44:47 AM
 #21

would it be possible to see exactly how many times this occurred on the main network?
1481424184
Hero Member
*
Offline Offline

Posts: 1481424184

View Profile Personal Message (Offline)

Ignore
1481424184
Reply with quote  #2

1481424184
Report to moderator
The forum was founded in 2009 by Satoshi and Sirius. It replaced a SourceForge forum.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481424184
Hero Member
*
Offline Offline

Posts: 1481424184

View Profile Personal Message (Offline)

Ignore
1481424184
Reply with quote  #2

1481424184
Report to moderator
bittenbob
Hero Member
*****
Offline Offline

Activity: 560


View Profile
February 10, 2012, 05:56:49 AM
 #22

My guess would be never at all. Testnet is where new code is tested out before it is released.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2506


View Profile
February 10, 2012, 06:15:04 AM
 #23

so to clarify, the main consequence of the bug was that a block reward could become lost forever?

still... turning 100 BTC into 50 is less serious of a bug than being able to turn 50 BTC into 100 Cheesy

More serious issues might be possible when there is a reorg. For example, when one coinbase is disconnected, all of its duplicates will also be disconnected.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
payb.tc
Hero Member
*****
Offline Offline

Activity: 812



View Profile
February 10, 2012, 07:07:39 AM
 #24

My guess would be never at all. Testnet is where new code is tested out before it is released.

oh, did satoshi test out his very first attempt on the test network before creating the main genesis block?

i thought we were talking about a bug in satoshi's creation, as old as bitcoin itself.
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
February 10, 2012, 04:36:52 PM
 #25

My guess would be never at all. Testnet is where new code is tested out before it is released.

oh, did satoshi test out his very first attempt on the test network before creating the main genesis block?

i thought we were talking about a bug in satoshi's creation, as old as bitcoin itself.


My guess is that there were several genesis blocks while he was working on it, and once everything was ready he released it and the last one he made became The Genesis Block.

As to the overwrite issue, it might be better to think of this as a hash collision.  Think hash function rather than cryptographic hash.

Cryptographic hashes are intentionally very hard to collide, and the default client uses a new address for each generation, so in a way the default client had solved the problem.  But, it didn't expect that someone else might use different software to reuse the same inputs to the hash and end up with the same transaction id.

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction.  And in the future, they will set it to reject blocks that include duplicates, which would be a de facto protocol change, and a good one.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
malevolent
can into space
Staff
Legendary
*
Offline Offline

Activity: 1624



View Profile
February 10, 2012, 10:26:11 PM
 #26

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction. 

I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
February 10, 2012, 10:56:07 PM
 #27

More serious issues might be possible when there is a reorg. For example, when one coinbase is disconnected, all of its duplicates will also be disconnected.
Yeah, which in theory means that all the nodes that had the block containing that duplicate coinbase in their main chain would wrongly treat an attempt to spend it as invalid and all those that hadn't would correctly consider it valid. This may be usable to create a persistent fork in Bitcoin - that is to say, one that can never actually resolve itself without a huge amount of manual intervention by everyone involved.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
February 11, 2012, 12:47:17 AM
 #28

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction. 

I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.

No, those are in the past; it is too late for them.  This would apply only when your node creates a new candidate block in response to a getwork request, and then later when a brand new block comes in over the network, fresh from some dude's GPU.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
February 11, 2012, 01:10:37 AM
 #29

More serious issues might be possible when there is a reorg. For example, when one coinbase is disconnected, all of its duplicates will also be disconnected.
Yeah, which in theory means that all the nodes that had the block containing that duplicate coinbase in their main chain would wrongly treat an attempt to spend it as invalid and all those that hadn't would correctly consider it valid. This may be usable to create a persistent fork in Bitcoin - that is to say, one that can never actually resolve itself without a huge amount of manual intervention by everyone involved.

That would take quite a bit of planning and effort, and the attacker would need to have huge amounts of hashing power plus incredibly good timing.  Oh, and they would only get one shot getting it right, since that fork is only possible during the moment when the network changes rules.  Plus, I'm not sure what anyone could possibly hope to gain by doing it.

And if it even looked like it was possible that someone might do it, we could randomize the rule change time.  Instead of coding it so that the rules change starting with block # X, we could say that the new rules take effect on the first block following # X where the last 8 bits of the header hash are all zero.  That would be totally unambiguous on the network, but still impossible to predict.

Note that under the current rules, if you generate two coinbases with the same transaction and wish to spend both of them, you must spend the first one before you generate the second one.  The duplicates in the past can't be fixed.  All in all, this is a very strange quirk of the system that needs to be fixed, but not a security issue.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
RaggedMonk
Sr. Member
****
Offline Offline

Activity: 308



View Profile
February 11, 2012, 01:29:45 AM
 #30

Please edit the title of the OP. Bitcoin is NOT in danger.  You misunderstood.
runeks
Legendary
*
Offline Offline

Activity: 924



View Profile WWW
February 11, 2012, 06:25:06 PM
 #31

My guess would be never at all. Testnet is where new code is tested out before it is released.
It has happened on the main network. The following transaction is present in both block 91812 and 91842: http://blockexplorer.com/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction. 

I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction. 

I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.

No, those are in the past; it is too late for them.  This would apply only when your node creates a new candidate block in response to a getwork request, and then later when a brand new block comes in over the network, fresh from some dude's GPU.
In order to check if a generation transaction with the same transaction ID is already existant in the block chain we will obviously have to check past generation transactions. Luckily, only one is created circa every 10 minutes, so even in a 1000 years, we will only have to check around 90 million transactions for duplicates (which can probably be done in a fraction of a pico second in the year 3012).
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
February 12, 2012, 07:10:24 AM
 #32

My guess would be never at all. Testnet is where new code is tested out before it is released.
It has happened on the main network. The following transaction is present in both block 91812 and 91842: http://blockexplorer.com/tx/d5d27987d2a3dfc724e359870c6644b40e497bdc0589a033220fe15429d88599

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction. 

I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.

From Gavin's post, it sounds like they are changing the default client to actually check the database to make sure that a newly created coinbase doesn't collide with a prior transaction. 

I at least hope it will not slow down bitcoin client as downloading all the blocks (and verifying them?) takes already too long.

No, those are in the past; it is too late for them.  This would apply only when your node creates a new candidate block in response to a getwork request, and then later when a brand new block comes in over the network, fresh from some dude's GPU.
In order to check if a generation transaction with the same transaction ID is already existant in the block chain we will obviously have to check past generation transactions. Luckily, only one is created circa every 10 minutes, so even in a 1000 years, we will only have to check around 90 million transactions for duplicates (which can probably be done in a fraction of a pico second in the year 3012).

The absolute worst case for a binary tree search over 256 bits is 256 comparisons.  BDB uses something better, probably a btree (I'm too lazy to look it up).  After 90 million coinbases, the typical search will probably take less than 30 comparisons.  Both of these numbers are trivial and won't add more than a couple of microseconds to block processing time (not counting I/O if the index isn't in memory for some bizarre reason).

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
Pages: « 1 [2]  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!