14
2
Some pools use a modified bitcoind that uses different rules for choosing the transactions to include in a block. Are there any pools that knowing one transaction to be included in a block would discard it if another transaction on the same inputs would arrive with a higher fee? That is to say, when faced with a double spend attack between a transaction that arrived earlier and a transaction that pays them more, the pool would choose the latter?
1
In your scenario there are two transactions with the same input, i.e. an attempt to double-spend.
If the first transaction is already part of a block in the chain, the second one can not be included in any block on top of that block. Other nodes would reject that new block. A miner could build his new block on top of the last block before the first transaction, but that fork of the blockchain would never catch up with the original chain, unless more than 50% of the networks hashrate also builds on top of it. That's the mechanism preventing double spending.
If the first transaction is not yet part of the blockchain (i.e. 0 confirmations), a miner can choose which one to include in the next block. Choosing the one with the higher fee would be a sensible choice, but I don't know if that is implemented in any client. In that case the first transaction would be discarded, and never become part of the blockchain, since it's effectively the same scenario as above.
So, no, there is no potential for a double spend attack through higher transaction fee.
@bananer: That's like saying "I wouldn't call it stealing if there's no guard at the store". Any attempt to reverse a payment to a merchant is a double-spend attack, regardless of the protective measures taken. As for relevance - waiting for 1 confirmation is not practical in most cases, therefore it is very important that 0-confirmation transactions will be fairly safe as well. If miners eschew a tx they know for another that has a higher fee, this will be compromised. – Meni Rosenfeld – 2014-04-16T10:02:53.507
3Well, it's an okay analysis of the problem, but doesn't really answer the question. There is "potential" for such a double-spend attack, but it would need to be done through some malicious pool designed for such attacks. – ThePiachu – 2013-01-22T20:52:57.057
-1 this is nice, but totally doesn't answer the question, which is EXACTLY asking if there is such a pool. – o0'. – 2013-01-23T09:26:54.687
I would not call it a "double-spend attack" if the first transaction has 0 confirmations, but that's a matter of definition. Thinking about it, if pools would make it a policy to prefer transactions with higher fees in such a scenario (not malicious if you ask me), it would allow one to revert an unconfirmed transactions by paying a higher fee. As long as merchants wait for at least 1 confirmation, they are safe. – Philip Frank – 2013-01-23T10:23:00.397
AFAIK They would choose the one they received first, the oldest transaction. – Blazr – 2012-05-10T12:41:52.130
Would doing as you describe make other honest miners reject the block, assuming they received the other transaction first too? – Highly Irregular – 2012-05-10T23:07:41.990
1That would be a quick way for a pool to commit suicide, I suppose. The bad PR as a result would probably be fatal. – Stephen Gornick – 2012-05-10T23:26:13.400
3@HighlyIrregular No, as the transaction would still be valid. A pool can put any valid transaction in the block, even if it invalidates some other transactions which are not part of any block. Otherwise there would be a fork each time someone would perform a double spend attack. – ThePiachu – 2012-05-10T23:48:48.333
2@StephenGornick It certainly would be, however, if someone make a private pool for themselves that would prefer higher-paying transactions, they could still do it. Probably some miners would still join it in hopes of getting slightly higher payouts. – ThePiachu – 2012-05-10T23:50:14.243
1Then I guess that's a good reason to wait for extra confirmations if you're receiving a substantial sum of bitcoins from an untrusted party. – Highly Irregular – 2012-05-11T03:41:33.380