From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 11 Sep 2025 03:01:55 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1uwe7l-0007Y2-SZ for bitcoindev@gnusha.org; Thu, 11 Sep 2025 03:01:55 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-319c4251788sf749978fac.3 for ; Thu, 11 Sep 2025 03:01:53 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1757584907; cv=pass; d=google.com; s=arc-20240605; b=ctqauaaleFvt/Nfnyfv+iPKk1ryrNQKt7KOBpGoTl+BlxhMDzlnkgie4IFHqmWEyal /gJXKyuTIJpkCc4MWX2f1yhpN8FYFRigBgF94/5m+kM/RfotGtp8hxUhJd7JDR/cCGs0 p5Qry4hZ22VYyTBRrFcXKuA7rabTo6HbCSwDEyTiwGfhkT+fvl/55YKJyMeqeDN99uPf XzzNz8FlXVn3VjRguswU6GRLzsmZ40FIc7zhf69/XAuKFSjJdzWzFF41ReNuv8QnEQJY w55tw+HJBXivOcROY48tYXd1mO3agvX0Vp1AHQIVXTzUYYc705R+Fl7o9/NJ9SFUKgWb 5Qaw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:to:subject:message-id:date:from :in-reply-to:references:mime-version:sender:dkim-signature :dkim-signature; bh=Eu3lLZl+718uYqMdiQLgesdCuMBvsYIEBjoAHhcF9X4=; fh=aNx4xjjyk0w4KWLmvZvm/q76+u9gI8iPl0OiVKP177Y=; b=YDbenyXwH+3JCevJH1xe9lxSPbAPZr2pIjHQ90kJVmeUDYHGobifRtj5W3rueWheRo HAPi7Xp67qST/CoUk1Z4NZRU1H92BjeqlC7XG82LbycEL5P9vvgmF8GyAVSNPbrnKVlv nLqr6CA3RIAwSQx8QKL4RUQ+BsyLO9ur4PChINi16CALJctp2WU4BHSN6JoOpvQzdsmW GMd5G1Hfhc4Abja6kxl7r0cDyvRb/3m/5rBzqHemlxoApHZ8y6dndCQFAG80u/YNEoIE EUdYmS+zYRFz8/JV+Zgek5u6k92Hz492jAoGqXpgt0cU8jnde2PJXIMgo9ZtHmR/g0LS YBTQ==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=AQLNAAuF; spf=pass (google.com: domain of omatimonteagudov@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=omatimonteagudov@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1757584907; x=1758189707; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:subject:message-id:date:from:in-reply-to :references:mime-version:sender:from:to:cc:subject:date:message-id :reply-to; bh=Eu3lLZl+718uYqMdiQLgesdCuMBvsYIEBjoAHhcF9X4=; b=DED8OLeF8wwXjjyeYZW3ee5EYKSvV3nLDPQDG6JoQd/9zeciNMRBgsP6BV869cg/f6 rcFPfF19nAD8nHChxjfCmVH9j1ByqBRmBdx1aFV89G3h1eWZRh8l05IplV29GxWcl2lL 7v666wDjiN1Qi34F3iY6EV77SL9xInrU8mcqzOdjx/BUdBXBVWTZpVGmCJfCSUE5SG7S 5sAhu0qEZFY70I9LGciLJaMBuHZwUwoYYmJZzMUR4WLvL62B6ltRuVlRqfwDe7GmHqoJ DVevwZsygJ/kszI+09kzjq5OLVWEdEf0rdFrtxdSSRog6ncRV1SEeeJJOcnIZkHP3wKD 2Kog== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757584907; x=1758189707; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:subject:message-id:date:from:in-reply-to :references:mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Eu3lLZl+718uYqMdiQLgesdCuMBvsYIEBjoAHhcF9X4=; b=BXQm3qdnrpQyFfMB2An2agmIWCha3FHzQTeiI5PMYawciTlTVQXocHwuUzXZVpmEIE n8nUrSfeM+btZm45WBFFYaX+89Yt4H9hM4MLEmajtw3zG4ToJT+3gZObqP0AGxH4Li7g 1OqX/WwrrOP+5vDJqwUJFhrZp7pWxotg9fOGDaPDgYyFWOUnETfjBN9/9nFVDdxlD1Ro RS0nTg+2URyDgr9WkJPK1Aov0W2Wflp1nmaA9mLDUU/VxXpmTQj+Y9m1FuwnlO9Q6SQ3 wAL9IEiloRJ5h3BvoJmZKEGGbV4EkymhsliMiGdU1phc4ObHHv3aanqXYsfM3JNK6VSZ cADg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757584907; x=1758189707; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:to:subject:message-id:date:from:in-reply-to :references:mime-version:x-beenthere:x-gm-message-state:sender:from :to:cc:subject:date:message-id:reply-to; bh=Eu3lLZl+718uYqMdiQLgesdCuMBvsYIEBjoAHhcF9X4=; b=r2Eztj3HXITpfZGn4ocZoX2zZnJ4E6Np/T2LwJksPV6T2ZCeC2kgIv0E63ohoeWd3L oOd80zmeTj7Q0pfGsAGk1vb1/LJudAVUrn2jt5yVvQ9Kba2vGOoM4GEHX4+PSPYBKuRq l+vnUqxKm8ojW4TFBJcRtNq8Oyd6+DFfRpD8ezmdNy3jP0pA8xeZ2jWgJuhU+PITA9iE LNY58pU5DzkFURNCmaZra5+FuTtmS4xj3nVnvKnD/nLaDIbT8VrpA+VYzX9C7Qw00DYE n2a36B2/Zttz238695kpuZ2MpBfggYaDKbZDTAxHIqLem9Gjvg6fK1viTP7zwlzkb4tJ iGwA== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCWJCU7n/0be+i7xwYtgneHiA9kZg/yJBf4WiMVBqRCuak2Np2uEHjT2AypHvVFQpJluP9GY5mNT0shA@gnusha.org X-Gm-Message-State: AOJu0YyeQQ+JJuJWLFTN6GV5/Ag86PmvSjkYHq0OWZah4YRHO+w10XX2 swBGC3BNk+uDUiYGticJuvZxl5aTRruAfLyBs/nb/7R7sru7uFxla73A X-Google-Smtp-Source: AGHT+IH8HxULJDriw/27tFdmJWfGEZ4KeviYFT4B8txbQ/5udISvLHzGiLloYA31v/+DABwUOR1O4g== X-Received: by 2002:a05:6870:a454:b0:315:a68c:d90b with SMTP id 586e51a60fabf-32264c20b6cmr9078879fac.23.1757584906472; Thu, 11 Sep 2025 03:01:46 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com; h=ARHlJd75LB20EkCSleYRgSXJG2yjTufZLBlBvNCeRBoh+ucVbA== Received: by 2002:a05:6871:9c27:b0:30c:c0b:fe9d with SMTP id 586e51a60fabf-32d02f12b7als238455fac.0.-pod-prod-03-us; Thu, 11 Sep 2025 03:01:42 -0700 (PDT) X-Received: by 2002:a05:6808:19aa:b0:438:257d:6663 with SMTP id 5614622812f47-43b29ba2499mr740945b6e.48.1757584901991; Thu, 11 Sep 2025 03:01:41 -0700 (PDT) Received: by 2002:a05:600c:a108:b0:45b:7de4:1372 with SMTP id 5b1f17b1804b1-45df86e828ams5e9; Thu, 11 Sep 2025 02:47:58 -0700 (PDT) X-Received: by 2002:a05:600c:4688:b0:45d:d2d2:f095 with SMTP id 5b1f17b1804b1-45deb702e1dmr101881055e9.19.1757584076420; Thu, 11 Sep 2025 02:47:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1757584076; cv=none; d=google.com; s=arc-20240605; b=DOGMi7s4iXmtHP7IGlQ1ev3Jr42Ni1rncP+KXNbYQcuh6nuPnhDY9s3jOI4OeOr+q/ WpoEwItzcfQ20GwVwxN9dcktSDydlzONlCWtI9TNkoSRwRCCVIKVz2mI0ucyl/0VaXHK DE4+7geLM9DpL/VNKRiCKBOtwuMzArEMLwnjnKUuXQP3jRzOi7rBJ7TDyMYzHe5LMgn3 Zp1pVVcAm/hQaKqBA8zFE2tiVNN69mMKE/Cm+naHXDncjVzl7ll9Bhgugw7oHRcSW9iP pwUeOkszVpTB4PETGEeLvr3JoW7eEvFuaNc9GVnEamOAU8VdmPXS4YADaBNg54yDRUio x3yA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=XaSNgyVFeuzkshJp+q9Jql8ORqpwYULwuq4O2C+HCus=; fh=DMP0F9ULS1guKiqimntQRCN8ZraraesEgQuVcn7F0Z0=; b=lRMyEk9Wc78XDGA1uXx1VIUrznsXH5tl442Yh00z5rpzcrPY0LxUli2sf3Z2cBGXaF lgQrpgCOUlFgZkTrEIf028Oky9kzJBA31n4wFihg5wYZjJ5vR4xce94HbYtVjs/XT5sA 5iVOc7TL7MZjw6cOpY34pei47rXfizyHk3rhDU/0BPcN+jAlfC7R/nT2YBaPr8KpP+NS viHXSmbvRzTukhB21Y+U++kXDdjnJOY+mASQ4JvVMENEEu2ZznJUe7D4OOdXxsfxtZWm eBRtoIRr3h7ZOFA35G7YV/xI8aBwqXLPqj0Qd+1u/MK5CAT/ZU1hGene9TN5VlZCFFQR vr9Q==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=AQLNAAuF; spf=pass (google.com: domain of omatimonteagudov@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=omatimonteagudov@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.com Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com. [2a00:1450:4864:20::631]) by gmr-mx.google.com with ESMTPS id 5b1f17b1804b1-45e017c471dsi384035e9.1.2025.09.11.02.47.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 11 Sep 2025 02:47:56 -0700 (PDT) Received-SPF: pass (google.com: domain of omatimonteagudov@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) client-ip=2a00:1450:4864:20::631; Received: by mail-ej1-x631.google.com with SMTP id a640c23a62f3a-b045d56e181so76836666b.2 for ; Thu, 11 Sep 2025 02:47:56 -0700 (PDT) X-Gm-Gg: ASbGncvEdUFeZW36kYcqUbYzEJOzS6CSop0vMRNS3KSMlbRGR4LJlLP4HyBkg2XwUe0 SLBwE4TbA3h/nqMgNLgdwLJUYvQwYPGGFz/pk0dq2Vu0nVDZA/U15AFo4Ld2ej0oW5kaHKvSF56 PGnNij21jxXGOJLKC7uc3xnQAl0gNPB3kzFEpWfzgNpOR7UTKVlTU2OkZLNwiwesfkCdxEfM1uv oS2nQtJtjVNFHXywlp42AHjt40hZ9+CNfx4ZV7bTpK4TeLZAnVDdEy/S3pooUVzzBR4lPIbXRe5 ck7pSqNKYiSj1QfsGq266CXl/qJuYBuz+LNdBsSDhD66nOfu8vPBJK3oBLcMNgLMGOx6rg== X-Received: by 2002:a17:907:7293:b0:b04:26a7:f77e with SMTP id a640c23a62f3a-b04b167d190mr1806753766b.51.1757584075413; Thu, 11 Sep 2025 02:47:55 -0700 (PDT) MIME-Version: 1.0 References: <6778d5ec-91dc-4c3b-9718-581ec2cf7be6n@googlegroups.com> In-Reply-To: <6778d5ec-91dc-4c3b-9718-581ec2cf7be6n@googlegroups.com> From: Matias Monteagudo Date: Thu, 11 Sep 2025 11:47:42 +0200 X-Gm-Features: Ac12FXz9mF_BNyHQE1SknKhp0ubDsZbK26w2jZtfwqYtVs6Y9BucVWZ_gWVZMQQ Message-ID: Subject: Re: [bitcoindev] BIP Booby Trapped Wallets - Covenant-Only Taproot Outputs To: Bitcoin Development Mailing List Content-Type: multipart/alternative; boundary="0000000000007a5ec5063e836ea6" X-Original-Sender: omatimonteagudov@gmail.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@gmail.com header.s=20230601 header.b=AQLNAAuF; spf=pass (google.com: domain of omatimonteagudov@gmail.com designates 2a00:1450:4864:20::631 as permitted sender) smtp.mailfrom=omatimonteagudov@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com; dara=pass header.i=@googlegroups.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.0 (/) --0000000000007a5ec5063e836ea6 Content-Type: text/plain; charset="UTF-8" Hi, I am not sure I presented my BIP the right way. I followed your guide but I am not getting any feedback and I am not sure if it is visible or I did something wrong I am not aware of. Thanks! M. On Thu, 21 Aug 2025, 20:16 Matias Monteagudo, wrote: > 
>   BIP: ?
>   Layer: Consensus (soft fork)
>   Title: Booby Trapped Wallets
>   Author: Matias Monteagudo 
>   Comments-Summary: No comments yet.
>   Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-XXXX
>   Status: Draft
>   Type: Standards Track
>   Created: 2025-08-21
>   License: BSD-2-Clause
>   Requires: 341, 342
>
> > == Abstract == > > This BIP proposes covenant-only Taproot outputs, an optional but > irrevocable wallet-level security mechanism. When activated by wallet > owners, covenant-only mode disables key-path spending and mandates > script-path spending, creating invisible transaction restrictions that only > become apparent when violated. This mechanism provides an optional security > layer for high-value institutional Bitcoin holdings against unauthorized > access while maintaining transaction privacy until restrictions are > triggered. > > == Copyright == > > This BIP is licensed under the BSD 2-clause license. > > == Motivation == > > High-profile Bitcoin holders, particularly institutional entities such as > exchanges, face significant security risks. When attackers gain access to > private keys, they can drain wallets with varying degrees of difficulty but > ultimately succeed. Current security measures are visible and can be > circumvented by sophisticated attackers. > > This proposal creates an optional but irrevocable security mechanism where: > > # Wallet owners can voluntarily and irrevocably restrict future > transactions to predefined destination addresses > # Once activated, unauthorized transfer attempts are automatically > redirected to arbitration wallets > # The restrictions remain completely invisible until triggered > # Protected wallets appear identical to unprotected ones, preventing > attacker preparation > # The mechanism is entirely opt-in and cannot be forced upon any wallet > > == Specification == > > === Covenant-Only Taproot Output === > > A covenant-only Taproot output extends standard Taproot (BIP 341) by > mandating script-path spending through the use of an invalidated internal > key: > > 
> scriptPubKey: OP_1 <32-byte-covenant-taproot-output>
>
> > The output commitment follows standard Taproot construction: > 
> covenant_taproot_output = internal_pubkey + tagged_hash("TapTweak",
> internal_pubkey || merkle_root)
>
> > Where internal_pubkey is set to an unspendable value, making key-path > spending impossible. > > === Key Components === > > ==== 1. Internal Key Invalidation ==== > > The internal public key MUST be set to the following unspendable point: > 
> internal_pubkey = lift_x(tagged_hash("CovenantOnly/InvalidKey", b""))
>
> > This point has no known discrete logarithm, ensuring key-path spending is > cryptographically impossible while maintaining compatibility with existing > Taproot validation rules. > > ==== 2. Covenant Script Template ==== > > The covenant script enforces destination restrictions through conditional > execution: > > 
> # Check if destination is whitelisted
> OP_DUP OP_HASH160  OP_EQUAL
> OP_IF
>     # Validate whitelist membership with Merkle proof
>     OP_SWAP  OP_CHECKTEMPLATEVERIFY
>      OP_CHECKSIG
> OP_ELSE
>     # Enforce arbitration for unauthorized destinations
>     
> OP_ENDIF
>
> > Note: This script assumes a hypothetical OP_CHECKTEMPLATEVERIFY opcode for > Merkle proof validation. Actual implementation would use existing opcodes > for Merkle tree verification. The arbitration_wallet_script can be any > valid script (single-sig, multisig, or other) as determined by the > institution and arbitrator. > > ==== 3. Whitelist Construction ==== > > Allowed destinations are hashed into a Merkle tree: > 
> whitelist_hash = merkle_root(destination_1, destination_2, ...,
> destination_n)
>
> > === Transaction Validation === > > ==== Normal Operation ==== > > When spending to a whitelisted destination: > # Transaction appears as standard Taproot spend > # Script-path reveals the covenant logic > # Whitelist proof validates the destination > # Transaction proceeds normally > > ==== Unauthorized Attempt ==== > > When attempting to spend to non-whitelisted destination: > # Script-path execution fails whitelist check > # Automatic fallback to arbitration wallet > # Funds are locked pending arbitration resolution > > === Activation and Deployment === > > This soft fork follows the deployment mechanism specified in BIP 9 > (Version bits with timeout and delay): > > 
> name: covenant-taproot
> bit: TBD (to be assigned by BIP editors)
> starttime: TBD (6 months after BIP Final status)
> timeout: TBD (2 years after starttime)
> threshold: 1815 (90% of 2016 blocks)
>
> > The soft fork activates when 90% of blocks in a difficulty period signal > readiness, ensuring broad miner consensus before enforcement begins. > > === New Consensus Rules === > > After activation, nodes MUST enforce the following rules for covenant-only > Taproot outputs: > > # '''Internal Key Validation''': Outputs using the covenant-only internal > key (as defined in section 1) MUST be validated as covenant-only outputs > # '''Mandatory Script-Path''': Covenant-only outputs MUST be spent using > script-path spending; key-path spending attempts are INVALID > # '''Script Execution''': The covenant script MUST successfully execute > and validate destination restrictions > # '''Merkle Proof Verification''': Whitelisted destinations MUST provide > valid Merkle inclusion proofs > # '''Arbitration Fallback''': Non-whitelisted destinations MUST redirect > to the specified arbitration wallet > > These rules only apply to outputs created after activation and do not > affect existing Taproot outputs. > > == Backwards Compatibility == > > This proposal maintains full backwards compatibility through careful soft > fork design: > > # '''Pre-existing Outputs''': All existing Taproot outputs continue to > function unchanged with their original semantics > # '''Node Compatibility''': Non-upgraded nodes validate covenant-only > outputs as standard Taproot without additional restrictions > # '''Wallet Compatibility''': Existing wallet software continues to work; > covenant functionality is purely additive > # '''Transaction Relay''': All transactions remain compatible with > existing relay policies and fee estimation > # '''Mining Compatibility''': No changes required to mining software or > pool configurations > > The soft fork nature ensures that old software never sees invalid > transactions, maintaining network cohesion during the upgrade period. > > == Rationale == > > === Why Extend Taproot? === > > Taproot provides the perfect foundation because: > > # '''Privacy''': Scripts remain hidden until execution > # '''Flexibility''': Merkle tree structure supports complex covenants > # '''Efficiency''': Minimal on-chain footprint > # '''Adoption''': Building on existing, activated technology > > === Why Disable Key-Path Spending? === > > Key-path spending would allow attackers to bypass covenant restrictions > entirely. By making the internal key unspendable, we ensure that all > spending must go through the covenant script validation. > > === Arbitration Mechanism === > > The automatic arbitration fallback provides: > > # '''Recovery path''': Legitimate users can recover funds through > arbitration > # '''Deterrent effect''': Attackers know stolen funds will be locked > # '''Institutional security''': Professional arbitration services can be > integrated with any wallet type > > Institutions can choose from existing specialized services such as the > Blockchain Arbitration & Commerce Society (https://bacsociety.com) or any > other arbitrator they trust, providing flexibility in arbitration provider > selection. > > === Privacy Benefits === > > # Protected wallets are indistinguishable from regular Taproot addresses > # Covenant restrictions only become visible when violated > # Normal operations remain completely private > # Attackers cannot identify targets in advance > > == Reference Implementation == > > === Core Validation Logic === > > 
> def validate_covenant_taproot(scriptPubKey, witness_stack, tx_outputs):
>     """Validate a Covenant-Only Taproot spend"""
>
>     # Extract the covenant output
>     if len(scriptPubKey) != 34 or scriptPubKey[0] != 0x51:
>         return False
>
>     covenant_output = scriptPubKey[2:]
>
>     # Verify script-path spending (key-path is invalid)
>     if len(witness_stack) < 3:
>         return False
>
>     script = witness_stack[-2]
>     control_block = witness_stack[-1]
>
>     # Validate Taproot script-path
>     if not validate_taproot_script_path(script, control_block,
> covenant_output):
>         return False
>
>     # Execute covenant script
>     return execute_covenant_script(script, witness_stack[:-2], tx_outputs)
>
> def execute_covenant_script(script, witness_stack, tx_outputs):
>     """Execute the covenant validation script"""
>
>     # Parse script to extract whitelist and arbitration keys
>     whitelist_hash, destination_key, arbitration_keys =
> parse_covenant_script(script)
>
>     # Check if spending to whitelisted destination
>     for output in tx_outputs:
>         dest_hash = hash160(output.scriptPubKey)
>         if validate_whitelist_inclusion(dest_hash, whitelist_hash,
> witness_stack):
>             # Spending to authorized destination
>             return validate_signature(destination_key, witness_stack)
>
>     # No whitelisted destination found - enforce arbitration
>     return validate_arbitration_wallet(arbitration_keys, witness_stack)
>
> > === Wallet Integration === > > 
> class CovenantWallet:
>     def create_covenant_output(self, whitelist_destinations,
> arbitrator_pubkey):
>         """Create a new Covenant-Only Taproot output"""
>
>         # Create whitelist Merkle tree
>         whitelist_hash =
> self.build_whitelist_merkle_tree(whitelist_destinations)
>
>         # Build covenant script
>         covenant_script = self.build_covenant_script(
>             whitelist_hash,
>             self.institution_pubkey,
>             arbitrator_pubkey
>         )
>
>         # Create Taproot commitment with invalid internal key
>         invalid_internal_key = tagged_hash("CovenantOnly/InvalidKey", b"")
>         taproot_output = self.compute_taproot_output(invalid_internal_key,
> covenant_script)
>
>         return taproot_output
>
>     def spend_covenant_output(self, utxo, destination, whitelist_proof):
>         """Spend from a covenant-protected output"""
>
>         # Build witness stack
>         witness_stack = []
>         witness_stack.extend(self.create_signature_data())
>         witness_stack.append(whitelist_proof)
>         witness_stack.append(self.covenant_script)
>         witness_stack.append(self.control_block)
>
>         return self.create_transaction(utxo, destination, witness_stack)
>
> > == Security Considerations == > > === Cryptographic Security === > > # '''Internal Key Security''': The covenant-only internal key is derived > using a cryptographically secure hash function with no known preimage, > ensuring no party can compute the corresponding private key > # '''Script Hiding''': Covenant logic remains hidden until first > execution, preventing attackers from analyzing restrictions beforehand > # '''Merkle Tree Security''': Whitelist validation relies on > cryptographically secure Merkle tree inclusion proofs, preventing > unauthorized destination forgery > > === Attack Vectors and Mitigations === > > # '''Private Key Compromise''': Primary threat mitigated by mandatory > script-path spending that enforces covenant restrictions regardless of key > compromise > # '''Script Analysis Attack''': Covenant structure only revealed upon > violation attempt, limiting attacker intelligence gathering > # '''Arbitration Compromise''': Mitigated by using secure arbitration > wallet configurations and the ability to use multiple independent > arbitrators > # '''Implementation Vulnerabilities''': Reference implementation includes > comprehensive test vectors and edge case handling > # '''Social Engineering''': Attacks against arbitrators are mitigated > because the arbitrator's identity remains hidden until the covenant is > triggered, preventing targeted attacks during normal operations > > === Economic Security Model === > > # '''Attacker Economics''': Theft attempts face high probability of fund > seizure through arbitration, making attacks economically irrational > # '''Arbitrator Incentives''': Arbitrators have economic stake in fair > resolution to maintain reputation and future business > # '''Institution Benefits''': Legitimate institutions maintain full > operational control while gaining protection against unauthorized access > # '''Network Effects''': Widespread adoption increases overall ecosystem > security without degrading privacy or performance > > === Privacy Trade-offs === > > # Normal operations maintain full privacy > # Violation attempts reveal covenant structure > # Overall privacy significantly better than current multisig alternatives > > == Test Vectors == > > === Vector 1: Covenant-Only Output Creation === > > 
> Internal Key:
> 50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0
> Merkle Root:
> 9a1c7d8f0e5b3a4c2d9f8e7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a8b7c
> Script Tree: [covenant_script_leaf]
> Expected Output: bc1p... (32-byte commitment)
>
> > === Vector 2: Valid Whitelisted Spend === > > 
> Input: Covenant-only Taproot UTXO from Vector 1
> Destination: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 (whitelisted)
> Witness Stack: [signature, merkle_proof, covenant_script, control_block]
> Expected: VALID transaction
> Privacy: Covenant script revealed but appears as normal Taproot spend
>
> > === Vector 3: Unauthorized Destination Attempt === > > 
> Input: Covenant-only Taproot UTXO from Vector 1
> Destination:
> bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3 (not
> whitelisted)
> Witness Stack: [arbitration_signatures, covenant_script, control_block]
> Expected: Funds redirected to arbitration wallet
> Privacy: Covenant structure fully revealed
>
> > === Vector 4: Key-Path Bypass Attempt === > > 
> Input: Covenant-only Taproot UTXO from Vector 1
> Spend Type: Key-path (single signature, no script reveal)
> Witness Stack: [invalid_signature]
> Expected: INVALID (unspendable internal key)
> Result: Transaction rejected by consensus rules
>
> > == Implementation Timeline == > > # '''Phase 1''': Reference implementation and test suite > # '''Phase 2''': Community review and feedback incorporation > # '''Phase 3''': Testnet deployment and testing > # '''Phase 4''': Mainnet soft fork activation (if consensus achieved) > > == Conclusion == > > This proposal introduces covenant-only Taproot outputs as an optional > security enhancement for Bitcoin. By leveraging existing Taproot > infrastructure with invalidated internal keys, we enable invisible > transaction restrictions that provide institutional-grade protection > without compromising privacy or usability. > > The mechanism offers a balanced approach to high-value Bitcoin security, > maintaining compatibility with existing systems while providing powerful > deterrence against unauthorized access. The optional nature ensures no > impact on users who do not require this additional security layer. > > == Acknowledgments == > > The author thanks the Bitcoin development community for their work on > Taproot (BIP 341) which provides the foundation for this proposal. Special > appreciation to the designers of the Taproot script commitment scheme that > enables covenant functionality. > > == References == > > * [[bip-0341.mediawiki|BIP 341: Taproot: SegWit version 1 spending rules]] > * [[bip-0342.mediawiki|BIP 342: Validation of Taproot Scripts]] > * [https://github.com/bitcoin/bitcoin Bitcoin Core implementation] > * [[https://bacsociety.com Blockchain Arbitration & Commerce Society]] > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/bitcoindev/Xlcztk_j3b4/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > bitcoindev+unsubscribe@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/bitcoindev/6778d5ec-91dc-4c3b-9718-581ec2cf7be6n%40googlegroups.com > > . > -- 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 email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CABQ%2BHo2E6Xea21LpM-2kOffd3kDkAYhmcomZ-%3DXS0YNPpdr6dg%40mail.gmail.com. --0000000000007a5ec5063e836ea6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

I am not sure I presented my BIP the right way. I followed y= our guide but I am not getting any feedback and I am not sure if it is visi= ble or I did something wrong I am not aware of.

Thanks!

M.


On Thu, 21 Aug 2025, 20:16 Matias Monteagudo, <omatimonteagudov@gmail.com> w= rote:
<pre>
=C2=A0 BIP: ?<= br>=C2=A0 Layer: Consensus (soft fork)
=C2=A0 Title: Booby Trapped Walle= ts
=C2=A0 Author: Matias Monteagudo <omatimonteagudov@gmail.c= om>
=C2=A0 Comments-Summary: No comments yet.
=C2=A0 Comments-= URI: https://github.com/bitcoin/bips/wiki/Comm= ents:BIP-XXXX
=C2=A0 Status: Draft
=C2=A0 Type: Standards Track=C2=A0 Created: 2025-08-21
=C2=A0 License: BSD-2-Clause
=C2=A0 Requ= ires: 341, 342
</pre>

=3D=3D Abstract =3D=3D

This BI= P proposes covenant-only Taproot outputs, an optional but irrevocable walle= t-level security mechanism. When activated by wallet owners, covenant-only = mode disables key-path spending and mandates script-path spending, creating= invisible transaction restrictions that only become apparent when violated= . This mechanism provides an optional security layer for high-value institu= tional Bitcoin holdings against unauthorized access while maintaining trans= action privacy until restrictions are triggered.

=3D=3D Copyright = =3D=3D

This BIP is licensed under the BSD 2-clause license.

= =3D=3D Motivation =3D=3D

High-profile Bitcoin holders, particularly = institutional entities such as exchanges, face significant security risks. = When attackers gain access to private keys, they can drain wallets with var= ying degrees of difficulty but ultimately succeed. Current security measure= s are visible and can be circumvented by sophisticated attackers.

Th= is proposal creates an optional but irrevocable security mechanism where:
# Wallet owners can voluntarily and irrevocably restrict future trans= actions to predefined destination addresses
# Once activated, unauthoriz= ed transfer attempts are automatically redirected to arbitration wallets# The restrictions remain completely invisible until triggered
# Protec= ted wallets appear identical to unprotected ones, preventing attacker prepa= ration
# The mechanism is entirely opt-in and cannot be forced upon any = wallet

=3D=3D Specification =3D=3D

=3D=3D=3D Covenant-Only Ta= proot Output =3D=3D=3D

A covenant-only Taproot output extends standa= rd Taproot (BIP 341) by mandating script-path spending through the use of a= n invalidated internal key:

<pre>
scriptPubKey: OP_1 <32= -byte-covenant-taproot-output>
</pre>

The output commitm= ent follows standard Taproot construction:
<pre>
covenant_tapro= ot_output =3D internal_pubkey + tagged_hash("TapTweak", internal_= pubkey || merkle_root)
</pre>

Where internal_pubkey is set = to an unspendable value, making key-path spending impossible.

=3D=3D= =3D Key Components =3D=3D=3D

=3D=3D=3D=3D 1. Internal Key Invalidati= on =3D=3D=3D=3D

The internal public key MUST be set to the following= unspendable point:
<pre>
internal_pubkey =3D lift_x(tagged_has= h("CovenantOnly/InvalidKey", b""))
</pre>
<= br>This point has no known discrete logarithm, ensuring key-path spending i= s cryptographically impossible while maintaining compatibility with existin= g Taproot validation rules.

=3D=3D=3D=3D 2. Covenant Script Template= =3D=3D=3D=3D

The covenant script enforces destination restrictions = through conditional execution:

<pre>
# Check if destination= is whitelisted
OP_DUP OP_HASH160 <destination_hash> OP_EQUAL
O= P_IF
=C2=A0 =C2=A0 # Validate whitelist membership with Merkle proof
= =C2=A0 =C2=A0 OP_SWAP <whitelist_merkle_root> OP_CHECKTEMPLATEVERIFY<= br>=C2=A0 =C2=A0 <destination_pubkey> OP_CHECKSIG
OP_ELSE
=C2= =A0 =C2=A0 # Enforce arbitration for unauthorized destinations
=C2=A0 = =C2=A0 <arbitration_wallet_script>
OP_ENDIF
</pre>
Note: This script assumes a hypothetical OP_CHECKTEMPLATEVERIFY opcode for= Merkle proof validation. Actual implementation would use existing opcodes = for Merkle tree verification. The arbitration_wallet_script can be any vali= d script (single-sig, multisig, or other) as determined by the institution = and arbitrator.

=3D=3D=3D=3D 3. Whitelist Construction =3D=3D=3D=3D<= br>
Allowed destinations are hashed into a Merkle tree:
<pre>whitelist_hash =3D merkle_root(destination_1, destination_2, ..., destina= tion_n)
</pre>

=3D=3D=3D Transaction Validation =3D=3D=3D
=3D=3D=3D=3D Normal Operation =3D=3D=3D=3D

When spending to a = whitelisted destination:
# Transaction appears as standard Taproot spend=
# Script-path reveals the covenant logic
# Whitelist proof validates= the destination
# Transaction proceeds normally

=3D=3D=3D=3D Una= uthorized Attempt =3D=3D=3D=3D

When attempting to spend to non-white= listed destination:
# Script-path execution fails whitelist check
# A= utomatic fallback to arbitration wallet
# Funds are locked pending arbit= ration resolution

=3D=3D=3D Activation and Deployment =3D=3D=3D
<= br>This soft fork follows the deployment mechanism specified in BIP 9 (Vers= ion bits with timeout and delay):

<pre>
name: covenant-tapr= oot
bit: TBD (to be assigned by BIP editors)
starttime: TBD (6 months= after BIP Final status)
timeout: TBD (2 years after starttime)
thres= hold: 1815 (90% of 2016 blocks)
</pre>

The soft fork activa= tes when 90% of blocks in a difficulty period signal readiness, ensuring br= oad miner consensus before enforcement begins.

=3D=3D=3D New Consens= us Rules =3D=3D=3D

After activation, nodes MUST enforce the followin= g rules for covenant-only Taproot outputs:

# '''Internal= Key Validation''': Outputs using the covenant-only internal ke= y (as defined in section 1) MUST be validated as covenant-only outputs
#= '''Mandatory Script-Path''': Covenant-only outputs= MUST be spent using script-path spending; key-path spending attempts are I= NVALID
# '''Script Execution''': The covenant sc= ript MUST successfully execute and validate destination restrictions
# &= #39;''Merkle Proof Verification''': Whitelisted destina= tions MUST provide valid Merkle inclusion proofs
# '''Arbitr= ation Fallback''': Non-whitelisted destinations MUST redirect t= o the specified arbitration wallet

These rules only apply to outputs= created after activation and do not affect existing Taproot outputs.
=3D=3D Backwards Compatibility =3D=3D

This proposal maintains full= backwards compatibility through careful soft fork design:

# '&#= 39;'Pre-existing Outputs''': All existing Taproot outputs c= ontinue to function unchanged with their original semantics
# ''= 'Node Compatibility''': Non-upgraded nodes validate covenan= t-only outputs as standard Taproot without additional restrictions
# = 9;''Wallet Compatibility''': Existing wallet software c= ontinues to work; covenant functionality is purely additive
# ''= 'Transaction Relay''': All transactions remain compatible w= ith existing relay policies and fee estimation
# '''Mining C= ompatibility''': No changes required to mining software or pool= configurations

The soft fork nature ensures that old software never= sees invalid transactions, maintaining network cohesion during the upgrade= period.

=3D=3D Rationale =3D=3D

=3D=3D=3D Why Extend Taproot= ? =3D=3D=3D

Taproot provides the perfect foundation because:

= # '''Privacy''': Scripts remain hidden until execut= ion
# '''Flexibility''': Merkle tree structure s= upports complex covenants
# '''Efficiency''': Mi= nimal on-chain footprint
# '''Adoption''': Build= ing on existing, activated technology

=3D=3D=3D Why Disable Key-Path= Spending? =3D=3D=3D

Key-path spending would allow attackers to bypa= ss covenant restrictions entirely. By making the internal key unspendable, = we ensure that all spending must go through the covenant script validation.=

=3D=3D=3D Arbitration Mechanism =3D=3D=3D

The automatic arbi= tration fallback provides:

# '''Recovery path''&= #39;: Legitimate users can recover funds through arbitration
# ''= ;'Deterrent effect''': Attackers know stolen funds will be = locked
# '''Institutional security''': Professio= nal arbitration services can be integrated with any wallet type

Inst= itutions can choose from existing specialized services such as the Blockcha= in Arbitration & Commerce Society (https://bacsociety.com) or any othe= r arbitrator they trust, providing flexibility in arbitration provider sele= ction.

=3D=3D=3D Privacy Benefits =3D=3D=3D

# Protected walle= ts are indistinguishable from regular Taproot addresses
# Covenant restr= ictions only become visible when violated
# Normal operations remain com= pletely private
# Attackers cannot identify targets in advance

= =3D=3D Reference Implementation =3D=3D

=3D=3D=3D Core Validation Log= ic =3D=3D=3D

<pre>
def validate_covenant_taproot(scriptPubK= ey, witness_stack, tx_outputs):
=C2=A0 =C2=A0 """Validate= a Covenant-Only Taproot spend"""
=C2=A0 =C2=A0
=C2= =A0 =C2=A0 # Extract the covenant output
=C2=A0 =C2=A0 if len(scriptPubK= ey) !=3D 34 or scriptPubKey[0] !=3D 0x51:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 re= turn False
=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 covenant_output= =3D scriptPubKey[2:]
=C2=A0 =C2=A0
=C2=A0 =C2=A0 # Verify script-pa= th spending (key-path is invalid)
=C2=A0 =C2=A0 if len(witness_stack) &l= t; 3:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return False
=C2=A0 =C2=A0 =C2=A0 = =C2=A0
=C2=A0 =C2=A0 script =3D witness_stack[-2]
=C2=A0 =C2=A0 cont= rol_block =3D witness_stack[-1]
=C2=A0 =C2=A0
=C2=A0 =C2=A0 # Valida= te Taproot script-path
=C2=A0 =C2=A0 if not validate_taproot_script_path= (script, control_block, covenant_output):
=C2=A0 =C2=A0 =C2=A0 =C2=A0 re= turn False
=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 # Execute coven= ant script
=C2=A0 =C2=A0 return execute_covenant_script(script, witness_= stack[:-2], tx_outputs)

def execute_covenant_script(script, witness_= stack, tx_outputs):
=C2=A0 =C2=A0 """Execute the covenant= validation script"""
=C2=A0 =C2=A0
=C2=A0 =C2=A0 # P= arse script to extract whitelist and arbitration keys
=C2=A0 =C2=A0 whit= elist_hash, destination_key, arbitration_keys =3D parse_covenant_script(scr= ipt)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 # Check if spending to whitelisted = destination
=C2=A0 =C2=A0 for output in tx_outputs:
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 dest_hash =3D hash160(output.scriptPubKey)
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 if validate_whitelist_inclusion(dest_hash, whitelist_hash, witne= ss_stack):
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # Spending to autho= rized destination
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return valid= ate_signature(destination_key, witness_stack)
=C2=A0 =C2=A0
=C2=A0 = =C2=A0 # No whitelisted destination found - enforce arbitration
=C2=A0 = =C2=A0 return validate_arbitration_wallet(arbitration_keys, witness_stack)<= br></pre>

=3D=3D=3D Wallet Integration =3D=3D=3D

<pr= e>
class CovenantWallet:
=C2=A0 =C2=A0 def create_covenant_output(= self, whitelist_destinations, arbitrator_pubkey):
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 """Create a new Covenant-Only Taproot output"&qu= ot;"
=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 # = Create whitelist Merkle tree
=C2=A0 =C2=A0 =C2=A0 =C2=A0 whitelist_hash = =3D self.build_whitelist_merkle_tree(whitelist_destinations)
=C2=A0 =C2= =A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Build covenant script=C2=A0 =C2=A0 =C2=A0 =C2=A0 covenant_script =3D self.build_covenant_scrip= t(
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 whitelist_hash,
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.institution_pubkey,
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 arbitrator_pubkey
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 )
=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 # C= reate Taproot commitment with invalid internal key
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 invalid_internal_key =3D tagged_hash("CovenantOnly/InvalidKey&q= uot;, b"")
=C2=A0 =C2=A0 =C2=A0 =C2=A0 taproot_output =3D self= .compute_taproot_output(invalid_internal_key, covenant_script)
=C2=A0 = =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return taproot_output<= br>=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 def spend_covenant_output(= self, utxo, destination, whitelist_proof):
=C2=A0 =C2=A0 =C2=A0 =C2=A0 &= quot;""Spend from a covenant-protected output"""=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Build witne= ss stack
=C2=A0 =C2=A0 =C2=A0 =C2=A0 witness_stack =3D []
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 witness_stack.extend(self.create_signature_data())
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 witness_stack.append(whitelist_proof)
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 witness_stack.append(self.covenant_script)
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 witness_stack.append(self.control_block)
=C2=A0 =C2= =A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return self.create_transa= ction(utxo, destination, witness_stack)
</pre>

=3D=3D Secur= ity Considerations =3D=3D

=3D=3D=3D Cryptographic Security =3D=3D=3D=

# '''Internal Key Security''': The covenant= -only internal key is derived using a cryptographically secure hash functio= n with no known preimage, ensuring no party can compute the corresponding p= rivate key
# '''Script Hiding''': Covenant logic= remains hidden until first execution, preventing attackers from analyzing = restrictions beforehand
# '''Merkle Tree Security''&= #39;: Whitelist validation relies on cryptographically secure Merkle tree i= nclusion proofs, preventing unauthorized destination forgery

=3D=3D= =3D Attack Vectors and Mitigations =3D=3D=3D

# '''Privat= e Key Compromise''': Primary threat mitigated by mandatory scri= pt-path spending that enforces covenant restrictions regardless of key comp= romise
# '''Script Analysis Attack''': Covenant = structure only revealed upon violation attempt, limiting attacker intellige= nce gathering
# '''Arbitration Compromise''': Mi= tigated by using secure arbitration wallet configurations and the ability t= o use multiple independent arbitrators
# '''Implementation V= ulnerabilities''': Reference implementation includes comprehens= ive test vectors and edge case handling
# '''Social Engineer= ing''': Attacks against arbitrators are mitigated because the a= rbitrator's identity remains hidden until the covenant is triggered, pr= eventing targeted attacks during normal operations

=3D=3D=3D Economi= c Security Model =3D=3D=3D

# '''Attacker Economics'&= #39;': Theft attempts face high probability of fund seizure through arb= itration, making attacks economically irrational
# '''Arbitr= ator Incentives''': Arbitrators have economic stake in fair res= olution to maintain reputation and future business
# '''Inst= itution Benefits''': Legitimate institutions maintain full oper= ational control while gaining protection against unauthorized access
# &= #39;''Network Effects''': Widespread adoption increases= overall ecosystem security without degrading privacy or performance
=3D=3D=3D Privacy Trade-offs =3D=3D=3D

# Normal operations maintain= full privacy
# Violation attempts reveal covenant structure
# Overal= l privacy significantly better than current multisig alternatives

= =3D=3D Test Vectors =3D=3D

=3D=3D=3D Vector 1: Covenant-Only Output = Creation =3D=3D=3D

<pre>
Internal Key: 50929b74c1a04954b78b= 4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0
Merkle Root: 9a1c7d8f0e5b3a= 4c2d9f8e7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a8b7c
Script Tree: [covenan= t_script_leaf]
Expected Output: bc1p... (32-byte commitment)
</pre= >

=3D=3D=3D Vector 2: Valid Whitelisted Spend =3D=3D=3D

&l= t;pre>
Input: Covenant-only Taproot UTXO from Vector 1
Destination= : bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 (whitelisted)
Witness Stack= : [signature, merkle_proof, covenant_script, control_block]
Expected: VA= LID transaction
Privacy: Covenant script revealed but appears as normal = Taproot spend
</pre>

=3D=3D=3D Vector 3: Unauthorized Desti= nation Attempt =3D=3D=3D

<pre>
Input: Covenant-only Taproot= UTXO from Vector 1 =C2=A0
Destination: bc1qrp33g0q5c5txsp9arysrx4k6zdkf= s4nce4xj0gdcccefvpysxf3qccfmv3 (not whitelisted)
Witness Stack: [arbitra= tion_signatures, covenant_script, control_block]
Expected: Funds redirec= ted to arbitration wallet
Privacy: Covenant structure fully revealed
= </pre>

=3D=3D=3D Vector 4: Key-Path Bypass Attempt =3D=3D=3D
<pre>
Input: Covenant-only Taproot UTXO from Vector 1
Spe= nd Type: Key-path (single signature, no script reveal)
Witness Stack: [i= nvalid_signature]
Expected: INVALID (unspendable internal key)
Result= : Transaction rejected by consensus rules
</pre>

=3D=3D Imp= lementation Timeline =3D=3D

# '''Phase 1''':= Reference implementation and test suite
# '''Phase 2'&#= 39;': Community review and feedback incorporation =C2=A0
# ''= ;'Phase 3''': Testnet deployment and testing
# ''= ;'Phase 4''': Mainnet soft fork activation (if consensus ac= hieved)

=3D=3D Conclusion =3D=3D

This proposal introduces cov= enant-only Taproot outputs as an optional security enhancement for Bitcoin.= By leveraging existing Taproot infrastructure with invalidated internal ke= ys, we enable invisible transaction restrictions that provide institutional= -grade protection without compromising privacy or usability.

The mec= hanism offers a balanced approach to high-value Bitcoin security, maintaini= ng compatibility with existing systems while providing powerful deterrence = against unauthorized access. The optional nature ensures no impact on users= who do not require this additional security layer.

=3D=3D Acknowled= gments =3D=3D

The author thanks the Bitcoin development community fo= r their work on Taproot (BIP 341) which provides the foundation for this pr= oposal. Special appreciation to the designers of the Taproot script commitm= ent scheme that enables covenant functionality.

=3D=3D References = =3D=3D

* [[bip-0341.mediawiki|BIP 341: Taproot: SegWit version 1 spe= nding rules]]
* [[bip-0342.mediawiki|BIP 342: Validation of Taproot Scri= pts]]
* [https://github.com/bitcoin/bitcoin Bitcoin Core im= plementation]
* [[https://bacsociety.com Blockchain Arbitration & C= ommerce Society]]

--
You received this message because you are subscribed to a topic in the Goog= le Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bitcoindev/Xlcztk_j3b4/unsubscribe<= /a>.
To unsubscribe from this group and all its topics, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit h= ttps://groups.google.com/d/msgid/bitcoindev/6778d5ec-91dc-4c3b-9718-581ec2c= f7be6n%40googlegroups.com.

--
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/bitcoindev/CABQ%2BHo2E6Xea21LpM-2kOffd3kDkAYhmcomZ-%3DXS0YNPpdr6dg%= 40mail.gmail.com.
--0000000000007a5ec5063e836ea6--