Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 389EB982 for ; Wed, 9 May 2018 00:25:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8842A14F for ; Wed, 9 May 2018 00:25:11 +0000 (UTC) Received: by mail-wm0-f42.google.com with SMTP id f6so21551234wmc.4 for ; Tue, 08 May 2018 17:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=N8l7ML3NC+fI55Z26H3XgfOMD10dKGsShS0Xk8VaVJ8=; b=tl4fdNPAM/CIe08k/Z+7689l31Xw7mQs0qv5/JbX2usDtCpmsUwm8WqrnVrzLz2/iT H+VaqSZt4E0oNrg7u2bJzVTvzdit952FBafVRod1oJKyG60vZSW55bXl2tuK1K0XXSXg 6swrOC4iyDOMzXfs2ndY3+iGrdutg4QxaJCTtfRYv8+y5FeKIIGxaBEhKZ75KuGh1UJ3 VHeb3FzHol9cUAR3qtOZP72kozroawLZ1cTAJeilFmdk6FMrDzVn02ylFXNtAKVxzI7p YFMYJupm253580hroIrLXR/EwHJ3IIo4Z0H+oUuO9skjg8+enc3LHiBcfmQTiAK6jrVg dzJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=N8l7ML3NC+fI55Z26H3XgfOMD10dKGsShS0Xk8VaVJ8=; b=foNbnVB0EHrLzMGIiUYlRNQhPkqe1m0vSIM/AAvsh7IEchKfwJBZDobYkU9LwGfqOW ZQ5hqGa0bZO5/QybFbLqddQr8TbiO4N9s73+AjmEeqvnvqITAsjjtO182AulhkaLP/rd wEZQ/GI909GW0dqeWU9Rnp9WiZK1554hdySsKUVU4Q7y+aHDjZEk0JiNLHvrQ+syvmoV /ycSwBOx6OfIpmbbM/Je7G5KIvQoWV/dxkpL43moQrYvJMIpIr/1t29RggUCCh2V6GHq F+dQuxhFlyHAWTyvYa932C1+pskuCriTZfSYG2Hp+8ng5HGunvHuCxtqXXoCLTMf9IxL qdPw== X-Gm-Message-State: ALQs6tBlvJj1pKDEQlMoeKttuMmF8xa+xDcXzRi/YKd8gGMjpPIUPH85 cfBX7PVTfLwZafVoigoKVHS+ehQ7XS9OMaE7XTEj/g== X-Google-Smtp-Source: AB8JxZox87+W4PzWnQwr3ed9+w67Qmf6OZgDce2GEiAJnpKjMlxN/cDLIcDbw16aOCyi6Fcz4UpsvOnCXbztkeN0ilU= X-Received: by 2002:a50:d311:: with SMTP id g17-v6mr23165898edh.160.1525825510066; Tue, 08 May 2018 17:25:10 -0700 (PDT) MIME-Version: 1.0 References: <87po25lmzs.fsf@rustcorp.com.au> In-Reply-To: <87po25lmzs.fsf@rustcorp.com.au> From: Olaoluwa Osuntokun Date: Wed, 09 May 2018 00:24:59 +0000 Message-ID: To: Rusty Russell , Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev Content-Type: multipart/alternative; boundary="000000000000844de7056bbaef20" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no 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: Wed, 09 May 2018 00:25:12 -0000 --000000000000844de7056bbaef20 Content-Type: text/plain; charset="UTF-8" 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@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 > --000000000000844de7056bbaef20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What are the downsides of just using p2wsh? This rou= te can be rolled out immediately, while policy changes are pretty "fuz= zy" and would require a near uniform rollout in order to ensure wide p= ropagation of the commitment transactions.=C2=A0

On Tue, May 8, 2018, 4:58 PM Rusty Russell via bit= coin-dev <bitco= in-dev@lists.linuxfoundation.org> wrote:
Hi all,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 The largest problem we are having today with th= e lightning
protocol is trying to predict future fees.=C2=A0 Eltoo solves this elegantl= y,
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.=C2=A0 Are there any reasons not to suggest such a policy
change?

Thanks!
Rusty.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000844de7056bbaef20--