Return-Path: <laolu32@gmail.com> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C28CCD8 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 9 May 2018 22:06:16 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 80BC9680 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 9 May 2018 22:06:15 +0000 (UTC) Received: by mail-wm0-f51.google.com with SMTP id a137-v6so25061733wme.1 for <bitcoin-dev@lists.linuxfoundation.org>; Wed, 09 May 2018 15:06:15 -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 :cc; bh=PrL8BiJKSKB+C1fq1/oNx/1zp6JXRpHFPPq4c4bmjT4=; b=UQKTb+FmDImj9dU4yjPoUopw8bVz2T8+oKdj22SfBgdDeQ0w8ck0TdZkvZdmfWlIKN ces6yHiQ5Thqk2Y2onJrniShnulkRbnYyMSFGLzgvuvq07UqjOyfVhw2pA+rqZA420dY cDO9S2d8Pr5b/7BpnKCAIZY7DD3HaWIHUJU3KQIZuYx90Oyd+5zS9iPoFiRV+RmdHBS/ /6XlQ+QJgOmPcryd1JRg0KWnEkmqalHE5udvt07T7kcrJNT8rCzUFXQlsqvxu0dN1Gqo bqfPrxrRkuWzyu1H30PTIo8NIVDkLzTGCL4gTA965dvhdEkAZ7bhFmDAouR9ARyN7gyL ZuHA== 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:cc; bh=PrL8BiJKSKB+C1fq1/oNx/1zp6JXRpHFPPq4c4bmjT4=; b=ZYL9/8zu3/VYwl2Erh1b943BAa04sHLza9vekECDwlcbnKDscjTwiPTzen9R/jAVpk NbCcy6KgbW2OPvAFA69VgskjPYaSnbxDj1Gx18eW59XcKiojatiOcTM5CkG+yvMTNFUg VJzpogJjEG0pbBUdU1GfoZG9+LGGUED4Fe7nbXZo5advWCKjtjjJyONzfGcELxEmu2or fvBrNNb5aLZ9cSuRG1DOR7XdjJ7lz6fMo4mSzTHnfBITmy9haxKvVC+R6qRu0OkjDrQG m14sQujsAWmak4ML7s7Gf8o9K80nYGjiwUGuBbK2uNX4tuCAY8Wm8tiWkLP9grVl1489 1jng== X-Gm-Message-State: ALQs6tCjyzzgfbP0vZFs07D3QbeJuuPhqPEtQzKUv8E40lbwUtD9+i8u /rBEGhA2gev/fo0ZWKx08SrSGQAsjKFtLcWggW8= X-Google-Smtp-Source: AB8JxZrr36BZnWW+SSOumaF/OJOuj+BFF698uwIUkvS6VPQl8O0XsamI16yjbAAyEDXEjuhLmEdLGYMc8MlUNEb5VZA= X-Received: by 2002:aa7:c2d0:: with SMTP id m16-v6mr63140241edp.171.1525903574094; Wed, 09 May 2018 15:06:14 -0700 (PDT) MIME-Version: 1.0 References: <87po25lmzs.fsf@rustcorp.com.au> <F8C553EE-9AF5-4348-90B7-3EC55FC46B4C@xbt.hk> In-Reply-To: <F8C553EE-9AF5-4348-90B7-3EC55FC46B4C@xbt.hk> From: Olaoluwa Osuntokun <laolu32@gmail.com> Date: Wed, 09 May 2018 22:06:03 +0000 Message-ID: <CAO3Pvs_ix-0xTg_Jqe5secqocZHz3y3r2eRuEftDZqy8OxTNDQ@mail.gmail.com> To: Johnson Lau <jl2012@xbt.hk>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> Content-Type: multipart/alternative; boundary="0000000000007ed57f056bcd1c7a" 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Wed, 09 May 2018 22:06:16 -0000 --0000000000007ed57f056bcd1c7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Instead, would you consider to use ANYONECANPAY to sign the tx, so it is > possible add more inputs for fees? The total tx size is bigger than the > OP_TRUE approach, but you don=E2=80=99t need to ask for any protocol chan= ge. If one has a "root" commitment with other nested descendent multi-transaction contracts, then changing the txid of the root commitment will invalidated all the nested multi tx contracts. In our specific case, w= e have pre-signed 2-stage HTLC transaction which rely on a stable txid. As a result, we can't use the ANYONECANPAY approach atm. > In long-term, I think the right way is to have a more flexible SIGHASH > system to allow people to add more inputs and outputs easily. Agreed, see the recent proposal to introduce SIGHASH_NOINPUT as a new sighash type. IMO it presents an opportunity to introduce more flexible fin= e grained sighash inclusion control. -- Laolu On Wed, May 9, 2018 at 11:12 AM Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > You should make a =E2=80=9C0 fee tx with exactly one OP_TRUE output=E2=80= =9D standard, but > nothing else. This makes sure CPFP will always be needed, so the OP_TRUE > output won=E2=80=99t pollute the UTXO set > > Instead, would you consider to use ANYONECANPAY to sign the tx, so it is > possible add more inputs for fees? The total tx size is bigger than the > OP_TRUE approach, but you don=E2=80=99t need to ask for any protocol chan= ge. > > In long-term, I think the right way is to have a more flexible SIGHASH > system to allow people to add more inputs and outputs easily. > > > > > On 9 May 2018, at 7:57 AM, 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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --0000000000007ed57f056bcd1c7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>> Instead, would you consider to use ANYONECANPAY = to sign the tx, so it is</div><div>> possible add more inputs for fees? = The total tx size is bigger than the</div><div>> OP_TRUE approach, but y= ou don=E2=80=99t need to ask for any protocol change.</div><div><br></div><= div>If one has a "root" commitment with other nested descendent</= div><div>multi-transaction contracts, then changing the txid of the root co= mmitment</div><div>will invalidated all the nested multi tx contracts. In o= ur specific case, we</div><div>have pre-signed 2-stage HTLC transaction whi= ch rely on a stable txid. As a</div><div>result, we can't use the ANYON= ECANPAY approach atm.</div><div><br></div><div>> In long-term, I think t= he right way is to have a more flexible SIGHASH</div><div>> system to al= low people to add more inputs and outputs easily.</div><div><br></div><div>= Agreed, see the recent proposal to introduce SIGHASH_NOINPUT as a new</div>= <div>sighash type. IMO it presents an opportunity to introduce more flexibl= e fine</div><div>grained sighash inclusion control.</div><div><br></div><di= v>-- Laolu</div><div><br></div><br><div class=3D"gmail_quote"><div dir=3D"l= tr">On Wed, May 9, 2018 at 11:12 AM Johnson Lau via bitcoin-dev <<a href= =3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo= undation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" styl= e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You sho= uld make a =E2=80=9C0 fee tx with exactly one OP_TRUE output=E2=80=9D stand= ard, but nothing else. This makes sure CPFP will always be needed, so the O= P_TRUE output won=E2=80=99t pollute the UTXO set<br> <br> Instead, would you consider to use ANYONECANPAY to sign the tx, so it is po= ssible add more inputs for fees? The total tx size is bigger than the OP_TR= UE approach, but you don=E2=80=99t need to ask for any protocol change.<br> <br> In long-term, I think the right way is to have a more flexible SIGHASH syst= em to allow people to add more inputs and outputs easily.<br> <br> <br> <br> > On 9 May 2018, at 7:57 AM, Rusty Russell via bitcoin-dev <<a href= =3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin= -dev@lists.linuxfoundation.org</a>> wrote:<br> > <br> > Hi all,<br> > <br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 The largest problem we are having today wit= h the lightning<br> > protocol is trying to predict future fees.=C2=A0 Eltoo solves this ele= gantly,<br> > but meanwhile we would like to include a 546 satoshi OP_TRUE output in= <br> > commitment transactions so that we use minimal fees and then use CPFP<= br> > (which can't be done at the moment due to CSV delays on outputs).<= br> > <br> > Unfortunately, we'd have to P2SH it at the moment as a raw 'OP= _TRUE' is<br> > non-standard.=C2=A0 Are there any reasons not to suggest such a policy= <br> > change?<br> > <br> > Thanks!<br> > Rusty.<br> > _______________________________________________<br> > bitcoin-dev mailing list<br> > <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= ank">bitcoin-dev@lists.linuxfoundation.org</a><br> > <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev</a><br> <br> <br> _______________________________________________<br> bitcoin-dev mailing list<br> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= bitcoin-dev@lists.linuxfoundation.org</a><br> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev</a><br> </blockquote></div></div> --0000000000007ed57f056bcd1c7a--