Covenant tools softfork

[jamesob]

@ajtowns

Personally, I think the “activation” part is probably the least interesting/useful thing to talk about.

I heartily agree. I meant less to talk about particular activation method and more put a stake in the ground on what I think a desirable target feature-set would be for the next soft fork.

I also didn’t mean to suggest that the literal HEAD of the draft PR is what I think we should merge - again, it was to give people a tangible reference point for what the shape of the change would look like.

@ajtowns

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.

I should maybe walk back some of my initial exuberance. In suggesting this fork, my goal was to focus the community on a particular feature set. It wasn’t to say that all the details have been ironed out and we’re ready to ship next week.

But consider how long both APO and CTV have been publicized. The refrain seems to always be “we just need x more years of thought experiments and testing.” If, as Jeremy said at some point, progress is a memoryless process, what are we really doing here?

At some point we need to decide on a direction and start getting serious about activating things that are widely regarded as desirable and safe in concept. Otherwise, in the immortal words of Jim Morrison, we’re just wallowing in the mire. Saying “we need more demos and tooling” hasn’t delivered a lot over the last few years, maybe in part because Bitcoin’s human capital is apparently out of proportion with our expectations on hurdles to clear.

@ajtowns

But using a two week old demo as an argument for activating a consensus change just seems way over-eager.

That’s a reasonable objection, my bad.

@ajtowns

Oh, also: ln-symmetry likely needs work on package relay and fees paid via ephemeral transactions and ways to avoid pinning

Just because something has multiple dependencies doesn’t mean we need to hold up progress on all the dependencies until they can proceed lockstep together. I think solving the package relay problem is pretty orthogonal to signatures that can bind to different outpoints, although no doubt that ln-symmetry certainly informs package relay’s design.

---

I want to be clear that my proposal isn’t “let’s merge this code now.” It’s “I think this would be a great feature set for the next update to script; can we agree on it and start to work towards particulars?”

I completely agree with you that more scrutiny, and testing is needed. But can you see the benefits of determining a shared goal to work towards? Right now the design space is so open and amorphous that paralysis seems pretty much assured.