Bitcoin Forum
December 02, 2021, 06:20:33 PM *
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)
blablahblah
Hero Member
*****
Offline Offline

Activity: 775
Merit: 1000


View Profile
March 12, 2013, 07:41:23 PM
 #21

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

Was only an issue while there were two chains; ie, for a couple hours last night. The possibility was well-known, which is why it was recommended that merchants, exchanges, etc, stop taking payments/deposits until the issue was resolved, which it now is.

Yep, I guess strictly speaking it's "single-spend in 2 currencies". But of course, having multiple chains is ideological anathema, therefore there seems to be no infrastructure to handle it.
1638469233
Hero Member
*
Offline Offline

Posts: 1638469233

View Profile Personal Message (Offline)

Ignore
1638469233
Reply with quote  #2

1638469233
Report to moderator
1638469233
Hero Member
*
Offline Offline

Posts: 1638469233

View Profile Personal Message (Offline)

Ignore
1638469233
Reply with quote  #2

1638469233
Report to moderator
1638469233
Hero Member
*
Offline Offline

Posts: 1638469233

View Profile Personal Message (Offline)

Ignore
1638469233
Reply with quote  #2

1638469233
Report to moderator
The forum strives to allow free discussion of any ideas. All policies are built around this principle. This doesn't mean you can post garbage, though: posts should actually contain ideas, and these ideas should be argued reasonably.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1638469233
Hero Member
*
Offline Offline

Posts: 1638469233

View Profile Personal Message (Offline)

Ignore
1638469233
Reply with quote  #2

1638469233
Report to moderator
RodeoX
Legendary
*
Offline Offline

Activity: 3066
Merit: 1144


The revolution will be monetized!


View Profile
March 12, 2013, 07:44:07 PM
 #22

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

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

Activity: 1106
Merit: 1001



View Profile
March 12, 2013, 07:45:06 PM
 #23

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

Yes, the "Schroedinger Cat period" during which the coins are both alive and dead. As soon as the blockchain became whole again, either one or the other has to materialise.
Elwar
Legendary
*
Offline Offline

Activity: 3570
Merit: 2376


Viva Ut Vivas


View Profile WWW
March 12, 2013, 07:45:27 PM
 #24

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

How does one detect a fork? Some guy in his basement can create a fork with his own new code but be useless due to most transactions going with the main fork, but it would still be a fork.

First seastead company actually selling sea homes: Ocean Builders https://ocean.builders  Of course we accept bitcoin.
Spaceman_Spiff
Legendary
*
Offline Offline

Activity: 1638
Merit: 1000


₪``Campaign Manager´´₪


View Profile
March 12, 2013, 07:47:39 PM
 #25

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

How does one detect a fork? Some guy in his basement can create a fork with his own new code but be useless due to most transactions going with the main fork, but it would still be a fork.

That is what waiting for x confirmations is for .  
Atheros
Sr. Member
****
Offline Offline

Activity: 249
Merit: 251



View Profile WWW
March 12, 2013, 07:48:09 PM
 #26

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

How does one detect a fork? Some guy in his basement can create a fork with his own new code but be useless due to most transactions going with the main fork, but it would still be 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.

BM-GteJMPqvHRUdUHHa1u7dtYnfDaH5ogeY
Bitmessage.org - Decentralized, trustless, encrypted, authenticated messaging protocol and client.
somenick
Legendary
*
Offline Offline

Activity: 1289
Merit: 1004


View Profile
March 12, 2013, 07:48:16 PM
 #27

I've heard he was already catched  Cheesy
RodeoX
Legendary
*
Offline Offline

Activity: 3066
Merit: 1144


The revolution will be monetized!


View Profile
March 12, 2013, 07:48:55 PM
 #28

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

Yes, the "Schroedinger Cat period" during which the coins are both alive and dead. As soon as the blockchain became whole again, either one or the other has to materialise.
Haha, I like that analogy.

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

Activity: 518
Merit: 500



View Profile
March 12, 2013, 07:49:56 PM
 #29

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

How does one detect a fork? Some guy in his basement can create a fork with his own new code but be useless due to most transactions going with the main fork, but it would still be a fork.

I have a whole drawer full of forks, but so far all have been ignored Sad

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

Activity: 1232
Merit: 1010


FPV Drone Pilot


View Profile WWW
March 12, 2013, 08:05:47 PM
 #30

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?

also, if this ever happens again, I think we should use this pic:



and sorry if there has already been a 2 Chainz reference.

I'm flying FPV race drones these days. Check out my YouTube channel: https://www.youtube.com/c/MiconFPV
iddo
Sr. Member
****
Offline Offline

Activity: 360
Merit: 251


View Profile
March 12, 2013, 08:09:01 PM
 #31

A serious solution is simply for several major stakeholders to publish signed endorsements and/or kills to blocks. Users can subscribe to them, and if a supermajority agrees to kill a block, the merchant at the very least can be configured to stop and go into safe mode.

I have thought of this long ago, now others might take the idea seriously. It was aggressively rejected in the past under the pretense it was too "centralized".  I believe we need it to raise the bar on the risk of a 51% attack.

Your centralized protocol with few designated major stakeholders is indeed a terrible idea imho, for the reasons that we discussed in your thread. Fully decentralized proof-of-stake protocol can be sound, and can have several additional features that are very beneficial (in exchange for the additional complexity in the work that the nodes perform), but the security analysis should take into account bribe attacks etc., as discussed in the PoA thread. Peer review for the best protocol that we came up with so far would be very welcome, see here.
mccorvic
Hero Member
*****
Offline Offline

Activity: 518
Merit: 500



View Profile
March 12, 2013, 08:15:07 PM
 #32

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?

Your points are my understanding.  The double spend was allowed only because the service provider here wasn't on the ball.

Offering Video/Audio Editing Services since 2011 - https://bitcointalk.org/index.php?topic=77932.0
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:28:30 PM
 #33

That is why bitcoin is still beta software

impulse
Full Member
***
Offline Offline

Activity: 151
Merit: 100


View Profile
March 12, 2013, 08:34:44 PM
 #34

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?

Your points are my understanding.  The double spend was allowed only because the service provider here wasn't on the ball.

Yeah, I think it's important to distinguish here for non-techie people that this is not a double-spend within the merged blockchain, this is a double-spend against OKPAY because of their clearing policy and the unusal circumstances of last night. This does not violate the promise that the blockchain prohibits double spends.
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:36:09 PM
 #35

Forcing the 0.7 clients to upgrade to 0.8 instead of orphaning the chain would have avoided that... but would require everyone in the bitcoin world to upgrade...

molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1018



View Profile
March 12, 2013, 08:36:23 PM
 #36

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

How does one detect a fork? Some guy in his basement can create a fork with his own new code but be useless due to most transactions going with the main fork, but it would still be 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.

Cool idea! And yes, this _is_ a business opportunity of, some size even.

The clients could not only be of different codebase (differnt versions and different clients), but also try to be connected to different "parts" of the network in order to also be able to detect a network split. Now add different configuration options and you have a whole bunch of instances you need to run and maintain.

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?

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

Activity: 2772
Merit: 1018



View Profile
March 12, 2013, 08:38:55 PM
 #37

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?

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
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:47:22 PM
 #38

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?
Indeed, this is a good question. Every client should have refused the second transaction, since it was a double spend. So what happened? A miner somehow received it and confirmed it because of the higher fee?

pera
Sr. Member
****
Offline Offline

Activity: 532
Merit: 261


­バカ


View Profile
March 12, 2013, 08:48:58 PM
 #39

[..]
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?

キタ━━━━(゚∀゚)━━━━ッ!!
molecular
Donator
Legendary
*
Offline Offline

Activity: 2772
Merit: 1018



View Profile
March 12, 2013, 08:49:45 PM
 #40

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?
Indeed, this is a good question. Every client should have refused the second transaction, since it was a double spend. So what happened? A miner somehow received it and confirmed it because of the higher fee?

Stupid question: did everyones 0.7-client crash (or restart or clear the mempool) upon failure to commit the big block? That would explain it, no?

If that's the reason, maybe the "mempool" should be a "diskpool".


PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
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!