bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-10-19 19:29:18 +00:00
Code Issues Releases Wiki Activity

bip138: address review

Browse Source
This commit is contained in:
pythcoiner
2026-07-16 02:19:27 -04:00
parent 090fbf0f35
commit f79d0862b8
2 changed files with 13 additions and 13 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
README.mediawiki
View File

@@ -823,7 +823,7 @@ users (see also: [https://en.bitcoin.it/wiki/Economic_majority economic majority
|- |-
| [[bip-0138.md|138]] | [[bip-0138.md|138]]
| Applications | Applications
| Compact encryption scheme for non-seed wallet data | Compact Encryption Scheme for Non-seed Wallet Data
| Pyth | Pyth
| Specification | Specification
| Draft | Draft

24
bip-0138.md
View File

@@ -1,7 +1,7 @@
``` ```
BIP: 138 BIP: 138
Layer: Applications Layer: Applications
Title: Compact encryption scheme for non-seed wallet data Title: Compact Encryption Scheme for Non-seed Wallet Data
Authors: Pyth <pythcoiner@wizardsardine.com> Authors: Pyth <pythcoiner@wizardsardine.com>
Status: Draft Status: Draft
Type: Specification Type: Specification
@@ -36,7 +36,7 @@ in all copies.
### Motivation ### Motivation
Losing the **wallet descriptor** (or **wallet policy**) is just as catastrophic as Losing the **wallet descriptor** (or **wallet policy**) is almost as catastrophic as
losing the seed itself. The seed lets you sign, but the descriptor maps you to your coins. losing the seed itself. The seed lets you sign, but the descriptor maps you to your coins.
For multisig or miniscript wallets, keys alone won't help: without the descriptor, you For multisig or miniscript wallets, keys alone won't help: without the descriptor, you
can't reconstruct the script. can't reconstruct the script.
@@ -79,7 +79,7 @@ Private key material MUST be removed before encrypting any payload.
## Specification ## Specification
Note: in the followings sections, the operator ⊕ refers to the bitwise XOR operation. Note: in the following sections, the operator ⊕ refers to the bitwise XOR operation.
### Secret generation ### Secret generation
@@ -90,7 +90,7 @@ Note: in the followings sections, the operator ⊕ refers to the bitwise XOR op
(see [Descriptor key requirements](#descriptor-key-requirements)). (see [Descriptor key requirements](#descriptor-key-requirements)).
- Let $s$ = sha256(sha256("BIP138_DECRYPTION_SECRET") | sha256("BIP138_DECRYPTION_SECRET") | $p_1$ | $p_2$ | ... | $p_n$) - Let $s$ = sha256(sha256("BIP138_DECRYPTION_SECRET") | sha256("BIP138_DECRYPTION_SECRET") | $p_1$ | $p_2$ | ... | $p_n$)
- Let $s_i$ = sha256(sha256("BIP138_INDIVIDUAL_SECRET") | sha256("BIP138_INDIVIDUAL_SECRET") | $p_i$) - Let $s_i$ = sha256(sha256("BIP138_INDIVIDUAL_SECRET") | sha256("BIP138_INDIVIDUAL_SECRET") | $p_i$)
- Let $c_i$ = $s$ ⊕ $s_i$ - Let $c_i$ = $s$ ⊕ $s_i$
Because $s$ and $s_i$ use distinct domain-separation tags, $s \neq s_i$ and Because $s$ and $s_i$ use distinct domain-separation tags, $s \neq s_i$ and
therefore $c_i$ is never the all-zero string. therefore $c_i$ is never the all-zero string.
@@ -312,7 +312,7 @@ Implementations MUST reject empty payloads.
`CIPHERTEXT` is the encrypted data resulting from encryption of `PAYLOAD` with algorithm `CIPHERTEXT` is the encrypted data resulting from encryption of `PAYLOAD` with algorithm
defined in `ENCRYPTION` where `PAYLOAD` is encoded following this format: defined in `ENCRYPTION` where `PAYLOAD` is encoded following this format:
`CONTENT` `LENGTH` `PLAINTEXT` (`CONTENT` `LENGTH` `PLAINTEXT` ...) (`PADDING`) `CONTENT_TYPE` `LENGTH` `PLAINTEXT` (`CONTENT_TYPE` `LENGTH` `PLAINTEXT` ...) (`PADDING`)
`LENGTH`: variable-length integer representing the length of `PLAINTEXT` in bytes. It MUST `LENGTH`: variable-length integer representing the length of `PLAINTEXT` in bytes. It MUST
be present. be present.
@@ -351,14 +351,14 @@ unnecessary for static ones such as BIP-380 descriptors and BIP-388 wallet polic
All variable-length integers are encoded as All variable-length integers are encoded as
[compact size](https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer). [compact size](https://en.bitcoin.it/wiki/Protocol_documentation#Variable_length_integer).
#### Content #### Content Type
`CONTENT` is a variable length field defining the type of the `PLAINTEXT` that follows `CONTENT_TYPE` is a variable length field defining the type of the `PLAINTEXT` that follows
it. It follows this format: it. It follows this format:
`TYPE` (`LENGTH`) `DATA` `TYPE` (`LENGTH`) `DATA`
A `PAYLOAD` carries one or more `CONTENT LENGTH PLAINTEXT` items, each `CONTENT` A `PAYLOAD` carries one or more `CONTENT_TYPE LENGTH PLAINTEXT` items, each `CONTENT_TYPE`
describing the `PLAINTEXT` immediately following it. The sequence ends at the first describing the `PLAINTEXT` immediately following it. The sequence ends at the first
`TYPE` byte equal to `0x00`, or at the end of the `PAYLOAD`, whichever comes first; all `TYPE` byte equal to `0x00`, or at the end of the `PAYLOAD`, whichever comes first; all
remaining bytes are `PADDING`. A `PAYLOAD` MUST contain at least one item (see remaining bytes are `PADDING`. A `PAYLOAD` MUST contain at least one item (see
@@ -397,7 +397,7 @@ For `TYPE` values defined above:
- 0x03: `DATA` MUST be empty, and the following `PLAINTEXT` is the string itself, - 0x03: `DATA` MUST be empty, and the following `PLAINTEXT` is the string itself,
which MUST be valid UTF-8. which MUST be valid UTF-8.
For all `TYPE` values except `0x01`, parsers MUST reject `CONTENT` if `LENGTH` exceeds For all `TYPE` values except `0x01`, parsers MUST reject `CONTENT_TYPE` if `LENGTH` exceeds
the remaining payload bytes. the remaining payload bytes.
For an unknown `TYPE` less than `0x80`, parsers MUST consume its `LENGTH` bytes of For an unknown `TYPE` less than `0x80`, parsers MUST consume its `LENGTH` bytes of
@@ -414,7 +414,7 @@ payload.[^type-upgrade]
#### BIP380 Descriptor Backup Content #### BIP380 Descriptor Backup Content
When `CONTENT` is `TYPE = 0x01` with `DATA = 0x017c` (BIP380), `PLAINTEXT` is a When `CONTENT_TYPE` is `TYPE = 0x01` with `DATA = 0x017c` (BIP380), `PLAINTEXT` is a
UTF-8 BIP380 descriptor backup. It is either a single bare descriptor string, or UTF-8 BIP380 descriptor backup. It is either a single bare descriptor string, or
a JSON descriptor backup document (for several descriptors) when the first a JSON descriptor backup document (for several descriptors) when the first
character is `{`. character is `{`.
@@ -457,7 +457,7 @@ wallets MAY use this value as a scanning hint.
#### BIP388 Wallet Policy Backup Content #### BIP388 Wallet Policy Backup Content
When `CONTENT` is `TYPE = 0x01` with `DATA = 0x0184` (BIP388), `PLAINTEXT` is a When `CONTENT_TYPE` is `TYPE = 0x01` with `DATA = 0x0184` (BIP388), `PLAINTEXT` is a
UTF-8 JSON wallet policy backup document. A BIP388 wallet policy is a descriptor UTF-8 JSON wallet policy backup document. A BIP388 wallet policy is a descriptor
template plus a vector of key information items, as defined in BIP388. template plus a vector of key information items, as defined in BIP388.
@@ -548,7 +548,7 @@ The version field enables possible future enhancements:
[key_types.json](./bip-0138/test_vectors/keys_types.json) contains test [key_types.json](./bip-0138/test_vectors/keys_types.json) contains test
vectors for key serialisations. vectors for key serialisations.
[content_type.json](./bip-0138/test_vectors/content_type.json) contains test [content_type.json](./bip-0138/test_vectors/content_type.json) contains test
vectors for contents types serialisations. vectors for content types serialisations.
[derivation_path.json](./bip-0138/test_vectors/derivation_path.json) contains [derivation_path.json](./bip-0138/test_vectors/derivation_path.json) contains
test vectors for derivation paths serialisations. test vectors for derivation paths serialisations.
[individual_secrets.json](./bip-0138/test_vectors/individual_secrets.json) [individual_secrets.json](./bip-0138/test_vectors/individual_secrets.json)