public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Joost Jager <joost.jager@gmail•com>
To: Antoine Riard <antoine.riard@gmail•com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	Greg Sanders <gsanders87@gmail•com>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Date: Tue, 20 Jun 2023 14:50:47 +0200	[thread overview]
Message-ID: <CAJBJmV9K351SG3FTLF0xxC-y5KV4CD6upiQoir+a3p2KBe4fDA@mail.gmail.com> (raw)
In-Reply-To: <CALZpt+FUzpr=3jUfQmqs=LFBjOU=0Ah-snipf-_j1PQKuC4seQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

Hi Antoine,

On Sun, Jun 18, 2023 at 10:32 PM Antoine Riard <antoine.riard@gmail•com>
wrote:

> > * Opt-in annex (every input must commit to an annex even if its is
> empty) -> make sure existing multi-party protocols remain unaffected
>
> By requiring every input to commit to an annex even if it is empty, do you
> mean rejecting a transaction where the minimal annex with its 0x50 tag is
> absent ?
>

No what I meant, and what was mentioned by Greg in a previous email, is
that either none of the inputs have an annex, or all of them have one.

So if you're part of a multi-party transaction and you don't commit to an
annex, you can be sure that no version of that tx will appear where another
signer surprises you with a potentially large annex.

For future protocols that rely on the annex, everyone would need to opt-in
by committing to an annex (which can be empty just to signal opt-in).

Joost

[-- Attachment #2: Type: text/html, Size: 1347 bytes --]

  parent reply	other threads:[~2023-06-20 12:51 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
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 [this message]
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=CAJBJmV9K351SG3FTLF0xxC-y5KV4CD6upiQoir+a3p2KBe4fDA@mail.gmail.com \
    --to=joost.jager@gmail$(echo .)com \
    --cc=antoine.riard@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