📅 Original date posted:2018-05-17
📝 Original message:ZmnSCPxj via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
> Good morning Rusty and list,
>
>> Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is
>> interesting,
>>
>> but if we want a SF just give us SIGHASH_NOINPUT and we'll not need
>> this
>>
>> at all (though others still might).
>
> We might still want this in general in Lightning; for instance we
> could make every funding transaction include such an output. If it
> turns out, our initial feerate estimate for the funding transaction is
> low, we can use the `OP_TRUE` for fee-bumping. This is a win for
> Lightning since the funding transaction ID remains the same (even in
> Decker-Russell-Osuntokun, the trigger transaction is signed with
> `SIGHASH_ALL`, and refers to a fixed funding transaction ID).
>
> Without the `OP_TRUE`-for-fee-bump, we would have to pretend to open a
> new different channel and RBF the old funding transaction with a new
> higher-feerate funding transaction, then keep track of which one gets
> confirmed deeply (there is a race where a miner discovers a block
> using the older funding transaction before our broadcast of the new
> funding transaction reaches it).
>
> (we could also feebump using the change output of the funding
> transaction, but such a change output might not exist for all funding
> transactions.)
This would only really help in the case of the funding tx not having a
change output, which I believe will be very rare. In the case of a
change output we can simply do a CPFP which includes the change output.
Christian Decker [ARCHIVE] /
npub1wt…gtuyn
2023-06-07 18:11:58
in reply to nevent1q…k78w
Author Public Key
npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynPublished at
2023-06-07 18:11:58Event JSON
{
"id": "d18b97350489f70e825004dd2d0af5638dd35a7af2e2b2ff1d1b5fdf25ecde5f",
"pubkey": "72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057",
"created_at": 1686161518,
"kind": 1,
"tags": [
[
"e",
"caee4e3828cad70a0aa9bfba9569480bc6157a528d4896eeab11f571613a9d97",
"",
"root"
],
[
"e",
"b3744cfb828f96aeccffa99d8b0957b40834a97a29fdd3f44e1dec0f3d6ab883",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-05-17\n📝 Original message:ZmnSCPxj via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e writes:\n\n\u003e Good morning Rusty and list,\n\u003e\n\u003e\u003e Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is\n\u003e\u003e interesting,\n\u003e\u003e \n\u003e\u003e but if we want a SF just give us SIGHASH_NOINPUT and we'll not need\n\u003e\u003e this\n\u003e\u003e \n\u003e\u003e at all (though others still might).\n\u003e\n\u003e We might still want this in general in Lightning; for instance we\n\u003e could make every funding transaction include such an output. If it\n\u003e turns out, our initial feerate estimate for the funding transaction is\n\u003e low, we can use the `OP_TRUE` for fee-bumping. This is a win for\n\u003e Lightning since the funding transaction ID remains the same (even in\n\u003e Decker-Russell-Osuntokun, the trigger transaction is signed with\n\u003e `SIGHASH_ALL`, and refers to a fixed funding transaction ID).\n\u003e\n\u003e Without the `OP_TRUE`-for-fee-bump, we would have to pretend to open a\n\u003e new different channel and RBF the old funding transaction with a new\n\u003e higher-feerate funding transaction, then keep track of which one gets\n\u003e confirmed deeply (there is a race where a miner discovers a block\n\u003e using the older funding transaction before our broadcast of the new\n\u003e funding transaction reaches it).\n\u003e\n\u003e (we could also feebump using the change output of the funding\n\u003e transaction, but such a change output might not exist for all funding\n\u003e transactions.)\n\nThis would only really help in the case of the funding tx not having a\nchange output, which I believe will be very rare. In the case of a\nchange output we can simply do a CPFP which includes the change output.",
"sig": "fe72eade2c58e99c1323953428cfeed1bf36a99c70b6ee3a8f89bcaf512fa01cb45e142d4b41c2a368ea5ecc5079ce2e440b73b61b184c4f8829be09601bf66e"
}