rich1.0npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lhttps://nostr.ae/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://nostr.ae📅 Original date posted:2018-05-09 📝 Original message:Good morning Olauluwa, I believe P2WSH is larger due to the script hash commitment in the `scriptPubKey` as well as the actual script revelation in the `witnessScript`, whereas, a flat OP_TRUE in the `scriptPubKey` is much smaller and can be spent with an empty `scriptSig`. It seems this is the entirety of the reason to desire an isStandard OP_TRUE. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On May 9, 2018 8:24 AM, Olaoluwa Osuntokun via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > What are the downsides of just using p2wsh? This route can be rolled out immediately, while policy changes are pretty "fuzzy" and would require a near uniform rollout in order to ensure wide propagation of the commitment transactions. > > On Tue, May 8, 2018, 4:58 PM Rusty Russell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > >> Hi all, >> >> The largest problem we are having today with the lightning >> protocol is trying to predict future fees. Eltoo solves this elegantly, >> but meanwhile we would like to include a 546 satoshi OP_TRUE output in >> commitment transactions so that we use minimal fees and then use CPFP >> (which can't be done at the moment due to CSV delays on outputs). >> >> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is >> non-standard. Are there any reasons not to suggest such a policy >> change? >> >> Thanks! >> Rusty. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev at lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180508/15690883/attachment-0001.html>