[WIP] Adding gRPC support

[stevenroose]

One of the main design differences is that the grpcServer takes (only) a server as argument, which significantly eases the implementation. The current RPC server uses indirects for all the server functionality, sometimes even just putting top level methods in one of the indirects.

Progress update:

TODOs:

• implement listening
• add GRPC dependenies (waiting for dep PR)
• correct error handling
• REST proxy? (cfr lnd)
• in case it will replace the JSON-RPC interface: find a solution for
  getblocktemplate (maybe separate small HTTP server in the mining package
  behind --getblocktemplate <interface>)
• update rpcclient: there is a WrappedBtcdClient in the btcrpc package
  that uses the respective Go structs like chainhash.Hash,
  btcutil.Tx|Block, wire.MsgTg,...
• update btcctl

Some questions:

• is using btcutil.Tx|Block.Serialize safe instead of BtcEncode?

All current methods and the new methods that cover them:

• addnode: ConnectPeer
• createrawtransaction: deprecated
• debuglevel: SetDebugLevel
• decoderawtransaction: deprecated
• decodescript: deprecated
• generate: GenerateBlocks
• getaddednodeinfo: GetPeers
• getbestblock: GetBestBlockInfo
• getbestblockhash: GetBestBlockInfo
• getblock: GetBlock
• getblockchaininfo: could add to GetNetworkInfo
• getblockcount: GetBestBlockInfo
• getblockhash: GetBlockInfo
• getblockheader: GetBlockInfo
• getblocktemplate: see below
• getconnectioncount: GetSystemInfo
• getcurrentnet: GetNetworkInfo
• getdifficulty: GetNetworkInfo or GetMiningInfo
• getgenerate: GetGenerate
• gethashespersec: GetHashRate (or GetNetworkInfo or GetMiningInfo for network HR)
• getheaders
• getinfo: GetSystemInfo and GetNetworkInfo
• getmempoolinfo: GetMempoolInfo
• getmininginfo: GetMiningInfo
• getnettotals: GetSystemInfo
• getnetworkhashps: GetNetworkInfo or GetMiningInfo
• getpeerinfo: GetPeers
• getrawmempool: GetMempool and GetRawMempool
• getrawtransaction: GetRawTransactions
• gettxout: just use GetTransaction
• help: deprecated
• node: ConnectPeer, DisconnectPeer, GetPeers
• ping: deprecated
• searchrawtransactions: how is this different than rescan?
• sendrawtransaction: SubmitTransactions
• setgenerate: SetGenerate
• stop: StopDaemon
• submitblock: SubmitBlock
• uptime: GetSystemInfoo
• validateaddress: deprecated
• verifychain: what's the use case of this?
• verifymessage: deprecated
• version: GetSystemInfo

There are WebSocket-only commands:

• loadtxfilter: deprecated
• notifyblocks: SubscsribeBlocks
• notifynewtransactions: SubscribeTransactions
• notifyreceived: potentially SubscribeTransactions
• notifyspent: potentially SubscribeTransactions
• rescan: RescanTransactions
• rescanblocks: why is this useful?
• session: deprecated
• stopnotifyblocks: SubscribeBlocks
• stopnotifynewtransactions: SubscribeTransaction
• stopnotifyspent: potentially SubscribeTransaction
• stopnotifyreceived: potentially SubscribeTransaction

Additions to the API that did not exist before:

• GetAddressTransactions
• GetAddressUnspentOutputs

These are mentioned in the code as not implemented, but desired:

• estimatefee
• estimatepriority
• getchaintips
• getmempoolentry: have GetRawMempool to get all
• getnetworkinfo: GetNetworkInfo
• getwork
• invalidateblock
• preciousblock
• reconsiderblock

[Yashiroo]

Question: Does using gRPC in this API means that someone using a language different from Go can perform calls to the RPC server?

[stevenroose]

@Yashiroo Well, that is already the case right now. But yes, with gRPC it would be very easy to use the API with any language that has gRPC support. We could either keep the old JSON RPC alive for more basic usage or do like lnd does and also have a REST version of the API in gRPC.

[stevenroose]

First iteration of implementation done. All functionality that I could think of is covered. Please review if I missed parts. Starting the server and listening etc is also implemented, but not yet replaced in server.go. I'm not sure how we should proceed with this: run both in parallel first, or provide different branch where GRPC replaces JSONRPC.

Also, if we are concerned about the HTTP1-only users, it might be worth it to provide an HTTP gateway the way lnd does it. (It's part of an extension protocol of GRPC that automatically maps a GRPC interface to REST.) The interface would be incompatible with the current JSON-RPC interface, though.

[stevenroose]

Implemented a wrapper client in btcrpc/wrapper.go. If it's preferred to have the client in a separate package, that's possible. Next up would be btcctl and a REST proxy.

Also, I have been running and testing the gRPC server on my own system successfully for some time now.

[jakesylvestre]

@jcvernaleo (as per #1530)

• Low priority
• Enhancement
• Outdated.

Wow.