Gloria Zhao [ARCHIVE] on Nostr: đź“… Original date posted:2022-05-24 đź“ť Original message:Hi aj, > If you've got ...
đź“… Original date posted:2022-05-24
đź“ť Original message: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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220524/056c9996/attachment-0001.html>;
đź“ť Original message: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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220524/056c9996/attachment-0001.html>;