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!
Topic: A successful DOUBLE SPEND US$10000 against OKPAY this morning. - page 4. (Read 123958 times)
That's easy : blame Canada !
http://www.youtube.com/watch?v=bOR38552MJA
I blame my mother.
I blame Canada's mother!
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.
Oh my god... Do we blame the services? Or the client upgrade?
That's easy : blame Canada !
http://www.youtube.com/watch?v=bOR38552MJA
Oh my god... Do we blame the services? Or the client upgrade?
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.
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....
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
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.
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
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
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.
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.
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.
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).
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).
[..]
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?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?
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.
Clients didn't crash, they just refused the "weird" block. Or did they crash?
A great opportunity to upgrade the software 
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?
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".
[..]
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? 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?
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?
Jump to: