<p>It seems as if there is such a pool now, advertising the behavior as a feature to allow "reverting mistaken payments":</p>

<p><a href="http://www.bitundo.com/" rel="nofollow">BitUndo</a></p>

<p>They also supply <a href="https://github.com/bitundo/bitcoin" rel="nofollow">a patch</a> to bitcoind.</p>

CC BY-SA 3.0
2014-04-16T08:59:35.610Z
2014-04-16T08:59:35.610Z
lxgr
<p>In your scenario there are two transactions with the same input, i.e. an attempt to double-spend.</p>

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

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

<p>So, no, there is no potential for a double spend attack through higher transaction fee.</p>

CC BY-SA 3.0
2013-01-22T20:52:57.057Z
Well, 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
CC BY-SA 3.0
2013-01-23T09:26:54.687Z
-1 this is nice, but totally doesn't answer the question, which is **EXACTLY** asking if there is such a pool.
o0'.
CC BY-SA 3.0
2013-01-23T10:23:00.397Z
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
CC BY-SA 3.0
2014-04-16T10:02:53.507Z
@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
CC BY-SA 3.0
2013-01-22T20:14:52.977Z
2013-01-22T20:14:52.977Z
Philip Frank
<p>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?</p>

CC BY-SA 3.0
2012-05-10T12:41:52.130Z
AFAIK They would choose the one they received first, the oldest transaction.
Blazr
CC BY-SA 3.0
2012-05-10T23:07:41.990Z
Would doing as you describe make other honest miners reject the block, assuming they received the other transaction first too?
Highly Irregular
CC BY-SA 3.0
2012-05-10T23:26:13.400Z
That 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
CC BY-SA 3.0
2012-05-10T23:48:48.333Z
@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
CC BY-SA 3.0
2012-05-10T23:50:14.243Z
@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
CC BY-SA 3.0
2012-05-11T03:41:33.380Z
Then 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
<transactions><mining-pools><security><doublespend><weaknesses>
Does any pool accept higher-fee transactions of a double spend, instead of the earlier one?
ThePiachu
# Does any pool accept higher-fee transactions of a double spend, instead of the earlier one?

(Asked by: username_0 on 2012-05-10)

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?

**Tags:** transactions, mining-pools, security, doublespend, weaknesses

> **Comments:**
> **username_1**: AFAIK They would choose the one they received first, the oldest transaction.  
> **username_2**: Would doing as you describe make other honest miners reject the block, assuming they received the other transaction first too?  
> **username_3**: That would be a quick way for a pool to commit suicide, I suppose.  The bad PR as a result would probably be fatal.  
> **username_0**: @username_2 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.  
> **username_0**: @username_3 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.  
> **username_2**: Then 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.  

---

## 2 answers

### Answer by username_4 on 2014-04-16. Score: 2

It seems as if there is such a pool now, advertising the behavior as a feature to allow "reverting mistaken payments":

[BitUndo](http://www.bitundo.com/)

They also supply [a patch](https://github.com/bitundo/bitcoin) to bitcoind.


---

### Answer by username_5 on 2013-01-22. Score: 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.

> **Comments:**
> **username_0**: Well, 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.  
> **username_6**: -1 this is nice, but totally doesn't answer the question, which is **EXACTLY** asking if there is such a pool.  
> **username_5**: 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.  
> **username_7**: @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.  

---

