|
adamstgBit
Legendary
Offline
Activity: 1904
Merit: 1037
Trusted Bitcoiner
|
|
December 14, 2012, 06:23:24 AM |
|
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 (OP)
|
|
December 14, 2012, 06:27:34 AM |
|
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
Legendary
Offline
Activity: 1904
Merit: 1037
Trusted Bitcoiner
|
|
December 14, 2012, 06:46:42 AM |
|
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
Legendary
Offline
Activity: 2506
Merit: 1010
|
|
December 14, 2012, 06:58:32 AM |
|
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
Legendary
Offline
Activity: 1904
Merit: 1037
Trusted Bitcoiner
|
|
December 14, 2012, 07:01:40 AM |
|
looks like both have been labeled double spend
|
|
|
|
Yuhfhrh (OP)
|
|
December 14, 2012, 07:08:23 AM Last edit: December 14, 2012, 07:33:09 AM by 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
Legendary
Offline
Activity: 2506
Merit: 1010
|
|
December 14, 2012, 07:33:11 AM |
|
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 (OP)
|
|
December 14, 2012, 09:29:37 AM |
|
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
Legendary
Offline
Activity: 2506
Merit: 1010
|
|
December 14, 2012, 10:04:59 AM |
|
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 (OP)
|
|
December 14, 2012, 10:08:54 AM Last edit: December 14, 2012, 11:23:04 AM by 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...
|
|
|
|
|
Stephen Gornick
Legendary
Offline
Activity: 2506
Merit: 1010
|
|
December 15, 2012, 02:57:22 AM Last edit: December 15, 2012, 06:09:03 AM by 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 (OP)
|
|
December 15, 2012, 03:22:19 AM |
|
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 (OP)
|
|
December 15, 2012, 04:33:13 AM |
|
I'm trying again.
|
|
|
|
Yuhfhrh (OP)
|
|
December 15, 2012, 04:43:34 AM |
|
Success.
|
|
|
|
paybitcoin
Member
Offline
Activity: 85
Merit: 10
1h79nc
|
|
December 15, 2012, 05:03:04 AM |
|
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 (OP)
|
|
December 15, 2012, 05:10:06 AM |
|
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
Legendary
Offline
Activity: 2506
Merit: 1010
|
|
December 15, 2012, 06:31:28 AM |
|
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 (OP)
|
|
December 15, 2012, 06:34:02 AM |
|
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.
|
|
|
|
|