* [bitcoin-dev] Why not Child-Pays-For-Parent? @ 2015-07-10 16:09 Richard Moore 2015-07-10 16:13 ` Jeff Garzik 2015-07-10 16:28 ` Tier Nolan 0 siblings, 2 replies; 17+ messages in thread From: Richard Moore @ 2015-07-10 16:09 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1404 bytes --] Hey guys, With all the recent congestion and discussion regarding FSS-RBF, I was wondering if there good reasons not to have CPFP as a default policy? Or is it? I was also wondering, with CPFP, should the transaction fee be based on total transactions size, or the sum of each transaction’s required fee? For example, a third transaction C whose unconfirmed utxo from transaction B has an unconfirmed utxo in transaction A (all of A’s inputs are confirmed), with each A, B and C being ~300bytes, should C’s transaction fee be 0.0001 btc for the ~1kb it is about to commit to the blockchain, or 0.0003 btc for the 3 transactions it is going to commit. I tried to test it out a few days ago, sending 0.0008 btc without any fee, then that utxo into another transaction w/ 0.0001 btc. It still hasn’t confirmed, which could be any of: a) CPFP doesn’t have enough hash power, b) the amounts are too small, c) the coins are too new, d) the fee should have actually been 0.0002 btc, e) the congestion is just too great; or some combination. Just curious as whatnot… Thanks, RicMoo .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º> Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ricmoo@geneticmistakes•com <mailto:ricmoo@geneticmistakes•com> www: http://GeneticMistakes.com <http://geneticmistakes.com/> [-- Attachment #2: Type: text/html, Size: 2651 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-10 16:09 [bitcoin-dev] Why not Child-Pays-For-Parent? Richard Moore @ 2015-07-10 16:13 ` Jeff Garzik 2015-07-10 16:25 ` Richard Moore 2015-07-10 16:28 ` Tier Nolan 1 sibling, 1 reply; 17+ messages in thread From: Jeff Garzik @ 2015-07-10 16:13 UTC (permalink / raw) To: Richard Moore; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1904 bytes --] CPFP is interesting, but it does not fully cover the case it is trying to address: If TX_a goes out without sufficient fee, sending out a new TX_b will not help TX_a suddenly reach nodes/miners that ignored TX_a. On Fri, Jul 10, 2015 at 12:09 PM, Richard Moore <me@ricmoo•com> wrote: > Hey guys, > > With all the recent congestion and discussion regarding FSS-RBF, I was > wondering if there good reasons not to have CPFP as a default policy? Or is > it? > > I was also wondering, with CPFP, should the transaction fee be based on > total transactions size, or the sum of each transaction’s required fee? For > example, a third transaction C whose unconfirmed utxo from transaction B > has an unconfirmed utxo in transaction A (all of A’s inputs are confirmed), > with each A, B and C being ~300bytes, should C’s transaction fee be 0.0001 > btc for the ~1kb it is about to commit to the blockchain, or 0.0003 btc for > the 3 transactions it is going to commit. > > I tried to test it out a few days ago, sending 0.0008 btc without any fee, > then that utxo into another transaction w/ 0.0001 btc. It still hasn’t > confirmed, which could be any of: a) CPFP doesn’t have enough hash power, > b) the amounts are too small, c) the coins are too new, d) the fee should > have actually been 0.0002 btc, e) the congestion is just too great; or some > combination. > > Just curious as whatnot… > > Thanks, > RicMoo > > .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º> > > Richard Moore ~ Founder > Genetic Mistakes Software inc. > phone: (778) 882-6125 > email: ricmoo@geneticmistakes•com > www: http://GeneticMistakes.com > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 2993 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-10 16:13 ` Jeff Garzik @ 2015-07-10 16:25 ` Richard Moore 2015-07-10 16:26 ` Dan Bryant 0 siblings, 1 reply; 17+ messages in thread From: Richard Moore @ 2015-07-10 16:25 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3177 bytes --] By ignored, do you mean the nodes/miners didn’t even include the low fee transaction in their memory pools, so would no longer have access to it? If a node decides to not include it in its memory pool for this reason, I guess it won’t send out any INV messages either? Could the broadcaster of TX_b rebroadcast TX_a? Then I guess any node that did add it to its memory pool would realize it’s not new and not rebroadcast it to those who didn’t, so it won’t propagate… Although, after receiving the orphan transaction TX_b, it could re-(pay attention) to an INV with TX_a (for a short-ish time to prevent further DoS vectors)? Assuming the sender of TX_b has a copy of TX_a… > On Jul 10, 2015, at 12:13 PM, Jeff Garzik <jgarzik@gmail•com> wrote: > > CPFP is interesting, but it does not fully cover the case it is trying to address: If TX_a goes out without sufficient fee, sending out a new TX_b will not help TX_a suddenly reach nodes/miners that ignored TX_a. > > > On Fri, Jul 10, 2015 at 12:09 PM, Richard Moore <me@ricmoo•com <mailto:me@ricmoo•com>> wrote: > Hey guys, > > With all the recent congestion and discussion regarding FSS-RBF, I was wondering if there good reasons not to have CPFP as a default policy? Or is it? > > I was also wondering, with CPFP, should the transaction fee be based on total transactions size, or the sum of each transaction’s required fee? For example, a third transaction C whose unconfirmed utxo from transaction B has an unconfirmed utxo in transaction A (all of A’s inputs are confirmed), with each A, B and C being ~300bytes, should C’s transaction fee be 0.0001 btc for the ~1kb it is about to commit to the blockchain, or 0.0003 btc for the 3 transactions it is going to commit. > > I tried to test it out a few days ago, sending 0.0008 btc without any fee, then that utxo into another transaction w/ 0.0001 btc. It still hasn’t confirmed, which could be any of: a) CPFP doesn’t have enough hash power, b) the amounts are too small, c) the coins are too new, d) the fee should have actually been 0.0002 btc, e) the congestion is just too great; or some combination. > > Just curious as whatnot… > > Thanks, > RicMoo > > .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º> > > Richard Moore ~ Founder > Genetic Mistakes Software inc. > phone: (778) 882-6125 <tel:%28778%29%20882-6125> > email: ricmoo@geneticmistakes•com <mailto:ricmoo@geneticmistakes•com> > www: http://GeneticMistakes.com <http://geneticmistakes.com/> > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev> > > .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸><(((º> Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ricmoo@geneticmistakes•com <mailto:ricmoo@geneticmistakes•com> www: http://GeneticMistakes.com <http://geneticmistakes.com/> [-- Attachment #2: Type: text/html, Size: 5296 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-10 16:25 ` Richard Moore @ 2015-07-10 16:26 ` Dan Bryant 0 siblings, 0 replies; 17+ messages in thread From: Dan Bryant @ 2015-07-10 16:26 UTC (permalink / raw) To: Richard Moore; +Cc: bitcoin-dev Some miners have voluntarily deployed CPFP. I had a thread about it earlier this month where some other ideas got tossed around. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009304.html The specific pull request to get it into the reference implementation is still open based on a merge conflict https://github.com/bitcoin/bitcoin/pull/1647 Peter Todd has another thread on RBF which you mentioned earlier http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-April/005620.html There is also a beautiful example of CPFP in action from Eligius in this transaction: https://blockchain.info/tx/4cc3e2b6407ae8cdc1fd62cb3235f9c92654277684da8970db19a0169e44c68c Follow the spent outputs and you will see the person is trying to incentive the transaction by upping the fees of dependent transactions. It set in the mempool until Eligius won a block, then it made it into the chain. CPFP still works, but only in an Eligius block (that I can see). So it's better than nothing. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-10 16:09 [bitcoin-dev] Why not Child-Pays-For-Parent? Richard Moore 2015-07-10 16:13 ` Jeff Garzik @ 2015-07-10 16:28 ` Tier Nolan 2015-07-10 16:31 ` Jeff Garzik 1 sibling, 1 reply; 17+ messages in thread From: Tier Nolan @ 2015-07-10 16:28 UTC (permalink / raw) Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 2315 bytes --] On Fri, Jul 10, 2015 at 5:09 PM, Richard Moore <me@ricmoo•com> wrote: > I was also wondering, with CPFP, should the transaction fee be based on > total transactions size, or the sum of each transaction’s required fee? For > example, a third transaction C whose unconfirmed utxo from transaction B > has an unconfirmed utxo in transaction A (all of A’s inputs are confirmed), > with each A, B and C being ~300bytes, should C’s transaction fee be 0.0001 > btc for the ~1kb it is about to commit to the blockchain, or 0.0003 btc for > the 3 transactions it is going to commit. > It should be whatever gives the highest fee. In effect, child pays for parent creates compound transactions. A: 250 bytes, 0 fee B: 300 bytes: 0.0005 fee C: 400 bytes: 0.0001 fee There are 3 combinations to consider A: 0 fee for 250 bytes = 0 per byte A&B: 0.0005 fee for 550 bytes = 0.91 uBTC per byte A&B&C: 0.0006 fee for 950 bytes = 0.63uBTC per byte This means that the A&B combination has the best fee per byte value. A&B should be added to the memory pool (if 0.91 uBTC per byte is above the threshold). Once A&B are added, then C can be reconsidered on its own. C: 0.0001 for 400 bytes = 0.25 BTC per byte If that is above the threshold, then C should be added. In practice, it isn't possible to check every combination. If there are N transactions, then checking all triple combinations costs around N cubed. A 2 pass system could get a reasonably efficient result. B is 0.0005 fee for 300 bytes = 1.67 uBTC per byte and is assumed to be a high value transaction. The algorithm would be Pass 1: Process all transactions in order of BTC per byte, until block is full If the transaction's parents are either already in the pool or a previous block, add the transaction. Pass 1: Process all non-included transactions in order of BTC per byte, until block is full If the transaction's parents are either already in the pool or a previous block, add the transaction. Otherwise, consider the transaction plus all non-included ancestors as a single transaction If this combined transaction has a higher BTC per byte than the lowest transaction(s), add the combined transaction drop the other transaction(s) [-- Attachment #2: Type: text/html, Size: 3117 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-10 16:28 ` Tier Nolan @ 2015-07-10 16:31 ` Jeff Garzik 2015-07-10 17:02 ` Justus Ranvier 2015-07-10 17:28 ` Tier Nolan 0 siblings, 2 replies; 17+ messages in thread From: Jeff Garzik @ 2015-07-10 16:31 UTC (permalink / raw) To: Tier Nolan; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 3064 bytes --] This is a good explanation but it does not address reachability. TX_a, the first tx sent out on the network, presumably has insufficient fee to get mined - which also means it did not necessarily even reach all miners. Simply sending out TX_b with added fee does not guarantee that nodes suddenly have TX_a, which they may have ignored/dropped before. On Fri, Jul 10, 2015 at 12:28 PM, Tier Nolan <tier.nolan@gmail•com> wrote: > > > On Fri, Jul 10, 2015 at 5:09 PM, Richard Moore <me@ricmoo•com> wrote: > >> I was also wondering, with CPFP, should the transaction fee be based on >> total transactions size, or the sum of each transaction’s required fee? For >> example, a third transaction C whose unconfirmed utxo from transaction B >> has an unconfirmed utxo in transaction A (all of A’s inputs are confirmed), >> with each A, B and C being ~300bytes, should C’s transaction fee be 0.0001 >> btc for the ~1kb it is about to commit to the blockchain, or 0.0003 btc for >> the 3 transactions it is going to commit. >> > > It should be whatever gives the highest fee. In effect, child pays for > parent creates compound transactions. > > A: 250 bytes, 0 fee > B: 300 bytes: 0.0005 fee > C: 400 bytes: 0.0001 fee > > There are 3 combinations to consider > > A: 0 fee for 250 bytes = 0 per byte > A&B: 0.0005 fee for 550 bytes = 0.91 uBTC per byte > A&B&C: 0.0006 fee for 950 bytes = 0.63uBTC per byte > > This means that the A&B combination has the best fee per byte value. A&B > should be added to the memory pool (if 0.91 uBTC per byte is above the > threshold). > > Once A&B are added, then C can be reconsidered on its own. > > C: 0.0001 for 400 bytes = 0.25 BTC per byte > > If that is above the threshold, then C should be added. > > In practice, it isn't possible to check every combination. If there are N > transactions, then checking all triple combinations costs around N cubed. > > A 2 pass system could get a reasonably efficient result. > > B is 0.0005 fee for 300 bytes = 1.67 uBTC per byte and is assumed to be a > high value transaction. > > The algorithm would be > > Pass 1: > Process all transactions in order of BTC per byte, until block is full > If the transaction's parents are either already in the pool or a > previous block, add the transaction. > > Pass 1: > Process all non-included transactions in order of BTC per byte, until > block is full > If the transaction's parents are either already in the pool or a > previous block, add the transaction. > > Otherwise, consider the transaction plus all non-included ancestors as > a single transaction > If this combined transaction has a higher BTC per byte than the > lowest transaction(s), > add the combined transaction > drop the other transaction(s) > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 4291 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-10 16:31 ` Jeff Garzik @ 2015-07-10 17:02 ` Justus Ranvier 2015-07-10 17:16 ` Dan Bryant 2015-07-10 17:51 ` Alex Morcos 2015-07-10 17:28 ` Tier Nolan 1 sibling, 2 replies; 17+ messages in thread From: Justus Ranvier @ 2015-07-10 17:02 UTC (permalink / raw) To: bitcoin-dev [-- Attachment #1.1: Type: text/plain, Size: 1162 bytes --] On 07/10/2015 11:31 AM, Jeff Garzik wrote: > This is a good explanation but it does not address reachability. TX_a, the > first tx sent out on the network, presumably has insufficient fee to get > mined - which also means it did not necessarily even reach all miners. > > Simply sending out TX_b with added fee does not guarantee that nodes > suddenly have TX_a, which they may have ignored/dropped before. I'm not sure why that's actually a problem. CPFP is initiated by the recipient of the parent transaction, and so if the recipient is creating this transaction in the first place they must have a copy of the parent transaction which can/should broadcast at the same time. If the child reaches a CPFP miner, then presumably the parents made it as well (any path between the sender and the miner that doesn't relay the parent should reject the child as trying to spend non-existent coins), so both of the transactions can be mined at the same time. -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ justus@openbitcoinprivacyproject•org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 [-- Attachment #1.2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 18667 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-10 17:02 ` Justus Ranvier @ 2015-07-10 17:16 ` Dan Bryant 2015-07-10 17:51 ` Alex Morcos 1 sibling, 0 replies; 17+ messages in thread From: Dan Bryant @ 2015-07-10 17:16 UTC (permalink / raw) To: Justus Ranvier; +Cc: bitcoin-dev On Fri, Jul 10, 2015 at 11:31 AM, Jeff Garzik <jgarzik@gmail•com> wrote: > This is a good explanation but it does not address reachability. TX_a, the > first tx sent out on the network, presumably has insufficient fee to get > mined - which also means it did not necessarily even reach all miners. > > Simply sending out TX_b with added fee does not guarantee that nodes > suddenly have TX_a, which they may have ignored/dropped before. True... there are two propagation thresholds... "-minrelaytxfee" (defaults to 1000 sotoshi/kbyte) and "relaypriority" (defaults to True). If -relaypriority is True, then items with a priority above 57600000 (currently <ref1>) will still be relayed, even if their TxFee is below MinRelayTxFee. Therefore even if miners are using bitcoind rules for mempool tx creation, they can still configure how and what they propagate. The flip-side of this is that a transactions priority will go up the longer it ages (in the mempool). So it would be possible (if relaypriority was on) for even a lowfee transaction to become relayable eventually simply based on relaypriority ref1: https://en.bitcoin.it/wiki/Transaction_fees On Fri, Jul 10, 2015 at 12:02 PM, Justus Ranvier <justus@openbitcoinprivacyproject•org> wrote: > CPFP is initiated by the recipient of the parent transaction, and so if > the recipient is creating this transaction in the first place they must > have a copy of the parent transaction which can/should broadcast at the > same time. > > If the child reaches a CPFP miner, then presumably the parents made it > as well (any path between the sender and the miner that doesn't relay > the parent should reject the child as trying to spend non-existent > coins), so both of the transactions can be mined at the same time. If the recipient is running a full node with incoming connections. I'm not sure if SPV clients rebroadcast both spend and receive transactions. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-10 17:02 ` Justus Ranvier 2015-07-10 17:16 ` Dan Bryant @ 2015-07-10 17:51 ` Alex Morcos 2015-07-10 19:39 ` Tier Nolan 1 sibling, 1 reply; 17+ messages in thread From: Alex Morcos @ 2015-07-10 17:51 UTC (permalink / raw) To: Justus Ranvier; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1623 bytes --] I think the biggest problem with merging CPFP right now is that at least in its current implementation it is not efficient enough in certain situations,. On Fri, Jul 10, 2015 at 1:02 PM, Justus Ranvier < justus@openbitcoinprivacyproject•org> wrote: > On 07/10/2015 11:31 AM, Jeff Garzik wrote: > > This is a good explanation but it does not address reachability. TX_a, > the > > first tx sent out on the network, presumably has insufficient fee to get > > mined - which also means it did not necessarily even reach all miners. > > > > Simply sending out TX_b with added fee does not guarantee that nodes > > suddenly have TX_a, which they may have ignored/dropped before. > > I'm not sure why that's actually a problem. > > CPFP is initiated by the recipient of the parent transaction, and so if > the recipient is creating this transaction in the first place they must > have a copy of the parent transaction which can/should broadcast at the > same time. > > If the child reaches a CPFP miner, then presumably the parents made it > as well (any path between the sender and the miner that doesn't relay > the parent should reject the child as trying to spend non-existent > coins), so both of the transactions can be mined at the same time. > > -- > Justus Ranvier > Open Bitcoin Privacy Project > http://www.openbitcoinprivacyproject.org/ > justus@openbitcoinprivacyproject•org > E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 2453 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-10 17:51 ` Alex Morcos @ 2015-07-10 19:39 ` Tier Nolan 2015-07-10 21:10 ` Luke Dashjr 0 siblings, 1 reply; 17+ messages in thread From: Tier Nolan @ 2015-07-10 19:39 UTC (permalink / raw) Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 418 bytes --] It depends on what kind of inefficiency. Inefficient could mean that it uses a lot of CPU power. If it gets a good solution rather than the best solution, it is still worth having. On Fri, Jul 10, 2015 at 6:51 PM, Alex Morcos <morcos@gmail•com> wrote: > I think the biggest problem with merging CPFP right now is that at least > in its current implementation it is not efficient enough in certain > situations,. > [-- Attachment #2: Type: text/html, Size: 775 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-10 19:39 ` Tier Nolan @ 2015-07-10 21:10 ` Luke Dashjr 2015-07-11 20:28 ` Micha Bailey 0 siblings, 1 reply; 17+ messages in thread From: Luke Dashjr @ 2015-07-10 21:10 UTC (permalink / raw) To: bitcoin-dev AFAIK the only thing holding it up is lack of unit tests. If anyone would like to implement those, I expect it'd be merged fairly soon. Then the problem is, as Jeff mentioned, getting the parent transactions relayed despite failing relay policy on their own. Luke ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-10 21:10 ` Luke Dashjr @ 2015-07-11 20:28 ` Micha Bailey 2015-07-11 21:30 ` Dan Bryant 0 siblings, 1 reply; 17+ messages in thread From: Micha Bailey @ 2015-07-11 20:28 UTC (permalink / raw) To: Luke Dashjr; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 894 bytes --] Right. The issue (AIUI) is that, right now, even though transactions are evaluated for inclusion as a group with CPFP, they're not yet evaluated for relaying as a unit, nor can they be, because the current p2p protocol doesn't have a way to send multiple transactions in a single protocol message to signify that they should be evaluated together. On Saturday, July 11, 2015, Luke Dashjr <luke@dashjr•org> wrote: > AFAIK the only thing holding it up is lack of unit tests. If anyone would > like > to implement those, I expect it'd be merged fairly soon. Then the problem > is, > as Jeff mentioned, getting the parent transactions relayed despite failing > relay policy on their own. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org <javascript:;> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 1303 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-11 20:28 ` Micha Bailey @ 2015-07-11 21:30 ` Dan Bryant 2015-07-11 22:29 ` Jeff Garzik 2015-07-11 23:19 ` Tier Nolan 0 siblings, 2 replies; 17+ messages in thread From: Dan Bryant @ 2015-07-11 21:30 UTC (permalink / raw) To: Micha Bailey; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 917 bytes --] I think a compromise will be somewhere in the middle. I think most people would be OK with TXs that don't have enough fees for P2P transfer to stay in deadmans land. Most people are stuck in a situation where they payed enough to get it into (and keep it in) the pool, but not enough to get it out. If we could get CPFP that only worked on TXs that met the minimum threshold for peer propagation, then I think we would be in much better position to battle this spam flood. On Sat, Jul 11, 2015 at 3:28 PM, Micha Bailey <michabailey@gmail•com> wrote: > Right. The issue (AIUI) is that, right now, even though transactions are > evaluated for inclusion as a group with CPFP, they're not yet evaluated for > relaying as a unit, nor can they be, because the current p2p protocol > doesn't have a way to send multiple transactions in a single protocol > message to signify that they should be evaluated together. > > [-- Attachment #2: Type: text/html, Size: 1369 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-11 21:30 ` Dan Bryant @ 2015-07-11 22:29 ` Jeff Garzik 2015-07-12 10:18 ` Matt Whitlock 2015-07-11 23:19 ` Tier Nolan 1 sibling, 1 reply; 17+ messages in thread From: Jeff Garzik @ 2015-07-11 22:29 UTC (permalink / raw) To: DKBryant; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1295 bytes --] It sounds like you are seeking transaction expiration from the mempool, not CPFP. On Sat, Jul 11, 2015 at 4:30 PM, Dan Bryant <dkbryant@gmail•com> wrote: > I think a compromise will be somewhere in the middle. I think most people > would be OK with TXs that don't have enough fees for P2P transfer to stay > in deadmans land. Most people are stuck in a situation where they payed > enough to get it into (and keep it in) the pool, but not enough to get it > out. > > If we could get CPFP that only worked on TXs that met the minimum > threshold for peer propagation, then I think we would be in much better > position to battle this spam flood. > > On Sat, Jul 11, 2015 at 3:28 PM, Micha Bailey <michabailey@gmail•com> > wrote: > >> Right. The issue (AIUI) is that, right now, even though transactions are >> evaluated for inclusion as a group with CPFP, they're not yet evaluated for >> relaying as a unit, nor can they be, because the current p2p protocol >> doesn't have a way to send multiple transactions in a single protocol >> message to signify that they should be evaluated together. >> >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > [-- Attachment #2: Type: text/html, Size: 2221 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-11 22:29 ` Jeff Garzik @ 2015-07-12 10:18 ` Matt Whitlock 0 siblings, 0 replies; 17+ messages in thread From: Matt Whitlock @ 2015-07-12 10:18 UTC (permalink / raw) To: Jeff Garzik; +Cc: bitcoin-dev I keep seeing (on /r/bitcoin) mentions of a 24-hour or 48-hour (varying accounts) interval at which miners clear their mempools. Is this a matter of local policy or something Bitcoin Core does by design? On Saturday, 11 July 2015, at 5:29 pm, Jeff Garzik wrote: > It sounds like you are seeking transaction expiration from the mempool, not > CPFP. > > On Sat, Jul 11, 2015 at 4:30 PM, Dan Bryant <dkbryant@gmail•com> wrote: > > > I think a compromise will be somewhere in the middle. I think most people > > would be OK with TXs that don't have enough fees for P2P transfer to stay > > in deadmans land. Most people are stuck in a situation where they payed > > enough to get it into (and keep it in) the pool, but not enough to get it > > out. > > > > If we could get CPFP that only worked on TXs that met the minimum > > threshold for peer propagation, then I think we would be in much better > > position to battle this spam flood. > > > > On Sat, Jul 11, 2015 at 3:28 PM, Micha Bailey <michabailey@gmail•com> > > wrote: > > > >> Right. The issue (AIUI) is that, right now, even though transactions are > >> evaluated for inclusion as a group with CPFP, they're not yet evaluated for > >> relaying as a unit, nor can they be, because the current p2p protocol > >> doesn't have a way to send multiple transactions in a single protocol > >> message to signify that they should be evaluated together. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-11 21:30 ` Dan Bryant 2015-07-11 22:29 ` Jeff Garzik @ 2015-07-11 23:19 ` Tier Nolan 1 sibling, 0 replies; 17+ messages in thread From: Tier Nolan @ 2015-07-11 23:19 UTC (permalink / raw) Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1189 bytes --] On Sat, Jul 11, 2015 at 10:30 PM, Dan Bryant <dkbryant@gmail•com> wrote: > I think a compromise will be somewhere in the middle. I think most people > would be OK with TXs that don't have enough fees for P2P transfer to stay > in deadmans land. Most people are stuck in a situation where they payed > enough to get it into (and keep it in) the pool, but not enough to get it > out. > Agreed. A lot of the functionality could be achieved by a system that works in most cases. Even if 100 transaction chains aren't supported, 3-5 transaction chains would give a significant fraction of the desired functionality. At the moment, a transaction is only added into the memory pool if it meets the relay threshold and spends transactions that are either in the memory pool or in a block. There is an orphan pool that can store up to 100 orphans. The same could be done for child pays for parent. A node could remember the last 100 transactions (up to 5000 bytes) that were rejected from the memory pool due to insufficient relay fees. This allows nodes to send a chain of transactions in a row. If the child is sent last, then the parent(s) will be in the unrelayed transaction pool. [-- Attachment #2: Type: text/html, Size: 1639 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: [bitcoin-dev] Why not Child-Pays-For-Parent? 2015-07-10 16:31 ` Jeff Garzik 2015-07-10 17:02 ` Justus Ranvier @ 2015-07-10 17:28 ` Tier Nolan 1 sibling, 0 replies; 17+ messages in thread From: Tier Nolan @ 2015-07-10 17:28 UTC (permalink / raw) Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1072 bytes --] On Fri, Jul 10, 2015 at 5:31 PM, Jeff Garzik <jgarzik@gmail•com> wrote: > This is a good explanation but it does not address reachability. TX_a, > the first tx sent out on the network, presumably has insufficient fee to > get mined - which also means it did not necessarily even reach all miners. > > Simply sending out TX_b with added fee does not guarantee that nodes > suddenly have TX_a, which they may have ignored/dropped before. > When the peer adds both parent and child to the memory pool, it should forward both of them. CPFP inherently requires that nodes keep transactions that they have rejected due to low fees. If peers requested parents, then it would be possible to forward them onwards. If a node receives a high-fee transaction and doesn't have the parent, it could request the parent. Spam protection could be handled by banning nodes which send lots of "children" and then never having the parent to the transaction. The rule would be that forwarding a transaction means that you have all its parents back to transactions contained in blocks. [-- Attachment #2: Type: text/html, Size: 1684 bytes --] ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2015-07-12 10:18 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-07-10 16:09 [bitcoin-dev] Why not Child-Pays-For-Parent? Richard Moore 2015-07-10 16:13 ` Jeff Garzik 2015-07-10 16:25 ` Richard Moore 2015-07-10 16:26 ` Dan Bryant 2015-07-10 16:28 ` Tier Nolan 2015-07-10 16:31 ` Jeff Garzik 2015-07-10 17:02 ` Justus Ranvier 2015-07-10 17:16 ` Dan Bryant 2015-07-10 17:51 ` Alex Morcos 2015-07-10 19:39 ` Tier Nolan 2015-07-10 21:10 ` Luke Dashjr 2015-07-11 20:28 ` Micha Bailey 2015-07-11 21:30 ` Dan Bryant 2015-07-11 22:29 ` Jeff Garzik 2015-07-12 10:18 ` Matt Whitlock 2015-07-11 23:19 ` Tier Nolan 2015-07-10 17:28 ` Tier Nolan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox