š
Original date posted:2018-05-17
š Original message: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.)
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-07 18:11:58
in reply to nevent1qā¦m9nz
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-07 18:11:58Event JSON
{
"id": "b3744cfb828f96aeccffa99d8b0957b40834a97a29fdd3f44e1dec0f3d6ab883",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686161518,
"kind": 1,
"tags": [
[
"e",
"caee4e3828cad70a0aa9bfba9569480bc6157a528d4896eeab11f571613a9d97",
"",
"root"
],
[
"e",
"808d2d1cd268e0dd60bd8e8a5be0067ac23d0deeb935940a49e8c4b0f6e05f52",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "š
Original date posted:2018-05-17\nš Original message:Good morning Rusty and list,\n\n\u003e Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is interesting,\n\u003e \n\u003e but if we want a SF just give us SIGHASH_NOINPUT and we'll not need this\n\u003e \n\u003e at all (though others still might).\n\nWe 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).\n\nWithout 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).\n\n(we could also feebump using the change output of the funding transaction, but such a change output might not exist for all funding transactions.)\n\nRegards,\nZmnSCPxj",
"sig": "1353987e73b84e1437e449adbcc2c82671079180cc0c90ba2f610b2cd5439f015dd2f80910733b0ea6a307b864a50033f6ce259ab9554238635be24b06778c75"
}