path: root/9f/7ca1bb97a52bd435fc64d15c8e923f694aa020

Delivery-date: Thu, 21 Aug 2025 11:16:50 -0700
Received: from mail-oa1-f60.google.com ([209.85.160.60])
	by mail.fairlystable.org with esmtps  (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
	(Exim 4.94.2)
	(envelope-from <bitcoindev+bncBCQL3WHQ24JRBBWFTXCQMGQEGEBSPYY@googlegroups.com>)
	id 1up9qC-0004eN-QP
	for bitcoindev@gnusha.org; Thu, 21 Aug 2025 11:16:50 -0700
Received: by mail-oa1-f60.google.com with SMTP id 586e51a60fabf-30ccec4adb4sf2305132fac.3
        for <bitcoindev@gnusha.org>; Thu, 21 Aug 2025 11:16:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=googlegroups.com; s=20230601; t=1755800202; x=1756405002; 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=QMZdtm6DRfkMumEaq8FTKEnC5S0O3kA3ife2CQ6rWDk=;
        b=PuQZPeYWypHK1VSaVtLP1rm0uoI/ZdzGqrx5j3htTfRi3H8YAHFiKkvNLYqWtjngEm
         7emTZYfoz7+Y8F3YvVpmmGG9kZcHv9w/FSkWNeCzaOQn1E3OzuoQwA22M89lbN0b2uK2
         bFZoSf91dDRfMNbe8Ont5pXOZ+r8KBqfuvCsQVoadSK1lQ68qOr/SMgP6wdDKQZTuark
         HhkpbCXpkkmgve+EJLkisekt2hCCk18XbaeFklwsedQojzcrnDP36mGbJNMZv02ZNREM
         JsD3Y31AvzuLqKHOqnommMIaD6xk3DnN45GzEt5JeRAmEUA+d0nusGK2JI7yR5IF1rGl
         A92Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20230601; t=1755800202; x=1756405002; 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=QMZdtm6DRfkMumEaq8FTKEnC5S0O3kA3ife2CQ6rWDk=;
        b=Cf9TMv5EWL3+Z+UxUr2Wtg3EfsNz0qErg5UO5HCrWc2RW+EZcy/4Bo3NMhwBfJA9VE
         QXitTBkofdgHeEFIx2wIyuLyDoN8RootEpZu7dSQVhS6pfjpXxqMewhpeWNMit4abPSl
         /60DQTlzJRxE4fdJXIMeCIGpWRcHzz2UVeX8A5cXEa1ctYYSwa+xRlrWt39m+hxJqKN2
         efJrGFP9JiPrFtcxWhwebpVNuOe74jP3zqF47u2XzgSzRho+TLTM2yLH0YMGzJ8UdhRY
         FUVIf5ior20LA+3F9wfEjF6Sdx/ELhfcWZu50QPwBe0WL66znjJCFAsYWIMz4COY8DnN
         +i9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20230601; t=1755800202; x=1756405002;
        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=QMZdtm6DRfkMumEaq8FTKEnC5S0O3kA3ife2CQ6rWDk=;
        b=fIP/7ePdKoEslnqygeAOidWEKH+9wV8+nzL12/PMov/+9TWZfU9i3yuHqoKVeYCJYs
         KWrf9KoCDAd3Em4bKmYdiZLu6f4rfkBunhRLI+abDGqWn0bCJzbHeDVx5boYNcII8Ifo
         YbeHnf675slQLeC4CuCoWUr0pVV+Ivj5qyuEHkGhdaCm1NtbwRU6koN5BvNUeXQzYtiX
         7E6mT2/lnjvePecO6ZFtdFVGb1s+juC6n3x8h71oGmBaHEpc5khObwU+P/QL7PSeSF4L
         hYJzeg8Z89K0q25B0LOejVp7mLutO2kxnqgMZbum/wv4uady6N8dF4e9NxocKoyyOU9r
         Rjtw==
Sender: bitcoindev@googlegroups.com
X-Forwarded-Encrypted: i=1; AJvYcCUdxJj/vP7Hi0wT9T6hiIaGTMonOiZKmiZyLcmpESp7a9wMk1zlO/NYSxgw8ICztxs/Y0G1z9pkqJkC@gnusha.org
X-Gm-Message-State: AOJu0YxE2Oa8Pd2lUoJYRfZ1hFFio1PcVlqoZq5ruIYE9/qmU3ISZu+2
	0lmt8LegRxirCrtC86y7+6lBRmZedwep7+jQCvXWlVfi11DP3Eo3b82G
X-Google-Smtp-Source: AGHT+IENif0du3VF6vcqjqNaKRKgbSBrKMcqueUhtuv8crfJ37Lzz+Wd8nLcrrIiio1pMzfSI+vFLQ==
X-Received: by 2002:a05:6871:e786:b0:2ef:eddd:690d with SMTP id 586e51a60fabf-314dcd4621fmr91088fac.24.1755800202372;
        Thu, 21 Aug 2025 11:16:42 -0700 (PDT)
X-BeenThere: bitcoindev@googlegroups.com; h=AZMbMZdeR8xBszxGl1u+CIzuNBdc4/XsPp2V4uO1uFPWeodcGA==
Received: by 2002:a05:6870:799:b0:2c2:2ed7:fb78 with SMTP id
 586e51a60fabf-314c1cf64e9ls557977fac.0.-pod-prod-01-us; Thu, 21 Aug 2025
 11:16:38 -0700 (PDT)
X-Received: by 2002:a05:6808:181b:b0:435:51e3:4c32 with SMTP id 5614622812f47-437851cd516mr337578b6e.22.1755800198377;
        Thu, 21 Aug 2025 11:16:38 -0700 (PDT)
Received: by 2002:a05:690c:3345:b0:718:5fd:a4e7 with SMTP id 00721157ae682-71fdb634fe6ms7b3;
        Thu, 21 Aug 2025 10:46:33 -0700 (PDT)
X-Received: by 2002:a05:690c:6d13:b0:71e:8165:990f with SMTP id 00721157ae682-71fdc316064mr1216997b3.24.1755798392300;
        Thu, 21 Aug 2025 10:46:32 -0700 (PDT)
Date: Thu, 21 Aug 2025 10:46:31 -0700 (PDT)
From: Matias Monteagudo <omatimonteagudov@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <6778d5ec-91dc-4c3b-9718-581ec2cf7be6n@googlegroups.com>
Subject: [bitcoindev] BIP Booby Trapped Wallets - Covenant-Only Taproot Outputs
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_80726_2044639498.1755798391708"
X-Original-Sender: omatimonteagudov@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.0 (/)

------=_Part_80726_2044639498.1755798391708
Content-Type: multipart/alternative; 
	boundary="----=_Part_80727_1919322406.1755798391708"

------=_Part_80727_1919322406.1755798391708
Content-Type: text/plain; charset="UTF-8"

<pre>
  BIP: ?
  Layer: Consensus (soft fork)
  Title: Booby Trapped Wallets
  Author: Matias Monteagudo <omatimonteagudov@gmail.com>
  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
</pre>

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

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

The output commitment follows standard Taproot construction:
<pre>
covenant_taproot_output = internal_pubkey + tagged_hash("TapTweak", 
internal_pubkey || merkle_root)
</pre>

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:
<pre>
internal_pubkey = lift_x(tagged_hash("CovenantOnly/InvalidKey", b""))
</pre>

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:

<pre>
# Check if destination is whitelisted
OP_DUP OP_HASH160 <destination_hash> OP_EQUAL
OP_IF
    # Validate whitelist membership with Merkle proof
    OP_SWAP <whitelist_merkle_root> OP_CHECKTEMPLATEVERIFY
    <destination_pubkey> OP_CHECKSIG
OP_ELSE
    # Enforce arbitration for unauthorized destinations
    <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 
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:
<pre>
whitelist_hash = merkle_root(destination_1, destination_2, ..., 
destination_n)
</pre>

=== 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):

<pre>
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)
</pre>

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

<pre>
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)
</pre>

=== Wallet Integration ===

<pre>
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)
</pre>

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

<pre>
Internal Key: 
50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0
Merkle Root: 
9a1c7d8f0e5b3a4c2d9f8e7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a8b7c
Script Tree: [covenant_script_leaf]
Expected Output: bc1p... (32-byte commitment)
</pre>

=== Vector 2: Valid Whitelisted Spend ===

<pre>
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
</pre>

=== Vector 3: Unauthorized Destination Attempt ===

<pre>
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
</pre>

=== Vector 4: Key-Path Bypass Attempt ===

<pre>
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
</pre>

== 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 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/6778d5ec-91dc-4c3b-9718-581ec2cf7be6n%40googlegroups.com.

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

&lt;pre&gt;<br />=C2=A0 BIP: ?<br />=C2=A0 Layer: Consensus (soft fork)<br =
/>=C2=A0 Title: Booby Trapped Wallets<br />=C2=A0 Author: Matias Monteagudo=
 &lt;omatimonteagudov@gmail.com&gt;<br />=C2=A0 Comments-Summary: No commen=
ts yet.<br />=C2=A0 Comments-URI: https://github.com/bitcoin/bips/wiki/Comm=
ents:BIP-XXXX<br />=C2=A0 Status: Draft<br />=C2=A0 Type: Standards Track<b=
r />=C2=A0 Created: 2025-08-21<br />=C2=A0 License: BSD-2-Clause<br />=C2=
=A0 Requires: 341, 342<br />&lt;/pre&gt;<br /><br />=3D=3D Abstract =3D=3D<=
br /><br />This BIP proposes covenant-only Taproot outputs, an optional but=
 irrevocable wallet-level security mechanism. When activated by wallet owne=
rs, covenant-only mode disables key-path spending and mandates script-path =
spending, creating invisible transaction restrictions that only become appa=
rent 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.<br /><br=
 />=3D=3D Copyright =3D=3D<br /><br />This BIP is licensed under the BSD 2-=
clause license.<br /><br />=3D=3D Motivation =3D=3D<br /><br />High-profile=
 Bitcoin holders, particularly institutional entities such as exchanges, fa=
ce significant security risks. When attackers gain access to private keys, =
they can drain wallets with varying degrees of difficulty but ultimately su=
cceed. Current security measures are visible and can be circumvented by sop=
histicated attackers.<br /><br />This proposal creates an optional but irre=
vocable security mechanism where:<br /><br /># Wallet owners can voluntaril=
y and irrevocably restrict future transactions to predefined destination ad=
dresses<br /># Once activated, unauthorized transfer attempts are automatic=
ally redirected to arbitration wallets<br /># The restrictions remain compl=
etely invisible until triggered<br /># Protected wallets appear identical t=
o unprotected ones, preventing attacker preparation<br /># The mechanism is=
 entirely opt-in and cannot be forced upon any wallet<br /><br />=3D=3D Spe=
cification =3D=3D<br /><br />=3D=3D=3D Covenant-Only Taproot Output =3D=3D=
=3D<br /><br />A covenant-only Taproot output extends standard Taproot (BIP=
 341) by mandating script-path spending through the use of an invalidated i=
nternal key:<br /><br />&lt;pre&gt;<br />scriptPubKey: OP_1 &lt;32-byte-cov=
enant-taproot-output&gt;<br />&lt;/pre&gt;<br /><br />The output commitment=
 follows standard Taproot construction:<br />&lt;pre&gt;<br />covenant_tapr=
oot_output =3D internal_pubkey + tagged_hash("TapTweak", internal_pubkey ||=
 merkle_root)<br />&lt;/pre&gt;<br /><br />Where internal_pubkey is set to =
an unspendable value, making key-path spending impossible.<br /><br />=3D=
=3D=3D Key Components =3D=3D=3D<br /><br />=3D=3D=3D=3D 1. Internal Key Inv=
alidation =3D=3D=3D=3D<br /><br />The internal public key MUST be set to th=
e following unspendable point:<br />&lt;pre&gt;<br />internal_pubkey =3D li=
ft_x(tagged_hash("CovenantOnly/InvalidKey", b""))<br />&lt;/pre&gt;<br /><b=
r />This point has no known discrete logarithm, ensuring key-path spending =
is cryptographically impossible while maintaining compatibility with existi=
ng Taproot validation rules.<br /><br />=3D=3D=3D=3D 2. Covenant Script Tem=
plate =3D=3D=3D=3D<br /><br />The covenant script enforces destination rest=
rictions through conditional execution:<br /><br />&lt;pre&gt;<br /># Check=
 if destination is whitelisted<br />OP_DUP OP_HASH160 &lt;destination_hash&=
gt; OP_EQUAL<br />OP_IF<br />=C2=A0 =C2=A0 # Validate whitelist membership =
with Merkle proof<br />=C2=A0 =C2=A0 OP_SWAP &lt;whitelist_merkle_root&gt; =
OP_CHECKTEMPLATEVERIFY<br />=C2=A0 =C2=A0 &lt;destination_pubkey&gt; OP_CHE=
CKSIG<br />OP_ELSE<br />=C2=A0 =C2=A0 # Enforce arbitration for unauthorize=
d destinations<br />=C2=A0 =C2=A0 &lt;arbitration_wallet_script&gt;<br />OP=
_ENDIF<br />&lt;/pre&gt;<br /><br />Note: This script assumes a hypothetica=
l OP_CHECKTEMPLATEVERIFY opcode for Merkle proof validation. Actual impleme=
ntation would use existing opcodes for Merkle tree verification. The arbitr=
ation_wallet_script can be any valid script (single-sig, multisig, or other=
) as determined by the institution and arbitrator.<br /><br />=3D=3D=3D=3D =
3. Whitelist Construction =3D=3D=3D=3D<br /><br />Allowed destinations are =
hashed into a Merkle tree:<br />&lt;pre&gt;<br />whitelist_hash =3D merkle_=
root(destination_1, destination_2, ..., destination_n)<br />&lt;/pre&gt;<br=
 /><br />=3D=3D=3D Transaction Validation =3D=3D=3D<br /><br />=3D=3D=3D=3D=
 Normal Operation =3D=3D=3D=3D<br /><br />When spending to a whitelisted de=
stination:<br /># Transaction appears as standard Taproot spend<br /># Scri=
pt-path reveals the covenant logic<br /># Whitelist proof validates the des=
tination<br /># Transaction proceeds normally<br /><br />=3D=3D=3D=3D Unaut=
horized Attempt =3D=3D=3D=3D<br /><br />When attempting to spend to non-whi=
telisted destination:<br /># Script-path execution fails whitelist check<br=
 /># Automatic fallback to arbitration wallet<br /># Funds are locked pendi=
ng arbitration resolution<br /><br />=3D=3D=3D Activation and Deployment =
=3D=3D=3D<br /><br />This soft fork follows the deployment mechanism specif=
ied in BIP 9 (Version bits with timeout and delay):<br /><br />&lt;pre&gt;<=
br />name: covenant-taproot<br />bit: TBD (to be assigned by BIP editors)<b=
r />starttime: TBD (6 months after BIP Final status)<br />timeout: TBD (2 y=
ears after starttime)<br />threshold: 1815 (90% of 2016 blocks)<br />&lt;/p=
re&gt;<br /><br />The soft fork activates when 90% of blocks in a difficult=
y period signal readiness, ensuring broad miner consensus before enforcemen=
t begins.<br /><br />=3D=3D=3D New Consensus Rules =3D=3D=3D<br /><br />Aft=
er activation, nodes MUST enforce the following rules for covenant-only Tap=
root outputs:<br /><br /># '''Internal Key Validation''': Outputs using the=
 covenant-only internal key (as defined in section 1) MUST be validated as =
covenant-only outputs<br /># '''Mandatory Script-Path''': Covenant-only out=
puts MUST be spent using script-path spending; key-path spending attempts a=
re INVALID<br /># '''Script Execution''': The covenant script MUST successf=
ully execute and validate destination restrictions<br /># '''Merkle Proof V=
erification''': Whitelisted destinations MUST provide valid Merkle inclusio=
n proofs<br /># '''Arbitration Fallback''': Non-whitelisted destinations MU=
ST redirect to the specified arbitration wallet<br /><br />These rules only=
 apply to outputs created after activation and do not affect existing Tapro=
ot outputs.<br /><br />=3D=3D Backwards Compatibility =3D=3D<br /><br />Thi=
s proposal maintains full backwards compatibility through careful soft fork=
 design:<br /><br /># '''Pre-existing Outputs''': All existing Taproot outp=
uts continue to function unchanged with their original semantics<br /># '''=
Node Compatibility''': Non-upgraded nodes validate covenant-only outputs as=
 standard Taproot without additional restrictions<br /># '''Wallet Compatib=
ility''': Existing wallet software continues to work; covenant functionalit=
y is purely additive<br /># '''Transaction Relay''': All transactions remai=
n compatible with existing relay policies and fee estimation<br /># '''Mini=
ng Compatibility''': No changes required to mining software or pool configu=
rations<br /><br />The soft fork nature ensures that old software never see=
s invalid transactions, maintaining network cohesion during the upgrade per=
iod.<br /><br />=3D=3D Rationale =3D=3D<br /><br />=3D=3D=3D Why Extend Tap=
root? =3D=3D=3D<br /><br />Taproot provides the perfect foundation because:=
<br /><br /># '''Privacy''': Scripts remain hidden until execution<br /># '=
''Flexibility''': Merkle tree structure supports complex covenants<br /># '=
''Efficiency''': Minimal on-chain footprint<br /># '''Adoption''': Building=
 on existing, activated technology<br /><br />=3D=3D=3D Why Disable Key-Pat=
h Spending? =3D=3D=3D<br /><br />Key-path spending would allow attackers to=
 bypass covenant restrictions entirely. By making the internal key unspenda=
ble, we ensure that all spending must go through the covenant script valida=
tion.<br /><br />=3D=3D=3D Arbitration Mechanism =3D=3D=3D<br /><br />The a=
utomatic arbitration fallback provides:<br /><br /># '''Recovery path''': L=
egitimate users can recover funds through arbitration<br /># '''Deterrent e=
ffect''': Attackers know stolen funds will be locked<br /># '''Institutiona=
l security''': Professional arbitration services can be integrated with any=
 wallet type<br /><br />Institutions can choose from existing specialized s=
ervices such as the Blockchain Arbitration &amp; Commerce Society (https://=
bacsociety.com) or any other arbitrator they trust, providing flexibility i=
n arbitration provider selection.<br /><br />=3D=3D=3D Privacy Benefits =3D=
=3D=3D<br /><br /># Protected wallets are indistinguishable from regular Ta=
proot addresses<br /># Covenant restrictions only become visible when viola=
ted<br /># Normal operations remain completely private<br /># Attackers can=
not identify targets in advance<br /><br />=3D=3D Reference Implementation =
=3D=3D<br /><br />=3D=3D=3D Core Validation Logic =3D=3D=3D<br /><br />&lt;=
pre&gt;<br />def validate_covenant_taproot(scriptPubKey, witness_stack, tx_=
outputs):<br />=C2=A0 =C2=A0 """Validate a Covenant-Only Taproot spend"""<b=
r />=C2=A0 =C2=A0 <br />=C2=A0 =C2=A0 # Extract the covenant output<br />=
=C2=A0 =C2=A0 if len(scriptPubKey) !=3D 34 or scriptPubKey[0] !=3D 0x51:<br=
 />=C2=A0 =C2=A0 =C2=A0 =C2=A0 return False<br />=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 <br />=C2=A0 =C2=A0 covenant_output =3D scriptPubKey[2:]<br />=C2=A0 =
=C2=A0 <br />=C2=A0 =C2=A0 # Verify script-path spending (key-path is inval=
id)<br />=C2=A0 =C2=A0 if len(witness_stack) &lt; 3:<br />=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 return False<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br />=C2=A0 =C2=
=A0 script =3D witness_stack[-2]<br />=C2=A0 =C2=A0 control_block =3D witne=
ss_stack[-1]<br />=C2=A0 =C2=A0 <br />=C2=A0 =C2=A0 # Validate Taproot scri=
pt-path<br />=C2=A0 =C2=A0 if not validate_taproot_script_path(script, cont=
rol_block, covenant_output):<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 return False<=
br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br />=C2=A0 =C2=A0 # Execute covenant scr=
ipt<br />=C2=A0 =C2=A0 return execute_covenant_script(script, witness_stack=
[:-2], tx_outputs)<br /><br />def execute_covenant_script(script, witness_s=
tack, tx_outputs):<br />=C2=A0 =C2=A0 """Execute the covenant validation sc=
ript"""<br />=C2=A0 =C2=A0 <br />=C2=A0 =C2=A0 # Parse script to extract wh=
itelist and arbitration keys<br />=C2=A0 =C2=A0 whitelist_hash, destination=
_key, arbitration_keys =3D parse_covenant_script(script)<br />=C2=A0 =C2=A0=
 <br />=C2=A0 =C2=A0 # Check if spending to whitelisted destination<br />=
=C2=A0 =C2=A0 for output in tx_outputs:<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 de=
st_hash =3D hash160(output.scriptPubKey)<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 i=
f validate_whitelist_inclusion(dest_hash, whitelist_hash, witness_stack):<b=
r />=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 # Spending to authorized dest=
ination<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return validate_sign=
ature(destination_key, witness_stack)<br />=C2=A0 =C2=A0 <br />=C2=A0 =C2=
=A0 # No whitelisted destination found - enforce arbitration<br />=C2=A0 =
=C2=A0 return validate_arbitration_wallet(arbitration_keys, witness_stack)<=
br />&lt;/pre&gt;<br /><br />=3D=3D=3D Wallet Integration =3D=3D=3D<br /><b=
r />&lt;pre&gt;<br />class CovenantWallet:<br />=C2=A0 =C2=A0 def create_co=
venant_output(self, whitelist_destinations, arbitrator_pubkey):<br />=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 """Create a new Covenant-Only Taproot output"""<br />=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Create whit=
elist Merkle tree<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 whitelist_hash =3D self.=
build_whitelist_merkle_tree(whitelist_destinations)<br />=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 <br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Build covenant script<br />=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 covenant_script =3D self.build_covenant_script(=
<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 whitelist_hash, <br />=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 self.institution_pubkey,<br />=C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 arbitrator_pubkey<br />=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 )<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br />=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 # Create Taproot commitment with invalid internal key<br />=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 invalid_internal_key =3D tagged_hash("CovenantOnly/Inv=
alidKey", b"")<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 taproot_output =3D self.com=
pute_taproot_output(invalid_internal_key, covenant_script)<br />=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 <br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 return taproot_output<b=
r />=C2=A0 =C2=A0 =C2=A0 =C2=A0 <br />=C2=A0 =C2=A0 def spend_covenant_outp=
ut(self, utxo, destination, whitelist_proof):<br />=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 """Spend from a covenant-protected output"""<br />=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 <br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 # Build witness stack<br />=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 witness_stack =3D []<br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
witness_stack.extend(self.create_signature_data())<br />=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 witness_stack.append(whitelist_proof)<br />=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 witness_stack.append(self.covenant_script)<br />=C2=A0 =C2=A0 =C2=A0=
 =C2=A0 witness_stack.append(self.control_block)<br />=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 <br />=C2=A0 =C2=A0 =C2=A0 =C2=A0 return self.create_transaction(utx=
o, destination, witness_stack)<br />&lt;/pre&gt;<br /><br />=3D=3D Security=
 Considerations =3D=3D<br /><br />=3D=3D=3D Cryptographic Security =3D=3D=
=3D<br /><br /># '''Internal Key Security''': The covenant-only internal ke=
y is derived using a cryptographically secure hash function with no known p=
reimage, ensuring no party can compute the corresponding private key<br />#=
 '''Script Hiding''': Covenant logic remains hidden until first execution, =
preventing attackers from analyzing restrictions beforehand<br /># '''Merkl=
e Tree Security''': Whitelist validation relies on cryptographically secure=
 Merkle tree inclusion proofs, preventing unauthorized destination forgery<=
br /><br />=3D=3D=3D Attack Vectors and Mitigations =3D=3D=3D<br /><br /># =
'''Private Key Compromise''': Primary threat mitigated by mandatory script-=
path spending that enforces covenant restrictions regardless of key comprom=
ise<br /># '''Script Analysis Attack''': Covenant structure only revealed u=
pon violation attempt, limiting attacker intelligence gathering<br /># '''A=
rbitration Compromise''': Mitigated by using secure arbitration wallet conf=
igurations and the ability to use multiple independent arbitrators<br /># '=
''Implementation Vulnerabilities''': Reference implementation includes comp=
rehensive test vectors and edge case handling<br /># '''Social Engineering'=
'': Attacks against arbitrators are mitigated because the arbitrator's iden=
tity remains hidden until the covenant is triggered, preventing targeted at=
tacks during normal operations<br /><br />=3D=3D=3D Economic Security Model=
 =3D=3D=3D<br /><br /># '''Attacker Economics''': Theft attempts face high =
probability of fund seizure through arbitration, making attacks economicall=
y irrational<br /># '''Arbitrator Incentives''': Arbitrators have economic =
stake in fair resolution to maintain reputation and future business<br /># =
'''Institution Benefits''': Legitimate institutions maintain full operation=
al control while gaining protection against unauthorized access<br /># '''N=
etwork Effects''': Widespread adoption increases overall ecosystem security=
 without degrading privacy or performance<br /><br />=3D=3D=3D Privacy Trad=
e-offs =3D=3D=3D<br /><br /># Normal operations maintain full privacy<br />=
# Violation attempts reveal covenant structure<br /># Overall privacy signi=
ficantly better than current multisig alternatives<br /><br />=3D=3D Test V=
ectors =3D=3D<br /><br />=3D=3D=3D Vector 1: Covenant-Only Output Creation =
=3D=3D=3D<br /><br />&lt;pre&gt;<br />Internal Key: 50929b74c1a04954b78b4b6=
035e97a5e078a5a0f28ec96d547bfee9ace803ac0<br />Merkle Root: 9a1c7d8f0e5b3a4=
c2d9f8e7b6a5c4d3e2f1a0b9c8d7e6f5a4b3c2d1e0f9a8b7c<br />Script Tree: [covena=
nt_script_leaf]<br />Expected Output: bc1p... (32-byte commitment)<br />&lt=
;/pre&gt;<br /><br />=3D=3D=3D Vector 2: Valid Whitelisted Spend =3D=3D=3D<=
br /><br />&lt;pre&gt;<br />Input: Covenant-only Taproot UTXO from Vector 1=
<br />Destination: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 (whitelisted)=
<br />Witness Stack: [signature, merkle_proof, covenant_script, control_blo=
ck]<br />Expected: VALID transaction<br />Privacy: Covenant script revealed=
 but appears as normal Taproot spend<br />&lt;/pre&gt;<br /><br />=3D=3D=3D=
 Vector 3: Unauthorized Destination Attempt =3D=3D=3D<br /><br />&lt;pre&gt=
;<br />Input: Covenant-only Taproot UTXO from Vector 1 =C2=A0<br />Destinat=
ion: bc1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3qccfmv3 (not wh=
itelisted)<br />Witness Stack: [arbitration_signatures, covenant_script, co=
ntrol_block]<br />Expected: Funds redirected to arbitration wallet<br />Pri=
vacy: Covenant structure fully revealed<br />&lt;/pre&gt;<br /><br />=3D=3D=
=3D Vector 4: Key-Path Bypass Attempt =3D=3D=3D<br /><br />&lt;pre&gt;<br /=
>Input: Covenant-only Taproot UTXO from Vector 1<br />Spend Type: Key-path =
(single signature, no script reveal)<br />Witness Stack: [invalid_signature=
]<br />Expected: INVALID (unspendable internal key)<br />Result: Transactio=
n rejected by consensus rules<br />&lt;/pre&gt;<br /><br />=3D=3D Implement=
ation Timeline =3D=3D<br /><br /># '''Phase 1''': Reference implementation =
and test suite<br /># '''Phase 2''': Community review and feedback incorpor=
ation =C2=A0<br /># '''Phase 3''': Testnet deployment and testing<br /># ''=
'Phase 4''': Mainnet soft fork activation (if consensus achieved)<br /><br =
/>=3D=3D Conclusion =3D=3D<br /><br />This proposal introduces covenant-onl=
y Taproot outputs as an optional security enhancement for Bitcoin. By lever=
aging existing Taproot infrastructure with invalidated internal keys, we en=
able invisible transaction restrictions that provide institutional-grade pr=
otection without compromising privacy or usability.<br /><br />The mechanis=
m offers a balanced approach to high-value Bitcoin security, maintaining co=
mpatibility with existing systems while providing powerful deterrence again=
st unauthorized access. The optional nature ensures no impact on users who =
do not require this additional security layer.<br /><br />=3D=3D Acknowledg=
ments =3D=3D<br /><br />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 comm=
itment scheme that enables covenant functionality.<br /><br />=3D=3D Refere=
nces =3D=3D<br /><br />* [[bip-0341.mediawiki|BIP 341: Taproot: SegWit vers=
ion 1 spending rules]]<br />* [[bip-0342.mediawiki|BIP 342: Validation of T=
aproot Scripts]]<br />* [https://github.com/bitcoin/bitcoin Bitcoin Core im=
plementation]<br />* [[https://bacsociety.com Blockchain Arbitration &amp; =
Commerce Society]]

<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/6778d5ec-91dc-4c3b-9718-581ec2cf7be6n%40googlegroups.com?utm_med=
ium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msgid/bitcoind=
ev/6778d5ec-91dc-4c3b-9718-581ec2cf7be6n%40googlegroups.com</a>.<br />

------=_Part_80727_1919322406.1755798391708--

------=_Part_80726_2044639498.1755798391708--