A successful DOUBLE SPEND US$10000 against OKPAY this morning.

[blablahblah]

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

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.

[1715048291]

1715048291

[1715048291]

1715048291

[1715048291]

1715048291

[RodeoX]

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

[Piper67]

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]

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.

[Spaceman_Spiff]

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]

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.

[somenick]

I've heard he was already catched  

[RodeoX]

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.

[mccorvic]

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

[Micon]

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.

[iddo]

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]

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.

[Gabi]

That is why bitcoin is still beta software

[impulse]

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]

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]

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?

[molecular]

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?

[Gabi]

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]

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

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".