đź“… 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>;
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 23:09:50
in reply to nevent1q…p0p9
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cPublished at
2023-06-07 23:09:50Event JSON
{
"id": "983b45e4fdd6aed273ab52847700333acb3a137423aa8d2995066335b28ae815",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686179390,
"kind": 1,
"tags": [
[
"e",
"2ff757999827be6e4e537a444aad80562c1001e4e555376a251ff2ee7be09c2d",
"",
"root"
],
[
"e",
"e56ecb7586e6a415a3f1f51c006af32eac9c3c21621ab4f4a2477345266b4a17",
"",
"reply"
],
[
"p",
"ae3ba6480aa67b9df74235b2a41ef2c684bb2699968a74d137220a710007a0a0"
]
],
"content": "📅 Original date posted:2022-05-24\n📝 Original message:The set of txs is the graph. Anything else would just reproduce the tx graph which must be traversed in any case.\n\nSimilarly 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.\n\nSince 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.\n\nIf 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.\n\nThe 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.\n\ne\n\n\u003e On May 24, 2022, at 16:21, Gloria Zhao via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e \n\u003e Hi aj,\n\u003e \n\u003e \u003e 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.\n\u003e \n\u003e To clarify, in this situation, I'm imagining something like\n\u003e A: 0 sat, 100vB\n\u003e B: 1500 sat, 100vB\n\u003e C: 0 sat, 100vB\n\u003e X: 500 sat, 100vB\n\u003e feerate floor is 3sat/vB\n\u003e \n\u003e With the algo:\n\u003e \u003e * is X alone above my fee rate? no, then forget it\n\u003e \u003e * otherwise, s := X.size, f := X.fees, R := [X]\n\u003e \u003e * for P = P1..Pn:\n\u003e \u003e * do I already have P? then skip to the next parent\n\u003e \u003e * s += P.size, f += P.fees, R += [P]\n\u003e \u003e * if f/s above my fee rate floor? if so, request all the txs in R\n\u003e \n\u003e We'd erroneously ask for A+B+C+X, but really we should only take A+B.\n\u003e But wouldn't A+B also be a package that was announced for B?\n\u003e Please lmk if you were imagining something different. I think I may be missing something.\n\u003e \n\u003e \u003e Is it plausible to add the graph in?\n\u003e \n\u003e 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.\n\u003e 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.\n\u003e 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.\n\u003e Then you can split it up into sub-packages and everything. Still not sure if we really need to.\n\u003e \n\u003e 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?\n\u003e \n\u003e Best,\n\u003e Gloria\n\u003e \n\u003e\u003e On Tue, 24 May 2022 at 12:48 Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\u003e\u003e On 23 May 2022 9:13:43 pm GMT-04:00, Gloria Zhao \u003cgloriajzhao at gmail.com\u003e wrote:\n\u003e\u003e \u003e\u003e If you're asking for the package for \"D\", would a response telling you:\n\u003e\u003e \u003e\u003e txid_D (500 sat, 100vB)\n\u003e\u003e \u003e\u003e txid_A (0 sat, 100vB)\n\u003e\u003e \u003e\u003e txid_B (2000 sat, 100 vB)\n\u003e\u003e \u003e\u003e be better, in that case? Then the receiver can maybe do the logic\n\u003e\u003e \u003e\u003e themselves to figure out that they already have A in their mempool\n\u003e\u003e \u003e\u003e so it's fine, or not?\n\u003e\u003e \u003eRight, I also considered giving the fees and sizes of each transaction in\n\u003e\u003e \u003ethe package in “pckginfo1”. But I don’t think that information provides\n\u003e\u003e \u003eadditional meaning unless you know the exact topology, i.e. also know if\n\u003e\u003e \u003ethe parents have dependency relationships between them. For instance, in\n\u003e\u003e \u003ethe {A, B, D} package there, even if you have the information listed, your\n\u003e\u003e \u003edecision should be different depending on whether B spends from A.\n\u003e\u003e \n\u003e\u003e 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?\n\u003e\u003e \n\u003e\u003e 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.\n\u003e\u003e \n\u003e\u003e Is it plausible to add the graph in?\n\u003e\u003e \n\u003e\u003e Cheers,\n\u003e\u003e aj\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e -- \n\u003e\u003e Sent from my phone.\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220524/0e92938d/attachment.html\u003e",
"sig": "137050680fa8fde467b13f29025d9e9fe0887ea50f39f98401baa820f920e54816460d49a0197f3cef2bf4d4c7b45ddb3b7fa3c7350eb838ce59aa027c6e85ec"
}