Bitcoin Forum
March 19, 2024, 09:05:23 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)
Wekkel
Legendary
*
Offline Offline

Activity: 3108
Merit: 1531


yes


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

A great opportunity to upgrade the software  Cool

1710839123
Hero Member
*
Offline Offline

Posts: 1710839123

View Profile Personal Message (Offline)

Ignore
1710839123
Reply with quote  #2

1710839123
Report to moderator
Be very wary of relying on JavaScript for security on crypto sites. The site can change the JavaScript at any time unless you take unusual precautions, and browsers are not generally known for their airtight security.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
1710839123
Hero Member
*
Offline Offline

Posts: 1710839123

View Profile Personal Message (Offline)

Ignore
1710839123
Reply with quote  #2

1710839123
Report to moderator
1710839123
Hero Member
*
Offline Offline

Posts: 1710839123

View Profile Personal Message (Offline)

Ignore
1710839123
Reply with quote  #2

1710839123
Report to moderator
Gabi
Legendary
*
Offline Offline

Activity: 1148
Merit: 1008


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


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

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

molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1019



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

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

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

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

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

Activity: 1428
Merit: 1093


Core Armory Developer


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

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

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

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

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

Activity: 900
Merit: 1000


Crypto Geek


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

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

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

Activity: 2940
Merit: 1327



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

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

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

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

Activity: 658
Merit: 500


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

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

Has this been answered?

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

Activity: 2772
Merit: 1019



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

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

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

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

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

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

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

EDIT: fixed 0.7/0.8 mixup

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

Activity: 2772
Merit: 1019



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

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

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

Probably true.

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

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

Activity: 504
Merit: 500


FPGA Mining LLC


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

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

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

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

Activity: 2772
Merit: 1019



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

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

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

thanks, fixed in my post

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

Activity: 240
Merit: 250



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

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

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

Activity: 112
Merit: 10



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

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

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


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

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

Fiyasko
Legendary
*
Offline Offline

Activity: 1428
Merit: 1001


Okey Dokey Lokey


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

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

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

Activity: 1638
Merit: 1001


₪``Campaign Manager´´₪


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

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

That's easy : blame Canada !

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

Activity: 518
Merit: 500



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

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

That's easy : blame Canada !

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

I blame my mother.

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

Activity: 1106
Merit: 1001



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

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

That's easy : blame Canada !

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

I blame my mother.

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

Activity: 2156
Merit: 1070


Crypto is the separation of Power and State.


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

How does one detect a fork?

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

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

You're reading my mind bro. 

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

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


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

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

Activity: 2618
Merit: 1022


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

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

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

Oh look my moneys back!!!

Oh look i did not get those bitcoins!

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

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

Activity: 730
Merit: 500



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

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

I suspect because nobody was testing for this problem.

Client testing needs to be radically improved if bitcoin is going to be a success.
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!