đź“… Original date posted:2021-05-29
đź“ť Original message:Sounds really interesting, thanks. Making CPFP reliable would be very nice
in my opinion.
On Sat, May 29, 2021, 14:24 Antoine Riard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Mark and Clara,
>
> Great research, thanks for it!
>
> Few questions out of mind after a first read.
>
> > This approach enables block building to consider Child Pays For Parent
> (CPFP) constellations.
>
> I think that's a really interesting point, it's likely that such
> transaction graphs with multiple disjunctive branches become far more
> regular in the future. One can think about OP_CTV's style
> congestion-tree, LN's splicing or chain of coinjoins. If this phenomenon
> happens, can you expect CSB feerate perf to improve ?
>
> > CSB is more complex and requires more computation
>
> Let's say a malicious miner identifies and connects to its competitors'
> mempools then starts to broadcast to them hard-to-traverse CPFP
> constellations. Doing so, this malicious miner would prevent them either
> from assembling block templates at all or slow down their assemblage
> computation enough to gain an advantage in fee collection. Following
> current mempools limits, it would be relevant to know by how much CSB makes
> that kind of DoS possible/efficient.
>
> > From the point of view of global blockspace demand, if miners generally
> became DPFA-sensitive,
> it could encourage creation of additional transactions for the sole
> purpose of bumping stuck ancestors.
>
> As ASB's ancestor set and CSB's candidate set, a fee bidder, we'll have to
> pay the feerate to cover the new transaction fields, high enough to catch
> up with the already-present feerate set ? Likely more feerate efficient to
> RBF the first child, though you have to swallow the replacement feerate
> penalty (default 1 sat/vbyte iirc)
>
> Antoine
>
> Le mar. 25 mai 2021 Ă 10:34, Murch via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> a Ă©crit :
>
>> Hi Bitcoin Devs,
>>
>> We are writing to share with you a suggested improvement to the current
>> bitcoin core block building algorithm. In short, currently Bitcoin Core
>> uses a straightforward greedy algorithm which evaluates each
>> transaction’s effective fee rate in the context of its unconfirmed
>> ancestors. This overlooks situations in which multiple descendant
>> transactions could be grouped with their shared ancestors to form a more
>> attractive transaction set for block inclusion.
>>
>> For example, if we have 4 transactions A,B,C, and D, with fee rates and
>> weights as follows
>>
>> Tx Fee Weight
>> A 5 1
>> B 10 1
>> C 15 1
>> D 14 1
>>
>> And dependencies:
>> • B is a descendant of A
>> • C is a descendant of B
>> • D is a descendant of A
>> The current algorithm will consider {A,B,C} best which has an effective
>> fee rate of 10. Our suggested algorithm will also consider {A,B,C,D},
>> which has an effective fee rate of 11.
>>
>> Experimental data shows that our suggested algorithm did better on more
>> than 94% of blocks (99% for times of high congestion). We have also
>> compared the results to CBC and SAT Linear Programming solvers. The LP
>> solvers did slightly better, at the price of longer running times. Greg
>> Maxwell has also studied LP solvers in the past, and his results suggest
>> that better running times are possible.
>>
>> The full details are given in this document, and we are happy to hear
>> any comment, critic or suggestion!
>>
>> Best,
>> Mark and Clara
>>
>> Full details:
>>
>> https://gist.github.com/Xekyo/5cb413fe9f26dbce57abfd344ebbfaf2#file-candidate-set-based-block-building-md
>>
>> Research Code:
>> https://github.com/Xekyo/blockbuilding
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210529/e817c2eb/attachment.html>;
Jorge TimĂłn [ARCHIVE] /
npub1fx…cl2d8
2023-06-07 22:54:07
in reply to nevent1q…z9a6
Author Public Key
npub1fx98zxt3lzspjs5f4msr0fxysx5euucm29ghysryju7vpc9j0jzqtcl2d8Published at
2023-06-07 22:54:07Event JSON
{
"id": "56babb0118ba0ee8af659f2aa29928eb9b9fe74634c9b222b33392eac5799827",
"pubkey": "498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84",
"created_at": 1686178447,
"kind": 1,
"tags": [
[
"e",
"9c9197103990b8dbfafd668ee8928a1d95368a445acb222938d299e777b530ef",
"",
"root"
],
[
"e",
"fdc483bf8976efff3f35ad4665778f206aa0657f5f6cdfd388de8102ff2aab4d",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2021-05-29\n📝 Original message:Sounds really interesting, thanks. Making CPFP reliable would be very nice\nin my opinion.\n\nOn Sat, May 29, 2021, 14:24 Antoine Riard via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi Mark and Clara,\n\u003e\n\u003e Great research, thanks for it!\n\u003e\n\u003e Few questions out of mind after a first read.\n\u003e\n\u003e \u003e This approach enables block building to consider Child Pays For Parent\n\u003e (CPFP) constellations.\n\u003e\n\u003e I think that's a really interesting point, it's likely that such\n\u003e transaction graphs with multiple disjunctive branches become far more\n\u003e regular in the future. One can think about OP_CTV's style\n\u003e congestion-tree, LN's splicing or chain of coinjoins. If this phenomenon\n\u003e happens, can you expect CSB feerate perf to improve ?\n\u003e\n\u003e \u003e CSB is more complex and requires more computation\n\u003e\n\u003e Let's say a malicious miner identifies and connects to its competitors'\n\u003e mempools then starts to broadcast to them hard-to-traverse CPFP\n\u003e constellations. Doing so, this malicious miner would prevent them either\n\u003e from assembling block templates at all or slow down their assemblage\n\u003e computation enough to gain an advantage in fee collection. Following\n\u003e current mempools limits, it would be relevant to know by how much CSB makes\n\u003e that kind of DoS possible/efficient.\n\u003e\n\u003e \u003e From the point of view of global blockspace demand, if miners generally\n\u003e became DPFA-sensitive,\n\u003e it could encourage creation of additional transactions for the sole\n\u003e purpose of bumping stuck ancestors.\n\u003e\n\u003e As ASB's ancestor set and CSB's candidate set, a fee bidder, we'll have to\n\u003e pay the feerate to cover the new transaction fields, high enough to catch\n\u003e up with the already-present feerate set ? Likely more feerate efficient to\n\u003e RBF the first child, though you have to swallow the replacement feerate\n\u003e penalty (default 1 sat/vbyte iirc)\n\u003e\n\u003e Antoine\n\u003e\n\u003e Le mar. 25 mai 2021 à 10:34, Murch via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\u003e\n\u003e\u003e Hi Bitcoin Devs,\n\u003e\u003e\n\u003e\u003e We are writing to share with you a suggested improvement to the current\n\u003e\u003e bitcoin core block building algorithm. In short, currently Bitcoin Core\n\u003e\u003e uses a straightforward greedy algorithm which evaluates each\n\u003e\u003e transaction’s effective fee rate in the context of its unconfirmed\n\u003e\u003e ancestors. This overlooks situations in which multiple descendant\n\u003e\u003e transactions could be grouped with their shared ancestors to form a more\n\u003e\u003e attractive transaction set for block inclusion.\n\u003e\u003e\n\u003e\u003e For example, if we have 4 transactions A,B,C, and D, with fee rates and\n\u003e\u003e weights as follows\n\u003e\u003e\n\u003e\u003e Tx Fee Weight\n\u003e\u003e A 5 1\n\u003e\u003e B 10 1\n\u003e\u003e C 15 1\n\u003e\u003e D 14 1\n\u003e\u003e\n\u003e\u003e And dependencies:\n\u003e\u003e • B is a descendant of A\n\u003e\u003e • C is a descendant of B\n\u003e\u003e • D is a descendant of A\n\u003e\u003e The current algorithm will consider {A,B,C} best which has an effective\n\u003e\u003e fee rate of 10. Our suggested algorithm will also consider {A,B,C,D},\n\u003e\u003e which has an effective fee rate of 11.\n\u003e\u003e\n\u003e\u003e Experimental data shows that our suggested algorithm did better on more\n\u003e\u003e than 94% of blocks (99% for times of high congestion). We have also\n\u003e\u003e compared the results to CBC and SAT Linear Programming solvers. The LP\n\u003e\u003e solvers did slightly better, at the price of longer running times. Greg\n\u003e\u003e Maxwell has also studied LP solvers in the past, and his results suggest\n\u003e\u003e that better running times are possible.\n\u003e\u003e\n\u003e\u003e The full details are given in this document, and we are happy to hear\n\u003e\u003e any comment, critic or suggestion!\n\u003e\u003e\n\u003e\u003e Best,\n\u003e\u003e Mark and Clara\n\u003e\u003e\n\u003e\u003e Full details:\n\u003e\u003e\n\u003e\u003e https://gist.github.com/Xekyo/5cb413fe9f26dbce57abfd344ebbfaf2#file-candidate-set-based-block-building-md\n\u003e\u003e\n\u003e\u003e Research Code:\n\u003e\u003e https://github.com/Xekyo/blockbuilding\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210529/e817c2eb/attachment.html\u003e",
"sig": "98fd35454dd2cd810b895a1ffdfea66e65c2dbaa621ea1daab0a61cb1b78dd21ded461f631dd6ee130e8411388596bbacc7e2e23d769b9e85060c41f91834ef4"
}