-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Child Pays For Parent Support #5102
Comments
Implementing this would be much easier if the info from An example:
So if I needed to spend this transaction's output as an input, I would just calculate:
then just add it on to the absolute fee calculated for your current transaction. The UI could be something like:
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? |
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. |
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. |
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. |
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>
.
|
@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. |
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>
.
|
CPFP logic should ONLY trigger IF:
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:
Also there are two types of CPFP I have made:
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... |
FYI, Electrum has implemented a simple CPFP implementation. Also I have made a few pull requests: These could easily be pulled in to current bitcored (<0.13.0 bitcoind) Electrum's CPFP implementation is number 1 in the examples I gave:
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... :-(... |
Also adding here: Starting with bitcoin core 0.13.0, a new RPC call was added called 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.
|
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? |
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. |
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? |
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. |
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. |
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. |
Got it, thanks. |
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. |
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" |
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. |
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>
.
|
Got it, thanks. |
bitcoin:?r=https://bitpay.com/i/8YeMQ7uNKLiCQgSXFe2Ynm |
Hello @gony2 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. |
To all Bitcoin wallet makers: Please include CPFP as standard - both TX and RX wise
There are some good thoughts in the comments section as well.
The text was updated successfully, but these errors were encountered: