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