2.9 KiB
2.9 KiB
SUPPORTED SPECIFICATIONS
- BIP-13: Address format for pay-to-script-hash
- BIP-14: Protocol version and user agent
- BIP-21: URI scheme for making Bitcoin payments
- BIP-31: Pong message
- BIP-32: Hierarchical deterministic wallets
- BIP-35: Mempool message
- BIP-37: Connection bloom filtering
- BIP-38: Passphrase-protected private key
- BIP-43: Purpose field for deterministic wallets
- BIP-66: Strict DER signatures
- BIP-70: Payment protocol
- BIP-71: Payment protocol MIME types
- RFC 6979: Deterministic usage of ECDSA
UNSUPPORTED OR PARTIALLY SUPPORTED SPECIFICATIONS
BIP-44: Multi-account hierarchy for deterministic wallets
We deliberately chose not to support multiple accounts per wallet. As BIP-44 requires supporting multiple accounts, we are using BIP-32 instead. This implies wallets can't be shared between BIP-32 and BIP-44 compatible wallets, as they would see a different transaction history for the same seed.
BIP-72: bitcoin: URI extensions for payment protocol
The spec is supported, except the "...it should ignore the bitcoin address/amount/label/message in the URI..." part of the recommendation. Important: If you use the request parameter, you have one of the following choices. If you don't follow one of those, your linked payment request won't be accepted.
- Supply an address and optionally an
amountparameter, with their values exactly matching the respective values from the linked payment request message. This means there can be only one output inPaymentDetails.outputsand that output can only contain anOutput.scriptof typepay-to-pubkey,pay-to-pubkey-hashorpay-to-script-hash. Note you should add these parameters anyway for backwards compatibility to wallets that don't support the payment protocol. - Supply an
hparameter, which contains the unpadded base64url-encoded SHA-256 hash of the linked payment request bytes.
(these lists are not exhaustive)