path: root/2f/5da099a7ecd43f8a7495cba67f9a009ca57851

Delivery-date: Mon, 05 May 2025 19:01:47 -0700
Received: from mail-yb1-f185.google.com ([209.85.219.185])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBDDJX3VKZACRB7624XAAMGQEEFPKHOY@googlegroups.com>)
	id 1uC7cv-0003u2-5E
	for bitcoindev@gnusha.org; Mon, 05 May 2025 19:01:46 -0700
Received: by mail-yb1-f185.google.com with SMTP id 3f1490d57ef6-e7330b53f6bsf7816745276.2
        for <bitcoindev@gnusha.org>; Mon, 05 May 2025 19:01:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1746496899; x=1747101699; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:sender:from:to:cc:subject:date
         :message-id:reply-to;
        bh=zXCcK1tcl8uN5uUKe2p1pOxD3PhQeHYF3Q/28p56LgA=;
        b=eGb1vuPcvYtFoGz6kBIdr9mIRJ+JviHDq9OGfeAySzO9d18yrkN7wmRDmR8b5U2brl
         JtgPa/IYQT+Ri/Z26PqAj++PMnI3Gfk4V7pfAY/NqBhvYTfBVk0xacJxVUzID8LWhRp4
         PBiLGRcWkhhdc2ekQdHBdyfXJ4E1O3pKDGL9UBvaxUJSc2VaBkWyaWxdiHAuJIeaCG+o
         b5Hmqw03EJ2gC6OWM8OJXrrDyfVYGLbWxDIPW9E8UMx/lxX/3tGPd0ofRZ9a3qZ01K8M
         0WtINOuDcS/jvROisMvGSiLxM9UnkHe0UIwhmht/n3OyD1WYEDLOehsnRQ6uCX0+x3XA
         25xA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1746496899; x=1747101699; darn=gnusha.org;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:from:to:cc:subject:date:message-id
         :reply-to;
        bh=zXCcK1tcl8uN5uUKe2p1pOxD3PhQeHYF3Q/28p56LgA=;
        b=NzipMps2eN2v/CiWtt64CpPPMzS7mjElkvkaXcVoLJLMx4tFUHmCnimDYSSNEU+MLl
         w3wbmrNb19CAtEhFxcP6z9It7oxdyswjgsVZivyyOSc1J/z3WKDcYEwp8hob8ZeciyiP
         QvzSVPUurB61i4O2CcR7P/8gwoGtzCgywhZanVJWmMydl05SMk8gZ1jHHFG1ISJWHBi/
         /S6Wbl25/vlGmC34aJDwRZ8VaZ3HNpS3EIJCoaEplSNzqLV6ybZd9bx3iRo2E4+i1/Dm
         RJQ6rfGXIGv7NwgeuCHVaJZ6cS2bslmKstVI2gj5ec/dNrl6aUKLGVQxIQ6X9KmQTL1g
         RT2A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1746496899; x=1747101699;
        h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post
         :list-id:mailing-list:precedence:x-original-sender:mime-version
         :subject:message-id:to:from:date:x-beenthere:x-gm-message-state
         :sender:from:to:cc:subject:date:message-id:reply-to;
        bh=zXCcK1tcl8uN5uUKe2p1pOxD3PhQeHYF3Q/28p56LgA=;
        b=abUxv5ztUh2NcVV96nrEEOqut5aNE8DXL1ElvjcSeXIXujf23ef3iBaSLx5TlqHQDL
         O1hCHxCyo0QUCLY702lhdjqMJ0YDrSnJYjn4JcLNUAGuXJZwrSheDRkLo6QkGRQT97fO
         sTMG0xO3b1yK5xoOTTuu1cd+OOgiV29aBbJ2So1HWu4Whc/31lNS49+is0uoRW0fFs5y
         8tgSu9g+gO7bYHikGnC1wNc6yGIVln5o803XxTJ7eEdO88nLijdvF/82Qjx8rsjG3tm/
         VwYoZlDfgv+00SehPWFnz3cekHCodI13ftDQfqUv0fsEtKvrHMeEFkeepjHjE3S/ROHT
         0xRA==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCWCgR1dRZtYsidoHpOtzEUMVCSyqxBcRaWiSlo8AG9StS5IlUSupATAIML90E6qVKaYKGxIzn3W1kpL@gnusha.org
X-Gm-Message-State: AOJu0YwzoMDP/uUmYTtjDMWvza7PknHXQavUkzfSQk2+ponbHQTk7OHY
	qo4j96s2p1Aymnu8e1J9tiUSCSgNx5TRuangc5z+wyu7mn8XPUip
X-Google-Smtp-Source: AGHT+IFTRgPv7jURyl1RrieUVHY6HFvEVn53TF+bNSFcfr38c0f8vgTxTKCog5mhz1nQlvnF8DLt8w==
X-Received: by 2002:a05:6902:110f:b0:e60:9dd3:38c9 with SMTP id 3f1490d57ef6-e75bf67d5f4mr2407039276.7.1746496898714;
        Mon, 05 May 2025 19:01:38 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AVT/gBEJrejkJPFcOddlsSMyU2HfUaPyxAjOo7mvhh3LPSOhBw==
Received: by 2002:a25:2d0e:0:b0:e74:6e83:3091 with SMTP id 3f1490d57ef6-e74dc4dae66ls1444333276.1.-pod-prod-01-us;
 Mon, 05 May 2025 19:01:34 -0700 (PDT)
X-Received: by 2002:a05:690c:9993:b0:708:39f9:ae22 with SMTP id 00721157ae682-708cf22111fmr208877377b3.27.1746496894656;
        Mon, 05 May 2025 19:01:34 -0700 (PDT)
Received: by 2002:a05:690c:a10:b0:708:1ea1:3cd5 with SMTP id 00721157ae682-708cfde0f16ms7b3;
        Mon, 5 May 2025 18:27:46 -0700 (PDT)
X-Received: by 2002:a05:690c:3612:b0:6f9:7a3c:1fe with SMTP id 00721157ae682-708cf21ffefmr209356637b3.23.1746494864909;
        Mon, 05 May 2025 18:27:44 -0700 (PDT)
Date: Mon, 5 May 2025 18:27:44 -0700 (PDT)
From: Josh Doman <joshsdoman@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <0b5b560b-aa0c-4669-9621-67ccbecba516n@googlegroups.com>
Subject: [bitcoindev] Graftleaf: Program Composition and Generic Delegation
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_8432_1006590177.1746494864548"
X-Original-Sender: joshsdoman@gmail.com
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com
List-ID: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
X-Spam-Score: -0.5 (/)

------=_Part_8432_1006590177.1746494864548
Content-Type: multipart/alternative; 
	boundary="----=_Part_8433_1117693382.1746494864548"

------=_Part_8433_1117693382.1746494864548
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

=20

*TLDR: I'm exploring an idea to enable generalized program composition and=
=20
coin delegation, which seems to strike a nice balance between simplicity=20
and flexibility.*

Hi all,

I=E2=80=99ve been thinking recently about the optimal way to introduce dele=
gation=20
to Bitcoin. The idea of delegating one=E2=80=99s coins is not a new one. So=
me=20
speculate <https://bitcoinops.org/en/topics/op_codeseparator/> that OP_
CODESEPARATOR was an early attempt by Satoshi to do delegation. More=20
recently, proposals like Graftroot=20
<https://gnusha.org/pi/bitcoindev/CAAS2fgSnfd++94+40vnSRxQfi9fk8N6+2-DbjVps=
sHxFvYveFQ@mail.gmail.com/>
 and Entroot <https://gist.github.com/sipa/ca1502f8465d0d5032d9dd2465f32603=
>
 have been put forward, which would enable delegation (and re-delegation),=
=20
but only from key path spends and only to a locking script. In contrast,=20
CSFS <https://github.com/bitcoin/bips/blob/master/bip-0348.md> would enable=
=20
delegation from script path spends, but it's limited, as it only=20
facilitates delegation within a pre-committed script.

When considering delegation, what type of functionality is desirable? I=E2=
=80=99d=20
argue that generalized delegation has two properties:

   1. Delegation *from any valid spending path*
   2. Delegation *to arbitrarily complex compositions of programs and=20
   script*

The latter is important so that users can delegate to *addresses*, and not=
=20
just public keys, while retaining the ability to add timelocks and other=20
conditions.

In order to build this, we need two key features: 1) "Generalized=20
Composition," and 2) "Generalized Delegation." Generalized composition=20
involves the conjunction of programs and script, and delegation is merely=
=20
the addition of a second composition on-the-fly, if the primary one is=20
satisfied.

Is there a simple and safe way to implement generalized composition and=20
delegation within Taproot? I think there is...

I=E2=80=99d like to present a proof-of-concept that I came up with, which I=
'm=20
calling "Graftleaf."
Proposal: Graftleaf

Graftleaf is a new Taproot leaf version (0xc2), which uses the annex to=20
perform delegations. Graftleaf adds two significant capabilities:

   1. *Composition*: The ability to execute zero, one, or more witness=20
   programs in sequence, including a locking script.
   2. *Delegation*: The ability to add additional spending conditions at=20
   signature-time, which can comprise any combination of programs and scrip=
t.

The core execution logic is fewer than 60 lines of code. You can find my=20
implementation here <https://github.com/joshdoman/bitcoin/pull/1>. I=E2=80=
=99ve=20
included a fairly large test suite, though there=E2=80=99s definitely room =
for=20
improvement.

Below are some technical details on how it works. I wrap up with a more=20
in-depth comparison versus existing proposals and a brief discussion of=20
some possible use cases. I=E2=80=99d appreciate feedback, and I hope this w=
ork is=20
of interest to the community.
Technical Overview

This implementation creates a new tapleaf version (0xc2) and gives=20
consensus meaning to the annex when this leaf version is used:
Composition Mechanism
  =20
   - Multiple witness programs can be executed in sequence
   - Each program has its own section of the witness stack, defined by=20
   explicit size elements
   - Programs can be different witness versions (v1+) or script
   - Resource limits (stack size, validation weight) are preserved and=20
   enforced across executions
   - Signatures commit to the chain of tapleafs and annexes in the=20
   execution path to prevent witness malleability and replay attacks
   - If the annex is absent, empty, or begins with 0x00, all elements on=20
   the stack must be consumed

Delegation Mechanism
  =20
   - Users can commit to additional spending conditions at signature-time=
=20
   using the annex
   - Any valid composition of programs and script can be delegated to
   - Delegation is indicated by an annex beginning with the tag 0x01
   - Annexes starting with the tag 0x01 are forbidden unless signed to=20
   prevent witness malleability
   - After delegated execution completes, all elements on the stack must be=
=20
   consumed

Technical Deep DiveComposition

A composed program consists of multiple subprograms that execute in=20
sequence. Each subprogram operates on its own portion of the witness stack,=
=20
defined by a size element that indicates how many witness elements belong=
=20
to the program.

The witness stack for a composed program looks like:
[program1 witness elements] [program2 witness elements] ... [programN=20
witness elements] [size element for programN] ... [size element for=20
program2] [size element for program1] [tapleaf] [control block]=20

Each size element encodes the number of stack items for its corresponding=
=20
program and is at most two bytes. Execution begins with the first program=
=20
and continues through each program in sequence.

The tapleaf encodes the list of programs as [witness version][program=20
length][program]. If the witness version is 0xc0, all subsequent bytes are=
=20
interpreted as script. Witness version 0 is not allowed as it is not=20
compatible with tapscript.

Tapleaf Example 1 (a series of programs composed with script):
[program1 witness version] [program1 program length] [program1] =E2=80=A6 [=
programN=20
witness version] [programN program length] [programN] [0xc0] [script]=20

Tapleaf Example 2 (a program composed of only script):
[0xc0] [script]=20

If the program is empty or the annex is absent, empty, or begins with 0x00,=
=20
the stack must be empty post-execution for validation to succeed.=20
Delegation

Delegation is implemented via the annex. When a non-empty annex is present=
=20
with the leaf version 0xc2 and the annex begins with the tag 0x01, the=20
remainder of the annex is interpreted as a composed program to be executed=
=20
after the primary program completes.

The witness stack for delegation looks like:
[primary program witness elements] [delegated program witness elements]=20
[size elements for delegated program] [size elements for primary program]=
=20
[tapleaf] [control block] [annex] (0x01 [delegated composed witness=20
program])=20

The primary program executes first according to the composition rules. If=
=20
successful and a signed annex exists with the 0x01 tag, the remaining stack=
=20
elements are passed to the delegated witness program. When delegated=20
execution completes, the stack must be empty for validation to succeed.

Annex tags 0x02+ are left as an upgrade path for future modes of delegation=
=20
and uses of the annex.
Resource Limitations

The validation weight budget is tracked and decremented across all=20
compositions and delegations, ensuring that programs cannot bypass global=
=20
resource limits.

Likewise, the global stack size limit is enforced by requiring both the=20
total stack size and the EvalScript stack size to be at most MAX_STACK_SIZE=
=20
/ 2 after a 0xc2 tapleaf is encountered. This conservatively ensures that=
=20
the total stack size remains at most MAX_STACK_SIZE.
Security Considerations

Replay attacks and witness malleability are the primary security concerns.=
=20
To prevent replay attacks, signatures commit to the full chain of tapleafs=
=20
and annexes in the execution path. This provides protection in the event=20
that there are multiple possible execution paths that the user may sign.=20

In addition, to prevent witness malleability, execution fails if a=20
delegating annex is not signed. The annex can be signed directly, or it can=
=20
be signed by a child program, which must commit to the full chain of=20
annexes in the execution path.
Potential Benefits

This proposal has several potential benefits, including:

   1. *Backward-compatibility*: Works with existing P2TR addresses.
   2. *Enhanced composability*: Enables "vault-of-vaults" and other complex=
=20
   spending policies, compatible with new witness programs adopted in the=
=20
   future (ex: P2QRH).
   3. *Generalized delegation*: Allows users to authorize additional=20
   spending conditions at signature-time, delegating to any combination of=
=20
   addresses and script.
   4. *Re-delegation*: Allows users to re-delegate to other users, adding=
=20
   additional restrictions to the structure of the final transaction.
   5. *Improved privacy and fungibility*: Could increase P2TR adoption by=
=20
   encouraging users to adopt wallets and vaults that can be composed with =
and=20
   delegated to.

Additional benefits may include:

   1. *Delegation-only opcodes*: Creates framework to allow math and=20
   introspection opcodes (ex: OP_CAT) to be committed to in an annex but=20
   not in a scriptPubKey. Such opcodes could then be safely used during=20
   delegation without enabling AMMs or state-carrying recursive covenants.
   2. *Compatibility with future upgrades*: Provides framework for future=
=20
   witness programs and uses of the annex.

Use CasesVault-of-Vaults

Ex: Alice, Bob, and Carol create a 2-of-3 vault by combining their P2TR=20
addresses, rather than their public keys. Each address corresponds to a=20
personal vault that Alice, Bob, or Carol controls. This can be a single=20
sig, a 2-of-3 multisig, a decaying multisig, or something more complex.=20
Only two addresses must be satisfied in order to unlock the funds. If=20
desired, additional spending paths can be added, such as a time-delayed=20
backup, accessible by a single party.

This vault-of-vaults is easy to audit and assemble, and parties can=20
selectively reveal their spending paths to the other parties, or not reveal=
=20
any except those that are used.
Receiver-Paid Payments

Ex: Alice pays Bob without committing to the fee rate of the transaction.=
=20
Alice simply delegates a portion of her balance to Bob, sending herself the=
=20
residual using SINGLE|ANYONECANPAY. Bob can then complete the transaction=
=20
and choose the appropriate fee rate.

This basic pattern could be used to support more complex payment flows in=
=20
the future.
Bitcoin Markets

Ex: With a single signature, Bob can make an offer to sell a UTXO-linked=20
asset from cold storage to one of many possible approved buyers, in=20
exchange for bitcoin. Using timelocks, Bob could even give some buyers a=20
right-of-first-refusal.

Likewise, if an introspection opcode is enabled, Bob could offer bitcoin to=
=20
many possible recipients, in exchange for some onchain or offchain asset=20
tied to a UTXO. The ability to commit to a specific UTXO is important=20
because it provides a built-in mechanism to cancel the offer, if the asset=
=20
is transferred to someone else.
A Path to Key Path Delegation

Graftleaf lays the groundwork for delegation from script path *and* key=20
path spends using the annex. Unfortunately, BIP341 Taproot does not appear=
=20
to have an upgrade mechanism for key path spends, since a key path spend is=
=20
only possible with a witness stack that has only one element after removing=
=20
the (optional) annex. This can be resolved with a new witness program, but=
=20
it would require a new address type, which history shows can take a long=20
time for industry to adopt.
Comparison with Other Proposals

This proposal shares similarities with several other proposals:

   - *Graftroot*: Allows delegation but only from key path spends and only=
=20
   once
   - *CSFS*: Complementary feature for re-binding signatures to=20
   pre-committed scripts
   - *G=E2=80=99root*: Complementary feature that uses Pederson commitments=
 to add=20
   script commitments to key path spends
   - *Entroot*: Combines ideas from Graftroot and G=E2=80=99root, replacing=
=20
   Pederson commitments with a hash-to-curve scheme, but only facilitates=
=20
   delegations from key path spends and compositions between a key path spe=
nd=20
   and script.

Pieter Wuille=E2=80=99s Entroot is perhaps the closest cousin to this propo=
sal. The=20
primary difference is that this proposal enables:

   1. Script path delegation
   2. Delegation from a composition of programs and script
   3. Arbitrarily complex compositions on a single leaf

In addition, this proposal does not require hash-to-curve or a new address=
=20
type. The core composition and delegation logic is upgradeable and=20
reusable, if new programs with hash-to-curve or key path delegation are=20
added in the future.
Concluding Thoughts

I have taken care to consider possible edge cases and respect resource=20
limitations, but if there is anything I have missed, I'd welcome the=20
community's feedback (this is my first formal proposal). Naturally, soft=20
fork proposals are highly contentious, but I believe that generic=20
composition and delegation is an important architectural problem for=20
Bitcoin to solve, provided there=E2=80=99s a way to do so safely with accep=
table=20
tradeoffs.

If there=E2=80=99s interest in a BIP, please let me know. Given the scope, =
this=20
probably deserves two BIPs, and I=E2=80=99d be happy to draft something up.

Sincerely,

Joshua Doman

**Special thanks to Alex Lewin for reviewing early drafts of this email*

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/=
0b5b560b-aa0c-4669-9621-67ccbecba516n%40googlegroups.com.

------=_Part_8433_1117693382.1746494864548
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


    <div aria-label=3D"Message Body" role=3D"textbox" aria-multiline=3D"tru=
e" tabindex=3D"1" aria-controls=3D":1f5" aria-expanded=3D"false" style=3D"c=
aret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); direction: ltr; min-height: =
289px;"><p><em>TLDR: I'm exploring an idea to enable generalized program co=
mposition and coin delegation, which seems to strike a nice balance between=
 simplicity and flexibility.</em></p><p>Hi all,</p><p>I=E2=80=99ve been thi=
nking recently about the optimal way to introduce delegation to Bitcoin. Th=
e idea of delegating one=E2=80=99s coins is not a new one. Some=C2=A0<a hre=
f=3D"https://bitcoinops.org/en/topics/op_codeseparator/" target=3D"_blank">=
speculate</a>=C2=A0that=C2=A0<span>OP_<span></span>CODESEPARATOR</span>=C2=
=A0was an early attempt by Satoshi to do delegation. More recently, proposa=
ls like=C2=A0<a href=3D"https://gnusha.org/pi/bitcoindev/CAAS2fgSnfd++94+40=
vnSRxQfi9fk8N6+2-DbjVpssHxFvYveFQ@mail.gmail.com/" target=3D"_blank">Graftr=
oot</a>=C2=A0and=C2=A0<a href=3D"https://gist.github.com/sipa/ca1502f8465d0=
d5032d9dd2465f32603" target=3D"_blank"><span>Entroot</span></a>=C2=A0<span>=
</span>have been put forward, which would enable delegation (and re-delegat=
ion), but only from key path spends and only to a locking script. In contra=
st,=C2=A0<a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0348.md=
" target=3D"_blank">CSFS</a>=C2=A0would enable delegation from script path =
spends, but it's limited, as it only facilitates delegation within a pre-co=
mmitted script.</p><p>When considering delegation, what type of functionali=
ty is desirable? I=E2=80=99d argue that generalized delegation has two prop=
erties:</p><ol><li style=3D"margin-left: 15px;">Delegation=C2=A0<em>from an=
y valid spending path</em></li><li style=3D"margin-left: 15px;">Delegation=
=C2=A0<em>to arbitrarily complex compositions of programs and script</em></=
li></ol><p>The latter is important so that users can delegate to=C2=A0<em>a=
ddresses</em>, and not just public keys, while retaining the ability to add=
 timelocks and other conditions.</p><p>In order to build this, we need two =
key features: 1) "Generalized Composition," and 2) "Generalized Delegation.=
" Generalized composition involves the conjunction of programs and script, =
and delegation is merely the addition of a second composition on-the-fly, i=
f the primary one is satisfied.</p><p>Is there a simple and safe way to imp=
lement generalized composition and delegation within Taproot? I think there=
 is...</p><p>I=E2=80=99d like to present a proof-of-concept that I came up =
with, which I'm calling "Graftleaf."<br /></p><span>Proposal: <span>Graftle=
af</span></span><p><span>Graftleaf</span> is a new Taproot leaf version (0x=
c2), which uses the annex to perform delegations. Graftleaf adds two signif=
icant capabilities:</p><ol><li style=3D"margin-left: 15px;"><strong>Composi=
tion</strong>: The ability to execute zero, one, or more witness programs i=
n sequence, including a locking script.</li><li style=3D"margin-left: 15px;=
"><strong>Delegation</strong>: The ability to add additional spending condi=
tions at signature-time, which can comprise any combination of programs and=
 script.</li></ol><p>The core execution logic is fewer than 60 lines of cod=
e. You can find my implementation=C2=A0<a href=3D"https://github.com/joshdo=
man/bitcoin/pull/1" target=3D"_blank">here</a>.=C2=A0I=E2=80=99ve included =
a fairly large test suite, though there=E2=80=99s definitely room for impro=
vement.</p><p>Below are some technical details on how it works. I wrap up w=
ith a more in-depth comparison versus existing proposals and a brief discus=
sion of some possible use cases. I=E2=80=99d appreciate feedback, and I hop=
e this work is of interest to the community.</p><span>Technical Overview</s=
pan><p>This implementation creates a new tapleaf version (0xc2) and gives c=
onsensus meaning to the annex when this leaf version is used:</p><span>Comp=
osition Mechanism</span><ul><li style=3D"margin-left: 15px;">Multiple witne=
ss programs can be executed in sequence</li><li style=3D"margin-left: 15px;=
">Each program has its own section of the witness stack, defined by explici=
t size elements</li><li style=3D"margin-left: 15px;">Programs can be differ=
ent witness versions (v1+) or script</li><li style=3D"margin-left: 15px;">R=
esource limits (stack size, validation weight) are preserved and enforced a=
cross executions</li><li style=3D"margin-left: 15px;">Signatures commit to =
the chain of tapleafs and annexes in the execution path to prevent witness =
malleability and replay attacks</li><li style=3D"margin-left: 15px;">If the=
 annex is absent, empty, or begins with 0x00, all elements on the stack mus=
t be consumed</li></ul><span>Delegation Mechanism</span><ul><li style=3D"ma=
rgin-left: 15px;">Users can commit to additional spending conditions at sig=
nature-time using the annex</li><li style=3D"margin-left: 15px;">Any valid =
composition of programs and script can be delegated to</li><li style=3D"mar=
gin-left: 15px;">Delegation is indicated by an annex beginning with the tag=
 0x01</li><li style=3D"margin-left: 15px;">Annexes starting with the tag 0x=
01 are forbidden unless signed to prevent witness malleability</li><li styl=
e=3D"margin-left: 15px;">After delegated execution completes, all elements =
on the stack must be consumed</li></ul><span>Technical Deep Dive</span><spa=
n>Composition</span><p>A composed program consists of multiple subprograms =
that execute in sequence. Each subprogram operates on its own portion of th=
e witness stack, defined by a size element that indicates how many witness =
elements belong to the program.</p><p>The witness stack for a composed prog=
ram looks like:</p><span style=3D"text-wrap-mode: wrap;"><span>[program1 wi=
tness elements]
[program2 witness elements]
...
[programN witness elements]
[size element for programN]
...
[size element for program2]
[size element for program1]
[tapleaf]
[control block]
</span></span><p>Each size element encodes the number of stack items for it=
s corresponding program and is at most two bytes. Execution begins with the=
 first program and continues through each program in sequence.</p><p>The ta=
pleaf encodes the list of programs as=C2=A0<span>[witness version][program =
length][program]</span>. If the witness version is 0xc0, all subsequent byt=
es are interpreted as script. Witness version 0 is not allowed as it is not=
 compatible with <span>tapscript</span>.</p><p>Tapleaf Example 1 (a series =
of programs composed with script):</p><span style=3D"text-wrap-mode: wrap;"=
><span>[program1 witness version]
[program1 program length]
[program1]
=E2=80=A6
[programN witness version]
[programN program length]
[programN]
[0xc0]
[script]
</span></span><p>Tapleaf Example 2 (a program composed of only script):</p>=
<span style=3D"text-wrap-mode: wrap;"><span>[0xc0]
[script]
</span></span><p>If the program is empty or the annex is absent, empty, or =
begins with 0x00, the stack must be empty post-execution for validation to =
succeed.=C2=A0</p><span>Delegation</span><p>Delegation is implemented via t=
he annex. When a non-empty annex is present with the leaf version 0xc2 and =
the annex begins with the tag 0x01, the remainder of the annex is interpret=
ed as a composed program to be executed after the primary program completes=
.</p><p>The witness stack for delegation looks like:</p><span style=3D"text=
-wrap-mode: wrap;"><span>[primary program witness elements]
[delegated program witness elements]
[size elements for delegated program]
[size elements for primary program]
[tapleaf]
[control block]
[annex] (0x01 [delegated composed witness program])
</span></span><p>The primary program executes first according to the compos=
ition rules. If successful and a signed annex exists with the 0x01 tag, the=
 remaining stack elements are passed to the delegated witness program. When=
 delegated execution completes, the stack must be empty for validation to s=
ucceed.</p><p>Annex tags 0x02+ are left as an upgrade path for future modes=
 of delegation and uses of the annex.</p><span>Resource Limitations</span><=
p>The validation weight budget is tracked and decremented across all compos=
itions and delegations, ensuring that programs cannot bypass global resourc=
e limits.</p><p>Likewise, the global stack size limit is enforced by requir=
ing both the total stack size and the=C2=A0<span>EvalScript</span>=C2=A0sta=
ck size to be at most=C2=A0<span>MAX_STACK_SIZE / 2</span>=C2=A0after a 0xc=
2 tapleaf is encountered. This conservatively ensures that the total stack =
size remains at most=C2=A0<span>MAX_STACK_SIZE</span>.</p><span>Security Co=
nsiderations</span><p>Replay attacks and witness malleability are the prima=
ry security concerns. To prevent replay attacks, signatures commit to the f=
ull chain of tapleafs and annexes in the execution path. This provides prot=
ection in the event that there are multiple possible execution paths that t=
he user may sign.=C2=A0</p><p>In addition, to prevent witness malleability,=
 execution fails if a delegating annex is not signed. The annex can be sign=
ed directly, or it can be signed by a child program, which must commit to t=
he full chain of annexes in the execution path.</p><span>Potential Benefits=
</span><p>This proposal has several potential benefits, including:</p><ol><=
li style=3D"margin-left: 15px;"><strong>Backward-compatibility</strong>: Wo=
rks with existing P2TR addresses.</li><li style=3D"margin-left: 15px;"><str=
ong>Enhanced composability</strong>: Enables "vault-of-vaults" and other co=
mplex spending policies, compatible with new witness programs adopted in th=
e future (ex: P2QRH).</li><li style=3D"margin-left: 15px;"><strong>Generali=
zed delegation</strong>: Allows users to authorize additional spending cond=
itions at signature-time, delegating to any combination of addresses and sc=
ript.</li><li style=3D"margin-left: 15px;"><strong>Re-delegation</strong>: =
Allows users to re-delegate to other users, adding additional restrictions =
to the structure of the final transaction.</li><li style=3D"margin-left: 15=
px;"><strong>Improved privacy and fungibility</strong>: Could increase P2TR=
 adoption by encouraging users to adopt wallets and vaults that can be comp=
osed with and delegated to.</li></ol><p>Additional benefits may include:</p=
><ol><li style=3D"margin-left: 15px;"><strong>Delegation-only opcodes</stro=
ng>: Creates framework to allow math and introspection opcodes (ex:=C2=A0<s=
pan>OP_CAT</span>) to be committed to in an annex but not in a scriptPubKey=
. Such opcodes could then be safely used during delegation without enabling=
 AMMs or state-carrying recursive covenants.</li><li style=3D"margin-left: =
15px;"><strong>Compatibility with future upgrades</strong>: Provides framew=
ork for future witness programs and uses of the annex.</li></ol><span>Use C=
ases</span><span>Vault-of-Vaults</span><p>Ex: Alice, Bob, and Carol create =
a 2-of-3 vault by combining their P2TR addresses, rather than their public =
keys. Each address corresponds to a personal vault that Alice, Bob, or Caro=
l controls. This can be a single sig, a 2-of-3 multisig, a decaying multisi=
g, or something more complex. Only two addresses must be satisfied in order=
 to unlock the funds. If desired, additional spending paths can be added, s=
uch as a time-delayed backup, accessible by a single party.</p><p>This vaul=
t-of-vaults is easy to audit and assemble, and parties can selectively reve=
al their spending paths to the other parties, or not reveal any except thos=
e that are used.</p><span>Receiver-Paid Payments</span><p>Ex: Alice pays Bo=
b without committing to the fee rate of the transaction. Alice simply deleg=
ates a portion of her balance to Bob, sending herself the residual using SI=
NGLE|ANYONECANPAY. Bob can then complete the transaction and choose the app=
ropriate fee rate.</p><p>This basic pattern could be used to support more c=
omplex payment flows in the future.</p><span>Bitcoin Markets</span><p>Ex: W=
ith a single signature, Bob can make an offer to sell a UTXO-linked asset f=
rom cold storage to one of many possible approved buyers, in exchange for b=
itcoin. Using timelocks, Bob could even give some buyers a right-of-first-r=
efusal.</p><p>Likewise, if an introspection opcode is enabled, Bob could of=
fer bitcoin to many possible recipients, in exchange for some <span>onchain=
</span> or <span>offchain</span> asset tied to a UTXO. The ability to commi=
t to a specific UTXO is important because it provides a built-in mechanism =
to cancel the offer, if the asset is transferred to someone else.</p><span>=
A Path to Key Path Delegation</span><p>Graftleaf lays the groundwork for de=
legation from script path=C2=A0<em>and</em>=C2=A0key path spends using the =
annex. Unfortunately, BIP341 Taproot does not appear to have an upgrade mec=
hanism for key path spends, since a key path spend is only possible with a =
witness stack that has only one element after removing the (optional) annex=
. This can be resolved with a new witness program, but it would require a n=
ew address type, which history shows can take a long time for industry to a=
dopt.</p><span>Comparison with Other Proposals</span><p>This proposal share=
s similarities with several other proposals:</p><ul><li style=3D"margin-lef=
t: 15px;"><strong>Graftroot</strong>: Allows delegation but only from key p=
ath spends and only once</li><li style=3D"margin-left: 15px;"><strong>CSFS<=
/strong>: Complementary feature for re-binding signatures to pre-committed =
scripts</li><li style=3D"margin-left: 15px;"><strong>G=E2=80=99root</strong=
>: Complementary feature that uses Pederson commitments to add script commi=
tments to key path spends</li><li style=3D"margin-left: 15px;"><strong>Entr=
oot</strong>: Combines ideas from Graftroot and <span>G=E2=80=99root</span>=
, replacing Pederson commitments with a hash-to-curve scheme, but only faci=
litates delegations from key path spends and compositions between a key pat=
h spend and script.</li></ul><p>Pieter Wuille=E2=80=99s <span>Entroot</span=
> is perhaps the closest cousin to this proposal. The primary difference is=
 that this proposal enables:</p><ol><li style=3D"margin-left: 15px;">Script=
 path delegation</li><li style=3D"margin-left: 15px;">Delegation from a com=
position of programs and script</li><li style=3D"margin-left: 15px;">Arbitr=
arily complex compositions on a single leaf</li></ol><p>In addition, this p=
roposal does not require hash-to-curve or a new address type. The core comp=
osition and delegation logic is upgradeable and reusable, if new programs w=
ith hash-to-curve or key path delegation are added in the future.</p><span>=
Concluding Thoughts</span><p>I have taken care to consider possible edge ca=
ses and respect resource limitations, but if there is anything I have misse=
d, I'd welcome the community's feedback (this is my first formal proposal).=
 Naturally, soft fork proposals are highly contentious, but I believe that =
generic composition and delegation is an important architectural problem fo=
r Bitcoin to solve, provided there=E2=80=99s a way to do so safely with acc=
eptable tradeoffs.</p><p>If there=E2=80=99s interest in a BIP, please let m=
e know. Given the scope, this probably deserves two BIPs, and I=E2=80=99d b=
e happy to draft something up.</p><p>Sincerely,</p><p>Joshua Doman</p><p><i=
>*Special thanks to Alex Lewin for reviewing early drafts of this email</i>=
</p></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion visit <a href=3D"https://groups.google.com/d/msgid/=
bitcoindev/0b5b560b-aa0c-4669-9621-67ccbecba516n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/0b5b560b-aa0c-4669-9621-67ccbecba516n%40googlegroups.com</a>.<br />

------=_Part_8433_1117693382.1746494864548--

------=_Part_8432_1006590177.1746494864548--