Bitcoin Forum
November 30, 2021, 06:29:20 AM *
News: Latest Bitcoin Core release: 22.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 123845 times)
00ph8al
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
April 08, 2014, 03:52:12 PM
 #101

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1638253760
Hero Member
*
Offline Offline

Posts: 1638253760

View Profile Personal Message (Offline)

Ignore
1638253760
Reply with quote  #2

1638253760
Report to moderator
1638253760
Hero Member
*
Offline Offline

Posts: 1638253760

View Profile Personal Message (Offline)

Ignore
1638253760
Reply with quote  #2

1638253760
Report to moderator
1638253760
Hero Member
*
Offline Offline

Posts: 1638253760

View Profile Personal Message (Offline)

Ignore
1638253760
Reply with quote  #2

1638253760
Report to moderator
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1010


View Profile
April 08, 2014, 04:01:35 PM
 #102

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.Cool. If they did not update, they would never see the original transaction confirmed.

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

Activity: 3066
Merit: 1144


The revolution will be monetized!


View Profile
April 08, 2014, 05:23:55 PM
 #103

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.
Maybe your right? Please point me to a double spend.

The gospel according to Satoshi - https://bitcoin.org/bitcoin.pdf
Free bitcoin in ? - Stay tuned for this years Bitcoin hunt!
Syke
Legendary
*
Offline Offline

Activity: 3822
Merit: 1171


View Profile
April 08, 2014, 05:34:48 PM
 #104

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.

Buy & Hold
Joshuar
Hero Member
*****
Offline Offline

Activity: 504
Merit: 500


eidoo wallet


View Profile
April 08, 2014, 05:37:38 PM
 #105

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.

██
█║█
║║║
║║║
█║█
██

                    ▄██▄
                  ▄██████▄
                ▄██████████
              ▄██████████▀   ▄▄
            ▄██████████▀   ▄████▄
          ▄██████████▀    ████████▄
         ██████████▀      ▀████████
         ▀███████▀   ▄███▄  ▀████▀   ▄█▄
    ▄███▄  ▀███▀   ▄███████▄  ▀▀   ▄█████▄
  ▄███████▄      ▄██████████     ▄█████████
  █████████    ▄██████████▀    ▄██████████▀
   ▀█████▀   ▄██████████▀    ▄██████████▀
     ▀▀▀   ▄██████████▀    ▄██████████▀
          ██████████▀    ▄██████████▀
          ▀███████▀      █████████▀
            ▀███▀   ▄██▄  ▀█████▀
                  ▄██████▄  ▀▀▀
                  █████████
                   ▀█████▀
                     ▀▀▀
e i d o o
██


                    ▄██▄
                  ▄██████▄
                ▄██████████
              ▄██████████▀   ▄▄
            ▄██████████▀   ▄████▄
          ▄██████████▀    ████████▄
         ██████████▀      ▀████████
         ▀███████▀   ▄███▄  ▀████▀   ▄█▄
    ▄███▄  ▀███▀   ▄███████▄  ▀▀   ▄█████▄
  ▄███████▄      ▄██████████     ▄█████████
  █████████    ▄██████████▀    ▄██████████▀
   ▀█████▀   ▄██████████▀    ▄██████████▀
     ▀▀▀   ▄██████████▀    ▄██████████▀
          ██████████▀    ▄██████████▀
          ▀███████▀      █████████▀
            ▀███▀   ▄██▄  ▀█████▀
                  ▄██████▄  ▀▀▀
                  █████████
                   ▀█████▀
                     ▀▀▀
██
█║█
║║║
║║║
█║█
██
skooter
Member
**
Offline Offline

Activity: 70
Merit: 10


View Profile
April 08, 2014, 06:12:50 PM
 #106

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.
b¡tco¡n
Member
**
Offline Offline

Activity: 84
Merit: 10

Correct Horse Battery Staple


View Profile
April 08, 2014, 09:28:29 PM
 #107

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.

1GiB1jQnqjwmNW4U4i8autnnVb1fG8HTYM

This would be my avitar; http://s9.postimg.org/m2pzsiy57/avi.png
Meuh6879
Legendary
*
Offline Offline

Activity: 1512
Merit: 1010



View Profile
April 08, 2014, 09:47:09 PM
 #108

How serious is this please. Double spends  I thought were impossible . Huh

it's impossible.
when you wait the 1 confirmation (1 block) ... anyway.  Grin
Maged
Legendary
*
Offline Offline

Activity: 1204
Merit: 1006


View Profile
April 09, 2014, 02:55:47 AM
 #109

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

Bit_Happy
Legendary
*
Offline Offline

Activity: 2002
Merit: 1020


A Great Time to Start Something!


View Profile
April 09, 2014, 03:36:30 AM
 #110



Your .gif was not accurate.
2013 turned out to be a great year for BTC.  Smiley
00ph8al
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile
April 09, 2014, 06:08:09 PM
 #111

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.
Maybe your right? Please point me to a double spend.


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.

RodeoX
Legendary
*
Offline Offline

Activity: 3066
Merit: 1144


The revolution will be monetized!


View Profile
April 09, 2014, 07:45:15 PM
 #112


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.

The gospel according to Satoshi - https://bitcoin.org/bitcoin.pdf
Free bitcoin in ? - Stay tuned for this years Bitcoin hunt!
Stephen Gornick
Legendary
*
Offline Offline

Activity: 2506
Merit: 1003


View Profile
April 12, 2014, 05:52:18 PM
 #113

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.

Unichange.me

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


stefek99
Full Member
***
Offline Offline

Activity: 237
Merit: 102


https://genesis.re


View Profile WWW
June 04, 2017, 09:21:51 PM
 #114

This is part of the history!

* https://99bitcoins.com/price-chart-history/
* https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki

cointastical
Newbie
*
Offline Offline

Activity: 22
Merit: 4


View Profile
January 03, 2019, 12:18:55 PM
 #115

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
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!