rich1.0npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynhttps://nostr.ae/npub1wtx5qvewc7pd6znlvwktq03mdld05mv3h5dkzfwd3dc30gdmsptsugtuynnjumphttps://nostr.ae📅 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.