|
Title: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: macbook-air on March 12, 2013, 06:22:02 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Jan on March 12, 2013, 06:38:27 PM All time UTC+08:00: Ouch...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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: bg002h on March 12, 2013, 06:38:59 PM 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... Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Jan on March 12, 2013, 06:42:19 PM Here is the tx: http://blockchain.info/tx/12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Elwar on March 12, 2013, 06:47:22 PM Ugh...this is worse than we thought.
Is this the first double spend? Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: yokosan on March 12, 2013, 06:51:50 PM Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: alir on March 12, 2013, 06:52:54 PM Guess they don't owe you anymore.
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Largo on March 12, 2013, 07:00:44 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Isokivi on March 12, 2013, 07:01:52 PM 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.
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: etotheipi on March 12, 2013, 07:04:49 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: casascius on March 12, 2013, 07:13:20 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: elux on March 12, 2013, 07:16:18 PM All time UTC+08:00: Ouch...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. Here is the tx: http://blockchain.info/tx/12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195 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? Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: TheButterZone on March 12, 2013, 07:18:04 PM move topic> https://bitcointalk.org/index.php?board=85.0 ?
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: gmaxwell on March 12, 2013, 07:20:09 PM 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.Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: MrCrabs on March 12, 2013, 07:21:24 PM How serious is this please. Double spends I thought were impossible . ???
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Melbustus on March 12, 2013, 07:26:35 PM How serious is this please. Double spends I thought were impossible . ??? 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: nevafuse on March 12, 2013, 07:35:06 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Spekulatius on March 12, 2013, 07:35:34 PM @ OP: Did you repay OK? ;D
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Ivica on March 12, 2013, 07:37:14 PM @ OP: Did you repay OK? ;D Nope, until they repay 64.91410001 BTC. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Nick on March 12, 2013, 07:41:05 PM 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 (http://www.reddit.com/r/Bitcoin/comments/1a5um4/bitcointalk_a_successful_double_spend_us10000/): 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? Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: blablahblah on March 12, 2013, 07:41:23 PM How serious is this please. Double spends I thought were impossible . ??? 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: RodeoX on March 12, 2013, 07:44:07 PM If I am reading this correctly, it could only happen during this weird period when we had several blockchains floating around. Is that correct?
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Piper67 on March 12, 2013, 07:45:06 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Elwar on March 12, 2013, 07:45:27 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Spaceman_Spiff on March 12, 2013, 07:47:39 PM 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 . Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Atheros on March 12, 2013, 07:48:09 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: somenick on March 12, 2013, 07:48:16 PM I've heard he was already catched :D
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: RodeoX on March 12, 2013, 07:48:55 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: mccorvic on March 12, 2013, 07:49:56 PM 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 :( Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Micon on March 12, 2013, 08:05:47 PM 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: http://floridatheatre.com/assets/2chainz_2nd-run-e1350312473755.jpg and sorry if there has already been a 2 Chainz reference. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: iddo on March 12, 2013, 08:09:01 PM 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 (https://bitcointalk.org/index.php?topic=102355.msg1437768#msg1437768). Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: mccorvic on March 12, 2013, 08:15:07 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Gabi on March 12, 2013, 08:28:30 PM That is why bitcoin is still beta software
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: impulse on March 12, 2013, 08:34:44 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Gabi on March 12, 2013, 08:36:09 PM 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...
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: molecular on March 12, 2013, 08:36:23 PM 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? Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: molecular on March 12, 2013, 08:38:55 PM 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? Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Gabi on March 12, 2013, 08:47:22 PM 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? Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: pera on March 12, 2013, 08:48:58 PM [..] could be something like this be implemented on the client to measure a potential fork?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? Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: molecular on March 12, 2013, 08:49:45 PM 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? 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". Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Wekkel on March 12, 2013, 08:50:27 PM A great opportunity to upgrade the software 8)
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Gabi on March 12, 2013, 08:51:57 PM Clients didn't crash, they just refused the "weird" block. Or did they crash?
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: molecular on March 12, 2013, 08:52:26 PM [..] could be something like this be implemented on the client to measure a potential fork?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? 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: etotheipi on March 12, 2013, 09:01:34 PM 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). Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: jago25_98 on March 12, 2013, 09:11:05 PM 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.
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: dooglus on March 12, 2013, 09:14:07 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Aseras on March 12, 2013, 09:18:06 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: molecular on March 12, 2013, 09:24:54 PM 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 Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: molecular on March 12, 2013, 09:27:57 PM 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 Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: TheSeven on March 12, 2013, 09:34:21 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: molecular on March 12, 2013, 09:42:24 PM 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 Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: bitcoinbetas on March 12, 2013, 09:48:43 PM 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.... Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Largo on March 12, 2013, 09:52:40 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Fiyasko on March 12, 2013, 10:51:45 PM Oh my god... Do we blame the services? Or the client upgrade?
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Spaceman_Spiff on March 12, 2013, 11:01:13 PM Oh my god... Do we blame the services? Or the client upgrade? That's easy : blame Canada ! http://www.youtube.com/watch?v=bOR38552MJA Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: mccorvic on March 12, 2013, 11:36:35 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Piper67 on March 12, 2013, 11:37:38 PM 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! Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: iCEBREAKER on March 12, 2013, 11:44:58 PM 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? Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: jubalix on March 13, 2013, 12:03:37 AM 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! Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: sd on March 13, 2013, 12:22:57 AM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: arklan on March 13, 2013, 12:24:25 AM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: makomk on March 13, 2013, 12:27:40 AM Excuse my non-technical, conceptual-only questions / thoughts / checking if I have this right in my head: 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.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? Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: oakpacific on March 13, 2013, 01:06:33 AM Excuse my non-technical, conceptual-only questions / thoughts / checking if I have this right in my head: 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.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? 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: datafish on March 13, 2013, 02:50:28 AM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: oakpacific on March 13, 2013, 03:00:12 AM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: DBordello on March 13, 2013, 03:19:23 AM 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.
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: iCEBREAKER on March 13, 2013, 03:30:57 AM 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? Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: oakpacific on March 13, 2013, 03:35:59 AM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Maged on March 13, 2013, 03:36:32 AM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: robbonz on March 13, 2013, 04:25:21 AM Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: eldentyrell on March 13, 2013, 05:04:25 AM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: jl2012 on March 13, 2013, 05:06:05 AM Is this the only sucessful double spend yesterday? Has anyone made a detailed analysis?
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: arklan on March 13, 2013, 05:24:09 AM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: molecular on March 13, 2013, 06:44:19 AM 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? Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Prattler on March 13, 2013, 09:22:38 AM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Raoul Duke on March 13, 2013, 09:46:14 AM You already have your 64.xxxx BTC. Unconfirmed yet. Now you can sleep 8)
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Grami on March 13, 2013, 09:48:17 AM http://blockchain.info/tx/cf7121622d6b208357b2a115cc75a9be283f8996dd7d6f612923b30f600bcadd
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: OKPAY on March 13, 2013, 09:49:16 AM 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/cf7121622d6b208357b2a115cc75a9be283f8996dd7d6f612923b30f600bcaddYup 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: S-Fattah on March 13, 2013, 10:16:47 AM Well done, guys.
One question: This guy has returned your money? Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: OKPAY on March 13, 2013, 10:25:08 AM Yes we resolved this situation.
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: oakpacific on March 13, 2013, 10:28:06 AM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: luv2drnkbr on March 14, 2013, 02:12:13 AM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: AndrH on March 14, 2013, 11:53:44 AM Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: matt4054 on March 14, 2013, 12:45:29 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Piper67 on March 14, 2013, 03:10:45 PM 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). Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: paraipan on March 14, 2013, 05:15:59 PM Yes we resolved this situation. Nice to hear that. To prevent this happening again in the future consider implementing "bitcoind alerts (https://en.bitcoin.it/wiki/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". Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Stephen Gornick on March 14, 2013, 09:24:25 PM 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) -- Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: JeromeS on March 15, 2013, 01:14:14 AM 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 (https://blockchain.info/en/orphaned-blocks), 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 ? Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: macbook-air on March 15, 2013, 02:02:08 AM 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) -- Code: $ git diff src/rpcrawtransaction.cpp 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. Title: Single implementation problem Post by: Yurock on April 17, 2013, 09:30:32 AM 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. Title: Re: Single implementation problem Post by: arklan on April 17, 2013, 09:37:52 AM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Bitcoinpro on April 17, 2013, 11:51:43 AM 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. http://www.yaohua2000.org/2013/20130312/OKPAY2.png 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 Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Raoul Duke on April 17, 2013, 12:18:45 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: jl2012 on April 08, 2014, 03:04:18 PM 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.
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: arklan on April 08, 2014, 03:12:55 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: drawingthesun on April 08, 2014, 03:16:04 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: franky1 on April 08, 2014, 03:19:17 PM 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 Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: zolace on April 08, 2014, 03:25:24 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: RodeoX on April 08, 2014, 03:28:31 PM There has never been a double spend.
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Peter R on April 08, 2014, 03:48:19 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: 00ph8al on April 08, 2014, 03:52:12 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: jl2012 on April 08, 2014, 04:01:35 PM 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.8). If they did not update, they would never see the original transaction confirmed. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: RodeoX on April 08, 2014, 05:23:55 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Syke on April 08, 2014, 05:34:48 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Joshuar on April 08, 2014, 05:37:38 PM 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.
Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: skooter on April 08, 2014, 06:12:50 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: b¡tco¡n on April 08, 2014, 09:28:29 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Meuh6879 on April 08, 2014, 09:47:09 PM How serious is this please. Double spends I thought were impossible . ??? it's impossible. when you wait the 1 confirmation (1 block) ... anyway. ;D Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Maged on April 09, 2014, 02:55:47 AM 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 Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Bit_Happy on April 09, 2014, 03:36:30 AM Your .gif was not accurate. 2013 turned out to be a great year for BTC. :) Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: 00ph8al on April 09, 2014, 06:08:09 PM 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. 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: RodeoX on April 09, 2014, 07:45:15 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: Stephen Gornick on April 12, 2014, 05:52:18 PM 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. Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: stefek99 on June 04, 2017, 09:21:51 PM This is part of the history!
* https://99bitcoins.com/price-chart-history/ * https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki Title: Re: A successful DOUBLE SPEND US$10000 against OKPAY this morning. Post by: cointastical on January 03, 2019, 12:18:55 PM 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 |
