Interesting.I'm still having second doubts if this will work.What if I pay really low fee,the case where the transaction gets dropped off the mempool (and we know it).What is the point of pushing it over and over when we know it will eventually be dropped off due to low fees.Or the case is different using Percy ?
First if it's truely too low you can cancel it out of Percy. When you add a transaction you recieve a confirmation string that can be used later to cancel the transaction. But, given enough time, most transactions will find a "low point" and eventually confirm, as evidenced by the 15.7 sat/byte transaction above. So say you look at 21's bitcoin fee reccomendation (as 226 bytes) but you say, man that's too high. You could pay significantly less and even if more transactions come in you could keep yours there as others fell off.
interesting project. just some thoughts that i wanted to share:
first of all as far as i know and the wiki says, "Transaction expiration"[1] is never going to happen. in other words when you send a transaction it will stay out there for ever, most probably.
i currently have a transaction with zero fees that is out there for more than 1.5 month
also on top of that the maximum mempool expiry time was increased to 2 weeks [2] so transaction aren't going to be forgotten that easily.
also why did you choose 6 hours
[1] https://en.bitcoin.it/wiki/Transaction_expiration
[2] https://github.com/bitcoin/bitcoin/commit/a72f76ca3d5d2f259d308f65810891389f728e9e
first of all as far as i know and the wiki says, "Transaction expiration"[1] is never going to happen. in other words when you send a transaction it will stay out there for ever, most probably.
i currently have a transaction with zero fees that is out there for more than 1.5 month
also on top of that the maximum mempool expiry time was increased to 2 weeks [2] so transaction aren't going to be forgotten that easily.
also why did you choose 6 hours
[1] https://en.bitcoin.it/wiki/Transaction_expiration
[2] https://github.com/bitcoin/bitcoin/commit/a72f76ca3d5d2f259d308f65810891389f728e9e
For the most part miners tend to try to keep stardardish rules on evicting. While they definitely "can" process a transaction that's been published (and you should sweep transaction outputs where you've "reclaimed" a transaction from to avoid this) they tend not to. So even if it shows up on a block explorer there's still a percentage of miners and nodes that probably no longer have it in their mempools. However re-broadcasting makes people re-broadcast and it tends to re-propogate among nodes that no long have it in their mempools.
0.14.x+ have this commit but 0.13.x and less don't. But most nodes and especially most miners aren't running 0.13.x (See the tags in your commit). Most of them still evict a transaction after 72 hours. Even if nodes kept transactions for 2 weeks instead of 72 hours, there's a 300MB limit on total transaction in the mempool (by default) [1]. According to blockchain.info mempool size hit 120MB a couple of times over the last 60 days (with most nodes on < 0.14.x code). So when transaction persistentce length rises by a factor of 4 I expect mempool requirements to rise to 480MB which means nodes configured with defaults will be evicting transactions.
6 hours was chosen with no real scientific reason. I tested a few variables on my Raspberry Pi text box. If you have a better time or reason I'd be happy to test it out.
[1] https://github.com/bitcoin/bitcoin/blob/08a7316c144f9f2516db8fa62400893f4358c5ae/src/policy/policy.h#L31