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 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
