path: root/8e/dd7e89a9f3052a2dd66c6a9dec186112689393

Return-Path: <prayank@tutanota.de>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5A97CC001E
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 Jan 2022 15:45:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 3B567607F7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 Jan 2022 15:45:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
 RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=tutanota.de
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id K8Vw5QYh70vh
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 Jan 2022 15:45:14 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 52F3A60783
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue,  4 Jan 2022 15:45:14 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
 by w1.tutanota.de (Postfix) with ESMTP id 95F10FBF65B;
 Tue,  4 Jan 2022 15:45:11 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1641311111; 
 s=s1; d=tutanota.de;
 h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender;
 bh=gLY4Nlq+vUyFFPoxM5A4vUblGTPqsEUzOC5NyUYcRKw=;
 b=sNoN2LpVV2L7L6SIzdQ+v5sBeOvbBOPz8OpxmW6K1acWI2YKlx1jra6vh47A9L8Y
 vKuM/O4AbznHaL504nOGyNZ9SS/NcNYL5HHV1o55UiYj87ikDeq2+kZolUR3ymbTfeT
 gLDHE6KZtoM0yOm9FYS9hZsgQMDiuX+TWcI6dtpNflLHaqpQjtUVpA4z9lACWYOzSMe
 F9cL5i1lO06tKE60zq8vnhSDxbMhiBUMmfWahdC63iomPUz/as2PPkS5hUeFwx8teaQ
 aGCOuMPBtUaUdW9utial2q6q8c7ZvC77WlxaBuPlMBL+20oj8wiIk4LE2V7+IPR74w5
 c3Vq2CRmgw==
Date: Tue, 4 Jan 2022 16:45:11 +0100 (CET)
From: Prayank <prayank@tutanota.de>
To: Christian Decker <decker.christian@gmail.com>
Message-ID: <Ms_l-H3--3-2@tutanota.de>
In-Reply-To: <87o84r7eaz.fsf@gmail.com>
References: <MsZvyxN--7-2@tutanota.de> <87o84r7eaz.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
 boundary="----=_Part_12243_1934899349.1641311111594"
X-Mailman-Approved-At: Tue, 04 Jan 2022 15:53:58 +0000
Cc: Michael Folkson <michaelfolkson@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Stumbling into a contentious soft fork activation
 attempt
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Tue, 04 Jan 2022 15:45:16 -0000

------=_Part_12243_1934899349.1641311111594
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Christian,

A few things are mentioned in these threads including unsolved research iss=
ues in which you were tagged and Richard Myers had even replied so I am ass=
uming this is known:

https://twitter.com/JeremyRubin/status/1460349481518465025

https://twitter.com/ajtowns/status/1477586002252238850

> I also see people comparing OP_CTV with APO, which may or may not work
out in the end.

Michael Folkson did in the first email for this thread: https://lists.linux=
foundation.org/pipermail/bitcoin-dev/2022-January/019728.html

> I therefore consider the two proposals complementary

Agree

> I'm also happy to go wih OP_CTV if only one gets activated (But then why =
would we? We've done much more obscure things to save bytes in a TX).

Maybe we can activate one that does more than just eltoo and see how things=
 work. If APO is still required for eltoo, there would be clear consensus f=
or APO.


--=20
Prayank

A3B1 E430 2298 178F



Jan 4, 2022, 20:12 by decker.christian@gmail.com:

> Prayank via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
>
>>> To contrast with his approach, the authors and contributors of
>>> another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT)
>>> aren=E2=80=99t promoting an imminent soft fork activation attempt and i=
nstead
>>> are building out and testing one of the speculated use cases, eltoo
>>> payment channels [4].
>>>
>>
>> Because its not ready?
>>
>
> Could you elaborate on this point? I keep seeing people mentioning this,
> but I, as BIP co-author, have not seen any real pushback. For context
> BIP118 was initially called `sighash_noinput` and it was mentioned at
> least as far back as 2015 when Joseph and Tadje wrote about its
> applications in the LN protocol. While writing eltoo we stumbled over an
> alternative use, and decided to draft the formal proposal.
>
> Once we saw that Taproot is likely to activate next, AJ started adapting
> it to integrate nicely with Taproot, and renamed it to anyprevout.
>
> I'd like to point out that the original noinput could be implemented
> with as little as 3-5 lines of code in Bitcoin Core, and there are
> experimental branches implementing APO, which isn't significantly more
> complex than the original proposal.
>
> In addition Richard Myers has implemented a PoC of eltoo on top of one
> of these experimental branches. So with all this I don't see how APO
> could be considered "not ready".
>
> The reason that neither noinput nor APO have a section on activation is
> that we want to allow bundling with other soft-forks, and we want to
> minimize the surface for potential conflicts. Also as the Taproot
> activation has shown activation is a whole another discussion, that is
> mostly unrelated to the soft-fork being activated.
>
> Why aren't we yelling about the advantages of APO over other soft-forks
> or asking for immediate activation? Because we want to be respectful of
> everyone's time. We know review capacity is very limited, and developer
> time expensive. By now most devs will be aware of the many improvements
> (on LN, eltoo, MPC, channel factories, statechains, spacechains, etc)
> anyprevout would enable, so there is little point in annoying everyone
> by constantly talking about it. The people interested in exploring this
> venue are already working on it, and we just need to wait for an
> opportune moment to start the activation discussion with other
> soft-forks.
>
> I also see people comparing OP_CTV with APO, which may or may not work
> out in the end. It seems possible to emulate APO using OP_CTV, but at
> what cost? APO does not have any overhead in the transaction size, which
> is not the case for OP_CTV, and I therefore consider the two proposals
> complementary, and not competing (APO does best what APO does best,
> while OP_CTV enables use-cases beyond APO's scope). While I'd prefer APO
> for eltoo, due to its lack of overhead, I'm also happy to go wih OP_CTV
> if only one gets activated (But then why would we? We've done much more
> obscure things to save bytes in a TX).
>
> Finally I see people mentioning that APO is insufficient to get
> eltoo. That's also not true, since in fact we can implement a poor-man's
> version of eltoo right now:
>
>  - When updating:
>  - Iterate through all prior update TXs
>  - Bind the new update TX to each of the prior ones
>  - Sign using `sighash_all`
>  - Collect all sinatures and send to peer (message size O(n), but
>  semantics are preserved, while APO enable O(1) making it actually
>  reasonable to implement).
>
> There may be some extensions, such as layered commitments that may be
> added at a later stage, but they are not required to get the first
> versions off the ground. Pretending that they're required would be like
> saying that the protocol in the LN paper hasn't changed since it was
> first written (definitely not the case).
>
> Overall I agree with Michael's sentiment that soft-fork activations have
> to be carefully planned, and kept at a reasonable pace. This is in order
> to ensure that the activated features will work as expected (building
> PoCs is important here) and that review time is kept efficient (bundling
> may help here). For these reasons we omitted the activation discussion
> in BIP118 and have trimmed the proposal to the bare minimum.
>
> Sorry for the longish rant, but I felt I needed to clarify this
> situation a bit.
>
> Cheers,
> Christian
>


------=_Part_12243_1934899349.1641311111594
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
  </head>
  <body>
<div>Hi Christian,<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">A=
 few things are mentioned in these threads including unsolved research issu=
es in which you were tagged and Richard Myers had even replied so I am assu=
ming this is known:<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">=
https://twitter.com/JeremyRubin/status/1460349481518465025<br></div><div di=
r=3D"auto"><br></div><div dir=3D"auto">https://twitter.com/ajtowns/status/1=
477586002252238850<br></div><div dir=3D"auto"><br></div><div>&gt; I also se=
e people comparing OP_CTV with APO, which may or may not work<br></div><div=
 dir=3D"auto">out in the end.<br></div><div dir=3D"auto"><br></div><div dir=
=3D"auto">Michael Folkson did in the first email for this thread: https://l=
ists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html<br>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; I therefore consid=
er the two proposals complementary<br></div><div dir=3D"auto"><br></div><di=
v dir=3D"auto">Agree<br></div><div dir=3D"auto"><br></div><div dir=3D"auto"=
>&gt; I'm also happy to go wih OP_CTV if only one gets activated (But then =
why would we? We've done much more obscure things to save bytes in a TX).<b=
r></div><div dir=3D"auto"><br></div><div dir=3D"auto">Maybe we can activate=
 one that does more than just eltoo and see how things work. If APO is stil=
l required for eltoo, there would be clear consensus for APO.<br></div><div=
 dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div>-- <br></div><div>=
Prayank<br></div><div><br></div><div dir=3D"auto">A3B1 E430 2298 178F<br></=
div><div><br></div><div><br></div><div><br></div><div>Jan 4, 2022, 20:12 by=
 decker.christian@gmail.com:<br></div><blockquote class=3D"tutanota_quote" =
style=3D"border-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5=
px;"><div>Prayank via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org=
&gt; writes:<br></div><blockquote><blockquote><div>To contrast with his app=
roach, the authors and contributors of<br></div><div>another future soft fo=
rk proposal (BIP 118 [3], SIGHASH_ANYPREVOUT)<br></div><div>aren=E2=80=99t =
promoting an imminent soft fork activation attempt and instead<br></div><di=
v>are building out and testing one of the speculated use cases, eltoo<br></=
div><div>payment channels [4].<br></div></blockquote><div><br></div><div>Be=
cause its not ready?<br></div></blockquote><div><br></div><div>Could you el=
aborate on this point? I keep seeing people mentioning this,<br></div><div>=
but I, as BIP co-author, have not seen any real pushback. For context<br></=
div><div>BIP118 was initially called `sighash_noinput` and it was mentioned=
 at<br></div><div>least as far back as 2015 when Joseph and Tadje wrote abo=
ut its<br></div><div>applications in the LN protocol. While writing eltoo w=
e stumbled over an<br></div><div>alternative use, and decided to draft the =
formal proposal.<br></div><div><br></div><div>Once we saw that Taproot is l=
ikely to activate next, AJ started adapting<br></div><div>it to integrate n=
icely with Taproot, and renamed it to anyprevout.<br></div><div><br></div><=
div>I'd like to point out that the original noinput could be implemented<br=
></div><div>with as little as 3-5 lines of code in Bitcoin Core, and there =
are<br></div><div>experimental branches implementing APO, which isn't signi=
ficantly more<br></div><div>complex than the original proposal.<br></div><d=
iv><br></div><div>In addition Richard Myers has implemented a PoC of eltoo =
on top of one<br></div><div>of these experimental branches. So with all thi=
s I don't see how APO<br></div><div>could be considered "not ready".<br></d=
iv><div><br></div><div>The reason that neither noinput nor APO have a secti=
on on activation is<br></div><div>that we want to allow bundling with other=
 soft-forks, and we want to<br></div><div>minimize the surface for potentia=
l conflicts. Also as the Taproot<br></div><div>activation has shown activat=
ion is a whole another discussion, that is<br></div><div>mostly unrelated t=
o the soft-fork being activated.<br></div><div><br></div><div>Why aren't we=
 yelling about the advantages of APO over other soft-forks<br></div><div>or=
 asking for immediate activation? Because we want to be respectful of<br></=
div><div>everyone's time. We know review capacity is very limited, and deve=
loper<br></div><div>time expensive. By now most devs will be aware of the m=
any improvements<br></div><div>(on LN, eltoo, MPC, channel factories, state=
chains, spacechains, etc)<br></div><div>anyprevout would enable, so there i=
s little point in annoying everyone<br></div><div>by constantly talking abo=
ut it. The people interested in exploring this<br></div><div>venue are alre=
ady working on it, and we just need to wait for an<br></div><div>opportune =
moment to start the activation discussion with other<br></div><div>soft-for=
ks.<br></div><div><br></div><div>I also see people comparing OP_CTV with AP=
O, which may or may not work<br></div><div>out in the end. It seems possibl=
e to emulate APO using OP_CTV, but at<br></div><div>what cost? APO does not=
 have any overhead in the transaction size, which<br></div><div>is not the =
case for OP_CTV, and I therefore consider the two proposals<br></div><div>c=
omplementary, and not competing (APO does best what APO does best,<br></div=
><div>while OP_CTV enables use-cases beyond APO's scope). While I'd prefer =
APO<br></div><div>for eltoo, due to its lack of overhead, I'm also happy to=
 go wih OP_CTV<br></div><div>if only one gets activated (But then why would=
 we? We've done much more<br></div><div>obscure things to save bytes in a T=
X).<br></div><div><br></div><div>Finally I see people mentioning that APO i=
s insufficient to get<br></div><div>eltoo. That's also not true, since in f=
act we can implement a poor-man's<br></div><div>version of eltoo right now:=
<br></div><div><br></div><div> - When updating:<br></div><div> - Iterate th=
rough all prior update TXs<br></div><div> - Bind the new update TX to each =
of the prior ones<br></div><div> - Sign using `sighash_all`<br></div><div> =
- Collect all sinatures and send to peer (message size O(n), but<br></div><=
div> semantics are preserved, while APO enable O(1) making it actually<br><=
/div><div> reasonable to implement).<br></div><div><br></div><div>There may=
 be some extensions, such as layered commitments that may be<br></div><div>=
added at a later stage, but they are not required to get the first<br></div=
><div>versions off the ground. Pretending that they're required would be li=
ke<br></div><div>saying that the protocol in the LN paper hasn't changed si=
nce it was<br></div><div>first written (definitely not the case).<br></div>=
<div><br></div><div>Overall I agree with Michael's sentiment that soft-fork=
 activations have<br></div><div>to be carefully planned, and kept at a reas=
onable pace. This is in order<br></div><div>to ensure that the activated fe=
atures will work as expected (building<br></div><div>PoCs is important here=
) and that review time is kept efficient (bundling<br></div><div>may help h=
ere). For these reasons we omitted the activation discussion<br></div><div>=
in BIP118 and have trimmed the proposal to the bare minimum.<br></div><div>=
<br></div><div>Sorry for the longish rant, but I felt I needed to clarify t=
his<br></div><div>situation a bit.<br></div><div><br></div><div>Cheers,<br>=
</div><div>Christian<br></div></blockquote><div dir=3D"auto"><br></div>  </=
body>
</html>

------=_Part_12243_1934899349.1641311111594--