|
fireduck
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 15, 2012, 05:02:35 PM |
|
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.
|
Bitrated user: fireduck.
|
|
|
fireduck
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 15, 2012, 05:32:59 PM |
|
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.
|
Bitrated user: fireduck.
|
|
|
piuk
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 15, 2012, 05:48:20 PM |
|
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 (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 15, 2012, 07:37:17 PM |
|
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
Staff
Legendary
Offline
Activity: 4256
Merit: 1208
I support freedom of choice
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 02:09:53 PM |
|
Can this idea be a solution? In the test code I have just implemented what I call the "Boomerang Rule" - see below: ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fmultibit.org%2FpostImages%2Fboomerang.png&t=665&c=TQZPKWe4lJc9mw) 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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 03:21:14 PM |
|
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
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 03:56:01 PM |
|
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
Legendary
Offline
Activity: 3878
Merit: 1193
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 04:10:49 PM |
|
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.
|
Buy & Hold
|
|
|
Gavin Andresen
Legendary
Offline
Activity: 1652
Merit: 2300
Chief Scientist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 04:24:53 PM |
|
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.
|
How often do you get the chance to work on a potentially world-changing project?
|
|
|
nevafuse
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 04:35:45 PM |
|
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?
|
The only reason to limit the block size is to subsidize non-Bitcoin currencies
|
|
|
DannyHamilton
Legendary
Offline
Activity: 3472
Merit: 4790
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 04:58:26 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 05:07:31 PM |
|
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.
|
The only reason to limit the block size is to subsidize non-Bitcoin currencies
|
|
|
Yuhfhrh (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 06:51:18 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 07:40:57 PM |
|
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.
|
The only reason to limit the block size is to subsidize non-Bitcoin currencies
|
|
|
Yuhfhrh (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 07:53:24 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 09:28:23 PM |
|
But to beat satoshi dice you only need 1/50 (to overcome the 2% house advantage).
|
|
|
|
Yuhfhrh (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 09:33:28 PM |
|
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
Legendary
Offline
Activity: 2506
Merit: 1010
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 17, 2012, 10:41:49 PM |
|
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: 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
Legendary
Offline
Activity: 1526
Merit: 1129
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 18, 2012, 10:55:35 AM |
|
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.
|
|
|
|
|