mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2024-11-19 01:40:05 +01:00
Code Issues Projects Releases Wiki Activity

Correct serialization

Browse Source 
Since the length of the data encoded by base58check affects the version
byte needed to produce a desired leading character, fix the length of
the payment code at 80 bytes, and correct the version byte to 0x23
This commit is contained in:
Justus Ranvier 2015-06-22 07:19:30 -05:00
parent 1612a0016a
commit 114ed229d3
1 changed files with 5 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
bip-0047.mediawiki
View File

@ -33,9 +33,7 @@ Each level has a special meaning, described in the chapters below.
===Purpose===
Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "47" with the most signifigant bit set to indicate hardened derivation (0x8000002F). It indicates that the subtree of this node is used according to this specification.
Hardened derivation is used at this level.
Purpose is a constant set to 47' (or 0x8000002F) following the BIP43 recommendation. It indicates that the subtree of this node is used according to this specification.
===Coin type===
@ -64,13 +62,13 @@ A payment code contains the following elements:
* Byte 2: sign. required value: 0x02 or 0x03
* Bytes 3 - 34: x value
* Bytes 35 - 66: chain code
* Bytes 67 - 79: optional. reserved for future expansion
* Bytes 67 - 79: reserved for future expansion, zero-filled unless otherwise noted
====Base58 Serialization====
When a payment code is presented to the user, it SHOULD be presented encoded in Base58Check form.
* The version byte is: 0x37 (produces a "P" as the first character of the serialized form)
* The version byte is: 0x23 (produces a "P" as the first character of the serialized form)
* The payload is the binary serialization of the payment code
===Protocol===
@ -211,8 +209,8 @@ A recipient specifies their preference for alternate notification by setting the
A recipient prefers to receive notifications via Bitmessage indiates this preference by:
* Setting bit 0 of the features byte to 1
* Appending a byte containing the desired Bitmessage address version to the payment code at byte 67
* Appending a byte containing the desired Bitmessage stream number to the payment code at byte 68
* Setting byte 67 of the serialized payment code to the desired Bitmessage address version
* Setting byte 67 of the serialized payment code to the desired Bitmessage stream number
The sender uses this information to construct a valid notification Bitmessage address: