From 1684344515eb1ec29fd931cbfacc86584572890f Mon Sep 17 00:00:00 2001
From: Seth For Privacy <hello@sethforprivacy.com>
Date: Mon, 15 May 2023 12:01:58 -0400
Subject: Add `spendable` state

---
 bip-0329.mediawiki | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

(limited to 'bip-0329.mediawiki')

diff --git a/bip-0329.mediawiki b/bip-0329.mediawiki
index 737a75d..3440614 100644
--- a/bip-0329.mediawiki
+++ b/bip-0329.mediawiki
@@ -62,6 +62,9 @@ Each JSON object must contain 3 or 4 key/value pairs, defined as follows:
 |-
 | <tt>origin</tt>
 | Optional key origin information referencing the wallet associated with the label
+|-
+| <tt>spendable</tt>
+| One of <tt>true</tt> or <tt>false</tt>, denoting if an output should be spendable by the wallet
 |}
 
 The reference is defined for each <tt>type</tt> as follows:
@@ -110,6 +113,7 @@ For security reasons no private key types are defined.
 * An importing wallet may ignore records it does not store, and truncate labels if necessary. A suggested default for maximum label length is 255 characters, and an importing wallet should consider warning the user if truncation is applied.
 * Wallets importing public key records may derive addresses from them to match against known wallet addresses.
 * Wallets importing extended public keys may match them against signers, for example in a multisig setup.
+* Wallets importing outputs should respect the <tt>spendable</tt> state, defaulting to <tt>true</tt> if none is found
 
 ==Backwards Compatibility==
 
@@ -124,7 +128,7 @@ The following fragment represents a wallet label export:
 { "type": "addr", "ref": "bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c", "label": "Address" }
 { "type": "pubkey", "ref": "0283409659355b6d1cc3c32decd5d561abaac86c37a353b52895a5e6c196d6f448", "label": "Public Key" }
 { "type": "input", "ref": "f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:0", "label": "Input" }
-{ "type": "output", "ref": "f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:1", "label": "Output" }
+{ "type": "output", "ref": "f91d0a8a78462bc59398f2c5d7a84fcff491c26ba54c4833478b202796c8aafd:1", "label": "Output" , "spendable" : "false" }
 { "type": "xpub", "ref": "xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8", "label": "Extended Public Key" }
 { "type": "tx", "ref": "f546156d9044844e02b181026a1a407abfca62e7ea1159f87bbeaa77b4286c74", "label": "Account #1 Transaction", "origin": "wpkh([d34db33f/84'/0'/1'])" }
 </pre>
-- 
cgit v1.2.3


From d20444a3ae65296b3c8b3f364c63618662218c4f Mon Sep 17 00:00:00 2001
From: Seth For Privacy <hello@sethforprivacy.com>
Date: Mon, 15 May 2023 13:22:19 -0400
Subject: Add motivation for spendable tag

---
 bip-0329.mediawiki | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'bip-0329.mediawiki')

diff --git a/bip-0329.mediawiki b/bip-0329.mediawiki
index 3440614..d79175c 100644
--- a/bip-0329.mediawiki
+++ b/bip-0329.mediawiki
@@ -26,8 +26,10 @@ These standards are well supported and allow users to move easily between differ
 There is, however, no defined standard to transfer any labels the user may have applied to the transactions, addresses, public keys, inputs, outputs or xpubs in their wallet.
 The UTXO model that Bitcoin uses makes these labels particularly valuable as they may indicate the source of funds, whether received externally or as a result of change from a prior transaction.
 In both cases, care must be taken when spending to avoid undesirable leaks of private information.
+
 Labels provide valuable guidance in this regard, and have even become mandatory when spending in several Bitcoin wallets.
 Allowing users to import and export their labels in a standardized way ensures that they do not experience lock-in to a particular wallet application.
+In addition, many wallets allow unspent outputs to be frozen or made unspendable within the wallet. Since this wallet-related metadata is similar to labels and not captured elsewhere, it is also included in this format.
 
 ==Rationale==
 
-- 
cgit v1.2.3


From fc0950e07eac6de2ebf68aa0493f17d3024fbe7c Mon Sep 17 00:00:00 2001
From: Seth For Privacy <hello@sethforprivacy.com>
Date: Tue, 30 May 2023 09:42:26 -0400
Subject: Properly handle `spendable` state and JSON edge cases

---
 bip-0329.mediawiki | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

(limited to 'bip-0329.mediawiki')

diff --git a/bip-0329.mediawiki b/bip-0329.mediawiki
index d79175c..fc5da42 100644
--- a/bip-0329.mediawiki
+++ b/bip-0329.mediawiki
@@ -102,6 +102,8 @@ The reference is defined for each <tt>type</tt> as follows:
 | <tt>xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8Nq...</tt>
 |}
 
+Each JSON object must contain both <tt>type</tt> and <tt>ref</tt> properties. The <tt>label</tt>, <tt>origin</tt> and <tt>spendable</tt> properties are optional. If the <tt>label</tt> or <tt>spendable</tt> properties are omitted, the importing wallet should not alter these values. The <tt>origin</tt> property should only appear where type is <tt>tx</tt>, and the <tt>spendable</tt> property only where type is <tt>output</tt>.
+
 If present, the optional <tt>origin</tt> property must contain an abbreviated output descriptor (as defined by BIP380<ref>[https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki BIP-0380]</ref>) describing a BIP32 compatible originating wallet, including all key origin information but excluding any actual keys, any child path elements, or a checksum.
 This property should be used to disambiguate transaction labels from different wallets contained in the same export, particularly when exporting multiple accounts derived from the same seed.
 
@@ -115,7 +117,6 @@ For security reasons no private key types are defined.
 * An importing wallet may ignore records it does not store, and truncate labels if necessary. A suggested default for maximum label length is 255 characters, and an importing wallet should consider warning the user if truncation is applied.
 * Wallets importing public key records may derive addresses from them to match against known wallet addresses.
 * Wallets importing extended public keys may match them against signers, for example in a multisig setup.
-* Wallets importing outputs should respect the <tt>spendable</tt> state, defaulting to <tt>true</tt> if none is found
 
 ==Backwards Compatibility==
 
-- 
cgit v1.2.3

