Hi Joost,

> Ignoring the argument that policy may provide a false sense of security

This may take longer form arguments than I'm willing to make on this thread, but I think this only true in a shallower sense that we cannot know for sure that anything will be confirmed quickly. When crafting policy, we are trying to make as reliable-as-possible systems to allow people to pay miners. That may mean opening up the annex to potential use-cases, but it certainly means allowing current users of the p2p network to make reasonable feerate transactions in coinjoin-like scenarios. Ideally we shoot for as many use cases as we can, to pay these miners.

> Would it then still be necessary to restrict the annex to a maximum size?

I think it's worth thinking about to protect the opt-in users, and can also be used for other anti-pinning efforts(though clearly not sufficient by itself for the many many pinning vectors we have :) )

Cheers,

Greg

On Thu, Jun 15, 2023 at 5:36 AM Joost Jager <joost.jager@gmail.com> wrote:

Hi Greg,

Getting back to this:

Another solution could be to make annex usage "opt-in"
by requiring all inputs to commit to an annex to be relay-standard. In this case, you've opted into a possible
vector, but at least current usage patterns wouldn't be unduly affected.

Ignoring the argument that policy may provide a false sense of security, I think this is an interesting idea. Opt-in would enable convenants through presigned txes with atomic on-chain signature backup, without needing to worry about non-annex multi-party protocols (coinjoin and dual funded lightning mentioned previously) that may suffer from annex inflation or the last signer presenting an unexpected annex. The downside is just that extra empty annex byte per input, if there are other inputs involved. To me that would be a reasonable trade-off.

Would it then still be necessary to restrict the annex to a maximum size? Perhaps not opting into annex for multi-party protocols is sufficient. Or otherwise, #24007 may be helpful. It is hard to pick a constant usually.

Joost.