MIME-Version: 1.0
References: <87po25lmzs.fsf@rustcorp.com.au>
In-Reply-To: <87po25lmzs.fsf@rustcorp.com.au>
From: Olaoluwa Osuntokun <laolu32@gmail.com>
Date: Wed, 09 May 2018 00:24:59 +0000
Message-ID: <CAO3Pvs9e5_YR9A_nqxcHAO5KgSvoyNq9q3P5UKBHbfK+kfvkKA@mail.gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>, 
	Arnoud Kouwenhoven - Pukaki Corp via bitcoin-dev
	<bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000844de7056bbaef20"
Subject: Re: [bitcoin-dev] Making OP_TRUE standard?
Precedence: list

--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

<div dir=3D"auto"><div>What are the downsides of just using p2wsh? This rou=
te can be rolled out immediately, while policy changes are pretty &quot;fuz=
zy&quot; and would require a near uniform rollout in order to ensure wide p=
ropagation of the commitment transactions.=C2=A0<br><br><div class=3D"gmail=
_quote"><div dir=3D"ltr">On Tue, May 8, 2018, 4:58 PM Rusty Russell via bit=
coin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitco=
in-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">Hi all,<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The largest problem we are having today with th=
e lightning<br>
protocol is trying to predict future fees.=C2=A0 Eltoo solves this elegantl=
y,<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&#39;t be done at the moment due to CSV delays on outputs).<br>
<br>
Unfortunately, we&#39;d have to P2SH it at the moment as a raw &#39;OP_TRUE=
&#39; 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"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div></div>

--000000000000844de7056bbaef20--