read.cash is a platform where you could earn money (total earned by users so far: $ 641,304.76).
You could get tips for writing articles and comments, which are paid in Bitcoin Cash (BCH) cryptocurrency,
which can be spent on the Internet or converted to your local money.
The recently announced protobuf gRPC API on BCHD provides developers with easy access to an indexing blockchain server. Simplifying the infrastructure back-end by integrating the indexing server into the BCHD bitcoin node. Read the announcement for more details on all the advantages of using gRPC over a JSON REST API.
Read the client usage example for detailed information on how to set up a connection.
All you need is a URI (and the corresponding certificate if self-signed). In this example we'll be using a public node provided by @zquestz.
If you are using a self-signed certificate on a locally hosted BCHD node, you need to copy the cert to your local .bchd folder or get the certificate by using a browser and surf to https://your.bchd.node:8335. Click the lock, view certificate and export it.
As you can see here, the block hash looks a bit different from what we are expecting, it ends in zeroes instead of starting with zeroes. There is a pretty good reason for this according to Chris Pacia and Mark B. Lundeberg:
The entire (BCHD) codebase treats all byte arrays as little endian (I believe the c++ code does as well?). Only when you go to string does it convert to big endian for display purposes. So given that, this is just continuing the rule that if it's a byte array it should be little endian.
In our Go libraries there's an object called chainhash that holds the hash representation. The constructors look like this:
NewHash(newHash byte) (*Hash, error) // expects little endian byte array.
NewHashFromStr(hash string) (*Hash, error) // expects big endian hex string.
So at least in Go we use the bytes directly from the protobuf object into a chainhash without doing any reversal.
I realize that might not be the case in other languages. I'm open to hearing other opinions. But if we changed it, it would be the only place in the codebase were we have to reverse the bytes before using them… both when writing to the wire and also when reading from the wire.
Mark B. Lundeberg:
Another way to say it: if you take double-sha256 of a block header it ends in a bunch of zero bytes, not starts. The bytestrings usually just get reversed when converting to hex.
We have to take this into account when we want to print the string encoded representation of the hash. First reverse the byteslice.