Bitcoin Forum
September 22, 2018, 06:39:01 AM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: [ANN] Percy, Persistent Bitcoin Transactions  (Read 1033 times)
chalbersma
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile WWW
June 01, 2017, 02:58:21 AM
 #1

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.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
theroryshow
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
June 04, 2017, 12:22:04 PM
 #2

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

Activity: 2674
Merit: 1340


I 💚 Bitcoin


View Profile WWW
June 04, 2017, 04:31:57 PM
 #3

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.

chalbersma
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile WWW
June 04, 2017, 07:40:37 PM
 #4

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

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.

chalbersma
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile WWW
June 04, 2017, 08:09:57 PM
 #5

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.

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

TXIDFee (sats/byte)Time in Percy
3bcd...51.68 Days
777d...72.17 Days
f8c1...19.64 Days
e6af...58.94 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
chalbersma
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile WWW
June 12, 2017, 05:51:07 PM
 #6

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.
Joel_Jantsen
Legendary
*
Offline Offline

Activity: 1092
Merit: 1185


Hand over the Merit and no one will get hurt!


View Profile
June 12, 2017, 06:19:31 PM
 #7

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 ?

.BitDice.               ▄▄███▄▄
           ▄▄██▀▀ ▄ ▀▀██▄▄
      ▄▄█ ▀▀  ▄▄█████▄▄  ▀▀ █▄▄
  ▄▄██▀▀     ▀▀ █████ ▀▀     ▀▀██▄▄
██▀▀ ▄▄██▀      ▀███▀      ▀██▄▄ ▀▀██
██  ████▄▄       ███       ▄▄████  ██
██  █▀▀████▄▄  ▄█████▄  ▄▄████▀▀█  ██
██  ▀     ▀▀▀███████████▀▀▀     ▀  ██
             ███████████
██  ▄     ▄▄▄███████████▄▄▄     ▄  ██
██  █▄▄████▀▀  ▀█████▀  ▀▀████▄▄█  ██
██  ████▀▀       ███       ▀▀████  ██
██▄▄ ▀▀██▄      ▄███▄      ▄██▀▀ ▄▄██
  ▀▀██▄▄     ▄▄ █████ ▄▄     ▄▄██▀▀
      ▀▀█ ▄▄  ▀▀█████▀▀  ▄▄ █▀▀
           ▀▀██▄▄ ▀ ▄▄██▀▀
               ▀▀███▀▀
        ▄▄███████▄▄
     ▄███████████████▄
    ████▀▀       ▀▀████
   ████▀           ▀████
   ████             ████
   ████ ▄▄▄▄▄▄▄▄▄▄▄ ████
▄█████████████████████████▄
██████████▀▀▀▀▀▀▀██████████
████                   ████
████                   ████
████                   ████
████                   ████
████                   ████
████▄                 ▄████
████████▄▄▄     ▄▄▄████████
  ▀▀▀█████████████████▀▀▀
        ▀▀▀█████▀▀▀
▄▄████████████████████████████████▄▄
██████████████████████████████████████
█████                            █████
█████                            █████
█████                            █████
█████                            █████
█████                     ▄▄▄▄▄▄▄▄▄▄
█████                   ▄█▀▀▀▀▀▀▀▀▀▀█▄
█████                   ██          ██
█████                   ██          ██
█████                   ██          ██
██████████████████▀▀███ ██          ██
 ████████████████▄  ▄██ ██          ██
   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀ ██          ██
             ██████████ ██          ██
           ▄███████████ ██████▀▀██████
          █████████████  ▀████▄▄████▀
[/]
pooya87
Legendary
*
Offline Offline

Activity: 1400
Merit: 1159


Buy bitcoin they said... who listened?


View Profile
June 13, 2017, 09:18:15 AM
 #8

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 Smiley

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

chalbersma
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile WWW
June 16, 2017, 04:48:26 AM
 #9

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 Smiley

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
chalbersma
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile WWW
August 24, 2017, 11:59:08 PM
 #10

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".
chalbersma
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile WWW
November 09, 2017, 10:55:23 PM
 #11

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.
chalbersma
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile WWW
November 13, 2017, 06:34:23 PM
 #12

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.
chalbersma
Full Member
***
Offline Offline

Activity: 163
Merit: 100


View Profile WWW
April 09, 2018, 05:11:03 AM
 #13

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!
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!