Hello Joost, David,
Thanks for the link to my ln-symmetry draft David. I'd also be curious as to the usage you have in
mind Joost.
It's probably helpful to cite the most recent discussions on the topic, which is probably
the `annexcarrier` option. I have a particular use for APO-enabled payment channel designs
that doesn't require consensus meaning, so some effort was put in to try something out there.
Attempting to summarize the linked PR:
I think the biggest remaining issue to this kind of idea, which is why I didn't propose it for mainnet,
is the fact that BIP341/342 signature hashes do not cover *other* inputs' annex fields, which we
This means that in a coinjoin like scenario, even if the other joining parties prove they don't have any
crazy script paths, a malicious party can make the signed transaction into a maximum sized transaction
package, causing griefing. The mitigation in the PR I linked was to limit it to 126 bytes, basically punting
on the problem by making the grief vector small. 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. For those who opt-in, perhaps the first
order of business would be to have a field that limits the total transaction weight, by policy only?
Anyways, curious to hear what people think and want to make sure everyone is on the same page.
Best,
Greg