Bitcoin Forum

Bitcoin => Bitcoin Discussion => Topic started by: bitpop on December 31, 2013, 11:45:59 AM



Title: Never confirm attack?
Post by: bitpop on December 31, 2013, 11:45:59 AM
I'm not sure if merchants accepting 0 confirmations check transaction fee but what would happen if I send a very complicated payment with no transaction fee. Isn't there a possibility it will never confirm?


Title: Re: Never confirm attack?
Post by: FenixRD on December 31, 2013, 12:15:02 PM
I'm not sure if merchants accepting 0 confirmations check transaction fee but what would happen if I send a very complicated payment with no transaction fee. Isn't there a possibility it will never confirm?

In theory. Maybe in practice too. You can recall it and try again. Basically a doublespend but one where you know the first one got stuck. It's happened for mistaken zero-fee tx before.


Title: Re: Never confirm attack?
Post by: prezbo on December 31, 2013, 12:26:40 PM
Such a transaction would not even be relayed. Any transaction that is relayed normally will confirm eventually.


Title: Re: Never confirm attack?
Post by: tysat on December 31, 2013, 12:27:51 PM
Such a transaction would not even be relayed. Any transaction that is relayed normally will confirm eventually.

Nope, relaying =\= guaranteeing confirmation.


Title: Re: Never confirm attack?
Post by: upal on December 31, 2013, 12:28:22 PM
I'm not sure if merchants accepting 0 confirmations check transaction fee but what would happen if I send a very complicated payment with no transaction fee. Isn't there a possibility it will never confirm?

For this => https://bitcointalk.org/index.php?topic=390969.0 ?


Title: Re: Never confirm attack?
Post by: prezbo on December 31, 2013, 12:37:14 PM
Such a transaction would not even be relayed. Any transaction that is relayed normally will confirm eventually.

Nope, relaying =\= guaranteeing confirmation.

True, my bad. It would have to be re-broadcasted regularly as well - but a merchant could also do that. (I am assuming every transaction with a priority of 58 mio will eventually be included in a block, so no miner selectively disregarding it or any shenanigans like that)


Title: Re: Never confirm attack?
Post by: bitpop on December 31, 2013, 01:03:27 PM
How do you get the priority score?


Title: Re: Never confirm attack?
Post by: prezbo on December 31, 2013, 01:09:18 PM
How do you get the priority score?

https://en.bitcoin.it/wiki/Transaction_fees (at the bottom)


Title: Re: Never confirm attack?
Post by: BeetcoinScummer on December 31, 2013, 01:21:57 PM
It would be nice for the standard client to have an explicit re-broadcast option.


Title: Re: Never confirm attack?
Post by: Aswan on December 31, 2013, 01:31:32 PM
0 Confirmation transactions are totally spendable without any problems. Your client might now allow you to do this but that is a problem of your client, not the bitcoin protocol. So if you have a non-confirmed transaction you could spend the output and add a fee to increase miners incentive to mine both and thus get the fee.


Title: Re: Never confirm attack?
Post by: Peter R on December 31, 2013, 06:15:09 PM
0 Confirmation transactions are totally spendable without any problems. Your client might now allow you to do this but that is a problem of your client, not the bitcoin protocol. So if you have a non-confirmed transaction you could spend the output and add a fee to increase miners incentive to mine both and thus get the fee.

You can try this yourself to confirm that it doesn't work.  Send a transaction to an address that you control with zero fee (but a transaction that is allowed to have zero fee) and then wait till you see that it was picked up by the bulk of the network (check blockchain.info).  Next, rebroadcast a fraudulent transaction using the same coin to a different address and this time attach a higher fee (you can do all of this with the "transactions" page at brainwallet.org).  The second transaction won't propagate, and the miners won't mine it, because they can see that that output has already been spent.  

As far as I know, the only ways you may get the second transaction to confirm would be to (1) be in cahoots with a miner who controls a lot of hash power and have him manually add your fraudulent transactions to his memory pool, (2) hope that your first transaction gets dropped by the network before it gets mined (and that no-one rebroadcasts it).  After your first transaction has been dropped by enough miners and nodes, your second transaction can propagate.  


Title: Re: Never confirm attack?
Post by: prezbo on December 31, 2013, 10:47:27 PM
0 Confirmation transactions are totally spendable without any problems. Your client might now allow you to do this but that is a problem of your client, not the bitcoin protocol. So if you have a non-confirmed transaction you could spend the output and add a fee to increase miners incentive to mine both and thus get the fee.

You can try this yourself to confirm that it doesn't work.  Send a transaction to an address that you control with zero fee (but a transaction that is allowed to have zero fee) and then wait till you see that it was picked up by the bulk of the network (check blockchain.info).  Next, rebroadcast a fraudulent transaction using the same coin to a different address and this time attach a higher fee (you can do all of this with the "transactions" page at brainwallet.org).  The second transaction won't propagate, and the miners won't mine it, because they can see that that output has already been spent.  

As far as I know, the only ways you may get the second transaction to confirm would be to (1) be in cahoots with a miner who controls a lot of hash power and have him manually add your fraudulent transactions to his memory pool, (2) hope that your first transaction gets dropped by the network before it gets mined (and that no-one rebroadcasts it).  After your first transaction has been dropped by enough miners and nodes, your second transaction can propagate.  

I think you misunderstood. What he wanted to say is you can spend unconfirmed coins (legitimately) and include a fee in the transaction so the previous transaction that would take long to confirm would confirm quicker - because it's in miners best interest to include both.


Title: Re: Never confirm attack?
Post by: Peter R on December 31, 2013, 10:51:54 PM
0 Confirmation transactions are totally spendable without any problems. Your client might now allow you to do this but that is a problem of your client, not the bitcoin protocol. So if you have a non-confirmed transaction you could spend the output and add a fee to increase miners incentive to mine both and thus get the fee.

You can try this yourself to confirm that it doesn't work.  Send a transaction to an address that you control with zero fee (but a transaction that is allowed to have zero fee) and then wait till you see that it was picked up by the bulk of the network (check blockchain.info).  Next, rebroadcast a fraudulent transaction using the same coin to a different address and this time attach a higher fee (you can do all of this with the "transactions" page at brainwallet.org).  The second transaction won't propagate, and the miners won't mine it, because they can see that that output has already been spent.  

As far as I know, the only ways you may get the second transaction to confirm would be to (1) be in cahoots with a miner who controls a lot of hash power and have him manually add your fraudulent transactions to his memory pool, (2) hope that your first transaction gets dropped by the network before it gets mined (and that no-one rebroadcasts it).  After your first transaction has been dropped by enough miners and nodes, your second transaction can propagate.  

I think you misunderstood. What he wanted to say is you can spend unconfirmed coins (legitimately) and include a fee in the transaction so the previous transaction that would take long to confirm would confirm quicker - because it's in miners best interest to include both.

Oh, yes you're absolutely right, I misunderstood.  I'm used to people arguing that the double-spend problem is bigger than it really is, and I thought this was one of those cases.  My apologies, Aswan.