public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Prayank <prayank@tutanota.de>
To: Christian Decker <decker.christian@gmail.com>
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
Date: Tue, 4 Jan 2022 16:45:11 +0100 (CET)	[thread overview]
Message-ID: <Ms_l-H3--3-2@tutanota.de> (raw)
In-Reply-To: <87o84r7eaz.fsf@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5536 bytes --]

Hi Christian,

A few things are mentioned in these threads including unsolved research issues in which you were tagged and Richard Myers had even replied so I am assuming 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.linuxfoundation.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 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 approach, the authors and contributors of
>>> another future soft fork proposal (BIP 118 [3], SIGHASH_ANYPREVOUT)
>>> aren’t promoting an imminent soft fork activation attempt and instead
>>> 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
>


[-- Attachment #2: Type: text/html, Size: 7424 bytes --]

  reply	other threads:[~2022-01-04 15:45 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-04 11:53 [bitcoin-dev] Stumbling into a contentious soft fork activation attempt Prayank
2022-01-04 14:15 ` Michael Folkson
2022-01-04 15:06   ` Prayank
2022-01-04 16:48     ` Michael Folkson
2022-01-04 17:07       ` Prayank
2022-01-04 14:42 ` Christian Decker
2022-01-04 15:45   ` Prayank [this message]
  -- strict thread matches above, loose matches on Subject: below --
2022-01-18  1:57 Prayank
2022-02-18 23:41 ` Peter Todd
2022-02-20 18:35   ` Erik Aronesty
2022-02-21  3:03     ` Prayank
2022-02-21  9:02       ` ZmnSCPxj
2022-02-21  9:11         ` ZmnSCPxj
2022-02-21  9:48         ` Prayank
2022-02-22 12:57           ` Billy Tetrud
2022-02-21  9:09       ` ZmnSCPxj
2022-01-03  2:05 Michael Folkson
2022-01-09 11:38 ` Peter Todd
2022-01-11  3:42   ` Jeremy
2022-01-11  4:38     ` Jeremy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ms_l-H3--3-2@tutanota.de \
    --to=prayank@tutanota.de \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=decker.christian@gmail.com \
    --cc=michaelfolkson@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox