Couple of comments:
Personally, I think the “activation” part is probably the least interesting/useful thing to talk about.
I don’t really think that’s quite true: there’s a couple of outstanding changes to BIP 118 that seem pretty likely to be desirable (inq#19); and I don’t really think either 118 or 119 have really been super well scrutinized. Meanwhile, 345 hasn’t had been officially published yet.
The link there goes to a project whose first commit was two weeks ago. To me, that’s an exciting first step – I’d rather read about how that works, see demo transactions, and think about if either it’s broken, or if it could be improved, either with better use of the proposed features, or with alternative proposals. But using a two week old demo as an argument for activating a consensus change just seems way over-eager.
I wouldn’t call the bip 118 code “comprehensively tested” – implementing the proposed change mentioned above doesn’t cause any breakage in the unit tests, and there aren’t test vectors included with the BIP, eg.
For me, I’d rate the next steps as:
- make it easy for people to try out demos and see what value they have (the vault stuff, ln-symmetry, spacechains?), ideally being able to run a live demo in public, in a way that allows people to attempt to attack it
- improve tooling for all this stuff – we still don’t really have all the tooling for taproot, after all (eg musig2, adaptor signatures, descriptors to specify specific tapscripts…)
- once we’ve demonstrated that these really are good idea, get more thorough review of everything, including:
- more tests
- check if there’s any tangible improvements to be had from tweaking the API (
op_txhashetc) - do our best to make sure that people can understand the proposed changes and judge them on their merits
- only then see about activating them