BitCache Message Specification
The BitCache message structure is one of length-delimited chunks of bytes with the following parts:
| Chunk | Chunk details | Example (as hex) |
|---|---|---|
Transaction | A chunk that includes a serialised transaction. |
|
Key usage metadata. | A chunk that defines key usage metadata in the outputs of the preceding transaction. |
|
Transaction chunk structure
| Fields | Details | Example (as hex) |
|---|---|---|
Chunk name | The "TXBYTES.." characters. |
|
Chunk size | The size of the chunk data. In this case this will be the size of the raw transaction bytes, as it is the only contents of this chunk. |
|
Transaction | The raw transaction bytes. | See the example data value for "Transaction" for a hex-encoded transaction. |
Output key usage chunk structure
| Fields | Details | Example (as hex) |
|---|---|---|
Chunk name | The "TXOKEYS." characters. |
|
Chunk size | The size of the chunk data. In this case, it will be the total length of all included txo key usage metadata. | |
N txo key usage metadata entries. | See the Key usage metadata structure. |
Key usage metadata structure
| Field | Details | Example |
|---|---|---|
TXO index | Unsigned 32 bit little endian encoding of the relevant output index. |
|
Script type | Script type length (unsigned 16 bit little endian encoding) followed by the script type name. |
|
Parent key fingerprint | Fingerprint length (unsigned 16 bit little endian encoding) followed by the fingerprint bytes. |
|
Key derivation | Derivation path length (unsigned 16 bit little endian encoding) followed by the derivation path text. |
|
Example data values
| Field | Details | Example |
|---|---|---|
Transaction | Raw transaction bytes |
|
Output Index | Output index (vout) a key is used in |
|
Seed/Key Fingerprint | A unique identifier to specify which seed/master key is used | |
Derivation | The derivation method and the derivation path used (separated by a colon) |
|
Script Type | The script type(s) used in that transaction output |
|
Seed/Key Fingerprint
Electrum wallets build on the BIP32 fingerprint. This is what is included into a BIP32 xpub and will likely be good enough for our needs. This is the first four bytes of the ripemd160 hash of the parent public key.
So wherever Electrum wallets have a need for fingerprints the following is done:
For single singer wallets this is the first four bytes of the ripemd160 hash of the parent key. This is 4 bytes long.
For multi-signature wallets, the fingerprint of each cosigner wallet is taken as per the single signer case, then they are ordered and concatenated. For n cosigners, this is n*4 bytes long.
Last updated