Bitcoin
هل أنت مستعد لاستدعاء هذا في الإنتاج؟
الخطة المجانية تغطي المشاريع الشخصية. الدفع حسب الاستخدام يتوسع دون بطاقة.
Bitcoin
الخطة المجانية تغطي المشاريع الشخصية. الدفع حسب الاستخدام يتوسع دون بطاقة.
For talking to the Bitcoin Core JSON-RPC API from Go, the simplest path is also the most portable: raw JSON-RPC over the standard library's net/http and encoding/json, with zero third-party dependencies. The btcsuite/btcd project ships an rpcclient package that gives you a typed Bitcoin client if you want method signatures and structs out of the box, but it's tuned for a local bitcoind and a plain HTTP client works just as well against a hosted provider like TheRPC. The recommendation here is a small reusable client with one Call method that you point at https://bitcoin.therpc.io/YOUR_API_KEY (the key comes from your TheRPC dashboard) and reuse across every RPC.
Bitcoin Core uses the legacy JSON-RPC 1.0 envelope: each request is {"jsonrpc":"1.0","id":"therpc","method":...,"params":[...]} where params is an ordered, positional array — argument order is significant on every method. Your TheRPC key lives in the URL path (https://bitcoin.therpc.io/YOUR_API_KEY), so the HTTP request itself stays plain. A failed RPC does not come back as an HTTP error — the call returns 200 and surfaces the failure in the response body's error field, so always check that field rather than relying on the status code.
Model the 1.0 envelope with two small structs: an rpcRequest carrying the jsonrpc, id, method, and []interface{} positional params, and an rpcResponse whose Result is a json.RawMessage (so you can defer decoding into the concrete shape each method returns) plus an optional Error with the node's numeric code and message. A single Call method marshals the request, posts it to the BTC endpoint, decodes the envelope, returns a Go error when the error field is set, and otherwise unmarshals Result into whatever out value the caller passed.
Reading chain state is a matter of choosing the right out type per method. getblockcount returns a bare integer, so decode it straight into an int64 to get the current tip height. getblockchaininfo returns an object, so decode the fields you care about — here chain, blocks, and difficulty — into a small anonymous struct. Broadcasting works the same way: pass a fully signed, hex-encoded raw transaction as the single positional param to sendrawtransaction and decode the result into a string, which is the txid the network accepted. Since Bitcoin mines a block roughly every ten minutes under proof of work, that txid sits in the mempool until a miner includes it — you confirm later by polling, not by waiting on the broadcast call.
Because Bitcoin tracks money as unspent transaction outputs (UTXOs) rather than account balances, you inspect a single output by its txid and output index with gettxout. The trick is the spent case: when the referenced output has already been spent — or never existed in the UTXO set — the node returns JSON null, which encoding/json decodes into a nil pointer. Decode the result into a *TxOut and check for nil before reading any field; treating a nil pointer as a present output is the most common bug here. A non-nil result carries the output's value (in BTC), confirmation count, and scriptPubKey details such as the address and script type.
Call.