[SUCCESS] Double Spend against a satoshidice loss

[Yuhfhrh]

DISCLAIMER: The following post shows the risk with accepting bitcoin transactions with no confirmations. This could not have been done if the transaction had a confirmation.

Second attempt: This time I started with twenty 0.01BTC imputs, to create a "spammy" transaction.

Here are the two transactions:
(Lost bet against satoshidice of 0.2BTC with no fee paid)https://blockchain.info/tx/7d6ce09ff0d013e9d59760857339c59b107d3e5c80437a9f5ea79d9a6ca32861
http://satoshidice.com/lookup.php?tx=7d6ce09ff0d013e9d59760857339c59b107d3e5c80437a9f5ea79d9a6ca32861&limit=100&min_bet=0&status=ALL
(Double spend with 0.004BTC fee paid)https://blockchain.info/tx/be585cd7c6e9a0a6f48502e5d3adde2588fe55bcb7b27964968e6ddce4701e1a

Edit: And the second transaction with the fee got the confirmation from BTC Guild, so the original bet against satoshidice will never confirm.


Failed first attempt:

EclipseMC picked up the 0 fee transaction.

Conclusion: The miner must be using a custom set of rules when picking transactions for this to work. I got lucky in the practice round.

Okay here is my attempt to double spend against a satoshidice loss: (Sorry it got a little sloppy)
This is the address I am using, which started with 0.5BTC:
https://blockchain.info/address/1PvsMBVx1tVrX4q5Ef2NfMjsB6qUF9G9q2
Here is the 0.25BTC bet against satoshidice, which I lost (No fees paid):
https://blockchain.info/tx-index/36578058
http://satoshidice.com/lookup.php?tx=dff6f55049a534855115d3efb76a6d1955b223a0d73bcbe95a0d74ba3f4445cc&limit=100&min_bet=0&status=ALL
Here is the double spend (0.001 fee paid), which included the whole balance of 0.5, and also a separate 0.1 input:
https://blockchain.info/tx-index/36578900

I then moved the double spend around twice, just as before, paying a 0.001 fee each time:
https://blockchain.info/tx/cd7ba48d2d0816dcf13c1be38eb434fcc02ef470198a5f6a5ef841be5e3ddbf4
https://blockchain.info/tx/acfd7095934893105b2fa4941e02d9b8fa28cd8a2bf47f550a15620747c70e88

Successful practice round:

Out of curiosity, I wondered what would happen if I tried to double spend some coins. So I did.

I started with a balance of 0.85037754 BTC at this address: https://blockchain.info/address/1NBSySCggyahxu5F3LHnFwT7MvJycfamuG

I then sent the 0.85037754 without a miner's fee to this address:
https://blockchain.info/address/1HPapF7cemm7Erat11LEsi461gVL2EWdWb
Then I sent the same 0.85037754 again with 0.05256613 from another address to the same address above, this time including a miner's fee.
https://blockchain.info/address/1HPapF7cemm7Erat11LEsi461gVL2EWdWb
From the transaction with the miner's fee, I sent the coins two more times including fees, and they finally rest here:
https://blockchain.info/address/1HJ18q1tsZCqgD4jtCeYvmtB3Sb9KMhN5R

So what I end up with is two unconfirmed balances.
0.85037754 at https://blockchain.info/address/1HPapF7cemm7Erat11LEsi461gVL2EWdWb (No fees paid),
0.9 at https://blockchain.info/address/1HJ18q1tsZCqgD4jtCeYvmtB3Sb9KMhN5R (Fees paid)

Will the transaction with miner fees get confirmed over the transaction without the miner fees? As I understand it after a few hours/days eventually one of them will be confirmed, but how do miners decide which one?

Edit: The transaction with the fees that was placed an hour later got confirmed over the transaction with no fees.

If you learned something new or enjoyed reading this post, please send donations to 1Donate3AJvrk5kNEoyR6qNFCuTdHsBsmr. I lost a few BTC in this process  

[1713569672]

1713569672

[1713569672]

1713569672

[1713569672]

1713569672

[1713569672]

1713569672

[1713569672]

1713569672

[adamstgBit]

miners will look at the blockchain and see you already spent the coins your trying to send and never confirm them

if one of these fraudulent tx gets confirmed bitcoin dies tonight.

[Yuhfhrh]

miners will look at the blockchain and see you already spent the coins your trying to send and never confirm them

if both of those transactions get confirmed bitcoin dies tonight.

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

[adamstgBit]

miners will look at the blockchain and see you already spent the coins your trying to send and never confirm them

if both of those transactions get confirmed bitcoin dies tonight.

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

right.

my guess is its random a bit, and which ever one gets included in the block chain first will be valid, it probably doesn't matter which tx was sent first...
I put my money on the one with a fee.

cool test.

[Stephen Gornick]

Will the transaction with miner fees get confirmed over the transaction without the miner fees? As I understand it after a few hours/days eventually one of them will be confirmed, but how do miners decide which one?

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).

The transaction without the miners fee hadn't hit many nodes yet,

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.

[adamstgBit]

looks like both have been labeled double spend

[Yuhfhrh]

Will the transaction with miner fees get confirmed over the transaction without the miner fees? As I understand it after a few hours/days eventually one of them will be confirmed, but how do miners decide which one?

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 and the second one is rejected (assuming the first one was valid) .  

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).

The transaction without the miners fee hadn't hit many nodes yet,

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?

[Stephen Gornick]

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?

That's why the recommendation is that a merchant running its own node should not have any support for incoming connections and to explicitly have an outgoing connection to a well-connected nodes.   In that scenario, presumably the well connected node will have the same transactions as the mining pools and thus the chance of a double spend (via race attack) is substantially less than 50%.

And if you have the ability to connect to the merchant's node you can double spend on 0/unconfirmed with at a success rate approaching 100%.

Because of this risk, those trading on OTC or in-person for cash with someone who doesn't have a good history of trust should consider verifying that no double-spend occurred by looking at the transaction on Blockchain.info (or using a service like a "LocalBitcoins Transaction" / escrow).

[Yuhfhrh]

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

[Stephen Gornick]

The second transaction I placed an hour later with the fee got confirmed. Not what was expected.

I'ld be curious to know the path between you and that node that mined it because if you were peered only to bitcoin.org clients that transaction would not have made it far. 

Because Blockchain.info considers transactions even when it is a double spend maybe they even relay these transactions regardless.  (and thus a well connected node that you reached somehow and then that it propagated the transaction to a node used by a miner.)

But the block was not mined by an address of any known pools, so that it is using a custom client would not be surprising.

[Yuhfhrh]

The second transaction I placed an hour later with the fee got confirmed. Not what was expected.

But the block was not mined by an address of any known pools, so that it is using a custom client would not be surprising.

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...

[Yuhfhrh]

Okay here is my attempt to double spend against a satoshidice loss: (Sorry it got a little sloppy)
This is the address I am using, which started with 0.5BTC:
https://blockchain.info/address/1PvsMBVx1tVrX4q5Ef2NfMjsB6qUF9G9q2
Here is the 0.25BTC bet against satoshidice, which I lost (No fees paid):
https://blockchain.info/tx-index/36578058
Here is the double spend (0.001 fee paid), which included the whole balance of 0.5, and also a separate 0.1 input:
https://blockchain.info/tx-index/36578900

I then moved the double spend around twice, just as before, paying a 0.001 fee each time:
https://blockchain.info/tx/cd7ba48d2d0816dcf13c1be38eb434fcc02ef470198a5f6a5ef841be5e3ddbf4
https://blockchain.info/tx/acfd7095934893105b2fa4941e02d9b8fa28cd8a2bf47f550a15620747c70e88

So lets see what happens.

[Stephen Gornick]

So lets see what happens.

I see you updated the original post.

FAILED

EclipseMC picked up the 0 fee transaction.

Conclusion: The miner must be using a custom set of rules when picking transactions for this to work. I got really lucky in the practice round.

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?

[Yuhfhrh]

So lets see what happens.

I see you updated the original post.

FAILED

EclipseMC picked up the 0 fee transaction.

Conclusion: The miner must be using a custom set of rules when picking transactions for this to work. I got really lucky in the practice round.

One big different 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?

Yes I had sent it from blockchain.info. I was considering sending many 0.01 transactions to an address and trying again, but it's a lot of effort (the whole double spending process). I may get around to trying it again tonight. But also something different about the second trial, the payment from satoshidice includes a fee.

[Yuhfhrh]

I'm trying again.

[Yuhfhrh]

Success.

[paybitcoin]

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...

[Yuhfhrh]

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!

It took ten minutes before the rest of the bitcoin network picked up the double spend apparently, I don't know why, but the same thing happened with my practice round.

[Stephen Gornick]

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!

It took ten minutes before the rest of the bitcoin network picked up the double spend apparently, I don't know why, but the same thing happened with my practice round.

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.

[Yuhfhrh]

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!

It took ten minutes before the rest of the bitcoin network picked up the double spend apparently, I don't know why, but the same thing happened with my practice round.

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.

OP^^ Another question is, would the transaction with no fees get confirmed at all considering it should have had 0.004BTC in fees?

I will test again, this time seeing how long it takes for a spammy transaction to confirm without fees, if at all.