Topic: [ANN] Percy, Persistent Bitcoin Transactions (Read 1169 times)

Hey all. I'm going to end this project. Mempool is low now. Code is still up if you want to use it. But the truth is that Bitcoin is long term going to be useful only as a backed for the lightning network. With that as the goal of Bitcoin this no longer makes sense to maintain (and pay for).

If you truly need this service message me and I can help you set up something. It's light enough where it can run on a RPI if it doesn't have to handle a ton of transactions.

Also the code is still up here and if there's some unknown demand for this service I can always start it back up again.

Good luck!

Hey guys doing some testing with Electrum 3, it looks good. However I've noticed that how accurate my ability to inspect the mempool is based heavily on which electrum server I'm connected to. I'm going to look into a pruned node specifically for this project, especially as the mempool is incredibly backed up due to blocksize constraints.

Also an update. If you attempted to add a transaction recently it probably failed. I think I may have found a reliability bug in the system. I'll attempt to mitigate.

Hey guys, just an update. I'm going to try to find some time this weekend to test Percy with Segwit transactions. Right now segwith txs are servicing less than 1% of the total transactions on bitcoin. Bu I expect that to rise, given the discount (source). I should have more for you "soonish".

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.


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

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

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 ?

New record. Percy just helped a 15.7 sat/byte transaction confirm after sitting in the mempool for almost a month (and in percy since the 3rd of June). So if you can wait, we can help you get a small transaction confirmed.

Ya we saw the mempool drop pretty low this weekend so we had some long lived, low fee transactions confirm. Here are some examples :

TXID	Fee (sats/byte)	Time in Percy
3bcd...	51.6	8 Days
777d...	72.1	7 Days
f8c1...	19.6	4 Days
e6af...	58.9	4 Days

Assuming your use case is disbursing payouts for nastyfans, this could at least in theory help you distribute them more reliably and ensure that they will eventually confirm when the backlog is low enough. The 19.6 satoshi/byte transaction is probably the closest to your ideal use case. Additionally, when adding a transaction, percy gives you a "confirmation string" that can be used to retire the transaction out of percy at a future date. So you could publish your low tx fee and if changes were needed later you could cancel it out of percy and let it fall off the network "naturally."

I've got a issue in the project to parse transactions and store the fee information so that I can provide these types of stats dynamically in the
future.

Hope Nastypool is doing great!

Edit- Fixing links

No, this targets the other half of the formula. Those with transactions who never confirm. In some specific circumstances it might help your transaction confirm faster; but that's pretty unlikely.

This is interesting. Do you have any data or example transactions showing a low fee? Would be great if this was another possible method of confirming low priority transactions in addition to the transaction accelerator.

Would this potentially cut down on the overall delays in processing the Bitcoin transactions that many of us have seen lately?

Hey guys I created a tool, percy, that will make your transactions persistent by resubmitting them periodically to the network.

Ideal use case is for someone with a transaction where they can afford to be patient (like a re-organizationing transaction to ones self or an incoming transaction with a lower fee and a known customer). Or where you can let subsequent child transactions add an additional bounty on payment (like when re-organizing coins in your wallet). It doesn't do anything too complex really. It just resubmits your transactions to the network every 6 hours until it confirms. So even if you put in a transaction during bitcoin's "busy" periods with an average fee this will continue to resubmit the transaction to the network until it confirms. The method used to do so is not complex (see source code here) and can be self hosted if desired (I run a test box on a raspberry pi out of my home).

Would love your feedback and if you spot a bug or a feature request please report it on github.

According to 21.co's Fee Chart there have been 60k+ transactions that have confirmed in the last 24 hours with a fee < 100 sats/byte. If you can be patient Percy can make sure your transaction persists until it's one of those confirmed.