Bitcoin RPC based CPFP script

[d4n13]

Still pretty rough, but here's a script to create a CPFP transaction from and unconfirmed in your wallet.
https://gist.github.com/brianddk/db762a50c6fa5049ff63

This will also give you the raw HEX transaction data to submit to Eligius

I found a Eligius submit URL here: http://eligius.st/~wizkid057/newstats/pushtxn.php

I recommend you get your fee schedule from here: http://bitcoinexchangerate.org/fees (or the estimatefee RPC)

Warning.. I did tweak bitcoinrpc.authproxy to support use simplejson instead of json.  I'll post a pull for that later.

[1714225038]

1714225038

[1714225038]

1714225038

[1714225038]

1714225038

[arnuschky]

This is about the fifth post of yours about CPFP. Just out of curiosity: why the urgency? Just the stress test? (Yes, I know, I am a bit late )

[achow101]

This is about the fifth post of yours about CPFP. Just out of curiosity: why the urgency? Just the stress test? (Yes, I know, I am a bit late )

Probably because of the stress test and because it is something good to have when more people adopt Bitcoin. With more transactions happening, things will get slowed down, and a higher fee might be needed. Instead of painstakingly waiting for a low fee transaction to confirm, you can just use CPFP and have it confirmed in no time.

[brianddk]

This is about the fifth post of yours about CPFP. Just out of curiosity: why the urgency? Just the stress test? (Yes, I know, I am a bit late )

Probably because of the stress test and because it is something good to have when more people adopt Bitcoin. With more transactions happening, things will get slowed down, and a higher fee might be needed. Instead of painstakingly waiting for a low fee transaction to confirm, you can just use CPFP and have it confirmed in no time.

^^ Yes, Exactly ^^
During the stress there was a tremendous amount of FUD going around about the death of bitcoin, and talk of hard-forks.  By contrast CPFP is a very simple and elegant way to rescue transactions drowning in the mempool.  I envision wallets that will start out with low fees, then just continually hook higher and higher CPFP TXs to it until it gets confirmed.  A true Free Market dynamic transaction fee determination.

I was frankly surprised that the de facto solution on the forum seemed to be, "shutdown your client and wait 48-72 hrs for the transactions to purge from the network, then double spend and hope your second TX goes through".  I realize that this worked in 99% of the times, but it put a lot of undue taint on addresses, and I felt it would have been more elegant to simply hook the unconfirmed TX with CPFP.  So for every "shutdown and wait" post, I put up a "or... CPFP" post.

Anyway... as knightdk mentioned... If wallets started to get smarter with CPFP TX, all the FUD that was poping up this month would have fallen on deaf ears.  Honestly I think there were likely some unfortunate beginners that tried Bitcoin this month and just went "meh... maybe next year"

[domob]

This is about the fifth post of yours about CPFP. Just out of curiosity: why the urgency? Just the stress test? (Yes, I know, I am a bit late )

Probably because of the stress test and because it is something good to have when more people adopt Bitcoin. With more transactions happening, things will get slowed down, and a higher fee might be needed. Instead of painstakingly waiting for a low fee transaction to confirm, you can just use CPFP and have it confirmed in no time.

^^ Yes, Exactly ^^
By contrast CPFP is a very simple and elegant way to rescue transactions drowning in the mempool.  I envision wallets that will start out with low fees, then just continually hook higher and higher CPFP TXs to it until it gets confirmed.  A true Free Market dynamic transaction fee determination.

Note, though, that such a series of CPFP transactions (as you envision above) is exactly what we don't want during periods with filled mempools.  CPFP is quite costly in terms of blockchain usage.  If each wallet user sends, say, on average three revisions of their tx before it gets confirmed, this triples the number of transactions sent.  This is makes the problem only worse.  I think that RBF (possibly the first seen safe variant) is a much better way to get transactions unstuck than CPFP.

[arnuschky]

Note, though, that such a series of CPFP transactions (as you envision above) is exactly what we don't want during periods with filled mempools.  CPFP is quite costly in terms of blockchain usage.  If each wallet user sends, say, on average three revisions of their tx before it gets confirmed, this triples the number of transactions sent.  This is makes the problem only worse.  I think that RBF (possibly the first seen safe variant) is a much better way to get transactions unstuck than CPFP.

Slight correction of word usage: CPFP allows additions to the initial tx while RBF allows revisions of the initial tx. So RBF is more efficient for sure.

However, it's still quite controversial whether full RBF should be implemented. Many people aren't very happy with the idea of deterministic doublespends. IMO, it's better to face a known and calculable risk than a unknown and incalculable risk (which is still very likely).

For the usage discussed in this thread, FSS-RBF should be the right choice: it allows you to revise transactions as long as the new transaction has an equal or greater number of inputs and outputs (this is a simolification, see http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html for the full spec).

[brianddk]

Note, though, that such a series of CPFP transactions (as you envision above) is exactly what we don't want during periods with filled mempools.  CPFP is quite costly in terms of blockchain usage.  If each wallet user sends, say, on average three revisions of their tx before it gets confirmed, this triples the number of transactions sent.  This is makes the problem only worse.  I think that RBF (possibly the first seen safe variant) is a much better way to get transactions unstuck than CPFP.

For the usage discussed in this thread, FSS-RBF should be the right choice: it allows you to revise transactions as long as the new transaction has an equal or greater number of inputs and outputs (this is a simolification, see http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008248.html for the full spec).

I agree on all counts.... As to the question of "Why am I so interested in CPFP...", it's because it is simple and could be rolled out with very little disruption (other than the points mentioned).  If I was to play king for a day, of course RBF is the better choice, but it requires a bit more heavy lifting and modifications to the signing flags that needs a good deal more inspection and deliberation than simply chaining TX together.

Also... RBF is already being evangelized by core developers... so I felt no need to draw attention to a solution that will likely be where we end up in the next year or two.  I just like the fact that 20 lines of python and a post to Eligius was all that it took to kick out CPFP TXs.

As was mentioned earlier though... it is mute now... the fire drill is over and it is unlikely that this crisis will return any time soon.  By then RBF could potentially be the standard.

[arnuschky]

I agree on all counts.... As to the question of "Why am I so interested in CPFP...", it's because it is simple and could be rolled out with very little disruption (other than the points mentioned).  If I was to play king for a day, of course RBF is the better choice, but it requires a bit more heavy lifting and modifications to the signing flags that needs a good deal more inspection and deliberation than simply chaining TX together.

Well, even full RBF is a very local modification to bitcoin core and doesn't affect any consensus rules. It just affects the rules that the nodes applies when determining whether or not a transaction is accepted into the mempool (no signing involved).

Also... RBF is already being evangelized by core developers... so I felt no need to draw attention to a solution that will likely be where we end up in the next year or two.  I just like the fact that 20 lines of python and a post to Eligius was all that it took to kick out CPFP TXs.

Yes, CPFP is certainly simpler because it can be done on a miner's transaction-selection level and doesn't affect the P2P network.

The "core" developers are very much divided on RBF. No, actually, they are not as AFAIK Peter Todd is the only one rooting for it. They have good reasons: Even if a fully deployed RBF is a scenario I could live with, the transitional period is critical. Some miners would implement it while others wouldn't, leading to a even more inconsistent state of doublespend handling. And merchants would need to hurry in order to protect themselves against doublespends due to RBF. A solution to this problem is the scheduled RBF deployment now proposed by Peter Todd: https://github.com/bitcoin/bitcoin/pull/6352

Not sure which system (or combination) will win. As said, RBF has some huge opposition. I see FSS-RBF + CPFP as the most likely (CPFP makes a whole lot of sense apart from stuck transitions, so I don't see a reason against it).

[brianddk]

...It just affects the rules that the nodes applies when determining whether or not a transaction is accepted into the mempool (no signing involved).

I was referring to the requirement for ANYONECANPAY sighash.  Although not technically part of the signature, it does control how the signing process works.  Any wallet intending to have TXs later RBF'd would have to update to ensure that the ANYONECANPAY bit was set when they sign.

source: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html

[arnuschky]

...It just affects the rules that the nodes applies when determining whether or not a transaction is accepted into the mempool (no signing involved).

I was referring to the requirement for ANYONECANPAY sighash.  Although not technically part of the signature, it does control how the signing process works.  Any wallet intending to have TXs later RBF'd would have to update to ensure that the ANYONECANPAY bit was set when they sign.

source: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html

Interested, wasn't aware of that. Thanks, this is quite clever! Technically, this isn't part of RBF. It's a sort of mini-protocol that allows to use RBF without CPFP.

[BitNow]

Still pretty rough, but here's a script to create a CPFP transaction from and unconfirmed in your wallet.
https://gist.github.com/d4n13/db762a50c6fa5049ff63

This will also give you the raw HEX transaction data to submit to Eligius

I found a Eligius submit URL here: http://eligius.st/~wizkid057/newstats/pushtxn.php

I recommend you get your fee schedule from here: http://bitcoinexchangerate.org/fees (or the estimatefee RPC)

Warning.. I did tweak bitcoinrpc.authproxy to support use simplejson instead of json.  I'll post a pull for that later.

I have a problem with a transaction with no fee that is 24 hours over the network unconfirmed.
https://bitcointalk.org/index.php?topic=1139711

There is something I can do about it?

There is a way of forcing a transaction broadcast without having to wait the 30 minutes Bitcoin Core period?