Add Address doc. Closes: #1727.
This commit is contained in:
parent
03d9663caa
commit
f58fb505ea
106
docs/address.rst
Normal file
106
docs/address.rst
Normal file
|
@ -0,0 +1,106 @@
|
||||||
|
Address
|
||||||
|
=======
|
||||||
|
|
||||||
|
Bitmessage adresses are Base58 encoded public key hashes. An address looks like
|
||||||
|
``BM-BcbRqcFFSQUUmXFKsPJgVQPSiFA3Xash``. All Addresses start with ``BM-``,
|
||||||
|
however clients should accept addresses without the prefix. PyBitmessage does
|
||||||
|
this. The reason behind this idea is the fact, that when double clicking on an
|
||||||
|
address for copy and paste, the prefix is usually not selected due to the dash
|
||||||
|
being a common separator.
|
||||||
|
|
||||||
|
Public Key usage
|
||||||
|
----------------
|
||||||
|
|
||||||
|
Addresses may look complicated but they fulfill the purpose of verifying the
|
||||||
|
sender. A Message claiming to be from a specific address can simply be checked by
|
||||||
|
decoding a special field in the data packet with the public key, that represents
|
||||||
|
the address. If the decryption succeeds, the message is from the address it
|
||||||
|
claims to be.
|
||||||
|
|
||||||
|
Length
|
||||||
|
------
|
||||||
|
|
||||||
|
Without the ``BM-`` prefix, an address is usually 32-34 chars long. Since an
|
||||||
|
address is a hash it can be calculated by the client in a way, that the first
|
||||||
|
bytes are zero (``\0``) and bitmessage strips these. This causes the client to do
|
||||||
|
much more work to be lucky and find such an address. This is an optional checkbox
|
||||||
|
in address generation dialog.
|
||||||
|
|
||||||
|
Versions
|
||||||
|
--------
|
||||||
|
|
||||||
|
* v1 addresses used a single RSA key pair
|
||||||
|
* v2 addresses use 2 ECC key pairs
|
||||||
|
* v3 addresses extends v2 addresses to allow specifying the proof of work
|
||||||
|
requirements. The pubkey object is signed to mitigate against
|
||||||
|
forgery/tampering.
|
||||||
|
* v4 addresses protect against harvesting addresses from getpubkey and pubkey
|
||||||
|
objects
|
||||||
|
|
||||||
|
Address Types
|
||||||
|
-------------
|
||||||
|
|
||||||
|
There are two address types the user can generate in PyBitmessage. The resulting
|
||||||
|
addresses have no difference, but the method how they are created differs.
|
||||||
|
|
||||||
|
Random Address
|
||||||
|
^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
Random addresses are generated from a randomly chosen number. The resulting
|
||||||
|
address cannot be regenerated without knowledge of the number and therefore the
|
||||||
|
keys.dat should be backed up. Generating random addresses takes slightly longer
|
||||||
|
due to the POW required for the public key broadcast.
|
||||||
|
|
||||||
|
Usage
|
||||||
|
"""""
|
||||||
|
|
||||||
|
* Generate unique addresses
|
||||||
|
* Generate one time addresses.
|
||||||
|
|
||||||
|
|
||||||
|
Deterministic Address
|
||||||
|
^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
For this type of Address a passphrase is required, that is used to seed the
|
||||||
|
random generator. Using the same passphrase creates the same addresses.
|
||||||
|
Using deterministic addresses should be done with caution, using a word from a
|
||||||
|
dictionary or a common number can lead to others generating the same address and
|
||||||
|
thus being able to receive messages not intended for them. Generating a
|
||||||
|
deterministic address will not publish the public key. The key is sent in case
|
||||||
|
somebody requests it. This saves :doc:`pow` time, when generating a bunch of
|
||||||
|
addresses.
|
||||||
|
|
||||||
|
Usage
|
||||||
|
"""""
|
||||||
|
|
||||||
|
* Create the same address on multiple systems without the need of copying
|
||||||
|
keys.dat or an Address Block.
|
||||||
|
* create a Channel. (Use the *Join/create chan* option in the file menu instead)
|
||||||
|
* Being able to restore the address in case of address database corruption or
|
||||||
|
deletation.
|
||||||
|
|
||||||
|
Address generation
|
||||||
|
------------------
|
||||||
|
|
||||||
|
1. Create a private and a public key for encryption and signing (resulting in
|
||||||
|
4 keys)
|
||||||
|
2. Merge the public part of the signing key and the encryption key together.
|
||||||
|
(encoded in uncompressed X9.62 format) (A)
|
||||||
|
3. Take the SHA512 hash of A. (B)
|
||||||
|
4. Take the RIPEMD160 of B. (C)
|
||||||
|
5. Repeat step 1-4 until you have a result that starts with a zero
|
||||||
|
(Or two zeros, if you want a short address). (D)
|
||||||
|
6. Remove the zeros at the beginning of D. (E)
|
||||||
|
7. Put the stream number (as a var_int) in front of E. (F)
|
||||||
|
8. Put the address version (as a var_int) in front of F. (G)
|
||||||
|
9. Take a double SHA512 (hash of a hash) of G and use the first four bytes as a
|
||||||
|
checksum, that you append to the end. (H)
|
||||||
|
10. base58 encode H. (J)
|
||||||
|
11. Put "BM-" in front J. (K)
|
||||||
|
|
||||||
|
K is your full address
|
||||||
|
|
||||||
|
.. note:: Bitmessage's base58 encoding uses the following sequence
|
||||||
|
(the same as Bitcoin's):
|
||||||
|
"123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz".
|
||||||
|
Many existing libraries for base58 do not use this ordering.
|
|
@ -7,6 +7,7 @@ Protocol documentation
|
||||||
:maxdepth: 2
|
:maxdepth: 2
|
||||||
|
|
||||||
protocol
|
protocol
|
||||||
|
address
|
||||||
encryption
|
encryption
|
||||||
pow
|
pow
|
||||||
|
|
||||||
|
|
Reference in New Issue
Block a user