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?
-
AFAIK They would choose the one they received first, the oldest transaction.– BlazrMay 10, 2012 at 12:41
-
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 GornickMay 10, 2012 at 23:26
-
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.– ThePiachuMay 10, 2012 at 23:48
-
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.– ThePiachuMay 10, 2012 at 23:50
-
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 IrregularMay 11, 2012 at 3:41
|
Show 1 more comment
2 Answers
It seems as if there is such a pool now, advertising the behavior as a feature to allow "reverting mistaken payments":
They also supply a patch to bitcoind.
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.
-
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. Jan 22, 2013 at 20:52
-
-1 this is nice, but totally doesn't answer the question, which is EXACTLY asking if there is such a pool.– o0'.Jan 23, 2013 at 9:26
-
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. Jan 23, 2013 at 10:23
-
@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. Apr 16, 2014 at 10:02