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: Thu, 15 Jun 2023 11:36:19 +0200 [thread overview]
Message-ID: <CAJBJmV88j7i3=uqnU5OwMCKyZaP9v6cx9EKEuK1FYs6aL0r1uw@mail.gmail.com> (raw)
In-Reply-To: <CAB3F3Dtad8Fqb4R1phFU33SQPoL66nRz3rSHNbAaDSF=RN1NOA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1603 bytes --]
next prev parent reply other threads:[~2023-06-15 9:37 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
2023-06-03 15:50 ` Peter Todd
2023-06-15 9:36 ` Joost Jager [this message]
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='CAJBJmV88j7i3=uqnU5OwMCKyZaP9v6cx9EKEuK1FYs6aL0r1uw@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