arklan
Legendary
Offline
Activity: 1778
Merit: 1008
|
|
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.
|
i don't post much, but this space for rent.
|
|
|
makomk
|
|
March 13, 2013, 12:27:40 AM |
|
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
|
|
March 13, 2013, 01:06:33 AM |
|
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.
|
|
|
|
datafish
Donator
Full Member
Offline
Activity: 129
Merit: 100
Swimming in a sea of data
|
|
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.
|
|
|
|
oakpacific
|
|
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.
|
|
|
|
DBordello
|
|
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.
|
www.BTCPak.com - Exchange your bitcoins for MP: Secure, Anonymous and Easy!
|
|
|
iCEBREAKER
Legendary
Offline
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
|
|
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?
|
██████████ ██████████████████ ██████████████████████ ██████████████████████████ ████████████████████████████ ██████████████████████████████ ████████████████████████████████ ████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ████████████████████████████████ ██████████████ ██████████████ ████████████████████████████ ██████████████████████████ ██████████████████████ ██████████████████ ██████████ 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
|
| | |
|
|
|
oakpacific
|
|
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.
|
|
|
|
Maged
Legendary
Offline
Activity: 1204
Merit: 1015
|
|
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. 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
Activity: 25
Merit: 0
|
|
March 13, 2013, 04:25:21 AM |
|
|
|
|
|
eldentyrell
Donator
Legendary
Offline
Activity: 980
Merit: 1004
felonious vagrancy, personified
|
|
March 13, 2013, 05:04:25 AM |
|
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 long er 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
Activity: 1792
Merit: 1111
|
|
March 13, 2013, 05:06:05 AM |
|
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
Activity: 1778
Merit: 1008
|
|
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.
|
i don't post much, but this space for rent.
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
|
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?
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
Prattler
|
|
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.
|
|
|
|
Raoul Duke
aka psy
Legendary
Offline
Activity: 1358
Merit: 1002
|
|
March 13, 2013, 09:46:14 AM |
|
You already have your 64.xxxx BTC. Unconfirmed yet. Now you can sleep
|
|
|
|
Grami
Newbie
Offline
Activity: 39
Merit: 0
|
|
March 13, 2013, 09:48:17 AM |
|
|
|
|
|
OKPAY
Newbie
Offline
Activity: 32
Merit: 0
|
|
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.
|
|
|
|
S-Fattah
Newbie
Offline
Activity: 28
Merit: 0
|
|
March 13, 2013, 10:16:47 AM |
|
Well done, guys. One question: This guy has returned your money?
|
|
|
|
OKPAY
Newbie
Offline
Activity: 32
Merit: 0
|
|
March 13, 2013, 10:25:08 AM |
|
Yes we resolved this situation.
|
|
|
|
|