Why not Child-Pays-For-Parent?
17 messages, 10 to 12 Jul 2015. Started by Richard Moore.
Tier Nolan (4), Jeff Garzik (3), Dan Bryant (3), Richard Moore (2), Justus Ranvier, Alex Morcos, Luke Dashjr, Micha Bailey, +1 more
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/>
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:
Quoted text (41 lines)
> 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 > >
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…
Quoted text (33 lines)
> 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/>
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.
On Fri, Jul 10, 2015 at 5:09 PM, Richard Moore <me@ricmoo•com> wrote:
Quoted text (8 lines)
> 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)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:
Quoted text (72 lines)
> > > 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 > >
On 07/10/2015 11:31 AM, Jeff Garzik wrote:
Quoted text (6 lines)
> 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.
On Fri, Jul 10, 2015 at 11:31 AM, Jeff Garzik <jgarzik@gmail•com> wrote:
Quoted text (6 lines)
> 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:
Quoted text (9 lines)
> 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.
On Fri, Jul 10, 2015 at 5:31 PM, Jeff Garzik <jgarzik@gmail•com> wrote:
Quoted text (7 lines)
> 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.
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:
Quoted text (34 lines)
> 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 > >
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:
Quoted text (4 lines)
> 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,. >
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
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:
Quoted text (13 lines)
> 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 >
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:
Quoted text (7 lines)
> 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. > >
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:
Quoted text (28 lines)
> 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 > >
On Sat, Jul 11, 2015 at 10:30 PM, Dan Bryant <dkbryant@gmail•com> wrote:
Quoted text (6 lines)
> 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.
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:
Quoted text (23 lines)
> 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.