On Monday, July 6, 2015, Dan Bryant 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 > 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 > 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 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >