Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C28CCD8 for ; 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 ; Wed, 9 May 2018 22:06:15 +0000 (UTC) Received: by mail-wm0-f51.google.com with SMTP id a137-v6so25061733wme.1 for ; 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> In-Reply-To: From: Olaoluwa Osuntokun Date: Wed, 09 May 2018 22:06:03 +0000 Message-ID: To: Johnson Lau , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
> 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 y= ou don=E2=80=99t need to ask for any protocol change.

<= div>If one has a "root" commitment with other nested descendent
multi-transaction contracts, then changing the txid of the root co= mmitment
will invalidated all the nested multi tx contracts. In o= ur specific case, we
have pre-signed 2-stage HTLC transaction whi= ch rely on a stable txid. As a
result, we can't use the ANYON= ECANPAY approach atm.

> In long-term, I think t= he right way is to have a more flexible SIGHASH
> system to al= low 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 flexibl= e fine
grained sighash inclusion control.

-- Laolu


On Wed, May 9, 2018 at 11:12 AM Johnson Lau via bitcoin-dev <bitcoin-dev@lists.linuxfo= undation.org> wrote:
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

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.

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.



> On 9 May 2018, at 7:57 AM, Rusty Russell via bitcoin-dev <bitcoin= -dev@lists.linuxfoundation.org> wrote:
>
> Hi all,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 The largest problem we are having today wit= h the lightning
> protocol is trying to predict future fees.=C2=A0 Eltoo solves this ele= gantly,
> 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<= br> > (which can't be done at the moment due to CSV delays on outputs).<= br> >
> 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.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--0000000000007ed57f056bcd1c7a--