0-confirmation transaction replaced with bigger fee. Is it possible?

[Tomek12]

Hello

I have a question about replacing transaction with smaller fee by the same transaction (same inputs) with bigger fee. As far as I understand it should not be possible because if miner has in its pool transaction which spends an input it will not accepts any other transaction which uses the same input. However everybody says that miner choose always by fee/kb ratio, so maybe from miner point of view pool content is not important and it accepts all new transaction as long as they are OK with previous blocks. Additionally in every manual for 'my transaction with small fee stacks' everybody says that you need to wait until transaction disappear from miners mempool. But my question is when it can happen since most of miners do not restart they machines at all. So is there any timeout for transaction?

[1715662081]

1715662081

[1715662081]

1715662081

[1715662081]

1715662081

[1715662081]

1715662081

[1715662081]

1715662081

[1715662081]

1715662081

[CIYAM]

Miners are free to do this - and some may already be doing this (I am not 100% certain if that is the case though).

[DannyHamilton]

If you can find a miner (or mining pool) that is willing to accept your higher fee transaction as a replacement for the lower fee transaction, and you are able to get your transaction to them, then there is a chance that the higher fee transaction will be confirmed by that miner (or pool) before the lower fee transaction is confirmed by some other miner (or pool).

If the lower fee transaction is confirmed first, then the higher fee transaction will become invalid and will be thrown away.

Most miners (and pools) do not accept higher fee transactions while the lower fee transaction is still in their memory pool.  Also most peers will not relay the higher fee transaction across the network while the lower fee transaction is still in their memory pool. And yes, transactions are eventually dropped from the memory pool even if the computer is not restarted.

[bcearl]

Miners could do that, but I think there is no efficient strategy to arrange an optimal combination of transactions.

When miners get a number of transactions, the obvious thing to do is the following:

1. Check whether the first transaction is consistent with the blockchain, if it is, add it to the mempool.
2. Check whether the next transaction is consistent with the blockchain AND the mempool.
3. GOTO 2.

Now, a transaction that is inconsistent with the pool may yield a higher fee if included and the conflicting transactions are removed. But it is not just one transaction versus the other. You might kick out a low-fee transaction and put your new transaction in. But your new transaction may make a third transaction invalid, and removing that one might make another one invalid and so on. An all these transactions have fees and you want to maximize the sum.

For me this smells like an NP-complete problem.

[hhanh00]

Miners could do that, but I think there is no efficient strategy to arrange an optimal combination of transactions.

When miners get a number of transactions, the obvious thing to do is the following:

1. Check whether the first transaction is consistent with the blockchain, if it is, add it to the mempool.
2. Check whether the next transaction is consistent with the blockchain AND the mempool.
3. GOTO 2.

Now, a transaction that is inconsistent with the pool may yield a higher fee if included and the conflicting transactions are removed. But it is not just one transaction versus the other. You might kick out a low-fee transaction and put your new transaction in. But your new transaction may make a third transaction invalid, and removing that one might make another one invalid and so on. An all these transactions have fees and you want to maximize the sum.

For me this smells like an NP-complete problem.

You can evaluate the total cost of switching a tx vs another. It would become hard if you have a lot of conflicting tx influencing each other but I doubt it happens often - a simple decision tree works. In any case, fishing for the extra few decimilli btc doesn't seem worthwhile.

[bcearl]

You can evaluate the total cost of switching a tx vs another. It would become hard if you have a lot of conflicting tx influencing each other but I doubt it happens often - a simple decision tree works. In any case, fishing for the extra few decimilli btc doesn't seem worthwhile.

Of course you could just look for specific cases like OP's, but then you still have to compare every new transaction with all the others etc. You could even implement a heuristic algorithm for the complete problem, with a rating function for fees etc., but you won't get much from it, it will not really find the optimum and it may introduce a lot of bugs that cost you money (if you are successfully mining and than your block turns out to be invalid).

[hhanh00]

I was thinking more along the lines of maintaining several blocks - pretty much like the blockchain handles forks.

Normally - only 1 block. The tree is a single root block.
When you receive a tx:
go through every leaf :
- try to add it to that leaf.
- If there is a replaceable tx, split the leaf into two. One with the old tx, one with the new one.
- Update the total fees
- If total fees > current max, update current max, set current block as best - switch hashing to this block

It's 1MB per block and it will become costly if there are many splits but you can optimize better by sharing the common txs in the lowest common ancestor.

But yeah - not worth the effort.

[bcearl]

But the adding of a single transaction to a single block can trigger a lot of searches.

Example:
1. You want to add transaction A with a conflict to already added transaction B.
2. You make two leaves: one with the old block (with B), second with A added (and B removed).
3. Now you have to search the whole block for transactions that depended on B.
4. Now you have to search the whole block for transactions dependent on the transactions from step 3 and so on.

[lontivero]

Replacing low fee transactions by higher fee transactions is possible and is up to the miners however that can kill 0-confirmation transactions because we can propagate a low fee tx and hours after that send another tx with higher fee then miners will prefer the second one and confirm it.

I know 0-confirmation tx are never valid but they are useful for small amounts but if tx replacement is perform by miners based on fee then 0-confirmation tx are riskier than before. I know I am not an expert and I can be wrong.

[hhanh00]

But the adding of a single transaction to a single block can trigger a lot of searches.

Example:
1. You want to add transaction A with a conflict to already added transaction B.
2. You make two leaves: one with the old block (with B), second with A added (and B removed).
3. Now you have to search the whole block for transactions that depended on B.
4. Now you have to search the whole block for transactions dependent on the transactions from step 3 and so on.

Yup, you don't scan though. You would keep the block as a DAG, prune a node and its dependents.

[bcearl]

Replacing low fee transactions by higher fee transactions is possible and is up to the miners however that can kill 0-confirmation transactions because we can propagate a low fee tx and hours after that send another tx with higher fee then miners will prefer the second one and confirm it.

I know 0-confirmation tx are never valid but they are useful for small amounts but if tx replacement is perform by miners based on fee then 0-confirmation tx are riskier than before. I know I am not an expert and I can be wrong.

Maybe this gets even wilder in the far future when fees start to matter a lot more. It is possible that a miner drops an already mined block to get a transaction out that prevents a new transaction with higher fee.

[sickpig]

Hello

I have a question about replacing transaction with smaller fee by the same transaction (same inputs) with bigger fee. As far as I understand it should not be possible because if miner has in its pool transaction which spends an input it will not accepts any other transaction which uses the same input. However everybody says that miner choose always by fee/kb ratio, so maybe from miner point of view pool content is not important and it accepts all new transaction as long as they are OK with previous blocks. Additionally in every manual for 'my transaction with small fee stacks' everybody says that you need to wait until transaction disappear from miners mempool. But my question is when it can happen since most of miners do not restart they machines at all. So is there any timeout for transaction?

Fwiw peter todd already implemented this idea, have a look:

https://github.com/petertodd/replace-by-fee-tools

And on this thread you can get more info:

https://bitcointalk.org/index.php?topic=199947.0

If memory serves there should be something also on bitcoin development mailing list

[exoton]

If you can find a miner (or mining pool) that is willing to accept your higher fee transaction as a replacement for the lower fee transaction, and you are able to get your transaction to them, then there is a chance that the higher fee transaction will be confirmed by that miner (or pool) before the lower fee transaction is confirmed by some other miner (or pool).

If the lower fee transaction is confirmed first, then the higher fee transaction will become invalid and will be thrown away.

Most miners (and pools) do not accept higher fee transactions while the lower fee transaction is still in their memory pool.  Also most peers will not relay the higher fee transaction across the network while the lower fee transaction is still in their memory pool. And yes, transactions are eventually dropped from the memory pool even if the computer is not restarted.

Maybe it would be a good idea to change the "standard" logic that most pools/nodes follow to accept this kind of transaction as long as the outputs are exactly the same (or a TX has additional outputs), and the only meaningful difference is that the TX fee is increased.

This would allow for someone to increase the fee attacked to a transaction without having to either wait for the old transaction to fall out of nodes memory poor nor having to risk that no no/low TX eventually gets confirmed prior to it falling out of node's memory pool

[yakuza699]

Fwiw peter todd already implemented this idea, have a look:

https://github.com/petertodd/replace-by-fee-tools

And on this thread you can get more info:

https://bitcointalk.org/index.php?topic=199947.0

If memory serves there should be something also on bitcoin development mailing list

I knew this one from the first week it was released but till now I haven't found a single miner that would have implemented it.

Maybe it would be a good idea to change the "standard" logic that most pools/nodes follow to accept this kind of transaction as long as the outputs are exactly the same (or a TX has additional outputs), and the only meaningful difference is that the TX fee is increased.

Sounds good to me.That is basically the same as petter todd's replace-by-fee tools expect we have to remove the double-spend feature and leave bump-fee only.

[gmannnnn]

Maybe it would be a good idea to change the "standard" logic that most pools/nodes follow to accept this kind of transaction as long as the outputs are exactly the same (or a TX has additional outputs), and the only meaningful difference is that the TX fee is increased.

Sounds good to me.That is basically the same as petter todd's replace-by-fee tools expect we have to remove the double-spend feature and leave bump-fee only.

I dont think this is currently a problem. Transactions with fees are generally included in the next block, small transactions without fees are generally not accepted as 0-conf deposits (see luckyb.it)

[yakuza699]

I dont think this is currently a problem.

As no miners yet implemented replace-by-fee it is not a problem. Yet.

Transactions with fees are generally included in the next block.

Depends on what the fee is. For example if you put a fee of 0.0001 on a 10000bytes transaction it is likely that this transactions wouldn't get in the block.

small transactions without fees are generally not accepted as 0-conf deposits (see luckyb.it)

What do you mean? Luckyb.it does accept 0-conf transactions. They just don't accept low priority transactions(the ones that pays too less of a fee or the ones that doesn't pay fee at all).

[sumantso]

small transactions without fees are generally not accepted as 0-conf deposits (see luckyb.it)

What do you mean? Luckyb.it does accept 0-conf transactions. They just don't accept low priority transactions(the ones that pays too less of a fee or the ones that doesn't pay fee at all).

If I am reading correctly, the idea is to make non-fee transactions low priority.

[yakuza699]

small transactions without fees are generally not accepted as 0-conf deposits (see luckyb.it)

What do you mean? Luckyb.it does accept 0-conf transactions. They just don't accept low priority transactions(the ones that pays too less of a fee or the ones that doesn't pay fee at all).

If I am reading correctly, the idea is to make non-fee transactions low priority.

From who did that idea came from? Does luckyb.it plans to don't accept 0-conf transactions anymore? Or is there something else?

[shorena]

If I may be so bold to say this:  get your "how does casino y handle x" in the appropriate section please (gambling) and keep posts here toward the subject of the thread (0-conf TX in general) and the subboard (bitcoin protocol).

[yakuza699]

If I may be so bold to say this:  get your "how does casino y handle x" in the appropriate section please (gambling) and keep posts here toward the subject of the thread (0-conf TX in general) and the subboard (bitcoin protocol).

If that was to me than actually it was gmannnnn who started to talk about luckyb.it. Also if we talk about 0-conf transactions it does also include luckyb.it as they accept 0-conf transactions and they might get hurt by it.