Eric Voskuil [ARCHIVE] on Nostr: đź“… Original date posted:2022-05-24 đź“ť Original message:The set of txs is the ...
đź“… Original date posted:2022-05-24
đź“ť Original message:The set of txs is the graph. Anything else would just reproduce the tx graph which must be traversed in any case.
Similarly the set of txs is the fee, the sigops, the size, and the weight. The only information required by packaging is the association of the txs with each other for the purpose of aggregate (vs. individual) net reward consideration.
Since a package can only be reasonably considered for a single block, there is a natural effective limit on acceptable package size. Since any number of individual txs may be transmitted, and the size/weight/sigops of one tx is bounded only by block validity, there is no reason to put any other constraints on packages. A package is just a set of txs that may fit into a block and may collectively be worth mining. A rational package is just a block or compact block without the header. Making it any more than that is unnecessary complexity.
If parts of a package satisfy profitability constraints, they will be accepted/mined and if other parts do not, they will be rejected. There’s no preventing this.
The only pertinent feature missing in the p2p protocol is the ability to associate a set of txs for consideration, where the set (or subset) may satisfy profitability constraints that would not be satisfied if the txs were considered individually.
e
> On May 24, 2022, at 16:21, Gloria Zhao via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 
> Hi aj,
>
> > If you've got (A,B,C,X) where B spends A and X spends A,B,C where X+C is below fee floor while A+B and A+B+C+X are above fee floor you have the problem though.
>
> To clarify, in this situation, I'm imagining something like
> A: 0 sat, 100vB
> B: 1500 sat, 100vB
> C: 0 sat, 100vB
> X: 500 sat, 100vB
> feerate floor is 3sat/vB
>
> With the algo:
> > * is X alone above my fee rate? no, then forget it
> > * otherwise, s := X.size, f := X.fees, R := [X]
> > * for P = P1..Pn:
> > * do I already have P? then skip to the next parent
> > * s += P.size, f += P.fees, R += [P]
> > * if f/s above my fee rate floor? if so, request all the txs in R
>
> We'd erroneously ask for A+B+C+X, but really we should only take A+B.
> But wouldn't A+B also be a package that was announced for B?
> Please lmk if you were imagining something different. I think I may be missing something.
>
> > Is it plausible to add the graph in?
>
> Fun to think about. Most basic design would be to represent {spends, doesn’t spend} for a previous transaction in the package as a bit. Can think of it as a matrix where row i, column j tells you whether Tx j (directly) spends Tx i.
> But of course you can omit the last row, since the child spends all of them. And since topological ordering is a requirement, you only need as many bits as there are transactions preceding this one in the package.
> If you have up to 24 parents, you need 1 + 2 + ... + 23 bits to codify spending for the 2nd ... 24th parent. For a maximum 25 transactions, 23*24/2 = 276, seems like 36 bytes for a child-with-parents package. A few more for tx-with-ancestors.
> Then you can split it up into sub-packages and everything. Still not sure if we really need to.
>
> Also side note, since there are no size/count params, wondering if we should just have "version" in "sendpackages" be a bit field instead of sending a message for each version. 32 versions should be enough right?
>
> Best,
> Gloria
>
>> On Tue, 24 May 2022 at 12:48 Anthony Towns <aj at erisian.com.au> wrote:
>> On 23 May 2022 9:13:43 pm GMT-04:00, Gloria Zhao <gloriajzhao at gmail.com> wrote:
>> >> If you're asking for the package for "D", would a response telling you:
>> >> txid_D (500 sat, 100vB)
>> >> txid_A (0 sat, 100vB)
>> >> txid_B (2000 sat, 100 vB)
>> >> be better, in that case? Then the receiver can maybe do the logic
>> >> themselves to figure out that they already have A in their mempool
>> >> so it's fine, or not?
>> >Right, I also considered giving the fees and sizes of each transaction in
>> >the package in “pckginfo1”. But I don’t think that information provides
>> >additional meaning unless you know the exact topology, i.e. also know if
>> >the parents have dependency relationships between them. For instance, in
>> >the {A, B, D} package there, even if you have the information listed, your
>> >decision should be different depending on whether B spends from A.
>>
>> I don't think that's true? We already know D is above our fee floor so if B with A is also above the floor, we want them all, but also if B isn't above the floor, but all of them combined are, then we also do?
>>
>> If you've got (A,B,C,X) where B spends A and X spends A,B,C where X+C is below fee floor while A+B and A+B+C+X are above fee floor you have the problem though.
>>
>> Is it plausible to add the graph in?
>>
>> Cheers,
>> aj
>>
>>
>>
>> --
>> Sent from my phone.
> _______________________________________________
> 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/20220524/0e92938d/attachment.html>;
đź“ť Original message:The set of txs is the graph. Anything else would just reproduce the tx graph which must be traversed in any case.
Similarly the set of txs is the fee, the sigops, the size, and the weight. The only information required by packaging is the association of the txs with each other for the purpose of aggregate (vs. individual) net reward consideration.
Since a package can only be reasonably considered for a single block, there is a natural effective limit on acceptable package size. Since any number of individual txs may be transmitted, and the size/weight/sigops of one tx is bounded only by block validity, there is no reason to put any other constraints on packages. A package is just a set of txs that may fit into a block and may collectively be worth mining. A rational package is just a block or compact block without the header. Making it any more than that is unnecessary complexity.
If parts of a package satisfy profitability constraints, they will be accepted/mined and if other parts do not, they will be rejected. There’s no preventing this.
The only pertinent feature missing in the p2p protocol is the ability to associate a set of txs for consideration, where the set (or subset) may satisfy profitability constraints that would not be satisfied if the txs were considered individually.
e
> On May 24, 2022, at 16:21, Gloria Zhao via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> 
> Hi aj,
>
> > If you've got (A,B,C,X) where B spends A and X spends A,B,C where X+C is below fee floor while A+B and A+B+C+X are above fee floor you have the problem though.
>
> To clarify, in this situation, I'm imagining something like
> A: 0 sat, 100vB
> B: 1500 sat, 100vB
> C: 0 sat, 100vB
> X: 500 sat, 100vB
> feerate floor is 3sat/vB
>
> With the algo:
> > * is X alone above my fee rate? no, then forget it
> > * otherwise, s := X.size, f := X.fees, R := [X]
> > * for P = P1..Pn:
> > * do I already have P? then skip to the next parent
> > * s += P.size, f += P.fees, R += [P]
> > * if f/s above my fee rate floor? if so, request all the txs in R
>
> We'd erroneously ask for A+B+C+X, but really we should only take A+B.
> But wouldn't A+B also be a package that was announced for B?
> Please lmk if you were imagining something different. I think I may be missing something.
>
> > Is it plausible to add the graph in?
>
> Fun to think about. Most basic design would be to represent {spends, doesn’t spend} for a previous transaction in the package as a bit. Can think of it as a matrix where row i, column j tells you whether Tx j (directly) spends Tx i.
> But of course you can omit the last row, since the child spends all of them. And since topological ordering is a requirement, you only need as many bits as there are transactions preceding this one in the package.
> If you have up to 24 parents, you need 1 + 2 + ... + 23 bits to codify spending for the 2nd ... 24th parent. For a maximum 25 transactions, 23*24/2 = 276, seems like 36 bytes for a child-with-parents package. A few more for tx-with-ancestors.
> Then you can split it up into sub-packages and everything. Still not sure if we really need to.
>
> Also side note, since there are no size/count params, wondering if we should just have "version" in "sendpackages" be a bit field instead of sending a message for each version. 32 versions should be enough right?
>
> Best,
> Gloria
>
>> On Tue, 24 May 2022 at 12:48 Anthony Towns <aj at erisian.com.au> wrote:
>> On 23 May 2022 9:13:43 pm GMT-04:00, Gloria Zhao <gloriajzhao at gmail.com> wrote:
>> >> If you're asking for the package for "D", would a response telling you:
>> >> txid_D (500 sat, 100vB)
>> >> txid_A (0 sat, 100vB)
>> >> txid_B (2000 sat, 100 vB)
>> >> be better, in that case? Then the receiver can maybe do the logic
>> >> themselves to figure out that they already have A in their mempool
>> >> so it's fine, or not?
>> >Right, I also considered giving the fees and sizes of each transaction in
>> >the package in “pckginfo1”. But I don’t think that information provides
>> >additional meaning unless you know the exact topology, i.e. also know if
>> >the parents have dependency relationships between them. For instance, in
>> >the {A, B, D} package there, even if you have the information listed, your
>> >decision should be different depending on whether B spends from A.
>>
>> I don't think that's true? We already know D is above our fee floor so if B with A is also above the floor, we want them all, but also if B isn't above the floor, but all of them combined are, then we also do?
>>
>> If you've got (A,B,C,X) where B spends A and X spends A,B,C where X+C is below fee floor while A+B and A+B+C+X are above fee floor you have the problem though.
>>
>> Is it plausible to add the graph in?
>>
>> Cheers,
>> aj
>>
>>
>>
>> --
>> Sent from my phone.
> _______________________________________________
> 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/20220524/0e92938d/attachment.html>;