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]]
| Applications
| Compact encryption scheme for non-seed wallet data
| Compact Encryption Scheme for Non-seed Wallet Data
| Pyth
| Specification
| Draft

24
bip-0138.md
View File

@@ -1,7 +1,7 @@
```
BIP: 138
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>
Status: Draft
Type: Specification
@@ -36,7 +36,7 @@ in all copies.
### 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.
For multisig or miniscript wallets, keys alone won't help: without the descriptor, you
can't reconstruct the script.
@@ -79,7 +79,7 @@ Private key material MUST be removed before encrypting any payload.
## 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
@@ -90,7 +90,7 @@ Note: in the followings sections, the operator ⊕ refers to the bitwise XOR op
(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_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
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
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
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
[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:
`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
`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
@@ -397,7 +397,7 @@ For `TYPE` values defined above:
- 0x03: `DATA` MUST be empty, and the following `PLAINTEXT` is the string itself,
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.
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
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
a JSON descriptor backup document (for several descriptors) when the first
character is `{`.
@@ -457,7 +457,7 @@ wallets MAY use this value as a scanning hint.
#### 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
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
vectors for key serialisations.
[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
test vectors for derivation paths serialisations.
[individual_secrets.json](./bip-0138/test_vectors/individual_secrets.json)