OLE: 301 Layer: Applications Title: Hierarchy for Deterministic Omni Wallets Author: Sean Gilligan <[email protected]> Comments-Summary: No comments yet. Comments-URI: https://github.com/OmniLayer/Documentation/blob/master/OLEs/ole-301.adoc Status: Draft Type: Informational Created: 2020-05-27 License: BSD-2-Clause
This document defines paths for Omni-capable Hierarchical Deterministic (HD) wallets. The definitions are based upon Bitcoin BIP-044. This document proposes that Omni tokens should/must be stored in a different HD Path than regular Bitcoin UTXOs.
There are several projects currently developing Hierarchical Deterministic (HD) wallets that will be capable of receiving, storing, and sending Omni Layer tokens. A standard specifying which HD Paths should be used by Omni wallets will simplify interoperability between HD Omni-capable wallets.
In addition, we propose that wallets store Omni tokens at different HD Paths than regular Bitcoins.
There are several reasons why this would be helpful:
-
In an Omni HD wallet implementation it may be desirable to use coin control code/algorithms developed for Bitcoin-only wallets. Those algorithms may not know that an address holds Omni and spend all the UTXOs at that address leaving no Bitcoin “gas” for Omni transactions.
-
If an Omni HD wallet is backed up via BIP 39 and restored to a wallet that doesn’t know about Omni, the same problem as in reason #1 can occur.
-
It may make implementation of wallet software that uses Omni-specific addresses [OLE 300] easier if there is a dedicated “receiving” address path for Omni properties. (I don’t think there would be a need for using the “change” path at m/84'/200‘/0’/1 for Omni transactions.)
Omni token transactions should be stored in the same "account" as Bitcoin transactions, but use a different "change" path. The value 200 is used for Omni receiving addresses and 201 for Omni change addresses.
- Note
-
Previous versions of this specification proposed using the "Coin Type" path-level to indicate the Omni path. This has been changed to using different values at the "change" path-level so that the relevant Bitcoin and Omni paths exist under the same hardened key. This allows a single "xpub" or "xpriv" to represent an HD keychain that includes both Bitcoin and Omni keys/addresses and will simplify Wallet implementation, import/export and backup.
| Purpose (Address Type) | Coin Type | Account | "Change" | Path |
|---|---|---|---|---|
Legacy (Base58) |
Bitcoin |
0 |
Receiving |
m / 44' / 0' / 0' / 0 |
Legacy (Base58) |
Bitcoin |
0 |
Change |
m / 44' / 0' / 0' / 1 |
Legacy (Base58) |
Bitcoin |
0 |
Omni Receiving |
m / 44' / 0' / 0' / 200 |
Legacy (Base58) |
Bitcoin |
0 |
Omni Change |
m / 44' / 0' / 0' / 201 |
SegWit |
Bitcoin |
0 |
Receiving |
m / 84' / 0' / 0' / 0 |
SegWit |
Bitcoin |
0 |
Change |
m / 84' / 0' / 0' / 1 |
SegWit |
Bitcoin |
0 |
Omni Receiving |
m / 84' / 0' / 0' / 200 |
SegWit |
Bitcoin |
0 |
Omni Change |
m / 84' / 0' / 0' / 201 |
The following table shows the Bitcoin Output Descriptor format for each path. The italicized variables stand for the following:
- fingerprint
-
The fingerprint of the account key
- xpub
-
The xpub string
- checksum
-
The Output Descriptor checksum
| Address Type | Path explanation | Descriptor |
|---|---|---|
Legacy |
Bitcoin receiving |
pkh([fingerprint/44'/0'/0']xpub/0/*)#checksum] |
Legacy |
Bitcoin change |
pkh([fingerprint/44'/0'/0']xpub/1/*)#checksum] |
Legacy |
Omni receiving |
pkh([fingerprint/44'/0'/0']xpub/200/*)#checksum] |
Legacy |
Omni change |
pkh([fingerprint/44'/0'/0']xpub/201/*)#checksum] |
SegWit |
Bitcoin receiving |
wpkh([fingerprint/84'/0'/0']xpub/0/*)#checksum] |
SegWit |
Bitcoin change |
wpkh([fingerprint/84'/0'/0']xpub/1/*)#checksum] |
SegWit |
Omni receiving |
wpkh([fingerprint/84'/0'/0']xpub/200/*)#checksum] |
SegWit |
Omni change |
wpkh([fingerprint/84'/0'/0']xpub/201/*)#checksum] |
-
BIP-49: Derivation scheme for P2WPKH-nested-in-P2SH based accounts
-
Omni Layer Segwit Implementation [TBD]
-
BIP-0173 : Base32 address format for native v0-16 witness outputs