Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
Breadwallet also implements CPFP when spending unconfirmed non-change inputs. It was released back in May, but happy to let Andreas have the bounty: https://github.com/voisine/breadwallet/blob/v0.5.1/BreadWallet/BRWallet.m#L382 Aaron Voisine co-founder and CEO breadwallet.com On Wed, Jul 15, 2015 at 9:26 AM, Dan Bryant via bitcoin-dev bitcoin-dev@lists.linuxfoundation.org wrote: Offering a bounty for this feature Specifically... Anyone who can put a CPFP transaction creation feature into any wallet featured on the bitcoin homepage (ref1) can claim this bounty. The funds are being raised by donation. The funds will be dispersed from the following address when the bounty is claimed: 3FEUByMeaxrNmBCVYjvsnhyAjiUdat5i7M Currently there isn't much in there, but I welcome angels to fill the bucket. Here's proof that the multisig address is not 1 of 1: https://bitcointalk.org/index.php?topic=1122956.0 Bounty announce: https://bitcointalk.org/index.php?topic=1123464.0 ref1: https://bitcoin.org/en/choose-your-wallet ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
Do you have any idea how much hashing power is using CPFP? It's a useful metric for wallet developers to know what sort of confirmation times they might be able to get when attempting to use it. Aaron Voisine co-founder and CEO breadwallet.com On Sun, Jul 5, 2015 at 9:24 PM, Luke Dashjr l...@dashjr.org wrote: On Monday, July 06, 2015 4:14:14 AM Dan Bryant wrote: When I wrote the BIP proposal I was assuming (incorrectly) that CPFP TX selection was already being done by miners, No, this is correct. It's just not included in the reference policy. Miners are not expected to use the reference policy as-is, and some of them do in fact use CPFP. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote: This is called child pays for parent and there is a three year old pull request implementing it: https://github.com/bitcoin/bitcoin/pull/1647 Understood... When I wrote the BIP proposal I was assuming (incorrectly) that CPFP TX selection was already being done by miners, but I see now that certain trees could bloom the TX selection latency as miners would need to be more dependency aware. Perhaps the BIP66 orphan block chain shows that some miners may not always be counted on to ensure that all TX stuffed in a block have dependencies met. Certainly not until the PR1647 is fully merged and deployed. On Wed, Jul 1, 2015 at 11:57 PM, Matt Whitlock b...@mattwhitlock.name wrote: PR#1647 only addresses miner policy, though, right? I believe the BIP is addressing the user-facing side of this functionality. CPFP mining policy does very little good if wallets don't offer any way for users to goose up incoming transactions. On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote: The points regarding sweep transaction UI is out of scope for a BIP I'm afraid. I suggest talking with wallet authors, and if agreement can be found writing a pull request. Yes... although I certainly admit, I didn't know about CPFP or I would have called it out as a requirement for this UI enhancement request. I'll see if I can't get some wallet authors interested in this as a feature enhancement when PR1647 commits. Perhaps there are risks raised if CPFP is not enabled but these sweep tx enter the mempool. If miners take the high fee children but ignore the low fee parents then the child might enter the blockchain without the parent. If miners were light on block validation, wouldn't it be possible that the child may go forward with many confirmations, while the parent patiently waits in the mempool? This could be bad since spending the child may look good, as it might have many confirmations, while its parent has few. On Fri, Jul 3, 2015 at 4:56 PM, Peter Todd p...@petertodd.org wrote: Replace-by-fee scorched-earth without child-pays-for-parent, Peter Todd, Bitcoin-development mailing list, Apr 28th 2014 http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html Very good! So if I follow, RPF can work one of two ways: In the countermeasure form, spender gives receiver a partially signed countermeasure transactions with juiced up fees. In the anyonecanpay form, spender signs the transaction with ANYONECANPAY bit allowing the reviver to add fees at will. One question I did have about RBF is this.. Is it correct to presume that the spender doesn't send the incomplete countermeasure transaction to the network? If they did, wouldn't they get flagged on DoS code banning them from peers? Corollary question. If the countermeasure transaction is not broadcast, is it sent to the receiver via back channel (email, etc) I'll try to clean up the draft BIP to include CPFP dependencies and RBF capabilities. Whether it belongs in a BIP or a PR, its just a doc to outline my thoughts at this point. Not burning a whole in my head, so may take some time. Thx. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
On Monday, July 6, 2015, Dan Bryant dkbry...@gmail.com wrote: On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote: This is called child pays for parent and there is a three year old pull request implementing it: https://github.com/bitcoin/bitcoin/pull/1647 Understood... When I wrote the BIP proposal I was assuming (incorrectly) that CPFP TX selection was already being done by miners, but I see now that certain trees could bloom the TX selection latency as miners would need to be more dependency aware. Perhaps the BIP66 orphan block chain shows that some miners may not always be counted on to ensure that all TX stuffed in a block have dependencies met. Certainly not until the PR1647 is fully merged and deployed. On Wed, Jul 1, 2015 at 11:57 PM, Matt Whitlock b...@mattwhitlock.name javascript:; wrote: PR#1647 only addresses miner policy, though, right? I believe the BIP is addressing the user-facing side of this functionality. CPFP mining policy does very little good if wallets don't offer any way for users to goose up incoming transactions. On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote: The points regarding sweep transaction UI is out of scope for a BIP I'm afraid. I suggest talking with wallet authors, and if agreement can be found writing a pull request. Yes... although I certainly admit, I didn't know about CPFP or I would have called it out as a requirement for this UI enhancement request. I'll see if I can't get some wallet authors interested in this as a feature enhancement when PR1647 commits. Perhaps there are risks raised if CPFP is not enabled but these sweep tx enter the mempool. If miners take the high fee children but ignore the low fee parents then the child might enter the blockchain without the parent. If miners were light on block validation, wouldn't it be possible that the child may go forward with many confirmations, while the parent patiently waits in the mempool? This could be bad since spending the child may look good, as it might have many confirmations, while its parent has few. A child is a transaction that spends outputs of another transaction, the parent. The child cannot be confirmed before the parent, because the outputs being spent do not yet exist. On Fri, Jul 3, 2015 at 4:56 PM, Peter Todd p...@petertodd.org javascript:; wrote: Replace-by-fee scorched-earth without child-pays-for-parent, Peter Todd, Bitcoin-development mailing list, Apr 28th 2014 http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html Very good! So if I follow, RPF can work one of two ways: In the countermeasure form, spender gives receiver a partially signed countermeasure transactions with juiced up fees. In the anyonecanpay form, spender signs the transaction with ANYONECANPAY bit allowing the reviver to add fees at will. One question I did have about RBF is this.. Is it correct to presume that the spender doesn't send the incomplete countermeasure transaction to the network? If they did, wouldn't they get flagged on DoS code banning them from peers? A transaction that is not completely signed won't be relayed, correct, and it cannot be mined. Corollary question. If the countermeasure transaction is not broadcast, is it sent to the receiver via back channel (email, etc) I'll try to clean up the draft BIP to include CPFP dependencies and RBF capabilities. Whether it belongs in a BIP or a PR, its just a doc to outline my thoughts at this point. Not burning a whole in my head, so may take some time. Thx. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org javascript:; https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
On Monday, July 06, 2015 4:14:14 AM Dan Bryant wrote: When I wrote the BIP proposal I was assuming (incorrectly) that CPFP TX selection was already being done by miners, No, this is correct. It's just not included in the reference policy. Miners are not expected to use the reference policy as-is, and some of them do in fact use CPFP. Luke ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
On Wed, Jul 01, 2015 at 09:52:57PM -0700, Mark Friedenbach wrote: This is called child pays for parent and there is a three year old pull request implementing it: https://github.com/bitcoin/bitcoin/pull/1647 CPFP probably needs changes to the P2P layer to be able to support RBF scorched earth well unfortunately, as currently transactions are processed individually and out of context. In the RBF case you'd need to keep previously removed transactions in a buffer and evaluate new transactions against that buffer - relatively complex. The other big issue is that existing wallets don't appear to be very good at preventing double-spends. There's lots of edge cases where transations aren't recorded correctly, like crashes, shutting down unexpected etc. and in those cases there's a high chance of the wallet sending a double-spend by accident. There's also coinjoin to consider - plainly incompatible. With scorched-earth this will lead to losses. Fortunately you can implement scorched-earth using SIGHASH_ANYONECANPAY instead on an opt-in basis, which wallets could add only if they've taken the special engineering considerations into account first: Replace-by-fee scorched-earth without child-pays-for-parent, Peter Todd, Bitcoin-development mailing list, Apr 28th 2014 http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html For the OP: I'd be interested in pursuing this further. -- 'peter'[:-1]@petertodd.org 15665ce75a321e5827cdf9af667eaa75aaeefbc315514da5 signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
PR#1647 only addresses miner policy, though, right? I believe the BIP is addressing the user-facing side of this functionality. CPFP mining policy does very little good if wallets don't offer any way for users to goose up incoming transactions. On Wednesday, 1 July 2015, at 9:52 pm, Mark Friedenbach wrote: This is called child pays for parent and there is a three year old pull request implementing it: https://github.com/bitcoin/bitcoin/pull/1647 The points regarding sweep transaction UI is out of scope for a BIP I'm afraid. I suggest talking with wallet authors, and if agreement can be found writing a pull request. On Jul 1, 2015 9:44 PM, Dan Bryant dkbry...@gmail.com wrote: This is a process BIP request to add functionality to the Bitcoin-Core reference implementation. If accepted, this could also add flexibility into any future fee schedules. https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] REQ BIP # / Discuss - Sweep incoming unconfirmed transactions with a bounty.
This is called child pays for parent and there is a three year old pull request implementing it: https://github.com/bitcoin/bitcoin/pull/1647 The points regarding sweep transaction UI is out of scope for a BIP I'm afraid. I suggest talking with wallet authors, and if agreement can be found writing a pull request. On Jul 1, 2015 9:44 PM, Dan Bryant dkbry...@gmail.com wrote: This is a process BIP request to add functionality to the Bitcoin-Core reference implementation. If accepted, this could also add flexibility into any future fee schedules. https://github.com/d4n13/bips/blob/master/bip-00nn.mediawiki Note, left the formatting in, since mediawiki is a fairly light markup. == pre BIP: nn Title: Sweep unconfirmed transactions by including their outputs in high fee transactions Author: Dan Bryant dkbry...@gmail.com Status: Draft Type: Process Created: 2015-07-01 /pre ==Abstract== This BIP describes an enhancement to the reference client that addresses the need incentive inclusion of unconfirmed transactions. This method will create new high fee (or bounty) transactions that spend the desired unconfirmed transactions. To claim the high fee (bounty) transactions, miners will need to include the desired unconfirmed transactions. ==Motivation== There are times when an individual receives a payment from someone that is in a poorly crafted transaction. This transaction may include no fees, or insufficient fees to be included by many miners. The recipient would be willing to pay a nominal transaction fee to have the payment transaction swept into the next block, but has no simple way to craft this incentive. This BIP could be highly desirable for merchants who may have little control over the type of wallets their customers use. A merchant will want to ensure that all POS transactions to their hot wallet be given a high probability of inclusion in the next block. This BIP would allow the merchant to sweep all their POS transactions currently in the mempool into one high fee sweep, thus greatly increasing the chance that they are in the next block. Although many wallets have the ability to tailor the transaction fees of payments that are sent, this BIP is unique in the sense that it allows people to offer a bounty for transactions that are incoming. ==Specification== This BIP would have two implementations; an automatic sweep of incoming unconfirmed transaction setting, and a manual sweep of unconfirmed transaction setting. Both would have the ability to set the fee amount the user would like to pay for the sweep. Automatic sweep of incoming unconfirmed transactions An automatic sweep configuration may be ideal for merchants who want to ensure that their incoming transactions are not skipped over by miners. An automatic sweep setting would consist of four fields, tt'''sweep_fee'''/tt, tt'''skipped_count'''/tt, and tt'''btc_threshold'''/tt Currently, the standard transaction fee is 0.0001 BTC, a generous sweep bounty would be 0.001 BTC. Skipped-count will control the age of unconfirmed transactions to include in the sweep. If skipped-count is set to three, then any incoming transaction that remains unconfirmed for 3 blocks would trigger a sweep. A skipped-count of 0 would trigger a sweep whenever any transaction is skipped, or if it reaches an age of 10 minutes, regardless of how long the current block is taking. As a safeguard to paying a bounty for small dust transactions, a minimum btc-threshold would be required for any automatic configuration. A good starting threshold would be 0.10 BTC. These automatic settings would allow a wallet implementing this BIP to automatically perform a sweep of unconfirmed transactions whenever more than 0.10 BTC of incoming transactions were detected in the mempool. Furthermore, no more than one automatic sweep would be performed in any 10 minute window. Whenever a sweep is triggered, all incoming unconfirmed transactions should be swept, not simply the ones that triggered the sweep. These would include new transactions as well as dust transactions. Each sweep transaction would go to a new wallet address since recycling wallet addresses is poor practice. Manual sweep of incoming unconfirmed transactions A manual sweep of incoming unconfirmed transactions would be a special type of Send in the current reference implementation. A manual sweep would auto-fill a send transaction with all currently unconfirmed incoming transactions in the mempool. The fee field would be completely settable by the user and would auto-fill with the suggestions of 0.001 BTC A manual sweep would also be available as a context option when selecting any unconfirmed transaction. ==Compatibility== Wallet software that does not support this BIP will continue to operate without modification. ==Examples== pre //unconf_tx =
