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>&gt; Instead, would you consider to use ANYONECANPAY =
to sign the tx, so it is</div><div>&gt; possible add more inputs for fees? =
The total tx size is bigger than the</div><div>&gt; 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 &quot;root&quot; 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&#39;t use the ANYON=
ECANPAY approach atm.</div><div><br></div><div>&gt; In long-term, I think t=
he right way is to have a more flexible SIGHASH</div><div>&gt; 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 &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfo=
undation.org</a>&gt; 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>
&gt; On 9 May 2018, at 7:57 AM, Rusty Russell via bitcoin-dev &lt;<a href=
=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin=
-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; <br>
&gt; Hi all,<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 The largest problem we are having today wit=
h the lightning<br>
&gt; protocol is trying to predict future fees.=C2=A0 Eltoo solves this ele=
gantly,<br>
&gt; but meanwhile we would like to include a 546 satoshi OP_TRUE output in=
<br>
&gt; commitment transactions so that we use minimal fees and then use CPFP<=
br>
&gt; (which can&#39;t be done at the moment due to CSV delays on outputs).<=
br>
&gt; <br>
&gt; Unfortunately, we&#39;d have to P2SH it at the moment as a raw &#39;OP=
_TRUE&#39; is<br>
&gt; non-standard.=C2=A0 Are there any reasons not to suggest such a policy=
<br>
&gt; change?<br>
&gt; <br>
&gt; Thanks!<br>
&gt; Rusty.<br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <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--