FTFY
I expect either one of the final outputs to confirm, or neither of them confirming. Both transactions have 0 confirmations at the moment.

The pools may use customized clients that behave different from the stock bitcoin.org client, but how the Bitcoin.org client handles it is the first transaction a node receives goes into the memory pool (only if it is a valid transaction, of course) and the second one is rejected as the inputs have already been spent by a valid transaction.

That is likely to be what will happen here.    The first one (without the fee) got propagated fast enough that most nodes never even knew about the second one (with the fee paid).


Well, blockchain.info shows the first transaction (without the fee) as being "first relayed by" 127.0.0.1.    I was thinking that meant that it was a transaction sent from blockchain.info/wallet, but maybe I'm wrong there.  But that is a well connected node and likely that is the transaction that will be included in a block and the second transaction will never confirm.

 - https://blockchain.info/tx/e860c52cd705d398abac710dc9a1df81ca153267dea7857f34fada2cedbc8409  <-- First No fee pad.
 - https://blockchain.info/tx/41a08e5afede7698f368d2516c6cb85134e158ae9bbf340d5382383b3d3b6183  <-- Second Fee paid.

Thanks for the response, I was pretty sure the first transaction (no fee) did come from a satoshi client, not the blockchain.info/wallet. I might have messed up here so I might try again: How about the scenario where the transactions are placed less than a second apart? Is there a way to effectively double spend with >50% probability (on 0 confirmations) this way?

The second transaction I placed an hour later with the fee got confirmed. Not what was expected. I will try to replicate this.

This was kind of my theory in the first place, by not paying a fee on the first transaction, it would take a long time to confirm. By paying the fee on the second one, a miner who maybe accepts transactions only with fees could come by and sweep it up.

Anyways I'm preparing for round two. Waiting for a block...

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

I see you updated the original post.


One big difference between your first trial and your second was that the second transaction was under 1K bytes, and the first was something like 2K.   So it would make sense that a "spam-like" transaction wouldn't confirm for many hours leaving the opportunity for a mining node with a "higher fee trumps a lower fee" customization to have the chance to mine a block.  

I see that in the second trial the "Relayed by IP" is again 127.0.0.1.   Had you sent that from Blockchain.info?

I'm trying again.

Wow. Nice. Also, from looking at the timestamps, 10 minutes went by from the unlucky dice roll to the included double spend transaction, if I'm seeing it correctly!

Hopefully they get around to patching it to wait before people start abusing this...

Can you provide the transaction IDs?   At a minimum, I'm curious which mining pool (if any) was responsible for the block in which this occurred.