đ
Original date posted:2022-08-10
đ Original message:
> 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/cedb54f6/attachment.html>;
Greg Sanders [ARCHIVE] /
npub1jdâŚ3gh0m
2023-06-09 13:06:40
in reply to nevent1qâŚgwvw
Author Public Key
npub1jdl3plz00rvxwc6g2ckemzrgg0amx5wen4kfvs3laxtssxvk9cvsf3gh0mPublished at
2023-06-09 13:06:40Event JSON
{
"id": "1ef89a8eec04eb946e8bbfa5263fce88e1cd53457262d4be350143280a2cd6df",
"pubkey": "937f10fc4f78d8676348562d9d886843fbb351d99d6c96423fe9970819962e19",
"created_at": 1686316000,
"kind": 1,
"tags": [
[
"e",
"f300f6e0f3fed5376a0ac2a6b73b9320ba0fc0ed249d64504b3196ccc8d9a07e",
"",
"root"
],
[
"e",
"dd7d09041d6b0e88d7cd13c9d1c3287a5a1de0396bb4052307b0540547c020d9",
"",
"reply"
],
[
"p",
"897fddf7e8d6dceae0590dbd4ecf88e3702c23e1384b9916dd4eecc41896af39"
]
],
"content": "đ
Original date posted:2022-08-10\nđ Original message:\n\u003e I think the ancestor bulking variant of pinning only matters if you are\ntrying to add a new descendant and can't due to the ancestor/descendant\nlimits.\n\nNot quite. It also matters if you want to RBF that transaction, since low\nfeerate ancestor junk puts the transaction at the bottom of the mempool, so\nto speak, even if it has a high feerate itself. You are forced to pay \"full\nfreight\" to replace it via bip125 rule#3 even though it's not going to be\nmined.\n\n(I don't know if that applies here, just noting the wrinkle)\n\nOn Wed, Aug 10, 2022 at 11:37 AM Eugene Siegel \u003celzeigel at gmail.com\u003e wrote:\n\n\u003e Hi,\n\u003e\n\u003e I think the ancestor bulking variant of pinning only matters if you are\n\u003e trying to add a new descendant and can't due to the ancestor/descendant\n\u003e limits. In this example, since all of the outputs are locked with `1\n\u003e OP_CSV`, you can't add a descendant to the splice tx. The ancestor bulking\n\u003e also shouldn't matter for RBF since you wouldn't be replacing any of the\n\u003e ancestors, only the splice tx. I think it might matter if the new funding\n\u003e output isn't encumbered.\n\u003e\n\u003e The new funding output can't have `1 OP_CSV` unless we also change the\n\u003e commit tx format, and I'm not sure if it would work. The commit tx has the\n\u003e disable bit set in nSequence so it isn't compatible with the sequence lock.\n\u003e Enabling the bit might be tricky since then the commit tx may have a\n\u003e time-based or block-based locktime based on the lower bits of the obscured\n\u003e commitment number, and it must be block-based (and non-zero) for the\n\u003e sequence lock to work. That means if it's not encumbered, pinning exists\n\u003e since an attacker can make a junk tree using the anchor output. It is\n\u003e replaceable using RBF since you have your own commit tx (with anchor) to\n\u003e broadcast.\n\u003e\n\u003e Eugene\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220810/cedb54f6/attachment.html\u003e",
"sig": "d46ae2b13ce368fee5fd6299baa28725a8a0f4c9f253a0aaff7815cdff77818fdb7131edbae41586ef2fa25a04098f0bf191fcbb9cf777d470111e968144f04c"
}