[SUCCESS] Double Spend against a satoshidice loss

[Yuhfhrh]

Another loss I am trying to double spend on
https://blockchain.info/tx/f4c76f4c2f906e08b8f7392285bfc8d5b593378c3e2a1b570887502c05b8f547
http://satoshidice.com/lookup.php?tx=f4c76f4c2f906e08b8f7392285bfc8d5b593378c3e2a1b570887502c05b8f547&limit=100&min_bet=0&status=ALL

Waiting for blockchain.info to pick up the double spend...

Double spend has been broadcast now:
https://blockchain.info/tx/0ddd5d48d880116eac5c361268f3fb5e069c0e059fe6b08f77db9039493de452

Waiting to see which one gets confirmed...

The amount of time this takes almost makes it not worth doing in the first place, then again I'm doing everything manually. I guess a bot could be set up to do this, which would give you an edge over the house even if only 1/4 of the double spends work.

FAILED

EclipseMC included the original transaction without the fee. This seems to be a luck of the draw game depending on who mines the block. Either way I'm done messing with this for now.

[fireduck]

Thanks to everyone how has been looking at this and reporting their findings.

I tried this earlier this year and couldn't get it to work, but I might have simply not tried hard enough or things have changed.

While I investigate I've set Satoshidice to only allow confirmed bets.  I'll bring up our test site and post the url in a little in case anyone wants to use a casino to continue to test this.  It has real funds, just not nearly as much.

[fireduck]

Anyone who wants to test double spends is free to try it on the test site:

http://1209k.com/testdice/

I'll be doing some of my own testing.

[piuk]

This should be a pretty reliable method.

1) Create a long chain of unconfirmed transactions (lots of free low priority transactions which depend on each other).
2) Send the final transaction in the chain to SatoshiDICE, including one input which isn't part of the unconfirmed chain. If the bet wins, great, keep rebroadcasting all the transactions in the chain and eventually they will confirm.
3) If the bet looses. Double spend the input from the betting transaction which is not part of the unconfirmed chain.

Because the chain will take a long time to confirm it gives a much larger window of opportunity for miners to pickup the double spending transaction. As miners join and leave the network they are much more likely to pickup the single double spend transaction, rather than the full chain of unconfirmed transactions (which you are no longer broadcasting). This technique was used to successfully double spend the blockchain.info mixer.

[Yuhfhrh]

I've set it to allow unconfirmed as long as they have a fee and are based on confirmed inputs.

New rules! I'll test some more tonight.

[HostFat]

Can this idea be a solution?

In the test code I have just implemented what I call the "Boomerang Rule" - see below:



It enables change to be spendable immediately as long as the transaction propagates through the network ok.

I will spend a little while testing it and then produce another test release (beta) with it in.
It would be very useful if a few people could test it out to make sure it works as expected before I put it into the live code.

[Fjordbit]

I just want to be clear, because the title is a little inaccurate. A double spend was not achieved. If that were true, then the bitcoin network would be in trouble. This is more of a Finney attack.

[DeathAndTaxes]

I just want to be clear, because the title is a little inaccurate. A double spend was not achieved. If that were true, then the bitcoin network would be in trouble. This is more of a Finney attack.

Um no it is a double spend.  A Finney attack is a type of double spend in which the attacker "reverses" a 0-confirm tx by submitting a replacement which is already in a block HE MINED.  There is nothing in the OP attack which makes it is a Finney attack.

[Syke]

I just want to be clear, because the title is a little inaccurate. A double spend was not achieved. If that were true, then the bitcoin network would be in trouble. This is more of a Finney attack.

Double-spends have always been possible. That's why we count "confirmations". The number of confirmations reduces the risk of double-spends.

[Gavin Andresen]

Double-spends have always been possible. That's why we count "confirmations". The number of confirmations reduces the risk of double-spends.

Yes -- 0/1-confirmation double spends are certainly possible. A successful 2-confirmation double-spend would be more interesting. I would love to see if real-network experience matches the theoretical results from Meni's paper.

[nevafuse]

If double spends are really this easy, I can only imagine shady clients that come out in the future that do this automatically.  Obviously someone willing to wait for confirmations will be fine, but how are people going to be expected to wait 10+ minutes at the convenience store for a candy bar purchase?

Is this when green addresses come into play?  The convenience store trusts transactions from mtgox addresses not to attempt double spending so they accept a 0 confirmation payment?

[DannyHamilton]

If double spends are really this easy, I can only imagine shady clients that come out in the future that do this automatically . . .

I'm already working on one.  Hope to have it working properly in a few months.

[nevafuse]

If double spends are really this easy, I can only imagine shady clients that come out in the future that do this automatically . . .

I'm already working on one.  Hope to have it working properly in a few months.

I actually support this.  The sooner people realize this can happen, the sooner people will be educated about the risk of 0 confirmation transactions.  I can't technically conceive a way to prevent this, but ideas like green addresses or physical coins could certainly help reduce the risk for people who rely on instant transactions.

[Yuhfhrh]

If the proper fee was paid to the miners and the payment is based on confirmed imputs, this type of double spend doesn't work. So, like satoshidice has done, simply check these two things before accepting a 0 confirmation payment. Otherwise wait for 1 confirmation. I'll work on wording this better and presenting it more effectively in the future.

[nevafuse]

If the proper fee was paid to the miners and the payment is based on confirmed imputs, this type of double spend doesn't work. So, like satoshidice has done, simply check these two things before accepting a 0 confirmation payment. Otherwise wait for 1 confirmation. I'll work on wording this better and presenting it more effectively in the future.

You could still double spend a transaction with a fee.  You just need your 2nd transaction to be a larger fee.  If someone was successfully pulling this off on satoshidice, they could have definitely raised the chances for themselves & screwed everyone else.  Maybe dooglus can do an analysis on the luckiest players of satoshidice.

[Yuhfhrh]

If the proper fee was paid to the miners and the payment is based on confirmed imputs, this type of double spend doesn't work. So, like satoshidice has done, simply check these two things before accepting a 0 confirmation payment. Otherwise wait for 1 confirmation. I'll work on wording this better and presenting it more effectively in the future.

You could still double spend a transaction with a fee.  You just need your 2nd transaction to be a larger fee.  If someone was successfully pulling this off on satoshidice, they could have definitely raised the chances for themselves & screwed everyone else.  Maybe dooglus can do an analysis on the luckiest players of satoshidice.

That only works if the miner who mines the block has special rules determining what transactions he includes. You are right, and this will probably get worse in the future. But for now most of the miners follow the standard protocol, so only ~1/8 IMO of these type of double spends would actually work.

[nibor]

But to beat satoshi dice you only need 1/50 (to overcome the 2% house advantage).

[Yuhfhrh]

But to beat satoshi dice you only need 1/50 (to overcome the 2% house advantage).

Very true, so I expect some bots are going to be hitting satoshidice with this now that it has been brought up.

[Stephen Gornick]

Is this when green addresses come into play?  The convenience store trusts transactions from mtgox addresses not to attempt double spending so they accept a 0 confirmation payment?

Well, SatoshiDICE did exactly what a merchant that accepts on 0/unconfirmed will likely need to do ... become discriminating on 0/unconfirmed.  Fireduck changed which 0/unconfirmed bets will be processed:

I've set it to allow unconfirmed as long as they have a fee and are based on confirmed inputs.

So the "spam-like" payment that was originally sent to SatoshiDICE will no longer be processed (it will sit unprocessed until it gets one confirmation).

Just to be clear, it isn't easy for one to send a payment and then "accidentally" spend the same funds to somewhere else except with the second time include a fee that happens to cause the second transaction to get included in a block over the first.  That is fraud -- which might be why Fireduck offered to let people test this approach against a version of the service for testing purposes:

Anyone who wants to test double spends is free to try it on the test site:

http://1209k.com/testdice/

So the chances of getting caught double spending to defraud SatoshiDICE are low, as bitcoin has user-definable anonymity (hat tip to Jon Matonis for defining it that way).    But buying a candy bar and double spending those funds is probably not something you can do anonymously.

I don't know that Green Addresses are the approach to get behind.   What I think this proves though is that a merchant that likes to DIY will be more at risk than one using a payment processor that can figure out how to combat these types of risks.

I wonder what would happen though ... where let's say I'm at a merchant and I pay with bitcoin but the payment processor flags it as a high risk payment because it included 2K of data and I didn't pay a fee.     The Bitcoin.org client doesn't let me do that but with Blockchain.info/wallet, for example, I could do that.

[Mike Hearn]

This should be a pretty reliable method.

1) Create a long chain of unconfirmed transactions (lots of free low priority transactions which depend on each other).
2) Send the final transaction in the chain to SatoshiDICE, including one input which isn't part of the unconfirmed chain. If the bet wins, great, keep rebroadcasting all the transactions in the chain and eventually they will confirm.
3) If the bet looses. Double spend the input from the betting transaction which is not part of the unconfirmed chain.

Because the chain will take a long time to confirm it gives a much larger window of opportunity for miners to pickup the double spending transaction. As miners join and leave the network they are much more likely to pickup the single double spend transaction, rather than the full chain of unconfirmed transactions (which you are no longer broadcasting). This technique was used to successfully double spend the blockchain.info mixer.

If I understood correctly, that attack can be solved by just having your own software periodically rebroadcast all unconfirmed transactions that are relevant to your wallet. Alternatively, by having miners sync their memory pools with their peers at startup (should be more reliable). This would ensure that it's much harder to repeatedly announce a double spend and have it take precedence due to natural miner churn.

Jeff has a patch to make nodes sync their mempools at startup already. I guess there are a few other mempool handling issues we'd need to fix first before it lands, but that specific way of double spending doesn't seem very hard to solve.

HostFat: no Jims "boomerang rule" (I'll not be using this term when I reimplement the code in bitcoinj) is handling a different issue that's only relevant to SPV clients. It's not connected to this.