{"type":"rich","version":"1.0","author_name":"npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","author_url":"https://nostr.ae/npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2018-05-08\n📝 Original message:What are the downsides of just using p2wsh? This route can be rolled out\nimmediately, while policy changes are pretty \"fuzzy\" and would require a\nnear uniform rollout in order to ensure wide propagation of the commitment\ntransactions.\n\nOn Tue, May 8, 2018, 4:58 PM Rusty Russell via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hi all,\n\u003e\n\u003e         The largest problem we are having today with the lightning\n\u003e protocol is trying to predict future fees.  Eltoo solves this elegantly,\n\u003e but meanwhile we would like to include a 546 satoshi OP_TRUE output in\n\u003e commitment transactions so that we use minimal fees and then use CPFP\n\u003e (which can't be done at the moment due to CSV delays on outputs).\n\u003e\n\u003e Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is\n\u003e non-standard.  Are there any reasons not to suggest such a policy\n\u003e change?\n\u003e\n\u003e Thanks!\n\u003e Rusty.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180509/63e18795/attachment.html\u003e"}