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 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 >