MIME-Version: 1.0
References: <87po25lmzs.fsf@rustcorp.com.au>
In-Reply-To: <87po25lmzs.fsf@rustcorp.com.au>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Thu, 10 May 2018 09:33:29 +0000
Message-ID: <CABm2gDoJEKQXPipWY5y6MUgQRu1W_ogBHL7ibjt8dD_=n2=ptg@mail.gmail.com>
To: Rusty Russell <rusty@rustcorp.com.au>, 
	Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f6cf47056bd6b622"
Subject: Re: [bitcoin-dev] Making OP_TRUE standard?
Precedence: list

--000000000000f6cf47056bd6b622
Content-Type: text/plain; charset="UTF-8"

I fail to see what's the practical difference between sending to op_true
and giving the coins are fees directly. Perhaps it is ao obvious to you
that you forget to mention it?
If you did I honestlt missed it.

On Wed, 9 May 2018, 01:58 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
>

--000000000000f6cf47056bd6b622
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I fail to see what&#39;s the practical difference between=
 sending to op_true and giving the coins are fees directly. Perhaps it is a=
o obvious to you that you forget to mention it?=C2=A0<div dir=3D"auto">If y=
ou did I honestlt missed it.</div></div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr">On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, &lt;<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.l=
inuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">H=
i 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>

--000000000000f6cf47056bd6b622--