[bitcoin-dev] Stumbling into a contentious soft fork activation attempt

[Prayank]

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 at gmail.com:

> Prayank via bitcoin-dev <bitcoin-dev at 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220104/033290d3/attachment.html>