Topic: [SUCCESS] Double Spend against a satoshidice loss - page 2. (Read 19088 times)

OK, a Finney attack against SD, nice.

BTW does anyone know if Eclipse publishes the list of blocks they solved anywhere? I couldn't find such a list on their site. If Eclipse did solve it, then I guess Inaba needs to examine how A' got into his memory pool.

Miners that are accepting direct submissions of transactions that would normally fail to relay really should be ensuring those transactions don't conflict with any in the memory pool, and if they see a broadcast transaction that would double spend a direct submission, should take the broadcast transaction as having priority.

Is it possible to send a tx that wouldn't normally relay to a node, but still get it accepted into the nodes memory pool? I thought the code did not allow that, but maybe I'm wrong.

It seems worth investigating this in more detail.

It seems possible that A' was submitted first (directly to any miner that would accept it) and didn't propagate over the rest of the network because of the lack of fee.  Then A and B could be submitted normally and make it to the rest of the network (except for any miners that already had the conflicting transaction).  The tricky part would be trying to affect who found the next block after seeing the bet outcome.  With enough hashing power you could point at one pool or another you could push the odds around somewhat but it would seem to be far from a sure thing, it wouldn't however necessarily require collusion from any mining pools directly.

I can't believe I posted in the wrong thread!  

A couple days ago, I observed a pretty large, successful, double spend against SD (25 BTC).  Please see my post in the statistics thread.  I have raw data if anyone wants to analyze it.  

It is not related to the vulnerability retep posted.  But it does look like a miner may have helped them.

tl;dr:  

The original bet, B, was made using an input from transaction A.  A was 7 kB and had 43 inputs.  I don't know what the transaction fee was (but I all zero-conf tx I received that entire day with timestamps, so all this information could be reconstructed... I can make it available to anyone who wants to dig into it).

Transaction A never made it past zero-conf, and was replaced by a block with transaction A'.  Thus, bet B was invalidated.  The curious part is that A' was 14 kB, with 83 inputs, and paid zero fee!.  14kB is clearly over the allowFree limit, thus it would only be accepted (even without a conflicting tx in the memory pool) by a miner with non-standard rules.  Now given that there was a public, conflicting transaction... hmmm

I still haven't confirmed if sending a spammy transaction with the standard 0.0005 BTC fee where a normal fee of ~0.01 would be required and double spending it would work or not. I haven't had the time to try, but this should theoretically work under their new rules unless satoshidice checks to make sure the standard fee is paid, and not just the 0.0005.

This was pure genius. Thank you for your contribution to science.

I agreed with this statement at first, but I think it will be difficult to trigger on testnet -- the makeup of the network and the miners is significantly different.  You probably don't have the same density and diversity of peers needed to do it -- you need significant propagation of each tx in the subnetworks of nodes that are willing to accept it and mine it.

Not to say it can't be done, I just think the attack will manifest differently on testnet.  

On the upside, anyone succeeding on the test site might make a few tenths of a BTC for their effort.

this testdice is located in prodnet?? what it the sense of that?

a testdice should be located in testnet with exactly the same parameters as in prodnet.

Thanks, I really appreciate it! 

Funny that you mention that, since in the process of testing your method I ended up 5 BTC ahead... I think I'm obligated now to cover your loss, so I'll share the winnings.

I couldn't pull off the double spend, but I only got 1 or 2 reasonable tests in. They do take quite a long time to execute.

Well they don't owe me a reward. Also I could have won BTC instead of losing during these tests.

I think Satoshidice owe you a reward. I am surprised that they do not offer a standard 10 BTC reward to anyone who posts a proven double spend on this forum.

Yes and yes.


Fees are not considered recursively at the moment. They should be and there are patches open to do that. I think Gavin is planning to merge some of that work soon (i hope?)

First off, thanks for writing an article on this! I appreciate it!
Also for others, I added a donation address to the OP since I lost about 1.5 BTC in this process.   If I receive more than 1.5BTC, further funds will be used for more double spending attempts.

1. The answer is yes to both.
2. I don't believe it works that way. As long as miners are following the standard rules, sending a transaction 999 times with no fee and then sending the last with a 1BTC fee will not affect the previous 999 transactions. Each transaction is based on it's own fees.

One idea I had to help mitigate this is that SatoshiDice could immediately re-send the output of any transaction that they receive to themselves with a fee, encouraging miners to quickly confirm both the new transaction and its parent over any conflicting transactions.

Two questions:

1. Can a transaction reference an unconfirmed transaction as an input? If so, can the two appear in the same block? I'm pretty sure the answer is yes to the first, but I'm not sure about the second.

2. Do miners actually work that way? Does a fee on a transaction also encourage miners to include its (possibly feeless and even non-standard/bloated) parent? If not, are there any obstacles / reasons not to implement such a strategy (with appropriate rules so you can't use one transaction to force miners to include 1000 bad ones, obviously)?

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.

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:


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.

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

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

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.

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.