Child Pays For Parent Support

[bitjson]

To all Bitcoin wallet makers: Please include CPFP as standard - both TX and RX wise

To get rid of these many posts "my tx does not confirm after 48 hours", please include CPFP support as an industry standard feature. This means:

• CPFP RX wise: technically spend a received unconfirmed tx to yourself.
• CPFP TX wise: Make sure your TX has always enough change to yourself (if not, show a warning understandable by the normal user), and allow to "accelerate" an own stuck TX by spending own change to yourself.
• GUI-wise, both functionalities could be accessible via the context menu of an unconfirmed incoming or outgoing transaction and could be called something like "Boost/accelerate this transaction" or "Enforce quick confirmation of this transaction".

There are some good thoughts in the comments section as well.

[dabura667]

Implementing this would be much easier if the info from bitcoin-cli getrawmempool true

An example:

"f7d0882d0216e0ed352bd1443614d85e755a895fb0763d73bda83a4c34dc5928": {
    "size": 192,
    "fee": 0.00050000,
    "modifiedfee": 0.00050000,
    "time": 1492181639,
    "height": 461854,
    "startingpriority": 0,
    "currentpriority": 0,
    "descendantcount": 1,
    "descendantsize": 192,
    "descendantfees": 50000,
    "ancestorcount": 2,
    "ancestorsize": 712,
    "ancestorfees": 134425,
    "depends": [
      "c1882d3ed3d8dbc61fff09554139a679a58cf9e8aa5ec0f52ac25a8c5d903d14"
    ]
}

So if I needed to spend this transaction's output as an input, I would just calculate:

var extraNeededFeeSatoshis = targetSatoshiPerByteRate * ancestorsize - ancestorfees

then just add it on to the absolute fee calculated for your current transaction.

The UI could be something like:

• If you notice that an input you MUST use is all of the below:
  • More than 1 hour since first seen on insight
  • 0 confirmations
  • targetSatoshiPerByteRate * ancestorsize > ancestorfees
• Then
  • If fee rate is set to Priority or Emergency, add the extra CPFP fees without asking.
  • If not, then pop up and tell the user "whoever sent to you didn't pay enough fees. You can pay on their behalf or just leave it and risk waiting a long time."
  • Maybe give the user the option to drop their sat/byte rate down to the ancestorfees / ancestorsize rate? (nah, on second thought no.)

THERE SHOULD BE A SAFE GUARD!!! (not sure what it is tho)

I have coded auto-CPFP estimators where we hard coded the max CPFP extra fee to add was 0.01 BTC total. So if I need to pay more than 13 USD to cover your stupid transaction, then I'll just write your utxo off as not valid until 1 conf.

Perhaps another measurement might be worth it... what could we tie the limit to? absolute values seem dumb and arbitrary usually... thoughts?

Just brain dumping here... anyone else have ideas?

[chrisrico]

Maybe I should break this out into its own issue, but a lot of the same challenges as CPFP.

I operate two-way bitcoin ATMs that require one confirmation before you can withdraw cash. In times of high volume, or when a customer includes too low a fee, they may want a refund instead of waiting for a confirmation. With Copay, there is no safe way to select the unconfirmed UTXO and force it to be the only input to a refund transaction.

[dabura667]

You can do that with bitcore-wallet-client (the main library used in development of Copay)

Since your use case is very rare, I would recommend writing your own special app to do such a thing.

I could write one for you, it might take me a few hours tops.

[chrisrico]

I was planning on doing that as a stop gap measure, but I don't see how it's any different than CPFP which needs to spend a specific UTXO anyway.

[matiu]

I like the idea, but the UI seems complex

…

On Apr 15, 2017 4:48 AM, "Chris Rico" ***@***.***> wrote: I was planning on doing that as a stop gap measure, but I don't see how it's any different than CPFP which needs to spend a specific UTXO anyway. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/bitpay/copay/issues/5102#issuecomment-294278423>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGCHGiLpUltEWGlOtQcYpHbEyBTwIP9ks5rwHZVgaJpZM4K6IxD> .

[dabura667]

@matiu Were you talking about @chrisrico and his ATM idea or CPFP in general?

CPFP doesn't have to be complex. Just calculate it in the background, add the extra fee, and on the confirmation screen, maybe add a yellow ! mark saying (extra 35 bits added to cover extra fees) or something.

[matiu]

cpfp in general. What you suggest if there are multiple utxos to choose for? CPFP should only be used if there is on ohter option than using unconfirmed, right?

…

On Apr 15, 2017 12:30 PM, "Dabura667" ***@***.***> wrote: @matiu <https://github.com/matiu> Were you talking about @chrisrico <https://github.com/chrisrico> and his ATM idea or CPFP in general? CPFP doesn't have to be complex. Just calculate it in the background, add the extra fee, and on the confirmation screen, maybe add a yellow ! mark saying (extra 35 bits added to cover extra fees) or something. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/bitpay/copay/issues/5102#issuecomment-294300312>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGCHIfYERZW3KeqNFQtvs-zG0UAHUUHks5rwOKugaJpZM4K6IxD> .

[dabura667]

CPFP logic should ONLY trigger IF:

1. The app MUST select a CPFP-elligible utxo. If it does not need to, it will prioritize any other utxo.

The biggest problem with CPFP implementation (i have done it many times) is defining when a utxo should be considered for CPFP fee adding.

In general, most places I have implemented with have:

1. More than 1 hour since first seen on their bitcoind instance.
2. 0 confirmations
3. targetSatoshiPerByteRate * ancestorsize > ancestorfees where ancestorsize is the total in bytes of all unconfirmed parents (recursive) of the unconfirmed utxo's tx, and ancestorfees is the total in satoshis of the same.
4. most of the time this only adds a few cents to a transaction, but ensures that the parent will confirm in case it is a low fee.

Also there are two types of CPFP I have made:

1. CPFP gathering transactions that merely gather up all the CPFP utxos periodically and send them to another address owned by the person receiving the bitcoin. This is inefficient fee-wise as it creates an extra transaction that is not an actual send (you are sending to yourself) (perhaps this is what you think CPFP is)
2. CPFP as an additional step to necessary fee calculation when actually sending an outgoing transaction. (This is more efficient, as you just add the parent's needed extra fees to a transaction that you were already going to send anyways)

I think Copay only needs num. 2 in these situations. Copay prioritizes confirmed utxos, and requires enabling an option to spend unconfirmed. However, when an unconfirmed is coming and you need to ensure it is confirmed before sending, one way to do it is to add extra fees to bring the parent transaction average fee rate up to your target.

However, this does open up the app to moochers. If they know you use Copay and that Copay automatically adds fees via CPFP, then more users might lower fees to expect the receiver to pay the extra fees when that user eventually sends again...

[dabura667]

FYI, Electrum has implemented a simple CPFP implementation.

Also I have made a few pull requests:
bitpay/bitcoind-rpc#24
bitpay/insight-api#508

These could easily be pulled in to current bitcored (<0.13.0 bitcoind)
OR
Like I mention in the PRs, since 0.13.0 bitcoind has an rpc call named getmempoolentry which basically grabs the same information for one specific tx, and returns nothing if the tx is already confirmed or otherwise not in the mempool.

Electrum's CPFP implementation is number 1 in the examples I gave:

CPFP gathering transactions that merely gather up all the CPFP utxos periodically and send them to another address owned by the person receiving the bitcoin. This is inefficient fee-wise as it creates an extra transaction that is not an actual send (you are sending to yourself) (perhaps this is what you think CPFP is)

Which would be nice as a last-resort hidden feature for users. perhaps a long tap of the transaction on the history screen? That way if we get a "omg my transaction has been stuck for 4 days" issue we could just say "long tap and it will pay the extra fees to speed along confirmation."

I have a little tool that you plug in a watch-only copay wallet file and it calculates any current CPFP candidates and creates a txp that will send only those utxos to a new address in your same wallet. Unfortunately, I'm not at liberty to share it... :-(...

[dabura667]

Also adding here:

Starting with bitcoin core 0.13.0, a new RPC call was added called getmempoolentry

If bitcore would support >=0.13.0 bitcoin Core, then we could add support for that to make my PR for CPFP support in insight-api a lot more efficient.

bitpay/insight-api#508

bitcoin-cli getmempoolentry ebf88e8aede968e8bd70e91f2e9400523157b42af06a96a207bfeb1b18866495
{
  "size": 225,
  "fee": 0.00027120,
  "modifiedfee": 0.00027120,
  "time": 1493777210,
  "height": 464590,
  "startingpriority": 0,
  "currentpriority": 0,
  "descendantcount": 1,
  "descendantsize": 225,
  "descendantfees": 27120,
  "ancestorcount": 4,
  "ancestorsize": 902,
  "ancestorfees": 108480,
  "depends": [
    "ee466a87cd2447cd0564a1f703a145e376ab32cffd6562e19bb610b980f7d7e8"
  ]
}

[letitbegood]

A general question when using CPFP (if anyone can answer): When making sure there is enough of a fee to cover both transactions, does that include factoring in the fee on the original unconfirmed transaction? In other words, if the original transaction was for 50 cents and I wanted each transaction to be 75 cents, would I want to have $1.50 in total fees? Or would I use $1 in total fees since the original 50 cents is also included in the amount?

[chrisrico]

Since the goal is to ensure that the parent transaction confirms, you want to pay at least the normal fee, if not more, on the child transaction.

[letitbegood]

Thanks for the reply. When you say to at least pay the 'normal' fee on the parent transaction, do you mean pay this on top of the fee that was originally included? I guess I am just trying to understand if the original fee is also a part of what the miner will get? Or should I disregard that fee when considering the appropriate amount to cover both transactions?

[chrisrico]

CPFP is to solve the problem where the parent transaction did not pay a sufficient fee. So the child transaction must pay for itself and the parent. So I would choose a fee that is higher than what you would normally pay for a single transaction.

[letitbegood]

So just to clarify - does a miner look at this from that standpoint that it's 2 transactions and wants a fee high enough on each (i.e. 2x what it would be on a single transaction)? Or is it looked at as a single transaction, were I would want to include a higher fee than what I would normally pay one a single transaction, but not necessarily 2x what I would pay on a single transaction?

Thanks again.

[chrisrico]

I don't know. I think at this point most miners aren't using Bitcoin Core transaction selection algorithms. I'm pretty certain they're optimizing for total fees per block (so fee per Kb, not straight fee), and since the child can't be included without the parent, I'd think they practically view it as one transaction.

[letitbegood]

Got it, thanks.

[dabura667]

1000 byte unconfirmed tx A has 10000 satoshi fee = 10 satoshi / byte

I want to bump that up to 20 satoshi / byte, and for simplicity's sake let's say my second tx B (the child of A) is also 1000 bytes.

I need 20000 satoshi fees to make B 20 sat/byte

Since A already has 10000 sat fees, it needs 10000 sat MORE to even out to 20 sat/byte

So I need to add an additional 10000 to cover that.

If I set B fee to 30000 satoshis, then the total size for the chain of tx A and tx B is 2000 and the total fee of both is 10000 + 30000 (=40000)

40000/2000 = 20 satoshi/byte for the whole unconfirmed tree.

[dabura667]

Sometimes people chain tons of unconfirmed transactions together, so to easily find the total size of a transaction and all of its unconfirmed parents (recursive) as well as total fees you can use bitcoind's "getmempoolentry" and look at "ancestorfees" and "ancestorsize"

[letitbegood]

Thanks, makes sense. Just to confirm, for CPFP to work, do I need to spend the entire unspent amount, or just a portion of the funds?

The purchase was through Glidera and the BTC was sent to my wallet, but the fee Glidera uses is too low so it's been stuck for 2 days.

[chrisrico]

For CPFP, all you need is for the second transaction to depend on the first one, so that the only way a miner can include the second is by also including the first.

…

On Tue, May 23, 2017, 8:28 PM letitbegood ***@***.***> wrote: Thanks, makes sense. Just to confirm, for CPFP to work, do I need to spend the entire unspent amount, or just a portion of the funds? The purchase was through Glidera and the BTC was sent to my wallet, but the fee Glidera uses is too low so it's been stuck for 2 days. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/bitpay/copay/issues/5102#issuecomment-303588651>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADeQVSyO1am2qrA-ZCeT3vhwNEIh_d41ks5r84RlgaJpZM4K6IxD> .

[letitbegood]

Got it, thanks.

[gony2]

bitcoin:?r=https://bitpay.com/i/8YeMQ7uNKLiCQgSXFe2Ynm

[BGalliotti]

Hello @gony2
Thanks for reaching out to us.

Please write to the Bitpay support: https://help.bitpay.com/requestHelp bringing them a clear and detailed explanation of what your issue is. The better explained the faster we will be able to address the issue.

Our representatives are going to address your inquiry there.

We would appreciate your patience.

Thanks in advance, Kind regards.