Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-24 📝 Original message:On 23 May 2022 9:13:43 pm ...
📅 Original date posted:2022-05-24
📝 Original message: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.
📝 Original message: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.