From: Joost Jager <joost.jager@gmail•com>
To: Greg Sanders <gsanders87@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Date: Sat, 3 Jun 2023 11:14:27 +0200 [thread overview]
Message-ID: <CAJBJmV8Vt_LLH-AEo-fCCs+S6uSy9UwC6QBakWY5tzn9Utwb8w@mail.gmail.com> (raw)
In-Reply-To: <CAB3F3Dtad8Fqb4R1phFU33SQPoL66nRz3rSHNbAaDSF=RN1NOA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3453 bytes --]
HI Greg,
On Sat, Jun 3, 2023 at 3:14 AM Greg Sanders <gsanders87@gmail•com> 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
[-- Attachment #2: Type: text/html, Size: 4416 bytes --]
next prev parent reply other threads:[~2023-06-03 9:15 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-02 15:00 Joost Jager
2023-06-03 1:08 ` David A. Harding
2023-06-03 1:14 ` Greg Sanders
2023-06-03 9:14 ` Joost Jager [this message]
2023-06-03 15:50 ` Peter Todd
2023-06-15 9:36 ` Joost Jager
2023-06-15 10:39 ` Greg Sanders
2023-06-16 11:26 ` Joost Jager
2023-06-16 13:30 ` Greg Sanders
2023-06-18 20:32 ` Antoine Riard
2023-06-18 20:40 ` Greg Sanders
2023-06-19 1:14 ` Antoine Riard
2023-06-20 12:50 ` Joost Jager
2023-06-03 7:49 ` Joost Jager
2023-06-03 8:06 ` Joost Jager
2023-06-03 12:05 ` Greg Sanders
2023-06-03 12:35 ` Joost Jager
2023-06-03 12:43 ` Greg Sanders
2023-06-03 12:55 ` Joost Jager
2023-06-08 9:16 ` Joost Jager
2023-06-10 0:23 ` Antoine Riard
2023-06-10 7:43 ` Joost Jager
2023-06-10 22:09 ` David A. Harding
2023-06-11 19:25 ` Joost Jager
2023-06-12 3:16 ` Antoine Riard
2023-06-13 8:51 ` David A. Harding
2023-06-13 10:38 ` Joost Jager
2023-06-12 13:03 ` Greg Sanders
2023-06-20 12:30 ` Joost Jager
2023-07-04 20:18 ` Antoine Riard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJBJmV8Vt_LLH-AEo-fCCs+S6uSy9UwC6QBakWY5tzn9Utwb8w@mail.gmail.com \
--to=joost.jager@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gsanders87@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox