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

molecular

donator

Activity: 2772

Merit: 1019

Quote from: etotheipi on March 12, 2013, 02:04:49 PM

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?

molecular

donator

Activity: 2772

Merit: 1019

Quote from: Atheros on March 12, 2013, 02:48:09 PM

Quote from: Elwar on March 12, 2013, 02:45:27 PM

Quote from: Nick on March 12, 2013, 02:41:05 PM

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?

Gabi

legendary

Activity: 1148

Merit: 1008

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

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

impulse

full member

Activity: 151

Merit: 100

Quote from: mccorvic on March 12, 2013, 03:15:07 PM

Quote from: Micon on March 12, 2013, 03:05:47 PM

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

Activity: 1148

Merit: 1008

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

That is why bitcoin is still beta software

mccorvic

hero member

Activity: 518

Merit: 500

Quote from: Micon on March 12, 2013, 03:05:47 PM

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.

iddo

sr. member

Activity: 360

Merit: 251

Quote from: casascius on March 12, 2013, 02:13:20 PM

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.

Micon

legendary

Activity: 1232

Merit: 1014

FPV Drone Pilot

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.

mccorvic

hero member

Activity: 518

Merit: 500

Quote from: Elwar on March 12, 2013, 02:45:27 PM

Quote from: Nick on March 12, 2013, 02:41:05 PM

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

RodeoX

legendary

Activity: 3066

Merit: 1147

The revolution will be monetized!

Quote from: Piper67 on March 12, 2013, 02:45:06 PM

Quote from: RodeoX on March 12, 2013, 02:44:07 PM

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.

somenick

legendary

Activity: 1286

Merit: 1004

I've heard he was already catched Cheesy

Atheros

sr. member

Activity: 249

Merit: 251

Quote from: Elwar on March 12, 2013, 02:45:27 PM

Quote from: Nick on March 12, 2013, 02:41:05 PM

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.

Spaceman_Spiff

legendary

Activity: 1638

Merit: 1001

₪``Campaign Manager´´₪

Quote from: Elwar on March 12, 2013, 02:45:27 PM

Quote from: Nick on March 12, 2013, 02:41:05 PM

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 .

Elwar

legendary

Activity: 3598

Merit: 2386

Viva Ut Vivas

Quote from: Nick on March 12, 2013, 02:41:05 PM

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.

Piper67

legendary

Activity: 1106

Merit: 1001

Quote from: RodeoX on March 12, 2013, 02:44:07 PM

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.

RodeoX

legendary

Activity: 3066

Merit: 1147

The revolution will be monetized!

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

blablahblah

hero member

Activity: 775

Merit: 1000

Quote from: Melbustus on March 12, 2013, 02:26:35 PM

Quote from: MrCrabs on March 12, 2013, 02:21:24 PM

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.

Nick

jr. member

Activity: 57

Merit: 1

Quote from: casascius on March 12, 2013, 02:13:20 PM

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.

I have just read this on the reddit thread:

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?

Ivica

full member

Activity: 218

Merit: 100