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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev