đ
Original date posted:2022-08-10
đ Original message:
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/7ae290f0/attachment-0001.html>;
Greg Sanders [ARCHIVE] /
npub1jdâŚ3gh0m
2023-06-09 13:06:40
in reply to nevent1qâŚ60zn
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-06-09 13:06:40Event JSON
{
"id": "6fcd2119c43f5173716f6674764228173823e2b50b6ead753072f0909109dfb6",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1686316000,
"kind": 1,
"tags": [
[
"e",
"f300f6e0f3fed5376a0ac2a6b73b9320ba0fc0ed249d64504b3196ccc8d9a07e",
"",
"root"
],
[
"e",
"b4551bc3f9a56ed9e63585bc3cac6b2ba13d576d1c01d29b2715014f410d8c28",
"",
"reply"
],
[
"p",
"897fddf7e8d6dceae0590dbd4ecf88e3702c23e1384b9916dd4eecc41896af39"
]
],
"content": "đ
Original date posted:2022-08-10\nđ Original message:\nYour reading is correct.\n\nMy example was that if TxB, size 100vB with feerate 1000 sat/vbyte, has an\n100kvB ancestor paying 1 sat/vbyte. The effective package rate for those\ntwo transactions will be (100*1,000 + 100,000*1)/(100,000 + 100) = ~2\nsat/vybte\n\nThis means TxB will not be picked up if the prevailing rate is \u003e 2\nsat/byte. Let's say it's 4 sat/vbyte prevailing rate. To replace it with\nTxB', one still has to pay to evict TxB, at roughly 1000/4=250 times the\nnormal feerate.\n\nSorry if I got the math wrong here, but at least trying to get the idea\nacross.\n\nOn Wed, Aug 10, 2022 at 12:20 PM Eugene Siegel \u003celzeigel at gmail.com\u003e wrote:\n\n\u003e Looking it up, rule 3 is \"The replacement transaction pays an absolute fee\n\u003e of at least the sum paid by the original transactions.\" but here the\n\u003e ancestors aren't getting replaced so I don't think the replacement has to\n\u003e pay for them? Or maybe your comment was just generally about how it can\n\u003e matter in certain cases\n\u003e\n\u003e On Wed, Aug 10, 2022 at 12:06 PM Greg Sanders \u003cgsanders87 at gmail.com\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e \u003e I think the ancestor bulking variant of pinning only matters if you are\n\u003e\u003e trying to add a new descendant and can't due to the ancestor/descendant\n\u003e\u003e limits.\n\u003e\u003e\n\u003e\u003e Not quite. It also matters if you want to RBF that transaction, since low\n\u003e\u003e feerate ancestor junk puts the transaction at the bottom of the mempool, so\n\u003e\u003e to speak, even if it has a high feerate itself. You are forced to pay \"full\n\u003e\u003e freight\" to replace it via bip125 rule#3 even though it's not going to be\n\u003e\u003e mined.\n\u003e\u003e\n\u003e\u003e (I don't know if that applies here, just noting the wrinkle)\n\u003e\u003e\n\u003e\u003e On Wed, Aug 10, 2022 at 11:37 AM Eugene Siegel \u003celzeigel at gmail.com\u003e\n\u003e\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Hi,\n\u003e\u003e\u003e\n\u003e\u003e\u003e I think the ancestor bulking variant of pinning only matters if you are\n\u003e\u003e\u003e trying to add a new descendant and can't due to the ancestor/descendant\n\u003e\u003e\u003e limits. In this example, since all of the outputs are locked with `1\n\u003e\u003e\u003e OP_CSV`, you can't add a descendant to the splice tx. The ancestor bulking\n\u003e\u003e\u003e also shouldn't matter for RBF since you wouldn't be replacing any of the\n\u003e\u003e\u003e ancestors, only the splice tx. I think it might matter if the new funding\n\u003e\u003e\u003e output isn't encumbered.\n\u003e\u003e\u003e\n\u003e\u003e\u003e The new funding output can't have `1 OP_CSV` unless we also change the\n\u003e\u003e\u003e commit tx format, and I'm not sure if it would work. The commit tx has the\n\u003e\u003e\u003e disable bit set in nSequence so it isn't compatible with the sequence lock.\n\u003e\u003e\u003e Enabling the bit might be tricky since then the commit tx may have a\n\u003e\u003e\u003e time-based or block-based locktime based on the lower bits of the obscured\n\u003e\u003e\u003e commitment number, and it must be block-based (and non-zero) for the\n\u003e\u003e\u003e sequence lock to work. That means if it's not encumbered, pinning exists\n\u003e\u003e\u003e since an attacker can make a junk tree using the anchor output. It is\n\u003e\u003e\u003e replaceable using RBF since you have your own commit tx (with anchor) to\n\u003e\u003e\u003e broadcast.\n\u003e\u003e\u003e\n\u003e\u003e\u003e Eugene\n\u003e\u003e\u003e _______________________________________________\n\u003e\u003e\u003e Lightning-dev mailing list\n\u003e\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\u003e\n\u003e\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/7ae290f0/attachment-0001.html\u003e",
"sig": "8aa35b725a008fbf41e28cf7d3c89811392ff4b1a34953fa667f25bb7056417e2ab5ac13e0cd98867fb11858769aa343d336f0ea6318e153d4991e336653864f"
}