Bitcoin Forum
March 19, 2024, 07:13:09 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 [4] 5 6 »  All
  Print  
Author Topic: A successful DOUBLE SPEND US$10000 against OKPAY this morning.  (Read 123951 times)
arklan
Legendary
*
Offline Offline

Activity: 1778
Merit: 1008



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

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

I suspect because nobody was testing for this problem.

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


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

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

Posts: 1710832389

View Profile Personal Message (Offline)

Ignore
1710832389
Reply with quote  #2

1710832389
Report to moderator
The Bitcoin network protocol was designed to be extremely flexible. It can be used to create timed transactions, escrow transactions, multi-signature transactions, etc. The current features of the client only hint at what will be possible in the future.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710832389
Hero Member
*
Offline Offline

Posts: 1710832389

View Profile Personal Message (Offline)

Ignore
1710832389
Reply with quote  #2

1710832389
Report to moderator
1710832389
Hero Member
*
Offline Offline

Posts: 1710832389

View Profile Personal Message (Offline)

Ignore
1710832389
Reply with quote  #2

1710832389
Report to moderator
makomk
Hero Member
*****
Offline Offline

Activity: 686
Merit: 564


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

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


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

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

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

Activity: 784
Merit: 1000


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

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


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

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

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

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

Activity: 129
Merit: 100


Swimming in a sea of data


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

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

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

Activity: 784
Merit: 1000


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

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

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

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

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

Activity: 349
Merit: 250


BTCPak.com - Exchange your Bitcoins for MP!


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

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

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

Activity: 2156
Merit: 1070


Crypto is the separation of Power and State.


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

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

I suspect because nobody was testing for this problem.

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


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

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


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

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

Activity: 784
Merit: 1000


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

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

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

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

Activity: 1204
Merit: 1015


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

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

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

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

robbonz
Newbie
*
Offline Offline

Activity: 25
Merit: 0



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

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

Activity: 980
Merit: 1004


felonious vagrancy, personified


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

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

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

Yeah, this is probably the solution.

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

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


How does one detect a fork?

Run several versions of Bitcoin

You can do it without having to run multiple clients.

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

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

Activity: 1792
Merit: 1087


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

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

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

Activity: 1778
Merit: 1008



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

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

I suspect because nobody was testing for this problem.

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


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

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

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

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

Activity: 2772
Merit: 1019



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

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

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

it's not quite that simple: which blockchain?

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

Activity: 192
Merit: 100


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

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

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

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

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

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

Activity: 1358
Merit: 1002



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

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

Activity: 39
Merit: 0


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

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

Activity: 32
Merit: 0



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

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

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

Activity: 28
Merit: 0


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

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

Activity: 32
Merit: 0



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

Yes we resolved this situation.
Pages: « 1 2 3 [4] 5 6 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!