From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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 To: Bitcoin Development Mailing List 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: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , 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 that OP_ CODESEPARATOR was an early attempt by Satoshi to do delegation. More=20 recently, proposals like Graftroot=20 and Entroot 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 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 . 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

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.

Hi all,

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= speculate=C2=A0that=C2=A0OP_CODESEPARATOR=C2= =A0was an early attempt by Satoshi to do delegation. More recently, proposa= ls like=C2=A0Graftr= oot=C2=A0and=C2=A0Entroot=C2=A0= 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=A0CSFS=C2=A0would enable delegation from script path = spends, but it's limited, as it only facilitates delegation within a pre-co= mmitted script.

When considering delegation, what type of functionali= ty is desirable? I=E2=80=99d argue that generalized delegation has two prop= erties:

  1. Delegation=C2=A0from an= y valid spending path
  2. Delegation= =C2=A0to arbitrarily complex compositions of programs and script

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

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.

Is there a simple and safe way to imp= lement generalized composition and 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 calling "Graftleaf."

Proposal: Graftle= af

Graftleaf is a new Taproot leaf version (0x= c2), which uses the annex to perform delegations. Graftleaf adds two signif= icant capabilities:

  1. Composi= tion: The ability to execute zero, one, or more witness programs i= n sequence, including a locking script.
  2. here.=C2=A0I=E2=80=99ve included = a fairly large test suite, though there=E2=80=99s definitely room for impro= vement.

    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.

    Technical Overview

    This implementation creates a new tapleaf version (0xc2) and gives c= onsensus meaning to the annex when this leaf version is used:

    Comp= osition Mechanism
    • Multiple witne= ss programs can be executed in sequence
    • Programs can be differ= ent witness versions (v1+) or script
    • R= esource limits (stack size, validation weight) are preserved and enforced a= cross executions
    • Signatures commit to = the chain of tapleafs and annexes in the execution path to prevent witness = malleability and replay attacks
    • If the= annex is absent, empty, or begins with 0x00, all elements on the stack mus= t be consumed
    Delegation Mechanism
    • Users can commit to additional spending conditions at sig= nature-time 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 0x= 01 are forbidden unless signed to prevent witness malleability
    • After delegated execution completes, all elements = on the stack must be consumed
    Technical Deep DiveComposition

    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.

    The witness stack for a composed prog= ram looks like:

    [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]

    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.

    The ta= pleaf encodes the list of programs as=C2=A0[witness version][program = length][program]. 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 tapscript.

    Tapleaf Example 1 (a series = of programs composed with script):

    [program1 witness version] [program1 program length] [program1] =E2=80=A6 [programN witness version] [programN program length] [programN] [0xc0] [script]

    Tapleaf Example 2 (a program composed of only script):

    = [0xc0] [script]

    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

    Delegation

    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= .

    The witness stack for delegation looks like:

    [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])

    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.

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

    Resource Limitations<= p>The validation weight budget is tracked and decremented across all compos= itions and delegations, ensuring that programs cannot bypass global resourc= e limits.

    Likewise, the global stack size limit is enforced by requir= ing both the total stack size and the=C2=A0EvalScript=C2=A0sta= ck size to be at most=C2=A0MAX_STACK_SIZE / 2=C2=A0after a 0xc= 2 tapleaf is encountered. This conservatively ensures that the total stack = size remains at most=C2=A0MAX_STACK_SIZE.

    Security Co= nsiderations

    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

    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.

    Potential Benefits=

    This proposal has several potential benefits, including:

      <= li style=3D"margin-left: 15px;">Backward-compatibility: Wo= rks with existing P2TR addresses.
    1. Enhanced composability: Enables "vault-of-vaults" and other co= mplex spending policies, compatible with new witness programs adopted in th= e future (ex: P2QRH).
    2. Generali= zed delegation: Allows users to authorize additional spending cond= itions at signature-time, delegating to any combination of addresses and sc= ript.
    3. Re-delegation: = Allows users to re-delegate to other users, adding additional restrictions = to the structure of the final transaction.
    4. Improved privacy and fungibility: Could increase P2TR= adoption by encouraging users to adopt wallets and vaults that can be comp= osed with and delegated to.

    Additional benefits may include:

    1. Delegation-only opcodes: Creates framework to allow math and introspection opcodes (ex:=C2=A0OP_CAT) 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.
    2. Compatibility with future upgrades: Provides framew= ork for future witness programs and uses of the annex.
    Use C= asesVault-of-Vaults

    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.

    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.

    Receiver-Paid Payments

    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.

    This basic pattern could be used to support more c= omplex payment flows in the future.

    Bitcoin Markets

    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.

    Likewise, if an introspection opcode is enabled, Bob could of= fer bitcoin to many possible recipients, in exchange for some onchain= or offchain 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.

    = A Path to Key Path Delegation

    Graftleaf lays the groundwork for de= legation from script path=C2=A0and=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.

    Comparison with Other Proposals

    This proposal share= s similarities with several other proposals:

    • Graftroot: Allows delegation but only from key p= ath spends and only once
    • CSFS<= /strong>: Complementary feature for re-binding signatures to pre-committed = scripts
    • G=E2=80=99root: Complementary feature that uses Pederson commitments to add script commi= tments to key path spends
    • Entr= oot: Combines ideas from Graftroot and G=E2=80=99root= , 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.

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

    1. Script= path delegation
    2. Delegation from a com= position of programs and script
    3. Arbitr= arily complex compositions on a single leaf

    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.

    = Concluding Thoughts

    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.

    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.

    Sincerely,

    Joshua Doman

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

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