Greg Sanders [ARCHIVE] on Nostr: 📅 Original date posted:2022-08-10 📝 Original message: In this vector, I'm ...
📅 Original date posted:2022-08-10
📝 Original message:
In this vector, I'm pretty sure feerate/total fee pinning is the same
issue. Even if you don't have to increase feerate, you have to pay for
100*1000=100,000 sats due to rule#3.
There's been some work trying to document the exact replacement behavior
implemented in core since it has drifted so much, and the feerate one would
be "rule#6" in the doc:
https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
Making sure inputs are confirmed completely mitigates this, so I'm guessing
it's not much of an issue.
On Wed, Aug 10, 2022 at 2:03 PM Eugene Siegel <elzeigel at gmail.com> wrote:
> I quickly looked it up and it seems that bitcoind has a function
> PaysMoreThanConflicts which checks that the tx pays a higher feerate than
> the replaced tx. This isn't a BIP125 rule AFAICT so I think that's what
> tripped me up. That means I'm wrong about the ancestor bulking variant as a
> malicious counterparty can put a high feerate splice tx at the bottom of
> the mempool, requiring a higher feerate to replace it.
>
> On Wed, Aug 10, 2022 at 12:31 PM Greg Sanders <gsanders87 at gmail.com>
> wrote:
>
>> Your reading is correct.
>>
>> My example was that if TxB, size 100vB with feerate 1000 sat/vbyte, has
>> an 100kvB ancestor paying 1 sat/vbyte. The effective package rate for those
>> two transactions will be (100*1,000 + 100,000*1)/(100,000 + 100) = ~2
>> sat/vybte
>>
>> This means TxB will not be picked up if the prevailing rate is > 2
>> sat/byte. Let's say it's 4 sat/vbyte prevailing rate. To replace it with
>> TxB', one still has to pay to evict TxB, at roughly 1000/4=250 times the
>> normal feerate.
>>
>> Sorry if I got the math wrong here, but at least trying to get the idea
>> across.
>>
>> On Wed, Aug 10, 2022 at 12:20 PM Eugene Siegel <elzeigel at gmail.com>
>> wrote:
>>
>>> Looking it up, rule 3 is "The replacement transaction pays an absolute
>>> fee of at least the sum paid by the original transactions." but here the
>>> ancestors aren't getting replaced so I don't think the replacement has to
>>> pay for them? Or maybe your comment was just generally about how it can
>>> matter in certain cases
>>>
>>> On Wed, Aug 10, 2022 at 12:06 PM Greg Sanders <gsanders87 at gmail.com>
>>> wrote:
>>>
>>>> > I think the ancestor bulking variant of pinning only matters if you
>>>> are trying to add a new descendant and can't due to the ancestor/descendant
>>>> limits.
>>>>
>>>> Not quite. It also matters if you want to RBF that transaction, since
>>>> low feerate ancestor junk puts the transaction at the bottom of the
>>>> mempool, so to speak, even if it has a high feerate itself. You are forced
>>>> to pay "full freight" to replace it via bip125 rule#3 even though it's not
>>>> going to be mined.
>>>>
>>>> (I don't know if that applies here, just noting the wrinkle)
>>>>
>>>> On Wed, Aug 10, 2022 at 11:37 AM Eugene Siegel <elzeigel at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think the ancestor bulking variant of pinning only matters if you
>>>>> are trying to add a new descendant and can't due to the ancestor/descendant
>>>>> limits. In this example, since all of the outputs are locked with `1
>>>>> OP_CSV`, you can't add a descendant to the splice tx. The ancestor bulking
>>>>> also shouldn't matter for RBF since you wouldn't be replacing any of the
>>>>> ancestors, only the splice tx. I think it might matter if the new funding
>>>>> output isn't encumbered.
>>>>>
>>>>> The new funding output can't have `1 OP_CSV` unless we also change the
>>>>> commit tx format, and I'm not sure if it would work. The commit tx has the
>>>>> disable bit set in nSequence so it isn't compatible with the sequence lock.
>>>>> Enabling the bit might be tricky since then the commit tx may have a
>>>>> time-based or block-based locktime based on the lower bits of the obscured
>>>>> commitment number, and it must be block-based (and non-zero) for the
>>>>> sequence lock to work. That means if it's not encumbered, pinning exists
>>>>> since an attacker can make a junk tree using the anchor output. It is
>>>>> replaceable using RBF since you have your own commit tx (with anchor) to
>>>>> broadcast.
>>>>>
>>>>> Eugene
>>>>> _______________________________________________
>>>>> Lightning-dev mailing list
>>>>> Lightning-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/ab81a7c1/attachment-0001.html>;
📝 Original message:
In this vector, I'm pretty sure feerate/total fee pinning is the same
issue. Even if you don't have to increase feerate, you have to pay for
100*1000=100,000 sats due to rule#3.
There's been some work trying to document the exact replacement behavior
implemented in core since it has drifted so much, and the feerate one would
be "rule#6" in the doc:
https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
Making sure inputs are confirmed completely mitigates this, so I'm guessing
it's not much of an issue.
On Wed, Aug 10, 2022 at 2:03 PM Eugene Siegel <elzeigel at gmail.com> wrote:
> I quickly looked it up and it seems that bitcoind has a function
> PaysMoreThanConflicts which checks that the tx pays a higher feerate than
> the replaced tx. This isn't a BIP125 rule AFAICT so I think that's what
> tripped me up. That means I'm wrong about the ancestor bulking variant as a
> malicious counterparty can put a high feerate splice tx at the bottom of
> the mempool, requiring a higher feerate to replace it.
>
> On Wed, Aug 10, 2022 at 12:31 PM Greg Sanders <gsanders87 at gmail.com>
> wrote:
>
>> Your reading is correct.
>>
>> My example was that if TxB, size 100vB with feerate 1000 sat/vbyte, has
>> an 100kvB ancestor paying 1 sat/vbyte. The effective package rate for those
>> two transactions will be (100*1,000 + 100,000*1)/(100,000 + 100) = ~2
>> sat/vybte
>>
>> This means TxB will not be picked up if the prevailing rate is > 2
>> sat/byte. Let's say it's 4 sat/vbyte prevailing rate. To replace it with
>> TxB', one still has to pay to evict TxB, at roughly 1000/4=250 times the
>> normal feerate.
>>
>> Sorry if I got the math wrong here, but at least trying to get the idea
>> across.
>>
>> On Wed, Aug 10, 2022 at 12:20 PM Eugene Siegel <elzeigel at gmail.com>
>> wrote:
>>
>>> Looking it up, rule 3 is "The replacement transaction pays an absolute
>>> fee of at least the sum paid by the original transactions." but here the
>>> ancestors aren't getting replaced so I don't think the replacement has to
>>> pay for them? Or maybe your comment was just generally about how it can
>>> matter in certain cases
>>>
>>> On Wed, Aug 10, 2022 at 12:06 PM Greg Sanders <gsanders87 at gmail.com>
>>> wrote:
>>>
>>>> > I think the ancestor bulking variant of pinning only matters if you
>>>> are trying to add a new descendant and can't due to the ancestor/descendant
>>>> limits.
>>>>
>>>> Not quite. It also matters if you want to RBF that transaction, since
>>>> low feerate ancestor junk puts the transaction at the bottom of the
>>>> mempool, so to speak, even if it has a high feerate itself. You are forced
>>>> to pay "full freight" to replace it via bip125 rule#3 even though it's not
>>>> going to be mined.
>>>>
>>>> (I don't know if that applies here, just noting the wrinkle)
>>>>
>>>> On Wed, Aug 10, 2022 at 11:37 AM Eugene Siegel <elzeigel at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I think the ancestor bulking variant of pinning only matters if you
>>>>> are trying to add a new descendant and can't due to the ancestor/descendant
>>>>> limits. In this example, since all of the outputs are locked with `1
>>>>> OP_CSV`, you can't add a descendant to the splice tx. The ancestor bulking
>>>>> also shouldn't matter for RBF since you wouldn't be replacing any of the
>>>>> ancestors, only the splice tx. I think it might matter if the new funding
>>>>> output isn't encumbered.
>>>>>
>>>>> The new funding output can't have `1 OP_CSV` unless we also change the
>>>>> commit tx format, and I'm not sure if it would work. The commit tx has the
>>>>> disable bit set in nSequence so it isn't compatible with the sequence lock.
>>>>> Enabling the bit might be tricky since then the commit tx may have a
>>>>> time-based or block-based locktime based on the lower bits of the obscured
>>>>> commitment number, and it must be block-based (and non-zero) for the
>>>>> sequence lock to work. That means if it's not encumbered, pinning exists
>>>>> since an attacker can make a junk tree using the anchor output. It is
>>>>> replaceable using RBF since you have your own commit tx (with anchor) to
>>>>> broadcast.
>>>>>
>>>>> Eugene
>>>>> _______________________________________________
>>>>> Lightning-dev mailing list
>>>>> Lightning-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/ab81a7c1/attachment-0001.html>;