12/5/2023 0 Comments Bitmessage protocolNotification transaction: a transaction which sends an output to a notification address which includes an embedded payment code.Notification address: the P2PKH address associated with the 0 th public key derived from a payment code.Payment code: an extended public key and associated metadata which is associated with a particular identity/account.It is assumed that Alice can easily obtain Bob's payment code via a suitable method outside the scope of the payment code protocol. Alice initiates a Bitcoin transaction, and Bob is the recipient of the transaction. In the following examples, Alice and Bob are identities with a corresponding payment codes. The payload is the binary serialization of the payment code.The version byte is: 0x47 (produces a "P" as the first character of the serialized form).When a payment code is presented to the user, it SHOULD be presented encoded in Base58Check form. Bytes 67 - 79: reserved for future expansion, zero-filled unless otherwise noted.Bytes 3 - 34: x value, must be a member of the secp256k1 group.All bits must be zero except where specified elsewhere in this specification Version 1 Representation Binary SerializationĪ payment code contains the following elements: Version 1 payment codes are only recommended for wallets which lack access to bloom filtering capability.Wallets which have bloom filtering capabilities SHOULD create version 2 payment codes instead of version 1 payment codes.If Alice uses a version x payment code, and Bob uses a version y payment code, they can still send and receive transactions between each other. Unless otherwise specified, payment codes of different versions are interoperable. Payment codes contain a version byte which identifies a specific set of behavior. Incoming payments received via this specification are equivalent to payments received to BIP-44 addresses, and unspent outputs from both types of addresses can be used as inputs in the same outgoing transaction.Įxcept where noted, all keys derived from a payment code use the public derivation method. The second account in a wallet consists of the new account/payment code pair created by using an index of 1 in as the account/identity level of both paths. Wallets SHOULD treat payment codes as intrinsically part of the BIP-44 account at the same index and create payment codes and accounts as pairs.įor example, the payment code created represented by (m / 47' / 0' / 0') is part of the account represented by (m / 44' / 0' / 0'). This derivation level is equivalent to the Account level in BIP-44. When the extended public key at this level is combined with the metadata specified in the Representation section below, the resulting entity is called a "payment code." The identity derivation level produces an extended public key and its associated extended private key. Hardened derivation is used at this level. The coin type field is identical to the same field in BIP44 It indicates that the subtree of this node is used according to this specification. Purpose is a constant set to 47' (or 0x8000002F) following the BIP43 recommendation. These (hardened) keypairs are ephemeral payment codes.Īpostrophe in the path indicates that BIP32 hardened derivation is used.Įach level has a special meaning, described in the chapters below. These (non-hardened) keypairs are used for ECDH to generate deposit addresses. M / purpose' / coin_type' / identity' / 0 through 2147483647 The 0th (non-hardened) child is the notification key. M / purpose' / coin_type' / identity' / 0 The child keys derived from an identity are used in different ways: We define the following 3 levels in BIP32 path: Payment codes provide the privacy benefits of Darkwallet-style Stealth Addresses to SPV clients without requiring the assistance of a trusted full node and while greatly reducing reliance on blockchain storage. Payment codes add identity information to transactions which is useful in a merchant-customer interaction while protecting the privacy of users. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. This BIP is a particular application of BIP43 and is intended to supplement HD wallets which implement BIP44. This BIP defines a technique for creating a payment code which can be publicly advertised and associated with a real-life identity without creating the loss of security or privacy inherent to P2PKH address reuse. 5.2.2.2 Post-Notification Privacy Considerations.5.2.2.1 Standard Notification Transaction Scripts.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |