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.