Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0F099957 for ; Tue, 8 May 2018 23:57:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (ozlabs.org [203.11.71.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6D2E4E3 for ; Tue, 8 May 2018 23:57:39 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 40gbyT17G9z9s3Z; Wed, 9 May 2018 09:57:37 +1000 (AEST) From: Rusty Russell To: "Bitcoin Protocol Discussion" Date: Wed, 09 May 2018 09:27:11 +0930 Message-ID: <87po25lmzs.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Making OP_TRUE standard? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2018 23:57:40 -0000 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.