From: Antoine Riard <antoine.riard@gmail•com>
To: Joost Jager <joost.jager@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Standardisation of an unstructured taproot annex
Date: Tue, 4 Jul 2023 21:18:23 +0100 [thread overview]
Message-ID: <CALZpt+GZd8kv4Nq-ANR26GPeT_6+0U8zRnsQM1_OLOuhxD7QFg@mail.gmail.com> (raw)
In-Reply-To: <CAJBJmV-PbDbi_9=z16yq7+cxhOzrfqvbN8=t-Kd3eWx_M5wSoA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4111 bytes --]
Hi Joost,
> Hopefully this further raises awareness of the on-chain ephemeral
signature backup functionality that the annex uniquely enables.
From my perspective, if vault applications can be made more robust by
on-chain backing up of ephemeral signatures, this can be rational to make
the annex standard.
There is the observation that other critical elements of vault's
application state could be backed up in this way (e.g pubkeys and amounts
of the destination output) to rebuild from scratch a pre-signed withdrawal.
The unstructured data could be even marked by an application-level "tag" or
"signaling" to identify all the backup annexes composing your vault
application state.
Of course, such backing up of more critical elements comes with its own
drawbacks in terms of confidentiality, as you would leak your vault policy
on-chain, so they would need to be ciphered first, I think.
It sounds to me another economically rational set of use-cases can be to
simplify protocols using the chain as a publication space for collectibles.
Using the annex as a publication space enables a clear chain of collectible
ownership thanks to the key signing the annex, which is not permissible
with op_return outputs today.
Best,
Antoine
Le mar. 20 juin 2023 à 13:30, Joost Jager <joost.jager@gmail•com> a écrit :
> Hi all,
>
> On Sat, Jun 10, 2023 at 9:43 AM Joost Jager <joost.jager@gmail•com> wrote:
>
>> However, the primary advantage I see in the annex is that its data isn't
>> included in the calculation of the txid or a potential parent commit
>> transaction's txid (for inscriptions). I've explained this at [1]. This
>> feature makes the annex a powerful tool for applications that would ideally
>> use covenants.
>>
>> The most critical application in this category, for me, involves
>> time-locked vaults. Given the positive reception to proposals such as
>> OP_VAULT [2], I don't think I'm alone in this belief. OP_VAULT is probably
>> a bit further out, but pre-signed transactions signed using an ephemeral
>> key can fill the gap and improve the safeguarding of Bitcoin in the short
>> term.
>>
>> Backing up the ephemeral signatures of the pre-signed transactions on the
>> blockchain itself is an excellent way to ensure that the vault can always
>> be 'opened'. However, without the annex, this is not as safe as it could
>> be. Due to the described circular reference problem, the vault creation and
>> signature backup can't be executed in one atomic operation. For example,
>> you can store the backup in a child commit/reveal transaction set, but the
>> vault itself can be confirmed independently and the backup may never
>> confirm. If you create a vault and lose the ephemeral signatures, the funds
>> will be lost.
>>
>> This use case for the annex has been labeled 'speculative' elsewhere. To
>> me, every use case appears speculative at this point because the annex
>> isn't available. However, if you believe that time-locked vaults are
>> important for Bitcoin and also acknowledge that soft forks, such as the one
>> required for OP_VAULT, aren't easy to implement, I'd argue that the
>> intermediate solution described above is very relevant.
>>
>
> To support this use case of the taproot annex, I've create a simple demo
> application here: https://github.com/joostjager/annex-covenants
>
> This demo shows how a coin can be spent to a special address from which it
> can - at a later stage - only move to a pre-defined final destination. It
> makes use of the annex to store the ephemeral signature for the presigned
> transaction so that the coin cannot get lost. This is assuming that nodes
> do not prune witness data en masse and also that the destination address
> itself is known.
>
> The application may not be the most practically useful, but more advanced
> covenants such as time-locked vaults can be implemented similarly.
>
> Hopefully this further raises awareness of the on-chain ephemeral
> signature backup functionality that the annex uniquely enables.
>
> Joost
>
[-- Attachment #2: Type: text/html, Size: 5121 bytes --]
prev parent reply other threads:[~2023-07-04 20:18 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
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 [this message]
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=CALZpt+GZd8kv4Nq-ANR26GPeT_6+0U8zRnsQM1_OLOuhxD7QFg@mail.gmail.com \
--to=antoine.riard@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=joost.jager@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