public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Joost Jager <joost.jager@gmail•com>
To: "David A. Harding" <dave@dtrt•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Date: Sun, 11 Jun 2023 21:25:42 +0200	[thread overview]
Message-ID: <CAJBJmV-eVZONZ-Qd54BLeN-6LCRNUpHOfLp3Ecg3HXT_AJzRLA@mail.gmail.com> (raw)
In-Reply-To: <fe630ee713829e1ce2df33a8438cbcf5@dtrt.org>

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

Hi Dave,

On Sun, Jun 11, 2023 at 12:10 AM David A. Harding <dave@dtrt•org> wrote:

> 3. When paying the script in #2, Alice chooses the scriptpath spend from
>     #1 and pushes a serialized partial signature for the ephemeral key
>     from #2 onto the stack, where it's immediately dropped by the
>     interpreter (but is permanently stored on the block chain).  She also
>     attaches a regular signature for the OP_CHECKSIG opcode.
>

Isn't it the case that that op-dropped partial signature for the ephemeral
key isn't committed to and thus can be modified by anyone before it is
mined, effectively deleting the keys to the vault? If not, this would be a
great alternative!

Even better, I think you can achieve nearly the same safety without
> putting any data on the chain.  All you need is a widely used
> decentralized protocol that allows anyone who can prove ownership of a
> UTXO to store some data.
>

I appreciate the suggestion, but I am really looking for a bitcoin-native
solution to leverage bitcoin's robustness and security properties.

By comparison, rolling
> out relay of the annex and witness replacement may take months of review
> and years for >90% deployment among nodes, would allow an attacker to
> lower the feerate of coinjoin-style transactions by up to 4.99%, would
> allow an attacker to waste 8 million bytes of bandwidth per relay node
> for the same cost they'd have to pay to today to waste 400 thousand
> bytes, and might limit the flexibility and efficiency of future
> consensus changes that want to use the annex.


That years-long timeline that you sketch for witness replacement (or any
other policy change I presume?) to become effective is perhaps indicative
of the need to have an alternative way to relay transactions to miners
besides the p2p network?

I agree though that it would be ideal if there is a good solution that
doesn't require any protocol changes or upgrade path.

Joost

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

  reply	other threads:[~2023-06-11 19:26 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
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 [this message]
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=CAJBJmV-eVZONZ-Qd54BLeN-6LCRNUpHOfLp3Ecg3HXT_AJzRLA@mail.gmail.com \
    --to=joost.jager@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=dave@dtrt$(echo .)org \
    /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