* [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 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
* 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 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-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
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