Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 5A97CC001E for ; 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 ; 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 ; 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 ; 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 To: Christian Decker Message-ID: In-Reply-To: <87o84r7eaz.fsf@gmail.com> References: <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 , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
Hi Christian,

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:

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

https://twitter.com/ajtowns/status/1= 477586002252238850

> I also se= e 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://l= ists.linuxfoundation.org/pipermail/bitcoin-dev/2022-January/019728.html
=

> I therefore consid= er 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 stil= l required for eltoo, there would be clear consensus for APO.


--
= 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 app= roach, the authors and contributors of
another future soft fo= rk proposal (BIP 118 [3], SIGHASH_ANYPREVOUT)
aren=E2=80=99t = promoting an imminent soft fork activation attempt and instead
are building out and testing one of the speculated use cases, eltoo
payment channels [4].

Be= cause its not ready?

Could you el= aborate 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 abo= ut its
applications in the LN protocol. While writing eltoo w= e stumbled over an
alternative use, and decided to draft the = formal proposal.

Once we saw that Taproot is l= ikely to activate next, AJ started adapting
it to integrate n= icely with Taproot, and renamed it to anyprevout.

<= div>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 signi= ficantly 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 thi= s I don't see how APO
could be considered "not ready".

The reason that neither noinput nor APO have a secti= on on activation is
that we want to allow bundling with other= soft-forks, and we want to
minimize the surface for potentia= l conflicts. Also as the Taproot
activation has shown activat= ion is a whole another discussion, that is
mostly unrelated t= o 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 deve= loper
time expensive. By now most devs will be aware of the m= any improvements
(on LN, eltoo, MPC, channel factories, state= chains, spacechains, etc)
anyprevout would enable, so there i= s little point in annoying everyone
by constantly talking abo= ut it. The people interested in exploring this
venue are alre= ady working on it, and we just need to wait for an
opportune = moment to start the activation discussion with other
soft-for= ks.

I also see people comparing OP_CTV with AP= O, which may or may not work
out in the end. It seems possibl= e 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
c= omplementary, 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 T= X).

Finally I see people mentioning that APO i= s insufficient to get
eltoo. That's also not true, since in f= act we can implement a poor-man's
version of eltoo right now:=

- When updating:
- Iterate th= rough 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
<= div> semantics are preserved, while APO enable O(1) making it actually
<= /div>
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 li= ke
saying that the protocol in the LN paper hasn't changed si= nce 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 reas= onable pace. This is in order
to ensure that the activated fe= atures will work as expected (building
PoCs is important here= ) and that review time is kept efficient (bundling
may help h= ere). 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 t= his
situation a bit.

Cheers,
=
Christian

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