Properly handle spendable state and JSON edge cases

Author: sethforprivacy

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