HI Greg, On Sat, Jun 3, 2023 at 3:14 AM Greg Sanders wrote: > 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 > briefly discussed here > https://github.com/bitcoin-inquisition/bitcoin/pull/22#discussion_r1143382264 > . > > 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? > > Some logs related to that here: > https://gist.github.com/instagibbs/7406931d953fd96fea28f85be50fc7bb > > Related discussion on possible BIP118 modifications to mitigate this in > tapscript-spending circumstances: > https://github.com/bitcoin-inquisition/bitcoin/issues/19 > While solutions such as making annex usage opt-in or imposing size limitations may initially appear effective, they may also inadvertently foster a false sense of security, as they lack alignment with economic incentives. Relying solely on policy enforcement merely transfers responsibility to the miners, without necessarily aligning their incentives with the broader network health. This situation is reminiscent of the challenges encountered with opt-in rbf. Despite signaling for non-replaceability, miners began accepting replacements probably due to the enticing higher fee incentives. At least that's how I picked up this development. Businesses that relied on zero-confirmation payments were unexpectedly affected, leading to undesirable outcomes. While we can define policy rules, miners will ultimately operate in a manner that maximizes their profits. Consequently, if a miner identifies an opportunity to bolster their fees by replacing an annex transaction, they're likely to seize it, regardless of any policy rules. This might not be readily apparent currently with a limited number of pools dominating block production, but it is my hope that mining will be more decentralized in the future. Depending on policy to mitigate this annex malleability vector could mislead developers into believing their transactions are immune to replacement, when in fact they might not be. This potential misalignment could result in developers and businesses constructing systems based on assumptions that could be compromised in the future, mirroring the situation that unfolded with zero-confirmation payments and rbf. It may thus be more prudent to permit the utilization of the annex without restrictions, inform developers of its inherent risks, and acknowledge that Bitcoin, in its present state, might not be ideally suited for certain types of applications? Joost