Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5652F900 for ; Thu, 10 May 2018 09:43:51 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id BCD37683 for ; Thu, 10 May 2018 09:43:50 +0000 (UTC) Received: from [2001:470:5:265:a45d:823b:2d27:961c] (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 64DE738B5DF7; Thu, 10 May 2018 09:43:31 +0000 (UTC) X-Hashcash: 1:25:180510:jtimon@jtimon.cc::b2Gc0ZzRvEb0z3cI:9W=B X-Hashcash: 1:25:180510:bitcoin-dev@lists.linuxfoundation.org::r+neo0UNmAnJwJOj:aYXJS From: Luke Dashjr To: Jorge =?utf-8?q?Tim=C3=B3n?= , Bitcoin Protocol Discussion Date: Thu, 10 May 2018 09:43:28 +0000 User-Agent: KMail/1.9.10 (enterprise35 0.20100827.1168748) References: <87po25lmzs.fsf@rustcorp.com.au> In-Reply-To: X-KMail-QuotePrefix: > X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201805100943.29654.luke@dashjr.org> X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [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: Thu, 10 May 2018 09:43:51 -0000 You'd send 0 satoshis to OP_TRUE, creating a UTXO. Then you spend that 0-va= lue=20 UTXO in another transaction with a normal fee. The idea is that to get the= =20 latter fee, the miner needs to confirm the original tranaction with the=20 0-value OP_TRUE. (Aside, in case it wasn't clear on my previous email, the template-script i= dea=20 would not make it *mandatory* to spend in the same block, but that the UTXO= =20 would merely cease to be valid *after* that block. So the 0-value output do= es=20 not take up a UTXO db entry when left unused.) On Thursday 10 May 2018 09:33:29 Jorge Tim=C3=B3n via bitcoin-dev wrote: > I fail to see what's the practical difference between sending to op_true > and giving the coins are fees directly. Perhaps it is ao obvious to you > that you forget to mention it? > If you did I honestlt missed it. > > On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, < > > bitcoin-dev@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@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev