<p>If that does happen, all you need to do is spend your unconfirmed transaction's output with a sufficient fee. A "sufficiently greedy miner" will process both transactions just to get the fee of the latter.</p>

CC BY-SA 3.0
2014-03-21T18:35:28.910Z
Oh I see. I hadn't considered that miners would analyse the queue in such way looking for various threads of dependent transactions and pick the most profitable *threads* over simply picking the most profitable transactions...although it *does* make sense so long as the extra profits on threads more than makes up for the CPU time that they expend analysing the queue to find them.
Phil Dann Ward
CC BY-SA 3.0
2014-03-21T18:20:26.707Z
2014-03-21T18:20:26.707Z
njaard
<p>I just read <a href="https://bitcoin.stackexchange.com/questions/3872/why-do-small-transactions-without-fees-ever-get-processed">Why do small transactions without fees ever get processed?</a> and it made me wonder about the risk that a legitimate, lock_timed transaction might not be processed once the lock_time is past.</p>

<p>I'm aware (from the above question) that in the reference implementation, the increasing age of a transaction (in the mempool once it's been submitted?) should increase its priority regardless of the its fees but not every miner is willing to process low(/no) fee transactions even now never mind what they may (not) do in future.</p>

<p>So if I have a signed transaction with a (very!) distant lock_time and it has fees that were considered reasonable at the time that the transaction was created and then when I submit it after lock_time what is the risk that no miners will process it because its fees are <em>subsequently</em> considered to be too low to bother with it?</p>

CC BY-SA 3.0
2014-03-21T13:17:37.783Z
Is there any way to increase the fees on an already signed transaction?
Phil Dann Ward
CC BY-SA 3.0
2014-03-21T15:29:50.413Z
No since the signature also signs the outputs (which is how the fee is derived)
Luca Matteis
<transaction-fees>
Could an old, unconfirmed transaction fail to be processed because it is no longer deemed to have enough fees
Phil Dann Ward
# Could an old, unconfirmed transaction fail to be processed because it is no longer deemed to have enough fees

(Asked by: username_0 on 2014-03-21)

I just read [Why do small transactions without fees ever get processed?](https://bitcoin.stackexchange.com/questions/3872/why-do-small-transactions-without-fees-ever-get-processed) and it made me wonder about the risk that a legitimate, lock\_timed transaction might not be processed once the lock\_time is past.

I'm aware (from the above question) that in the reference implementation, the increasing age of a transaction (in the mempool once it's been submitted?) should increase its priority regardless of the its fees but not every miner is willing to process low(/no) fee transactions even now never mind what they may (not) do in future.

So if I have a signed transaction with a (very!) distant lock\_time and it has fees that were considered reasonable at the time that the transaction was created and then when I submit it after lock\_time what is the risk that no miners will process it because its fees are *subsequently* considered to be too low to bother with it?

**Tags:** transaction-fees

> **Comments:**
> **username_0**: Is there any way to increase the fees on an already signed transaction?  
> **username_1**: No since the signature also signs the outputs (which is how the fee is derived)  

---

## 1 answers

### Answer by username_2 on 2014-03-21. Score: 1 | Accepted answer

If that does happen, all you need to do is spend your unconfirmed transaction's output with a sufficient fee. A "sufficiently greedy miner" will process both transactions just to get the fee of the latter.

> **Comments:**
> **username_0**: Oh I see. I hadn't considered that miners would analyse the queue in such way looking for various threads of dependent transactions and pick the most profitable *threads* over simply picking the most profitable transactions...although it *does* make sense so long as the extra profits on threads more than makes up for the CPU time that they expend analysing the queue to find them.  

---

