* SHA256 produces 256 bits pseudo-randomly uniformly, so you may
compare to a 256 bit target to get a proof of work
* If you pretend that the hash and targets are both integers between 0
and 2^256 - 1, then the target partitions the range into passing and
failing segments.
* In order to match the use of the `get_uint16` function from
`ocplib-endian`, the easiest way to encode `target` is as a `int list`
which works if not ideal
* This seems like the same thing bitcoin does; difficulty there is
actually not a primary notion but is calculated from a 256 bit target,
which is what gets adjusted over time
Implement a minimal "completion" service.
The use of Base48 encoding allows to efficiently implement a "completion" mechanism for blocks, operations, public key and contract identifiers. For instance:
```
> ./tezos-client complete eeHfgnr9QeDN
eeHfgnr9QeDNvcMgSfATNeDeec4KG4CkHHkNNJt5B9xdVmsxhsHNR
```
This command returns all the identifiers matching the given prefix. Adding the option `-unique` let the command fails when there more than one possible completion.
This completion mechanism should probably never be used implicitly, but it might still be useful to display a small completion popup in a GUI, or during manual testing on the CLI.
See merge request !101
* include a public key in peer record type
* include public key in `Connect` packet
* receive/send public keys in `Connect` packet
* include public key in `connect_to_peer`
* json encode/decode public key
* include public key in peer file encode/decode
* include public key in bootstrapping
