Bitcoin Forum
September 26, 2021, 02:02:21 PM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: 1 2 3 4 5 6 [All]
  Print  
Author Topic: A successful DOUBLE SPEND US$10000 against OKPAY this morning.  (Read 123829 times)
macbook-air
Sr. Member
****
Offline Offline

Activity: 324
Merit: 250


View Profile WWW
March 12, 2013, 06:22:02 PM
 #1

All time UTC+08:00:

08:08 – Well before I knew what later have happened, I deposited $10000-worth Bitcoins to BTC-e over OKPAY's Bitcoin payment, I paid OKPAY address 12z2n8YCJw1BEsJhhQPLCTuLqwH341nKnE 211.9093 BTC and 0.0005 BTC as transaction fee.
09:30 – The transaction was included in version 0.8's fork, block 225446
10:08 – Deposit completed, $9800 credited to my BTC-e account
12:53 – After some study, I recognized, the transaction, though included in version 0.8's fork, was never confirmed by the pre-0.8 fork, so I decided to make two double spend transactions on two of the vins of the OKPAY transaction, and broadcasted them with the raw transaction API, 0.001 BTC transaction fee included in each transaction.
13:01 – The double spend transaction was included in pre-0.8 fork block 225446

You should know what happens next...

I bet merchants would think twice before they decide to accept Bitcoins after the incident.

1632664941
Hero Member
*
Offline Offline

Posts: 1632664941

View Profile Personal Message (Offline)

Ignore
1632664941
Reply with quote  #2

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

Posts: 1632664941

View Profile Personal Message (Offline)

Ignore
1632664941
Reply with quote  #2

1632664941
Report to moderator
1632664941
Hero Member
*
Offline Offline

Posts: 1632664941

View Profile Personal Message (Offline)

Ignore
1632664941
Reply with quote  #2

1632664941
Report to moderator
1632664941
Hero Member
*
Offline Offline

Posts: 1632664941

View Profile Personal Message (Offline)

Ignore
1632664941
Reply with quote  #2

1632664941
Report to moderator
Jan
Legendary
*
Offline Offline

Activity: 1043
Merit: 1002



View Profile
March 12, 2013, 06:38:27 PM
 #2

All time UTC+08:00:

08:08 – Well before I knew what later have happened, I deposited $10000-worth Bitcoins to BTC-e over OKPAY's Bitcoin payment, I paid OKPAY address 12z2n8YCJw1BEsJhhQPLCTuLqwH341nKnE 211.9093 BTC and 0.0005 BTC as transaction fee.
09:30 – The transaction was included in version 0.8's fork, block 225446
10:08 – Deposit completed, $9800 credited to my BTC-e account
12:53 – After some study, I recognized, the transaction, though included in version 0.8's fork, was never confirmed by the pre-0.8 fork, so I decided to make two double spend transactions on two of the vins of the OKPAY transaction, and broadcasted them with the raw transaction API, 0.001 BTC transaction fee included in each transaction.
13:01 – The double spend transaction was included in pre-0.8 fork block 225446

You should know what happens next...

I bet merchants would think twice before they decide to accept Bitcoins after the incident.
Ouch...

Mycelium let's you hold your private keys private.
bg002h
Donator
Legendary
*
Offline Offline

Activity: 1445
Merit: 1016


I outlived my lifetime membership:)


View Profile WWW
March 12, 2013, 06:38:59 PM
 #3

All time UTC+08:00:

08:08 – Well before I knew what later have happened, I deposited $10000-worth Bitcoins to BTC-e over OKPAY's Bitcoin payment, I paid OKPAY address 12z2n8YCJw1BEsJhhQPLCTuLqwH341nKnE 211.9093 BTC and 0.0005 BTC as transaction fee.
09:30 – The transaction was included in version 0.8's fork, block 225446
10:08 – Deposit completed, $9800 credited to my BTC-e account
12:53 – After some study, I recognized, the transaction, though included in version 0.8's fork, was never confirmed by the pre-0.8 fork, so I decided to make two double spend transactions on two of the vins of the OKPAY transaction, and broadcasted them with the raw transaction API, 0.001 BTC transaction fee included in each transaction.
13:01 – The double spend transaction was included in pre-0.8 fork block 225446

You should know what happens next...

I bet merchants would think twice before they decide to accept Bitcoins after the incident.

Good thing someone honest was the cause of the double spend...

Hardforks aren't that hard. It’s getting others to use them that's hard.
1GCDzqmX2Cf513E8NeThNHxiYEivU1Chhe
Jan
Legendary
*
Offline Offline

Activity: 1043
Merit: 1002



View Profile
March 12, 2013, 06:42:19 PM
 #4

Here is the tx: http://blockchain.info/tx/12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195

Mycelium let's you hold your private keys private.
Elwar
Legendary
*
Offline Offline

Activity: 3556
Merit: 2326


Viva Ut Vivas


View Profile WWW
March 12, 2013, 06:47:22 PM
 #5

Ugh...this is worse than we thought.

Is this the first double spend?

First seastead company actually selling sea homes: Ocean Builders https://ocean.builders  Of course we accept bitcoin.
yokosan
Hero Member
*****
Offline Offline

Activity: 700
Merit: 500


View Profile
March 12, 2013, 06:51:50 PM
 #6

alir
Member
**
Offline Offline

Activity: 216
Merit: 11



View Profile
March 12, 2013, 06:52:54 PM
 #7

Guess they don't owe you anymore.
Largo
Member
**
Offline Offline

Activity: 112
Merit: 10



View Profile
March 12, 2013, 07:00:44 PM
 #8

Thats why merchants should have stopped accepting bitcoin deposits, at least those handing out some other form of cash instantly.

The problem was that 0.8 clients were thinking they are in the right fork (because that was actually the case before miners switched to 0.7) so it didnt stop the RPC interface like the 0.7 clients did.


Isokivi
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000


Items flashing here available at btctrinkets.com


View Profile WWW
March 12, 2013, 07:01:52 PM
 #9

Heres a merchant giving 0-fucks about double spends, go for it. www.btctrinkets.com Every single payment goes trough a payment processor (mtgox) and I verify every single payment by hand.

Bitcoin trinkets now on my online store: btc trinkets.com <- Bitcoin Tiepins, cufflinks, lapel pins, keychains, card holders and challenge coins.
etotheipi
Legendary
*
Offline Offline

Activity: 1428
Merit: 1048


Core Armory Developer


View Profile WWW
March 12, 2013, 07:04:49 PM
 #10

Any guesses as to the reason it didn't show up in the pre-0.8 branch?   I don't see any reason that the original transaction could be systematically rejected by one branch and not the other.  Even transactions that hadn't made it into blocks in the pre-0.7 branch should still be in the nodes' memory pools and double-spends rejected.

gmaxwell pointed out that this could happen if an attacker started by flooding the system with duplicate transactions hoping to create disagreement, but it sounds like macbook-air did not do that.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1386
Merit: 1073


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
March 12, 2013, 07:13:20 PM
 #11

A serious solution is simply for several major stakeholders to publish signed endorsements and/or kills to blocks. Users can subscribe to them, and if a supermajority agrees to kill a block, the merchant at the very least can be configured to stop and go into safe mode.

I have thought of this long ago, now others might take the idea seriously. It was aggressively rejected in the past under the pretense it was too "centralized".  I believe we need it to raise the bar on the risk of a 51% attack.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper or hardware wallets instead.
elux
Legendary
*
Offline Offline

Activity: 1458
Merit: 1004



View Profile
March 12, 2013, 07:16:18 PM
 #12

All time UTC+08:00:

08:08 – Well before I knew what later have happened, I deposited $10000-worth Bitcoins to BTC-e over OKPAY's Bitcoin payment, I paid OKPAY address 12z2n8YCJw1BEsJhhQPLCTuLqwH341nKnE 211.9093 BTC and 0.0005 BTC as transaction fee.
09:30 – The transaction was included in version 0.8's fork, block 225446
10:08 – Deposit completed, $9800 credited to my BTC-e account
12:53 – After some study, I recognized, the transaction, though included in version 0.8's fork, was never confirmed by the pre-0.8 fork, so I decided to make two double spend transactions on two of the vins of the OKPAY transaction, and broadcasted them with the raw transaction API, 0.001 BTC transaction fee included in each transaction.
13:01 – The double spend transaction was included in pre-0.8 fork block 225446

You should know what happens next...

I bet merchants would think twice before they decide to accept Bitcoins after the incident.
Ouch...


And the other: http://blockchain.info/tx-index/59996016

The "unconfirmed" transaction was included in http://blockchain.info/block-index/357971, later orphaned.

Story seems to check out. How many confirmations did the first transaction get?
TheButterZone
Legendary
*
Offline Offline

Activity: 2828
Merit: 1027


RIP Mommy


View Profile WWW
March 12, 2013, 07:18:04 PM
 #13

move topic> https://bitcointalk.org/index.php?board=85.0 ?

Saying that you don't trust someone because of their behavior is completely valid.
gmaxwell
Staff
Legendary
*
Offline Offline

Activity: 3542
Merit: 5645



View Profile
March 12, 2013, 07:20:09 PM
 #14

gmaxwell pointed out that this could happen if an attacker started by flooding the system with duplicate transactions hoping to create disagreement, but it sounds like macbook-air did not do that.
One way would be for miners on the other fork to already have long mempool queues, and so the transaction was just waiting to get mined but they had it. The miners were restarted to switch from 0.8 to 0.7 and in doing so that instantly expires their mempools, and nothing will resync them. Once an entry is mempool expired then all it takes it the transaction managing to get relayed to one of them.
MrCrabs
Full Member
***
Offline Offline

Activity: 121
Merit: 100



View Profile
March 12, 2013, 07:21:24 PM
 #15

How serious is this please. Double spends  I thought were impossible . Huh
Melbustus
Legendary
*
Offline Offline

Activity: 1722
Merit: 1003



View Profile
March 12, 2013, 07:26:35 PM
 #16

How serious is this please. Double spends  I thought were impossible . Huh

Was only an issue while there were two chains; ie, for a couple hours last night. The possibility was well-known, which is why it was recommended that merchants, exchanges, etc, stop taking payments/deposits until the issue was resolved, which it now is.

Bitcoin is the first monetary system to credibly offer perfect information to all economic participants.
nevafuse
Sr. Member
****
Offline Offline

Activity: 247
Merit: 250


View Profile
March 12, 2013, 07:35:06 PM
 #17

Any guesses as to the reason it didn't show up in the pre-0.8 branch?   I don't see any reason that the original transaction could be systematically rejected by one branch and not the other.  Even transactions that hadn't made it into blocks in the pre-0.7 branch should still be in the nodes' memory pools and double-spends rejected.

Is this the only successful double spend from last night?  Maybe the difference will be easier to spot if there are others.  Sounds like there may be other fork issues besides the database problem.

The only reason to limit the block size is to subsidize non-Bitcoin currencies
Spekulatius
Legendary
*
Offline Offline

Activity: 1022
Merit: 1000



View Profile
March 12, 2013, 07:35:34 PM
 #18

@ OP: Did you repay OK? Grin
Ivica
Full Member
***
Offline Offline

Activity: 218
Merit: 100


Firstbits: 19e3fc


View Profile
March 12, 2013, 07:37:14 PM
 #19

@ OP: Did you repay OK? Grin

Nope, until they repay 64.91410001 BTC.

19e3fcoLTu8YVFAU1NywJ88YnHH5kF8ScP - donations are welcome.
Nick
Newbie
*
Offline Offline

Activity: 57
Merit: 0


View Profile
March 12, 2013, 07:41:05 PM
 #20

A serious solution is simply for several major stakeholders to publish signed endorsements and/or kills to blocks. Users can subscribe to them, and if a supermajority agrees to kill a block, the merchant at the very least can be configured to stop and go into safe mode.

I have thought of this long ago, now others might take the idea seriously. It was aggressively rejected in the past under the pretense it was too "centralized".  I believe we need it to raise the bar on the risk of a 51% attack.


I have just read this on the reddit thread:

Quote from: Bitcoinin
Merchants like this probably need to build something into their systems to automatically go into a safe mode if a 2-3 block fork is detected.

This might be an equally effective but less centralized approach. What do you think?

blablahblah
Hero Member
*****
Offline Offline

Activity: 775
Merit: 1000


View Profile
March 12, 2013, 07:41:23 PM
 #21

How serious is this please. Double spends  I thought were impossible . Huh

Was only an issue while there were two chains; ie, for a couple hours last night. The possibility was well-known, which is why it was recommended that merchants, exchanges, etc, stop taking payments/deposits until the issue was resolved, which it now is.

Yep, I guess strictly speaking it's "single-spend in 2 currencies". But of course, having multiple chains is ideological anathema, therefore there seems to be no infrastructure to handle it.
RodeoX
Legendary
*
Offline Offline

Activity: 3066
Merit: 1144


The revolution will be monetized!


View Profile
March 12, 2013, 07:44:07 PM
 #22

If I am reading this correctly, it could only happen during this weird period when we had several blockchains floating around. Is that correct?

The gospel according to Satoshi - https://bitcoin.org/bitcoin.pdf
Free bitcoin in ? - Stay tuned for this years Bitcoin hunt!
Piper67
Legendary
*
Offline Offline

Activity: 1106
Merit: 1001



View Profile
March 12, 2013, 07:45:06 PM
 #23

If I am reading this correctly, it could only happen during this weird period when we had several blockchains floating around. Is that correct?

Yes, the "Schroedinger Cat period" during which the coins are both alive and dead. As soon as the blockchain became whole again, either one or the other has to materialise.
Elwar
Legendary
*
Offline Offline

Activity: 3556
Merit: 2326


Viva Ut Vivas


View Profile WWW
March 12, 2013, 07:45:27 PM
 #24

This might be an equally effective but less centralized approach. What do you think?

How does one detect a fork? Some guy in his basement can create a fork with his own new code but be useless due to most transactions going with the main fork, but it would still be a fork.

First seastead company actually selling sea homes: Ocean Builders https://ocean.builders  Of course we accept bitcoin.
Spaceman_Spiff
Legendary
*
Offline Offline

Activity: 1638
Merit: 1000


₪``Campaign Manager´´₪


View Profile
March 12, 2013, 07:47:39 PM
 #25

This might be an equally effective but less centralized approach. What do you think?

How does one detect a fork? Some guy in his basement can create a fork with his own new code but be useless due to most transactions going with the main fork, but it would still be a fork.

That is what waiting for x confirmations is for .  
Atheros
Sr. Member
****
Offline Offline

Activity: 249
Merit: 251



View Profile WWW
March 12, 2013, 07:48:09 PM
 #26

This might be an equally effective but less centralized approach. What do you think?

How does one detect a fork? Some guy in his basement can create a fork with his own new code but be useless due to most transactions going with the main fork, but it would still be a fork.

Run several versions of Bitcoin and if they start to mutually deviate over three blocks then that is either a fork or is, a least, sufficient reason for merchants to go into safe mode. Sounds to me like a business opportunity.

Actually, if this is implemented, it would make it much safer for alternative full Bitcoin clients to operate because we could detect the inevitable chain splits quickly and safely.

BM-GteJMPqvHRUdUHHa1u7dtYnfDaH5ogeY
Bitmessage.org - Decentralized, trustless, encrypted, authenticated messaging protocol and client.
somenick
Legendary
*
Offline Offline

Activity: 1291
Merit: 1004


View Profile
March 12, 2013, 07:48:16 PM
 #27

I've heard he was already catched  Cheesy
RodeoX
Legendary
*
Offline Offline

Activity: 3066
Merit: 1144


The revolution will be monetized!


View Profile
March 12, 2013, 07:48:55 PM
 #28

If I am reading this correctly, it could only happen during this weird period when we had several blockchains floating around. Is that correct?

Yes, the "Schroedinger Cat period" during which the coins are both alive and dead. As soon as the blockchain became whole again, either one or the other has to materialise.
Haha, I like that analogy.

The gospel according to Satoshi - https://bitcoin.org/bitcoin.pdf
Free bitcoin in ? - Stay tuned for this years Bitcoin hunt!
mccorvic
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile
March 12, 2013, 07:49:56 PM
 #29

This might be an equally effective but less centralized approach. What do you think?

How does one detect a fork? Some guy in his basement can create a fork with his own new code but be useless due to most transactions going with the main fork, but it would still be a fork.

I have a whole drawer full of forks, but so far all have been ignored Sad

Offering Video/Audio Editing Services since 2011 - https://bitcointalk.org/index.php?topic=77932.0
Micon
Legendary
*
Offline Offline

Activity: 1232
Merit: 1010


FPV Drone Pilot


View Profile WWW
March 12, 2013, 08:05:47 PM
 #30

Excuse my non-technical, conceptual-only questions / thoughts / checking if I have this right in my head:


1)  There was no *permanent*  "double spend" right?   i.e. the transaction on the .8 fork would have eventually been orphaned / dumped / never credited to the address specified in the .8 block?

2)  The risk here (and reason why SwC shut off all deposits / withdraws for a few hrs until this was resolved) was that during this very odd period a sophisticated user could use multiple 0-conf services that would all at the same time believe they were getting the same coins, but after the blockchain becomes 1 again only 1 of the transactions would actually be included in the "real" blockchain?

also, if this ever happens again, I think we should use this pic:



and sorry if there has already been a 2 Chainz reference.

I'm flying FPV race drones these days. Check out my YouTube channel: https://www.youtube.com/c/MiconFPV
iddo
Sr. Member
****
Offline Offline

Activity: 360
Merit: 251


View Profile
March 12, 2013, 08:09:01 PM
 #31

A serious solution is simply for several major stakeholders to publish signed endorsements and/or kills to blocks. Users can subscribe to them, and if a supermajority agrees to kill a block, the merchant at the very least can be configured to stop and go into safe mode.

I have thought of this long ago, now others might take the idea seriously. It was aggressively rejected in the past under the pretense it was too "centralized".  I believe we need it to raise the bar on the risk of a 51% attack.

Your centralized protocol with few designated major stakeholders is indeed a terrible idea imho, for the reasons that we discussed in your thread. Fully decentralized proof-of-stake protocol can be sound, and can have several additional features that are very beneficial (in exchange for the additional complexity in the work that the nodes perform), but the security analysis should take into account bribe attacks etc., as discussed in the PoA thread. Peer review for the best protocol that we came up with so far would be very welcome, see here.
mccorvic
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile
March 12, 2013, 08:15:07 PM
 #32

Excuse my non-technical, conceptual-only questions / thoughts / checking if I have this right in my head:


1)  There was no *permanent*  "double spend" right?   i.e. the transaction on the .8 fork would have eventually been orphaned / dumped / never credited to the address specified in the .8 block?

2)  The risk here (and reason why SwC shut off all deposits / withdraws for a few hrs until this was resolved) was that during this very odd period a sophisticated user could use multiple 0-conf services that would all at the same time believe they were getting the same coins, but after the blockchain becomes 1 again only 1 of the transactions would actually be included in the "real" blockchain?

Your points are my understanding.  The double spend was allowed only because the service provider here wasn't on the ball.

Offering Video/Audio Editing Services since 2011 - https://bitcointalk.org/index.php?topic=77932.0
Gabi
Legendary
*
Offline Offline

Activity: 1148
Merit: 1008


If you want to walk on water, get out of the boat


View Profile
March 12, 2013, 08:28:30 PM
 #33

That is why bitcoin is still beta software

impulse
Full Member
***
Offline Offline

Activity: 151
Merit: 100


View Profile
March 12, 2013, 08:34:44 PM
 #34

Excuse my non-technical, conceptual-only questions / thoughts / checking if I have this right in my head:


1)  There was no *permanent*  "double spend" right?   i.e. the transaction on the .8 fork would have eventually been orphaned / dumped / never credited to the address specified in the .8 block?

2)  The risk here (and reason why SwC shut off all deposits / withdraws for a few hrs until this was resolved) was that during this very odd period a sophisticated user could use multiple 0-conf services that would all at the same time believe they were getting the same coins, but after the blockchain becomes 1 again only 1 of the transactions would actually be included in the "real" blockchain?

Your points are my understanding.  The double spend was allowed only because the service provider here wasn't on the ball.

Yeah, I think it's important to distinguish here for non-techie people that this is not a double-spend within the merged blockchain, this is a double-spend against OKPAY because of their clearing policy and the unusal circumstances of last night. This does not violate the promise that the blockchain prohibits double spends.
Gabi
Legendary
*
Offline Offline

Activity: 1148
Merit: 1008


If you want to walk on water, get out of the boat


View Profile
March 12, 2013, 08:36:09 PM
 #35

Forcing the 0.7 clients to upgrade to 0.8 instead of orphaning the chain would have avoided that... but would require everyone in the bitcoin world to upgrade...

molecular
Donator
Legendary
*
Offline Offline

Activity: 2744
Merit: 1016



View Profile
March 12, 2013, 08:36:23 PM
 #36

This might be an equally effective but less centralized approach. What do you think?

How does one detect a fork? Some guy in his basement can create a fork with his own new code but be useless due to most transactions going with the main fork, but it would still be a fork.

Run several versions of Bitcoin and if they start to mutually deviate over three blocks then that is either a fork or is, a least, sufficient reason for merchants to go into safe mode. Sounds to me like a business opportunity.

Cool idea! And yes, this _is_ a business opportunity of, some size even.

The clients could not only be of different codebase (differnt versions and different clients), but also try to be connected to different "parts" of the network in order to also be able to detect a network split. Now add different configuration options and you have a whole bunch of instances you need to run and maintain.

Hmm, that begs the question: why run the instances yourself in the first place? Why not simply ask a bunch of clients about their opinion about the latest block (height and hash or whatever) via the protocol itself? Would that also be workable or does that approach have a problem?

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
molecular
Donator
Legendary
*
Offline Offline

Activity: 2744
Merit: 1016



View Profile
March 12, 2013, 08:38:55 PM
 #37

Any guesses as to the reason it didn't show up in the pre-0.8 branch?   I don't see any reason that the original transaction could be systematically rejected by one branch and not the other.  Even transactions that hadn't made it into blocks in the pre-0.7 branch should still be in the nodes' memory pools and double-spends rejected.

Has this been answered?

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
Gabi
Legendary
*
Offline Offline

Activity: 1148
Merit: 1008


If you want to walk on water, get out of the boat


View Profile
March 12, 2013, 08:47:22 PM
 #38

Any guesses as to the reason it didn't show up in the pre-0.8 branch?   I don't see any reason that the original transaction could be systematically rejected by one branch and not the other.  Even transactions that hadn't made it into blocks in the pre-0.7 branch should still be in the nodes' memory pools and double-spends rejected.

Has this been answered?
Indeed, this is a good question. Every client should have refused the second transaction, since it was a double spend. So what happened? A miner somehow received it and confirmed it because of the higher fee?

pera
Sr. Member
****
Offline Offline

Activity: 532
Merit: 261


­バカ


View Profile
March 12, 2013, 08:48:58 PM
 #39

[..]
Hmm, that begs the question: why run the instances yourself in the first place? Why not simply ask a bunch of clients about their opinion about the latest block (height and hash or whatever) via the protocol itself? Would that also be workable or does that approach have a problem?

could be something like this be implemented on the client to measure a potential fork?

キタ━━━━(゚∀゚)━━━━ッ!!
molecular
Donator
Legendary
*
Offline Offline

Activity: 2744
Merit: 1016



View Profile
March 12, 2013, 08:49:45 PM
 #40

Any guesses as to the reason it didn't show up in the pre-0.8 branch?   I don't see any reason that the original transaction could be systematically rejected by one branch and not the other.  Even transactions that hadn't made it into blocks in the pre-0.7 branch should still be in the nodes' memory pools and double-spends rejected.

Has this been answered?
Indeed, this is a good question. Every client should have refused the second transaction, since it was a double spend. So what happened? A miner somehow received it and confirmed it because of the higher fee?

Stupid question: did everyones 0.7-client crash (or restart or clear the mempool) upon failure to commit the big block? That would explain it, no?

If that's the reason, maybe the "mempool" should be a "diskpool".


PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
Wekkel
Legendary
*
Offline Offline

Activity: 2954
Merit: 1475


yes


View Profile
March 12, 2013, 08:50:27 PM
 #41

A great opportunity to upgrade the software  Cool

Gabi
Legendary
*
Offline Offline

Activity: 1148
Merit: 1008


If you want to walk on water, get out of the boat


View Profile
March 12, 2013, 08:51:57 PM
 #42

Clients didn't crash, they just refused the "weird" block. Or did they crash?

molecular
Donator
Legendary
*
Offline Offline

Activity: 2744
Merit: 1016



View Profile
March 12, 2013, 08:52:26 PM
 #43

[..]
Hmm, that begs the question: why run the instances yourself in the first place? Why not simply ask a bunch of clients about their opinion about the latest block (height and hash or whatever) via the protocol itself? Would that also be workable or does that approach have a problem?

could be something like this be implemented on the client to measure a potential fork?

probably. I don't know enough about the protocol myself to answer this question. But say you have 8 connections and one reports a different hash for the newest block (or a lower chain height)... this wouldn't in itself mean much. You'd have to have access to a larger sample, so maybe it'd make sense to implement this as a service with an api that publishes some kind of "alert level" to be used by merchants to halt accepting bitcoin above a certain treshold.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
etotheipi
Legendary
*
Offline Offline

Activity: 1428
Merit: 1048


Core Armory Developer


View Profile WWW
March 12, 2013, 09:01:34 PM
Last edit: March 12, 2013, 09:47:29 PM by etotheipi
 #44

gmaxwell answered it:  a large majority of mining power switched to running 0.7 -- which meant restarting the miners and clearing their memory pools.  With the right dynamics, a rebroadcast would not repropagate because most nodes had not been restarted and would not rebroadcast it.  Thus, those miners that restarted, started mining without it, and accepted the double-spend as a first-spend.

That particular theory, if correct, suggests that it's safer to have saved memory pools between loads, to make the keep/drop decision deterministic.  It would also appease those that want to do far-future locked transactions, whose transactions cannot, by definition, survive a software update cycle.  At least it would give clients/miners a choice about their locked-tx policy, rather than having it decided for them (drop all tx on restart).

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
jago25_98
Hero Member
*****
Offline Offline

Activity: 900
Merit: 1000


Crypto Geek


View Profile WWW
March 12, 2013, 09:11:05 PM
 #45

Out of interest, how far did the spend get before the 0.8 chain went dominant? I take it that it didn't even get to 1 confirmation? How many confirmations was OKPay requiring at the time? 6 confirms at gox annoys me so it's a useful case study.

Bitcoiner since the early days. Crypto YouTube Channel: Trading Nomads | Analyst | News Reporter | Bitcoin Hodler | Support Freedom of Speech!
dooglus
Legendary
*
Offline Offline

Activity: 2926
Merit: 1310



View Profile
March 12, 2013, 09:14:07 PM
 #46

That particular theory, if correct, suggests that it's safer to have saved memory pools between loads

Would that have helped in this situation?  The first spend had already been mined on the 0.8 chain, and so wouldn't have been in the mempool any more.  Even if the mempool persisted when the miner switched to 0.7, the first spend wouldn't be known and so the double spend would still be added to the mempool when broadcast.

Just-Dice                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   Play or Invest                 ██             
          ██████████         
      ██████████████████     
  ██████████████████████████ 
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
██████████████████████████████
    ██████████████████████   
        ██████████████       
            ██████           
   1% House Edge
Aseras
Hero Member
*****
Offline Offline

Activity: 658
Merit: 500


View Profile
March 12, 2013, 09:18:06 PM
 #47

Any guesses as to the reason it didn't show up in the pre-0.8 branch?   I don't see any reason that the original transaction could be systematically rejected by one branch and not the other.  Even transactions that hadn't made it into blocks in the pre-0.7 branch should still be in the nodes' memory pools and double-spends rejected.

Has this been answered?

Perfect timing, the second transaction went in because it was mined, and at the same time enough pools reverted while the chain was reloaded that it was 51% and the other block was considered orphaned so it was included.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2744
Merit: 1016



View Profile
March 12, 2013, 09:24:54 PM
Last edit: March 12, 2013, 09:42:13 PM by molecular
 #48

gmaxwell answered it:  a large majority of mining power switched to running 0.7 -- which meant restarting the miners and clearing their memory pools.  With the right dynamics, a rebroadcast would not repropagate because most nodes had not been restarted and would not rebroadcast it.  Thus, those miners that restarted, started mining without it, and accepted the double-spend as a first-spend.

gmaxwell and gwillen just enlightened me a little further on #bitcoin-dev. The scenario seems likely to me now especially after I got the info that only about 10% of the miners had been on 0.7 before the split. They probably had the initial TX, but just didn't find a block in time.

I also understand why the 0.7 chain was chosen: if the 0.8 chains was chosen, double-spends would even now still be possible against merchants who are still asleep about the issue, which is worse.

A question still: rebroadcast? How does that work? Who would rebroadcasts the tx and triggered by what?

That particular theory, if correct, suggests that it's safer to have saved memory pools between loads, to make the keep/drop decision deterministic.

Saved memory pools, or maybe something in the protocol that enables syncing of the mempool from other peers? Sounds good, but again I don't know enough.

EDIT: fixed 0.7/0.8 mixup

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
molecular
Donator
Legendary
*
Offline Offline

Activity: 2744
Merit: 1016



View Profile
March 12, 2013, 09:27:57 PM
 #49

That particular theory, if correct, suggests that it's safer to have saved memory pools between loads

Would that have helped in this situation?  The first spend had already been mined on the 0.8 chain, and so wouldn't have been in the mempool any more.  Even if the mempool persisted when the miner switched to 0.7, the first spend wouldn't be known and so the double spend would still be added to the mempool when broadcast.

Probably true.

Quote from: #bitcoin-dev
<jgarzik> another example of mempool-on-startup being useful to miners: https://bitcointalk.org/index.php?topic=152348.msg1617466#msg1617466
<jgarzik> again, I ponder a -mempool-on-startup command line flag
<jgarzik> default off, but present for miners

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
TheSeven
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500


FPGA Mining LLC


View Profile WWW
March 12, 2013, 09:34:21 PM
 #50

I also understand why the 0.8 chain was chosen: if the 0.7 chains was chosen, double-spends would even now still be possible against merchants who are still asleep about the issue, which is worse.

That's exactly the wrong way round. The 0.7 chain was chosen, because this would have happened if the 0.8 one would have been chosen.

My tip jar: 13kwqR7B4WcSAJCYJH1eXQcxG5vVUwKAqY
molecular
Donator
Legendary
*
Offline Offline

Activity: 2744
Merit: 1016



View Profile
March 12, 2013, 09:42:24 PM
 #51

I also understand why the 0.8 chain was chosen: if the 0.7 chains was chosen, double-spends would even now still be possible against merchants who are still asleep about the issue, which is worse.

That's exactly the wrong way round. The 0.7 chain was chosen, because this would have happened if the 0.8 one would have been chosen.

thanks, fixed in my post

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
bitcoinbetas
Sr. Member
****
Offline Offline

Activity: 240
Merit: 250



View Profile
March 12, 2013, 09:48:43 PM
 #52

If I am reading this correctly, it could only happen during this weird period when we had several blockchains floating around. Is that correct?

Correct. Nothing to see here....
Largo
Member
**
Offline Offline

Activity: 112
Merit: 10



View Profile
March 12, 2013, 09:52:40 PM
 #53

I also understand why the 0.8 chain was chosen: if the 0.7 chains was chosen, double-spends would even now still be possible against merchants who are still asleep about the issue, which is worse.

That's exactly the wrong way round. The 0.7 chain was chosen, because this would have happened if the 0.8 one would have been chosen.


If the 0.8 chain was chosen, no double spends would have happened since RPC interface on 0.7 clients was stopped and client showed a 'you might need to upgrade/downgrade' message.

At least for me, ironically it made me upgrade to 0.8, because i noticed it before the threads started.

Fiyasko
Legendary
*
Offline Offline

Activity: 1428
Merit: 1000


Okey Dokey Lokey


View Profile
March 12, 2013, 10:51:45 PM
 #54

Oh my god... Do we blame the services? Or the client upgrade?

http://bitcoin-otc.com/viewratingdetail.php?nick=DingoRabiit&sign=ANY&type=RECV <-My Ratings
https://bitcointalk.org/index.php?topic=857670.0 GAWminers and associated things are not to be trusted, Especially the "mineral" exchange
Spaceman_Spiff
Legendary
*
Offline Offline

Activity: 1638
Merit: 1000


₪``Campaign Manager´´₪


View Profile
March 12, 2013, 11:01:13 PM
 #55

Oh my god... Do we blame the services? Or the client upgrade?

That's easy : blame Canada !

http://www.youtube.com/watch?v=bOR38552MJA
mccorvic
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile
March 12, 2013, 11:36:35 PM
 #56

Oh my god... Do we blame the services? Or the client upgrade?

That's easy : blame Canada !

http://www.youtube.com/watch?v=bOR38552MJA

I blame my mother.

Offering Video/Audio Editing Services since 2011 - https://bitcointalk.org/index.php?topic=77932.0
Piper67
Legendary
*
Offline Offline

Activity: 1106
Merit: 1001



View Profile
March 12, 2013, 11:37:38 PM
 #57

Oh my god... Do we blame the services? Or the client upgrade?

That's easy : blame Canada !

http://www.youtube.com/watch?v=bOR38552MJA

I blame my mother.

I blame Canada's mother!
iCEBREAKER
Legendary
*
Offline Offline

Activity: 2156
Merit: 1070


Crypto is the separation of Power and State.


View Profile WWW
March 12, 2013, 11:44:58 PM
 #58

How does one detect a fork?

Run several versions of Bitcoin and if they start to mutually deviate over three blocks then that is either a fork or is, a least, sufficient reason for merchants to go into safe mode. Sounds to me like a business opportunity.

Actually, if this is implemented, it would make it much safer for alternative full Bitcoin clients to operate because we could detect the inevitable chain splits quickly and safely.

You're reading my mind bro. 

Any service handling serious amounts of BTC should be running a .7 (stable) and a .8 (beta) while checking the outputs for diff.

Also, why didn't .7's large block problem show up on testnet?


██████████
█████████████████
██████████████████████
█████████████████████████
████████████████████████████
████
████████████████████████
█████
███████████████████████████
█████
███████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
███████████████████████████
██████
██████████████████████████
█████
███████████████████████████
█████████████
██████████████
████████████████████████████
█████████████████████████
██████████████████████
█████████████████
██████████

Monero
"The difference between bad and well-developed digital cash will determine
whether we have a dictatorship or a real democracy." 
David Chaum 1996
"Fungibility provides privacy as a side effect."  Adam Back 2014
Buy and sell XMR near you
P2P Exchange Network
Buy XMR with fiat
Is Dash a scam?
jubalix
Legendary
*
Offline Offline

Activity: 2338
Merit: 1013


View Profile WWW
March 13, 2013, 12:03:37 AM
 #59

well this is a fine mess one block chain goes sailing of into the abyss, but on the way people still think it ok and so cash in on int

it was the *other block chain* that was actually the real one, with no record of what is no longer the truth.

Oh look my moneys back!!!

Oh look i did not get those bitcoins!

Admitted Practicing Lawyer::BTC/Crypto Specialist. B.Engineering/B.Laws

https://www.binance.com/?ref=10062065
sd
Hero Member
*****
Offline Offline

Activity: 730
Merit: 500



View Profile
March 13, 2013, 12:22:57 AM
 #60

Also, why didn't .7's large block problem show up on testnet?

I suspect because nobody was testing for this problem.

Client testing needs to be radically improved if bitcoin is going to be a success.
arklan
Legendary
*
Offline Offline

Activity: 1778
Merit: 1008



View Profile
March 13, 2013, 12:24:25 AM
 #61

Also, why didn't .7's large block problem show up on testnet?

I suspect because nobody was testing for this problem.

Client testing needs to be radically improved if bitcoin is going to be a success.


agreed. unfortunately it's kinda difficult. i mean, as someone involved in the testing of bitcoin, i have one pc, with one OS. the tests i can do are limited.

i don't post much, but this space for rent.
makomk
Hero Member
*****
Offline Offline

Activity: 686
Merit: 501


View Profile
March 13, 2013, 12:27:40 AM
 #62

Excuse my non-technical, conceptual-only questions / thoughts / checking if I have this right in my head:


1)  There was no *permanent*  "double spend" right?   i.e. the transaction on the .8 fork would have eventually been orphaned / dumped / never credited to the address specified in the .8 block?

2)  The risk here (and reason why SwC shut off all deposits / withdraws for a few hrs until this was resolved) was that during this very odd period a sophisticated user could use multiple 0-conf services that would all at the same time believe they were getting the same coins, but after the blockchain becomes 1 again only 1 of the transactions would actually be included in the "real" blockchain?
In theory this didn't just affect 0-confirmation services. The transaction on the 0.8 side of the double-spend got 15 confirmations on that fork before it was invalidated by the conflicting transaction from the 0.7 side of the fork, which is more confirmations than anyone requires.

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

Activity: 784
Merit: 1000


View Profile
March 13, 2013, 01:06:33 AM
 #63

Excuse my non-technical, conceptual-only questions / thoughts / checking if I have this right in my head:


1)  There was no *permanent*  "double spend" right?   i.e. the transaction on the .8 fork would have eventually been orphaned / dumped / never credited to the address specified in the .8 block?

2)  The risk here (and reason why SwC shut off all deposits / withdraws for a few hrs until this was resolved) was that during this very odd period a sophisticated user could use multiple 0-conf services that would all at the same time believe they were getting the same coins, but after the blockchain becomes 1 again only 1 of the transactions would actually be included in the "real" blockchain?
In theory this didn't just affect 0-confirmation services. The transaction on the 0.8 side of the double-spend got 15 confirmations on that fork before it was invalidated by the conflicting transaction from the 0.7 side of the fork, which is more confirmations than anyone requires.

So I think the 6-confirmation recommendation should be changed: tell the merchants to wait for as many as possible if time permits, or if the amount is large.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
datafish
Donator
Full Member
*
Offline Offline

Activity: 129
Merit: 100


Swimming in a sea of data


View Profile
March 13, 2013, 02:50:28 AM
 #64

So I think the 6-confirmation recommendation should be changed: tell the merchants to wait for as many as possible if time permits, or if the amount is large.

How about 6 confirmations plus the length of the longest fork difference, which is usually 0 or 1.  I think we need an automated fork monitoring system, with red alerts to the devs, miners and merchants when it gets greater than 2 blocks. 
oakpacific
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
March 13, 2013, 03:00:12 AM
 #65

So I think the 6-confirmation recommendation should be changed: tell the merchants to wait for as many as possible if time permits, or if the amount is large.

How about 6 confirmations plus the length of the longest fork difference, which is usually 0 or 1.  I think we need an automated fork monitoring system, with red alerts to the devs, miners and merchants when it gets greater than 2 blocks.  

There would be no way of knowing whether the longest one is the correct one, i.e., someone mined an orphan block and is immediately rejected, yet the main chain's difference to the orphaned chain will still continue to grow, but the monitoring system is a good idea, if both branches are detected to have two or more blocks, everyone gets an alert, and the merchant will keep requesting new confirmations until one branch stops growing for a certain period of time.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
DBordello
Sr. Member
****
Offline Offline

Activity: 349
Merit: 250


BTCPak.com - Exchange your Bitcoins for MP!


View Profile WWW
March 13, 2013, 03:19:23 AM
 #66

Currently the merchant just polls the transaction for the number of confirmations.  The client never says "this one is non-reversible".  This kind of monitoring system would require the client to make a judgement call.

www.BTCPak.com - Exchange your bitcoins for MP: Secure, Anonymous and Easy!
iCEBREAKER
Legendary
*
Offline Offline

Activity: 2156
Merit: 1070


Crypto is the separation of Power and State.


View Profile WWW
March 13, 2013, 03:30:57 AM
 #67

Also, why didn't .7's large block problem show up on testnet?

I suspect because nobody was testing for this problem.

Client testing needs to be radically improved if bitcoin is going to be a success.


agreed. unfortunately it's kinda difficult. i mean, as someone involved in the testing of bitcoin, i have one pc, with one OS. the tests i can do are limited.

Really?  You can't emulate testnets-in-a-VM and try ranges of values for different parameters to see what breaks?


██████████
█████████████████
██████████████████████
█████████████████████████
████████████████████████████
████
████████████████████████
█████
███████████████████████████
█████
███████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
████████████████████████████
██████
███████████████████████████
██████
██████████████████████████
█████
███████████████████████████
█████████████
██████████████
████████████████████████████
█████████████████████████
██████████████████████
█████████████████
██████████

Monero
"The difference between bad and well-developed digital cash will determine
whether we have a dictatorship or a real democracy." 
David Chaum 1996
"Fungibility provides privacy as a side effect."  Adam Back 2014
Buy and sell XMR near you
P2P Exchange Network
Buy XMR with fiat
Is Dash a scam?
oakpacific
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
March 13, 2013, 03:35:59 AM
 #68

Currently the merchant just polls the transaction for the number of confirmations.  The client never says "this one is non-reversible".  This kind of monitoring system would require the client to make a judgement call.

I don't think you even need to change the client, it's about if the merchant delivers the final goods or not, so it could be an additional system that just checks the blockchain for possible forks.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
Maged
Legendary
*
Offline Offline

Activity: 1204
Merit: 1006


View Profile
March 13, 2013, 03:36:32 AM
 #69

So I think the 6-confirmation recommendation should be changed: tell the merchants to wait for as many as possible if time permits, or if the amount is large.

How about 6 confirmations plus the length of the longest fork difference, which is usually 0 or 1.  I think we need an automated fork monitoring system, with red alerts to the devs, miners and merchants when it gets greater than 2 blocks.  

There would be no way of knowing whether the longest one is the correct one, i.e., someone mined an orphan block and is immediately rejected, yet the main chain's difference to the orphaned chain will still continue to grow, but the monitoring system is a good idea, if both branches are detected to have two or more blocks, everyone gets an alert, and the merchant will keep requesting new confirmations until one branch stops growing for a certain period of time.
More importantly, if there is ever an orphan chain that appears to have more than a few percent of the hashing power, ALL clients should enter safe mode. The only time we wouldn't want that is if we did an intentional hard fork, but in that case the incompatible ("new") chain should have over 90% of the hashing power

robbonz
Newbie
*
Offline Offline

Activity: 25
Merit: 0



View Profile
March 13, 2013, 04:25:21 AM
 #70

http://coincompare.com/themes/bitcompare/images/bitcoin-fork.jpg
eldentyrell
Donator
Legendary
*
Offline Offline

Activity: 980
Merit: 1004


felonious vagrancy, personified


View Profile WWW
March 13, 2013, 05:04:25 AM
 #71

Quote from: Bitcoinin
Merchants like this probably need to build something into their systems to automatically go into a safe mode if a 2-3 block fork is detected.

This might be an equally effective but less centralized approach. What do you think?

Yeah, this is probably the solution.

The Satoshi client already watches for long invalid chains -- a chain it thinks is malformed but yet has had more hashpower thrown at it than any other.  The 0.7 clients saw this happen; it's what triggered the "maybe you need to upgrade" message.  Unfortunately this never happened from the perspective of 0.8 clients.  From their perspective the whole network suddenly colluded to perform a massive 51% attack by orphaning a huge part of the chain.

Unfortunately it doesn't look like this can be ruled out in the future -- a situation where the miners have to choose between orphaning a huge branch vs permanently splitting the network (I hope they'll continue choosing the former).  So watching not only for longer invalid chains but also for unusually-long-but-not-longest branches is probably something that needs to happen.


How does one detect a fork?

Run several versions of Bitcoin

You can do it without having to run multiple clients.

Example: if there is a branch more than six blocks long and the forking point is less than 144 blocks (~24 hours) back, stay in safe mode until this is no longer true.  This will protect users on both sides of the fork so long as (a) nobody's trusting transactions with less than six confirmations and (b) the problem is discovered within 24 hours.

The printing press heralded the end of the Dark Ages and made the Enlightenment possible, but it took another three centuries before any country managed to put freedom of the press beyond the reach of legislators.  So it may take a while before cryptocurrencies are free of the AML-NSA-KYC surveillance plague.
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1010


View Profile
March 13, 2013, 05:06:05 AM
 #72

Is this the only sucessful double spend yesterday? Has anyone made a detailed analysis?

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
arklan
Legendary
*
Offline Offline

Activity: 1778
Merit: 1008



View Profile
March 13, 2013, 05:24:09 AM
 #73

Also, why didn't .7's large block problem show up on testnet?

I suspect because nobody was testing for this problem.

Client testing needs to be radically improved if bitcoin is going to be a success.


agreed. unfortunately it's kinda difficult. i mean, as someone involved in the testing of bitcoin, i have one pc, with one OS. the tests i can do are limited.

Really?  You can't emulate testnets-in-a-VM and try ranges of values for different parameters to see what breaks?

while obviously that's possible, i'm sad ot admit it's beyond my knowledge, currently.

i don't post much, but this space for rent.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2744
Merit: 1016



View Profile
March 13, 2013, 06:44:19 AM
 #74

Currently the merchant just polls the transaction for the number of confirmations.  The client never says "this one is non-reversible".  This kind of monitoring system would require the client to make a judgement call.

I don't think you even need to change the client, it's about if the merchant delivers the final goods or not, so it could be an additional system that just checks the blockchain for possible forks.

it's not quite that simple: which blockchain?

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
Prattler
Full Member
***
Offline Offline

Activity: 192
Merit: 100


View Profile
March 13, 2013, 09:22:38 AM
 #75

Well to be fair, OKpay did a pretty lousy job.

Cheap, fast, secure – you can only choose 2.

1. Cheap and secure: wait for a big number of confirmations, depending on the transaction size and business type.
2. Fast and secure: you need to have people and automatic warning systems to hold payments when something goes bad.
3. Cheap and fast: don't allow users to cash out big sums.

OKpay went with option 3. It's unfortunate it happened, they would have avoided trouble, had they gone with options 1 or 2.

I don't think this will seriously damage bitcoin. If anything, payment processors will implement warning systems that will automatically suspend payments and prevent this in the future.
Raoul Duke
aka psy
Legendary
*
Offline Offline

Activity: 1358
Merit: 1000



View Profile
March 13, 2013, 09:46:14 AM
 #76

You already have your 64.xxxx BTC. Unconfirmed yet. Now you can sleep  Cool
Grami
Newbie
*
Offline Offline

Activity: 39
Merit: 0


View Profile
March 13, 2013, 09:48:17 AM
 #77

http://blockchain.info/tx/cf7121622d6b208357b2a115cc75a9be283f8996dd7d6f612923b30f600bcadd
OKPAY
Newbie
*
Offline Offline

Activity: 32
Merit: 0



View Profile WWW
March 13, 2013, 09:49:16 AM
 #78

This is not the way to do customer service. If not this incident, I don't know when they start to care me and return me the 64.xxx BTC.
The payment has been successfully completed http://blockchain.info/tx/cf7121622d6b208357b2a115cc75a9be283f8996dd7d6f612923b30f600bcadd

Yup the "duplicate" payment has been payed out and thus the amount of 64 BTC was put on hold before user agreed to return the faulty payment. So everything could be solved much faster and easier by contacting support. I suppose it's always a tempting to try to get away with something that not belongs to you.
S-Fattah
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
March 13, 2013, 10:16:47 AM
 #79

Well done, guys.
One question: This guy has returned your money?
OKPAY
Newbie
*
Offline Offline

Activity: 32
Merit: 0



View Profile WWW
March 13, 2013, 10:25:08 AM
 #80

Yes we resolved this situation.
oakpacific
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
March 13, 2013, 10:28:06 AM
Last edit: March 13, 2013, 10:46:33 AM by oakpacific
 #81

Currently the merchant just polls the transaction for the number of confirmations.  The client never says "this one is non-reversible".  This kind of monitoring system would require the client to make a judgement call.

I don't think you even need to change the client, it's about if the merchant delivers the final goods or not, so it could be an additional system that just checks the blockchain for possible forks.

it's not quite that simple: which blockchain?

The simplest way is to  just query a third party, e.g., blockchain.info's API, I am sure there are many other methods, to those who are on the orphaned chain, the main chain is just their orphaned chain, you only need to decide if there is a big difference between the two chains, no need to decide which one is right.

https://tlsnotary.org/ Fraud proofing decentralized fiat-Bitcoin trading.
luv2drnkbr
Hero Member
*****
Offline Offline

Activity: 794
Merit: 1001



View Profile
March 14, 2013, 02:12:13 AM
 #82

Currently the merchant just polls the transaction for the number of confirmations.  The client never says "this one is non-reversible".  This kind of monitoring system would require the client to make a judgement call.

I don't think you even need to change the client, it's about if the merchant delivers the final goods or not, so it could be an additional system that just checks the blockchain for possible forks.

it's not quite that simple: which blockchain?

the longest one.  that's always the main chain.  that's why the two forks were called the 0.8 chain and the 0.7 chain.  chains that aren't the longest are the forks.  for a while the 0.7 chain was the fork until miners agreed with gavin that they should switch to it.  then it became the longest.

AndrH
Newbie
*
Offline Offline

Activity: 7
Merit: 0


View Profile
March 14, 2013, 11:53:44 AM
 #83

Yes we resolved this situation.

Happy end =)
matt4054
Legendary
*
Offline Offline

Activity: 1778
Merit: 1017


BitcoinQueue.com


View Profile WWW
March 14, 2013, 12:45:29 PM
 #84

I was wondering if this was the reason why OKPAY has still not resumed Bitcoin operations since the fork, while others already have?

I use OKPAY services including Bitcoin on a regular basis and I would hate that such events have long term consequences on OKPAY operations as well as other payment providers.
Piper67
Legendary
*
Offline Offline

Activity: 1106
Merit: 1001



View Profile
March 14, 2013, 03:10:45 PM
 #85

Yes we resolved this situation.

On behalf of those of us wanting to use OKPAY and Bitcoin, please don't let the wilful actions of one individual affect your operations too much. By his own admission, he attempted a double spend once he saw what was happening... clearly, a hard fork is not desirable, but the last time there was one was in 2010 (technically, orphaned blocks happen all the time and could be considered mini forks, but we're talking about one that went beyond six confirmations).
paraipan
Legendary
*
Offline Offline

Activity: 924
Merit: 1003


Firstbits: 1pirata


View Profile WWW
March 14, 2013, 05:15:59 PM
Last edit: March 14, 2013, 10:52:35 PM by paraipan
 #86

Yes we resolved this situation.

Nice to hear that.

To prevent this happening again in the future consider implementing "bitcoind alerts", and do automatic emergency stop on all bitcoin transactions if an alert ever shows up. It's an elegant and easy way to be warned by the community, and with enough time to avoid being "double-spent".

BTCitcoin: An Idea Worth Saving - Q&A with bitcoins on rugatu.com - Check my rep
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1003


View Profile
March 14, 2013, 09:24:25 PM
Last edit: March 14, 2013, 11:01:59 PM by Stephen Gornick
 #87

I later manually corrected the issue with another transaction, thus double spend.

For post-mortem analysis, would you mind sharing how that raw transaction was broadcast?  Through bitcoin-Qt/bitcoind I presume?   But was this just connecting to peers or had you actually explicitly connected to a mining pool or well connected node?

The question is that most peers would have rejected it because they should already have known of the original transaction (12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195) and not relayed your double spend (762443f6373b7c8b3833d4ad23578fc3099cc29b86d1359d0c0565e3c8614f91).  

With all the nodes reverting to 0.7 and/or starting up with an empty memory pool it is not impossible for your node to have reached one of them with no knowledge of the original transaction and then because your double spend transaction was perfectly valid for that node to relay your transaction got relayed to other new nodes as well.  Eventually then there would be a path that would reach the miner who eventually mined 225466 (the block with the double spend) -- BTC Guild [Edit: Yes, confirmed BTC Guild, per the coinbase].

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


JeromeS
Newbie
*
Offline Offline

Activity: 55
Merit: 0


View Profile
March 15, 2013, 01:14:14 AM
 #88

Been meaning to do this since The Night of the Two Chains, finally got the time to do it today.

A list of all transactions included in the .8 fork but not the (current) main chain. i.e. possible double spends.
270 transactions out of 11914 fit that description (2.26%).


(got the data from here, for some reason that page doesn't work anymore)

I might go through all of these later and try to find any "special" ones. For now though I have to study... : /


p.s. sorry for the huge post. [spoiler] tag not working. how do I spoiler stuff on this forum ?
macbook-air
Sr. Member
****
Offline Offline

Activity: 324
Merit: 250


View Profile WWW
March 15, 2013, 02:02:08 AM
Last edit: March 15, 2013, 02:21:27 AM by macbook-air
 #89

I later manually corrected the issue with another transaction, thus double spend.

For post-mortem analysis, would you mind sharing how that raw transaction was broadcast?  Through bitcoin-Qt/bitcoind I presume?   But was this just connecting to peers or had you actually explicitly connected to a mining pool or well connected node?

The question is that most peers would have rejected it because they should already have known of the original transaction (12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195) and not relayed your double spend (762443f6373b7c8b3833d4ad23578fc3099cc29b86d1359d0c0565e3c8614f91).  

With all the nodes reverting to 0.7 and/or starting up with an empty memory pool it is not impossible for your node to have reached one of them with no knowledge of the original transaction and then because your double spend transaction was perfectly valid for that node to relay your transaction got relayed to other new nodes as well.  Eventually then there would be a path that would reach the miner who eventually mined 225466 (the block with the double spend) -- BTC Guild [Edit: Yes, confirmed BTC Guild, per the coinbase].


Code:
$ git diff src/rpcrawtransaction.cpp
diff --git a/src/rpcrawtransaction.cpp b/src/rpcrawtransaction.cpp
index e634ed7..1f045e8 100644
--- a/src/rpcrawtransaction.cpp
+++ b/src/rpcrawtransaction.cpp
@@ -164,8 +164,6 @@ Value listunspent(const Array& params, bool fHelp)
             CBitcoinAddress address(input.get_str());
             if (!address.IsValid())
                 throw JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY, string("Invalid Bitcoin address: ")+input.get_str());
-            if (setAddress.count(address))
-                throw JSONRPCError(RPC_INVALID_PARAMETER, string("Invalid parameter, duplicated address: ")+input.get_str());
            setAddress.insert(address);
         }
     }
@@ -520,9 +518,11 @@ Value sendrawtransaction(const Array& params, bool fHelp)
     {
         // push to local node
         CTxDB txdb("r");
-        if (!tx.AcceptToMemoryPool(txdb))
-            throw JSONRPCError(RPC_DESERIALIZATION_ERROR, "TX rejected");
-
+        if (!tx.AcceptToMemoryPool(txdb)) {
+            SyncWithWallets(tx, NULL, true);
+            RelayMessage(CInv(MSG_TX, hashTx), tx);
+            throw JSONRPCError(RPC_DESERIALIZATION_ERROR, string("TX rejected, relay anyway ")+hashTx.GetHex());
+        }
         SyncWithWallets(tx, NULL, true);
     }
     RelayMessage(CInv(MSG_TX, hashTx), tx);
$ bitcoin createrawtransaction '[{"txid": "e6ee06cec15f8fab2c1aa81037e6ba9b1d7c7c4073a2795e847aa9ca5b84daf1", "vout": 1}]' '{"1J1F3U7gHrCjsEsRimDJ3oYBiV24wA8FuV": 137.35368622}'
0100000001f1da845bcaa97a845e79a273407c7c1d9bbae63710a81a2cab8f5fc1ce06eee60100000000ffffffff01ae17b132030000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000
$ bitcoin signrawtransaction 0100000001f1da845bcaa97a845e79a273407c7c1d9bbae63710a81a2cab8f5fc1ce06eee60100000000ffffffff01ae17b132030000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000 '[{"txid": "e6ee06cec15f8fab2c1aa81037e6ba9b1d7c7c4073a2795e847aa9ca5b84daf1", "vout": 1, "scriptPubKey": "76a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac"}]'
{
    "hex" : "0100000001f1da845bcaa97a845e79a273407c7c1d9bbae63710a81a2cab8f5fc1ce06eee6010000008c493046022100d6e0dec64778c669a4869a73dc057959ac6f8c6fa390e9ceb03bb040d3eb0933022100f3dc55dccbde883e7aadf737a5d8531847fdab1cc2b80a2357ce5dc5378a8485014104054f0d458c4dc3d0a4bb35cd17e624eb76ea99b702561bd0bea0aefe34c6c860fafca4faae957bb009e0ece9cba07cccd30dc008512a9a3021dbcfd2127938fcffffffff01ae17b132030000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000",
    "complete" : true
}
$ bitcoin createrawtransaction '[{"txid": "b53cbbf160f1a5c470dba13672338908c5c9099985f6fdc37d44a5facae957df", "vout": 1}]' '{"1J1F3U7gHrCjsEsRimDJ3oYBiV24wA8FuV": 62.64371378}'
0100000001df57e9cafaa5447dc3fdf6859909c9c50889337236a1db70c4a5f160f1bb3cb50100000000ffffffff01b2b86275010000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000
$ bitcoin signrawtransaction 0100000001df57e9cafaa5447dc3fdf6859909c9c50889337236a1db70c4a5f160f1bb3cb50100000000ffffffff01b2b86275010000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000 '[{"txid": "b53cbbf160f1a5c470dba13672338908c5c9099985f6fdc37d44a5facae957df", "vout": 1, "scriptPubKey": "76a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac"}]'
{
    "hex" : "0100000001f1da845bcaa97a845e79a273407c7c1d9bbae63710a81a2cab8f5fc1ce06eee6010000008c493046022100d6e0dec64778c669a4869a73dc057959ac6f8c6fa390e9ceb03bb040d3eb0933022100f3dc55dccbde883e7aadf737a5d8531847fdab1cc2b80a2357ce5dc5378a8485014104054f0d458c4dc3d0a4bb35cd17e624eb76ea99b702561bd0bea0aefe34c6c860fafca4faae957bb009e0ece9cba07cccd30dc008512a9a3021dbcfd2127938fcffffffff01ae17b132030000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000",
    "complete" : true
}
$ while true; do bitcoin sendrawtransaction 0100000001f1da845bcaa97a845e79a273407c7c1d9bbae63710a81a2cab8f5fc1ce06eee6010000008c493046022100d6e0dec64778c669a4869a73dc057959ac6f8c6fa390e9ceb03bb040d3eb0933022100f3dc55dccbde883e7aadf737a5d8531847fdab1cc2b80a2357ce5dc5378a8485014104054f0d458c4dc3d0a4bb35cd17e624eb76ea99b702561bd0bea0aefe34c6c860fafca4faae957bb009e0ece9cba07cccd30dc008512a9a3021dbcfd2127938fcffffffff01ae17b132030000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000; sleep 10; bitcoin sendrawtransaction 0100000001f1da845bcaa97a845e79a273407c7c1d9bbae63710a81a2cab8f5fc1ce06eee6010000008c493046022100d6e0dec64778c669a4869a73dc057959ac6f8c6fa390e9ceb03bb040d3eb0933022100f3dc55dccbde883e7aadf737a5d8531847fdab1cc2b80a2357ce5dc5378a8485014104054f0d458c4dc3d0a4bb35cd17e624eb76ea99b702561bd0bea0aefe34c6c860fafca4faae957bb009e0ece9cba07cccd30dc008512a9a3021dbcfd2127938fcffffffff01ae17b132030000001976a914ba85dc466140d3ef2eac3f7e42088ec501315a4b88ac00000000; sleep 10; done
15e8729f4632f9542790e12e7e6891ac42ca9d109c38656e7259b58ee9133d2e
22b85b88ac4f18afaab9c06ee70b47df7da23201bd2ad646ca0b202d775aa999
15e8729f4632f9542790e12e7e6891ac42ca9d109c38656e7259b58ee9133d2e
22b85b88ac4f18afaab9c06ee70b47df7da23201bd2ad646ca0b202d775aa999
15e8729f4632f9542790e12e7e6891ac42ca9d109c38656e7259b58ee9133d2e
22b85b88ac4f18afaab9c06ee70b47df7da23201bd2ad646ca0b202d775aa999
......

(I cannot remember whether the last command returns simply txid or "error: {"code":-22,"message":"TX rejected, relay anyway txid"})

No. My fully synced bitcoind refused to execute any commands except getinfo. It simply reports error message: "Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade." and exit.

So I had to set up a new bitcoind in Parallels Desktop's Ubuntu virtual machine and this bitcoind was not yet fully synced with the network. And it shouldn't have many connections as it was behind NAT.

Yurock
Sr. Member
****
Offline Offline

Activity: 462
Merit: 250


View Profile
April 17, 2013, 09:30:32 AM
 #90

Maybe the problem it that there is one implementation (bitcoind / bitcoin-qt) that decides what is right and what is not for the majority of the network. Bitcoin relies on a state when the vast majority of the network agree on the rules. That may not be the case when a single bug affects a large portion of the network. Under these conditions the whole proof of work mechanism becomes unreliable.

If we had a variety of implementations, a bug in one of them would have much smaller impact. Only users of the buggy client would be required to upgrade. We would not have to take the generally wrong way of downgrading to a buggy version.
arklan
Legendary
*
Offline Offline

Activity: 1778
Merit: 1008



View Profile
April 17, 2013, 09:37:52 AM
 #91

Maybe the problem it that there is one implementation (bitcoind / bitcoin-qt) that decides what is right and what is not for the majority of the network. Bitcoin relies on a state when the vast majority of the network agree on the rules. That may not be the case when a single bug affects a large portion of the network. Under these conditions the whole proof of work mechanism becomes unreliable.

If we had a variety of implementations, a bug in one of them would have much smaller impact. Only users of the buggy client would be required to upgrade. We would not have to take the generally wrong way of downgrading to a buggy version.

this is why the discussion of a "bitcoin spec" is ongoing and of worth. check the dev sub forum.

i don't post much, but this space for rent.
Bitcoinpro
Legendary
*
Offline Offline

Activity: 1344
Merit: 1000



View Profile
April 17, 2013, 11:51:43 AM
 #92

Just received a telephone call from OKPAY. The double spend money has been refunded to them. They promise me to send me my 64.xxx BTC within 15 minutes after they receive my refund. Please see if they respect their promise: 1J1F3U7gHrCjsEsRimDJ3oYBiV24wA8FuV This address should receive 64.xxx BTC before 09:30 UTC.



This is not the way to do customer service. If not this incident, I don't know when they start to care me and return me the 64.xxx BTC.

why is ok support using a comma and decimal point in the same post

WWW.FACEBOOK.COM

CRYPTOCURRENCY CENTRAL BANK

LTC: LP7bcFENVL9vdmUVea1M6FMyjSmUfsMVYf
Raoul Duke
aka psy
Legendary
*
Offline Offline

Activity: 1358
Merit: 1000



View Profile
April 17, 2013, 12:18:45 PM
 #93

why is ok support using a comma and decimal point in the same post

Probably both values copy pasted from previous messages or one of them c/p and the other written by the support person.
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1010


View Profile
April 08, 2014, 03:04:18 PM
 #94

It has been more than a year. I think this is the only instance of successful double spending of a 6-confirmation transaction. Have anything been done to address this problem? Comparing with those fancy applications, this involves the very fundamental principle: transaction irreversibility. If it is not fixed, I am sure it will happen again when we have another unexpected fork and the harm could be much more serious.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
arklan
Legendary
*
Offline Offline

Activity: 1778
Merit: 1008



View Profile
April 08, 2014, 03:12:55 PM
 #95

It has been more than a year. I think this is the only instance of successful double spending of a 6-confirmation transaction. Have anything been done to address this problem? Comparing with those fancy applications, this involves the very fundamental principle: transaction irreversibility. If it is not fixed, I am sure it will happen again when we have another unexpected fork and the harm could be much more serious.

Because this required a fork, I don't think there's anything that can be done. I mean, the entire system of bitcoin relies on forks not occurring. I'm no Dev though, so don't take my word as law.

i don't post much, but this space for rent.
drawingthesun
Legendary
*
Offline Offline

Activity: 1162
Merit: 1003


View Profile
April 08, 2014, 03:16:04 PM
 #96

It has been more than a year. I think this is the only instance of successful double spending of a 6-confirmation transaction. Have anything been done to address this problem? Comparing with those fancy applications, this involves the very fundamental principle: transaction irreversibility. If it is not fixed, I am sure it will happen again when we have another unexpected fork and the harm could be much more serious.

I wonder how it can be fixed?

Perhaps the client once seeing two similar chains is put into safe mode until an obvious longer chain emerges. Once one chain is perhaps 6 confirm ahead then automatically go out of safe mode and resume using the longest chain.

This solution would require no central control and can be automated by the nodes.

The important aspect would be the detection mechanism and watching two chains until there is a clear winner.
franky1
Legendary
*
Offline Offline

Activity: 3262
Merit: 2145



View Profile
April 08, 2014, 03:19:17 PM
 #97

It has been more than a year. I think this is the only instance of successful double spending of a 6-confirmation transaction. Have anything been done to address this problem? Comparing with those fancy applications, this involves the very fundamental principle: transaction irreversibility. If it is not fixed, I am sure it will happen again when we have another unexpected fork and the harm could be much more serious.

technically its not a double spend.. there is only one "receipt" of BTC that got confirmed on this main blockchain, meaning there is not 2 bunches of bitcoins that originated from one single bitcoin source on this main blockchain.

what happened is that businesses did not update the clients to be using the correct blockchain. thus the business does not see the correct transaction and ends out paying FIAT twice.

what needs to be done is to ensure forks dont happen, and in the small chance that a fork does occur, that businesses are not lazy about updating their clients, or double checking transactions before releasing different forms of funds or goods. (which would have prevented malleability issues if businesses had proper double checking methods in place)

there is not one single extra bitcoin on the blockchain that was cloned or not originate from a verified block reward. ill say it again a double spend is where 1 btc can be used twice. no coin has been used twice. all that has happened is that businesses have not had adequate checking processes in place. the bitcoin protocol and the blockchain does not show more confirmed coins then what has been released through blockchain rewards

I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER.
Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
zolace
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250


View Profile
April 08, 2014, 03:25:24 PM
 #98

All time UTC+08:00:

08:08 – Well before I knew what later have happened, I deposited $10000-worth Bitcoins to BTC-e over OKPAY's Bitcoin payment, I paid OKPAY address 12z2n8YCJw1BEsJhhQPLCTuLqwH341nKnE 211.9093 BTC and 0.0005 BTC as transaction fee.
09:30 – The transaction was included in version 0.8's fork, block 225446
10:08 – Deposit completed, $9800 credited to my BTC-e account
12:53 – After some study, I recognized, the transaction, though included in version 0.8's fork, was never confirmed by the pre-0.8 fork, so I decided to make two double spend transactions on two of the vins of the OKPAY transaction, and broadcasted them with the raw transaction API, 0.001 BTC transaction fee included in each transaction.
13:01 – The double spend transaction was included in pre-0.8 fork block 225446

You should know what happens next...

I bet merchants would think twice before they decide to accept Bitcoins after the incident.

well this is why there should be inventory watchers, and this is why there has to be someone to over look these transactions as this can be avoided.   

⚂⚄ Pocket Dice — Real dice experienceProvably Fair
Free BTC Faucet
⚅⚁
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
RodeoX
Legendary
*
Offline Offline

Activity: 3066
Merit: 1144


The revolution will be monetized!


View Profile
April 08, 2014, 03:28:31 PM
 #99

There has never been a double spend.

The gospel according to Satoshi - https://bitcoin.org/bitcoin.pdf
Free bitcoin in ? - Stay tuned for this years Bitcoin hunt!
Peter R
Legendary
*
Offline Offline

Activity: 1162
Merit: 1007



View Profile
April 08, 2014, 03:48:19 PM
Last edit: April 08, 2014, 04:04:25 PM by Peter R
 #100

It has been more than a year. I think this is the only instance of successful double spending of a 6-confirmation transaction. Have anything been done to address this problem? Comparing with those fancy applications, this involves the very fundamental principle: transaction irreversibility. If it is not fixed, I am sure it will happen again when we have another unexpected fork and the harm could be much more serious.

Like others have said, the same coin has never been spent twice in the history of bitcoin; when we say "double spend," we mean that someone thought they got paid but later found out that they didn't.  

There are many ways one can protect himself against such events.  In the case described in the OP, the event took place during a planned hard fork of the protocol.  If we feel it necessary to fork the code again (and we likely will), I think it would be wise for exchanges to require a full day of confirmations for large deposits.  Once it is clear that the fork was handled properly, services can reduce the confirmation requirements back to normal.  

Non-planned forks (large orphans) are rare. It is rarer still that the funds confirmed in the now-orphaned chain wouldn't also be confirmed in the new longest chain (it would strongly imply malicious intent, careful planning, and a large financial investment).  But one should still dynamically track confirmed coins and in the very very unlikely event that coins are not confirmed in the new chain, the service should immediately freeze the accounts in question.    

There is also nothing special about the number "6": personally, if I ran a large exchange I would likely require less than 6 confirmations for most deposits, but more than 6 for, say, 10 000 BTC.  

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
00ph8al
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
April 08, 2014, 03:52:12 PM
 #101

There has never been a double spend.

It seems like many have to believe this for their world to continue spinning but it is patently ludicrous to put your faith in a negative statement that by definition cannot be proven.

There HAVE been double spends and there will continue to be double spends.

If we truly want this experiment to survive we must identify these edge cases and provide solutions instead of burying our heads in the sand afraid of the bad publicity.
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1010


View Profile
April 08, 2014, 04:01:35 PM
 #102

ok, if you guys think it is not "double spend", let's call it "reversed transaction". That's not the main point here.


Quote
what happened is that businesses did not update the clients

Actually the opposite is true. OKPAY got cheated because they were using the latest client (0.Cool. If they did not update, they would never see the original transaction confirmed.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
RodeoX
Legendary
*
Offline Offline

Activity: 3066
Merit: 1144


The revolution will be monetized!


View Profile
April 08, 2014, 05:23:55 PM
 #103

There has never been a double spend.

It seems like many have to believe this for their world to continue spinning but it is patently ludicrous to put your faith in a negative statement that by definition cannot be proven.

There HAVE been double spends and there will continue to be double spends.

If we truly want this experiment to survive we must identify these edge cases and provide solutions instead of burying our heads in the sand afraid of the bad publicity.
Maybe your right? Please point me to a double spend.

The gospel according to Satoshi - https://bitcoin.org/bitcoin.pdf
Free bitcoin in ? - Stay tuned for this years Bitcoin hunt!
Syke
Legendary
*
Offline Offline

Activity: 3766
Merit: 1130


View Profile
April 08, 2014, 05:34:48 PM
 #104

Because this required a fork, I don't think there's anything that can be done. I mean, the entire system of bitcoin relies on forks not occurring. I'm no Dev though, so don't take my word as law.

Good thing you added that last line, because you are dead wrong. Forks are expected. They will always happen. That is a core feature in how Bitcoin is designed.

Buy & Hold
Joshuar
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500


eidoo wallet


View Profile
April 08, 2014, 05:37:38 PM
 #105

Correct me if I'm wrong, but forks are only possible with a certain amount of hash power, and to gain enough hash to fork the Bitcoin chain would be very expensive and thus impractical.

██
█║█
║║║
║║║
█║█
██

                    ▄██▄
                  ▄██████▄
                ▄██████████
              ▄██████████▀   ▄▄
            ▄██████████▀   ▄████▄
          ▄██████████▀    ████████▄
         ██████████▀      ▀████████
         ▀███████▀   ▄███▄  ▀████▀   ▄█▄
    ▄███▄  ▀███▀   ▄███████▄  ▀▀   ▄█████▄
  ▄███████▄      ▄██████████     ▄█████████
  █████████    ▄██████████▀    ▄██████████▀
   ▀█████▀   ▄██████████▀    ▄██████████▀
     ▀▀▀   ▄██████████▀    ▄██████████▀
          ██████████▀    ▄██████████▀
          ▀███████▀      █████████▀
            ▀███▀   ▄██▄  ▀█████▀
                  ▄██████▄  ▀▀▀
                  █████████
                   ▀█████▀
                     ▀▀▀
e i d o o
██


                    ▄██▄
                  ▄██████▄
                ▄██████████
              ▄██████████▀   ▄▄
            ▄██████████▀   ▄████▄
          ▄██████████▀    ████████▄
         ██████████▀      ▀████████
         ▀███████▀   ▄███▄  ▀████▀   ▄█▄
    ▄███▄  ▀███▀   ▄███████▄  ▀▀   ▄█████▄
  ▄███████▄      ▄██████████     ▄█████████
  █████████    ▄██████████▀    ▄██████████▀
   ▀█████▀   ▄██████████▀    ▄██████████▀
     ▀▀▀   ▄██████████▀    ▄██████████▀
          ██████████▀    ▄██████████▀
          ▀███████▀      █████████▀
            ▀███▀   ▄██▄  ▀█████▀
                  ▄██████▄  ▀▀▀
                  █████████
                   ▀█████▀
                     ▀▀▀
██
█║█
║║║
║║║
█║█
██
skooter
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
April 08, 2014, 06:12:50 PM
 #106

Correct me if I'm wrong, but forks are only possible with a certain amount of hash power, and to gain enough hash to fork the Bitcoin chain would be very expensive and thus impractical.

yeah you're wrong.

Forks happen anytime 2 miners solve a block referencing the same previous block.
b¡tco¡n
Member
**
Offline Offline

Activity: 84
Merit: 10

Correct Horse Battery Staple


View Profile
April 08, 2014, 09:28:29 PM
 #107

Correct me if I'm wrong, but forks are only possible with a certain amount of hash power, and to gain enough hash to fork the Bitcoin chain would be very expensive and thus impractical.

yeah you're wrong.

Forks happen anytime 2 miners solve a block referencing the same previous block.

But usually one of the forks gets chosen by consensus right? And after 6 of so confirmations it is extremely unlikely to change.

When this thread was opened there was a bug (or bug fixed) with the latest version of the software which means that the new version of the software chose a different branch to the old, which is a very different and horrible problem. IIRC the developers told people to downgrade to the old version and the associated fork became the chosen fork, and thus losing transactions made in the unchosen fork.

Hammer me if this isn't 100% accurate but I think it is the gist.

Usually forks are OK and get resolved. This thread is about a different 'hard' fork cause by software issues.

1GiB1jQnqjwmNW4U4i8autnnVb1fG8HTYM

This would be my avitar; http://s9.postimg.org/m2pzsiy57/avi.png
Meuh6879
Legendary
*
Offline Offline

Activity: 1512
Merit: 1010



View Profile
April 08, 2014, 09:47:09 PM
 #108

How serious is this please. Double spends  I thought were impossible . Huh

it's impossible.
when you wait the 1 confirmation (1 block) ... anyway.  Grin
Maged
Legendary
*
Offline Offline

Activity: 1204
Merit: 1006


View Profile
April 09, 2014, 02:55:47 AM
 #109

It has been more than a year. I think this is the only instance of successful double spending of a 6-confirmation transaction. Have anything been done to address this problem?
Yes, the failures in the automated alert systems have been addressed, so services should be able to disable themselves when a long fork is detected:
https://github.com/bitcoin/bitcoin/pull/2658

Bit_Happy
Legendary
*
Offline Offline

Activity: 2002
Merit: 1020


A Great Time to Start Something!


View Profile
April 09, 2014, 03:36:30 AM
 #110



Your .gif was not accurate.
2013 turned out to be a great year for BTC.  Smiley
00ph8al
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
April 09, 2014, 06:08:09 PM
 #111

There has never been a double spend.

It seems like many have to believe this for their world to continue spinning but it is patently ludicrous to put your faith in a negative statement that by definition cannot be proven.

There HAVE been double spends and there will continue to be double spends.

If we truly want this experiment to survive we must identify these edge cases and provide solutions instead of burying our heads in the sand afraid of the bad publicity.
Maybe your right? Please point me to a double spend.


What is your definition of double spend?

Are you including operator error and self-inflicted (ie. allowing 0-confirmations)?  The network (and access) isn't always fast enough for every use case either.

RodeoX
Legendary
*
Offline Offline

Activity: 3066
Merit: 1144


The revolution will be monetized!


View Profile
April 09, 2014, 07:45:15 PM
 #112


What is your definition of double spend?

Are you including operator error and self-inflicted (ie. allowing 0-confirmations)?  The network (and access) isn't always fast enough for every use case either.



I think of a double spend as a spend with confirmation followed by another spend of the same balance. Without confirmation it seems to me that the protocol is behaving as designed and, as you mention, it's an operator error. I also don't think that it counts if it happened on the test net.
A true double spend in the wild would spook me. If a method were found to do that, it would be the most serious threat to bitcoin so far.

The gospel according to Satoshi - https://bitcoin.org/bitcoin.pdf
Free bitcoin in ? - Stay tuned for this years Bitcoin hunt!
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1003


View Profile
April 12, 2014, 05:52:18 PM
 #113

I think of a double spend as a spend with confirmation followed by another spend of the same balance.

Which is what happened in March, 2013.  If you were using the v0.8 client there was a transaction that had more than six confirmations but later the fork which pre-v0.8 clients were mining surpassed the one the v0.8 were using and that transaction became invalid.  What happened was a user noticed the fork, created a new transaction that spent the same funds, used a custom client that repeatedly broadcast the double spend attempt and eventually that new transaction got included in the pre-v0.8 blockchain fork.

So yes, a double spend of a transaction that had six or more confirmations on what was at the time the longest chain is something that has occurred.

The gist of the problem was that miners starting up with the v0.7 client had an empty memory pool and thus no knowledge of the transactions that had already confirmed in the blockchain fork mined by the v0.8 clients.  So then it simply is a race -- whichever transaction (of the two that were spending the same coin) that reached those miners first is the one that was being hashed.   For that specific weakness, there are solutions that had been discussed but not implemented as far as I know.  For instance, when the miner is shut down the unconfirmed transactions in the memory pool could be written to the filesystem and then those transactions get loaded first when the miner starts back up.   That would likely have made the result of that March 2013 fork be that no double spends had occurred.

Unichange.me

            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █
            █


stefek99
Full Member
***
Offline Offline

Activity: 237
Merit: 102


https://genesis.re


View Profile WWW
June 04, 2017, 09:21:51 PM
 #114

This is part of the history!

* https://99bitcoins.com/price-chart-history/
* https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

cointastical
Newbie
*
Offline Offline

Activity: 22
Merit: 4


View Profile
January 03, 2019, 12:18:55 PM
 #115

Five years later, no block explorers still show Macbook-air's original transaction that had gotten double-spent after the block reorg.

Here's a list of seven transactions that (allegedly) had been confirmed on the v0.8 side of the fork, but were later double spent on the v0.7 side of the fork.
 
12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195
cb36ba33b3ecd4d3177d786209670c9e6cdf95eb62be54986f0b49ca292714af
7192807f952b252081d0db0aa7575c4695b945820adaf7776b7189e6b3d86f96
355d4ea51c3b780cf0b10e8099a06a31484e0060bc140b63f3d6e5fb713ace5e
b961bc0c663a46893afd3166a604e7e2639533522d9fec61fdb95eb665e86f5a
138063e4bdb76feaa511f1e7f9c681eb468ef9140c141671741c965e503b84c6
a10bd194cdbf9aa4c12eb0b120056998a081a9b0d93d70570edff24dec831f90

Source: https://pastebin.com/raw/wctJU3Ln
Pages: 1 2 3 4 5 6 [All]
  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!