ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-05-17 📝 Original message:Good morning Rusty and ...
📅 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
📝 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