Topic: A successful DOUBLE SPEND US$10000 against OKPAY this morning. - page 3. (Read 124029 times)
You already have your 64.xxxx BTC. Unconfirmed yet. Now you can sleep
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.
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.
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.
+1
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?
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.
Is this the only sucessful double spend yesterday? Has anyone made a detailed analysis?
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.
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.
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.
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?
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.
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.
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.
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.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.
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. 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, 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.
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.
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!
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!
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?
Jump to: