From 1684344515eb1ec29fd931cbfacc86584572890f Mon Sep 17 00:00:00 2001 From: Seth For Privacy Date: Mon, 15 May 2023 12:01:58 -0400 Subject: Add `spendable` state --- bip-0329.mediawiki | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) 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: |- | origin | Optional key origin information referencing the wallet associated with the label +|- +| spendable +| One of true or false, denoting if an output should be spendable by the wallet |} The reference is defined for each type 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 spendable state, defaulting to true 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'])" } -- cgit v1.2.3 From d20444a3ae65296b3c8b3f364c63618662218c4f Mon Sep 17 00:00:00 2001 From: Seth For Privacy Date: Mon, 15 May 2023 13:22:19 -0400 Subject: Add motivation for spendable tag --- bip-0329.mediawiki | 2 ++ 1 file changed, 2 insertions(+) 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 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(-) 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 type as follows: | xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8Nq... |} +Each JSON object must contain both type and ref properties. The label, origin and spendable properties are optional. If the label or spendable properties are omitted, the importing wallet should not alter these values. The origin property should only appear where type is tx, and the spendable property only where type is output. + If present, the optional origin property must contain an abbreviated output descriptor (as defined by BIP380[https://github.com/bitcoin/bips/blob/master/bip-0380.mediawiki BIP-0380]) 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 spendable state, defaulting to true if none is found ==Backwards Compatibility== -- cgit v1.2.3