Exchange Listing API

The dev community recommends using the open source Rosetta API implementation for integrating BitClout on an exchange: https://github.com/bitclout/rosetta-bitclout. The other APIs in this doc are less supported than the Rosetta APIs.
Multiple major crypto exchanges have expressed interest in listing BitClout. The dev community is working closely with several of these, but, now that anyone in the world can run a BitClout node, we thought we'd democratize and decentralize this effort by publishing a simple public API that any crypto exchange in the world could follow to integrate BitClout.
This guide will cover all of the API endpoints that are needed in order to list BitClout, with detailed descriptions and examples. This includes:
Setting up a node.
Using the Exchange API to create unlimited public/private key pairs.
Using the Exchange API to check the balance of BitClout public keys.
Using the Exchange API to transfer BitClout between public keys.
Using the Exchange API to query for transactions by transaction ID.
Using the Exchange API to query for transactions by public key.
Using the Exchange API to query for node sync status.
Using the Exchange API to query for block information by height or block hash.
The Quick Start section provides examples of all of the above using the “curl” command. The Full API Guide section provides more detail on each API endpoint shown in the examples.
Note: This API is strictly for use by exchanges. The bitclout.com nodes use in-browser signing such that your seed phrase never leaves your browser (learn more). In contrast, exchanges are typically custodial and so some of these endpoints manipulate seeds on behalf of users.
Quick Start
Generate a Seed Mnemonic
To get started, you need to generate a standard BIP39 mnemonic seed that will be used to generate public/private key pairs. If you don't require that your keys be generated on an air-gapped computer, then you can use the bitclout.com signup flow to generate your mnemonic. Note that your seed never leaves your browser when you generate it on bitclout.com. See Privacy and Security for more details on this process.
If you need your seed to be generated in an offline fashion, then we recommend that you use this tool. Either a 12 or 24-word mnemonic should be fine, and standard Bitcoin mnemonics work as well.
What we will use in our examples:
Mnemonic: arrive mixture refuse loud people robot dolphin scissors lift curve better demand
Passphrase (also known as "ExtraText"): password
Run a Node
All of the commands and examples in this guide will assume that you have a BitClout node running on your local machine. To set one up, simply follow the instructions in the open-source /run repository. If you run into any trouble, the nodes-discussion Discord channel is always available to help you:
​https://github.com/bitclout/run​
Note that the node software is cross-platform and should run on Linux, Mac, and Windows. However, it seems as though people have had the most success with Linux and Mac machines with at least 32GB of RAM and at least 100GB of free disk space.
NOTE: You must set READ_ONLY_MODE to false in dev.env in order for some API calls to work. However, at the time of this writing, it is not yet recommended to deploy a production node with READ_ONLY_MODE set to false. This should change shortly, though. Keep an eye on the README for updates.
Check Node Sync Status
This query will return information about a node’s sync status, among other things. See the Full API Guide section for more information.
1
curl --header "Content-Type: application/json" --data-raw '{}' \
2
    http://localhost:17001/api/v1/node-info | python -m json.tool
Copied!
Notes:
We pipe the command into “python -m json.tool” so that it will “pretty print” but that you can delete this part of the command if you don’t have Python installed.
We are assuming the node is running on the same machine on which we’re doing this query. If the node is running on a different machine then the IP of that machine should be substituted for “localhost.”
Generate a Public/Private Key Pair
This will generate a public/private key-pair that corresponds to index “0” for this account. Each key-pair will map to an index for a particular seed. To generate more key-pairs, simply iterate the “Index” parameter.
1
curl --header "Content-Type: application/json" --request POST --data '{
2
    "Mnemonic":"arrive mixture refuse loud people robot dolphin scissors lift curve better demand",
3
    "ExtraText":"password",
4
    "Index": 0
5
}' http://localhost:17001/api/v1/key-pair  | python -m json.tool
Copied!
Notes:
Under the hood, every public/private key pair maps to derivation path m/44'/0'/0'/0/{index}. Thus they would be identical to what is generated by any Bitcoin wallet using the same mnemonic, passphrase, and derivation path.
The public and private keys returned by this function will be encoded using base58 check encoding described in more detail in the Full API Guide section for this endpoint. For now, all that you need to know is that you can pass the public/private key strings to other API endpoints to check balances, spend BitClout, etc…
BitClout public keys that are encoded with base58 always start with the prefix “BC”. BitClout private keys that are encoded with base58 always start with the prefix “bc” (lower-case).
Example of BitClout public/private key pair returned by this function. Note that Error being empty string means the endpoint succeeded.
1
{
2
    "Error": "",
3
    "PrivateKeyBase58Check": "bc6EmekhAbzn2V9BchgRLMRMZW1m8mo7kmvdwjZRB5nnKpgQhWSf4",
4
    "PrivateKeyHex": "423e1f1fe03469e4173f5a0056f468255358f9200fd5acfa7be8185d2fcb98b4",
5
    "PublicKeyBase58Check": "BC1YLgAJ2kZ7Q4fZp7KzK2Mzr9zyuYPaQ1evEWG4s968sChRBPKbSV1",
6
    "PublicKeyHex": "024089f4297576513ce07de8190583154c15b8279a586f7d0663ff3c5391351a1e"
7
}
Copied!
We pipe the command into “python -m json.tool” so that it will “pretty print” but that you can delete this if you don’t have Python installed.
Note: This API is strictly for use by exchanges. The bitclout.com nodes use a different API that never receives your seed phrase, and your seed phrase never leaves your browser. In contrast, exchanges are typically custodial and so some of these endpoints manipulate seeds on behalf of users.
Check Balance of BitClout Public Key
1
curl --header "Content-Type: application/json" --request POST --data '{
2
    "PublicKeyBase58Check":"BC1YLgAJ2kZ7Q4fZp7KzK2Mzr9zyuYPaQ1evEWG4s968sChRBPKbSV1"
3
}' http://localhost:17001/api/v1/balance | python -m json.tool
Copied!
Notes:
This will return the balance in “nanos,” where 1 BitClout = 1,000,000,000 “nanos.” For example, if the balance for this public key was “1 BitClout” then this endpoint will return 1,000,000,000 (or 1e9 nanos).
This endpoint also returns UTXO's, but this likely won't be useful to most node operators.
Transfer BitClout Using a Public/Private Key-Pair
1
curl --header "Content-Type: application/json" --request POST --data '{
2
    "SenderPublicKeyBase58Check":"BC1YLgAJ2kZ7Q4fZp7KzK2Mzr9zyuYPaQ1evEWG4s968sChRBPKbSV1", 
3
    "SenderPrivateKeyBase58Check":"bc6EmekhAbzn2V9BchgRLMRMZW1m8mo7kmvdwjZRB5nnKpgQhWSf4", 
4
    "RecipientPublicKeyBase58Check":"BC1YLgU67opDhT9bTPsqvue9QmyJLDHRZrSj77cF3P4yYDndmad9Wmx", 
5
    "AmountNanos": 1000000000
6
}' http://localhost:17001/api/v1/transfer-bitclout | python -m json.tool
Copied!
Notes:
This example will fail unless you send BitClout to the SenderPublicKeyBase58Check.
You can buy BitClout on bitclout.com and then use the "Send BitClout" page to get some BitClout for testing purposes.
The amount must be specified in "nanos," where 1 BitClout = 1e9 nanos. This example transfers 1 BitClout from public key BC1YLgAJ2kZ7Q4fZp7KzK2Mzr9zyuYPaQ1evEWG4s968sChRBPKbSV1 to public key BC1YLgU67opDhT9bTPsqvue9QmyJLDHRZrSj77cF3P4yYDndmad9Wmx
To do a "dry run" of the transaction without broadcasting it, simply add DryRun: true to the params.
Setting “AmountNanos” to a negative value like -1 will send the maximum amount possible.
To implement a UI with a “Max” button, we recommend hitting this endpoint with a negative AmountNanos with DryRun set to true, grabbing the resultant “spend amount,” which will be net of fees, and displaying that to the user.
This endpoint will return information for the transaction created. See the Full API Guide section on this endpoint for more information on what is returned.
A custom “fee rate” can also be set. See the Full API Guide section for this endpoint for more detail on that.
Note: This API is strictly for use by exchanges. The bitclout.com nodes use a different API that never receives your seed phrase, and your seed phrase never leaves your browser. In contrast, exchanges are typically custodial and so some of these endpoints manipulate seeds on behalf of users.
Look Up Transactions for a Public Key
1
curl --header "Content-Type: application/json" --request POST --data '{
2
    "PublicKeyBase58Check":"BC1YLgAJ2kZ7Q4fZp7KzK2Mzr9zyuYPaQ1evEWG4s968sChRBPKbSV1",
3
    "IDsOnly": true
4
}' http://localhost:17001/api/v1/transaction-info | python -m json.tool
Copied!
Notes:
A transaction ID is a sha256 hash of a transaction, encoded using base58 check encoding, that uniquely identifies a transaction.
This gets all the transaction IDs for a particular public key ordered from oldest to newest.
To fetch full transactions rather than just the IDs, simply set IDsOnly to false rather than true or leave it out of the request entirely.
This endpoint will only work if the node was started with the TXINDEX flag set to true, which is the default.
You must also wait for your TXINDEX to generate, which can take a few hours. Grep your logs for UpdateTxIndex to monitor its progress.
See the Full API Guide section for this endpoint to see what information will be returned by this endpoint.
Look Up Transaction Using Transaction ID
Get information for a specific transaction using that transaction’s transaction ID. You can get a transaction ID from other endpoints like the transfer-bitclout endpoint described previously.
1
curl --header "Content-Type: application/json" --request POST --data '{
2
    "TransactionIDBase58Check": "3JuEUE5QSkjyuLwY8WUjS3MRjMbaNEd4nE63VugpU17HMzJW7vbrJP"
3
}' http://localhost:17001/api/v1/transaction-info | python -m json.tool
Copied!
Notes:
This is the same endpoint as the one used to lookup the transactions for a public key. When a PublicKeyBase58Check param is set, the TransactionIDBase58Check param is expected to be unset and is ignored.
This endpoint will only work if the node was started with the TXINDEX flag set to true, which is the default.
See the Full API Guide section for this endpoint to see what information will be returned by this endpoint.
Get Block For Block Hash or Height
This will return all the information associated with the block at height 10715. If the chain is not synced up to this point, an error will be returned.
1
curl --header "Content-Type: application/json" --request POST --data '{
2
    "Height":10715
3
}' http://localhost:17001/api/v1/block | python -m json.tool
Copied!
Same as the previous example, only queries the block by its hash rather than its height.
1
curl --header "Content-Type: application/json" --request POST --data '{
2
    "HashHex":"0000000000306a10b85a0bfd801479f1f2227ebaa8bdd5c61da4736dff319362"
3
}' http://localhost:17001/api/v1/block | python -m json.tool
Copied!
For more information, see the Full API Guide section for these endpoints.
Full API Guide
Note: This API is strictly for use by exchanges. The bitclout.com nodes use a different API that never receives your seed phrase, and your seed phrase never leaves your browser. In contrast, exchanges are typically custodial and so some of these endpoints manipulate seeds on behalf of users.
Note: The dev community is also working to complete an integration with Rosetta that will further build on this API.
/api/v1/key-pair
You can generate public/private keypairs with a standard BIP39 mnemonic. Each public/private key pair corresponds to a particular index associated with the mnemonic. This means that index “5” for a particular mnemonic, for example, will always generate the same public/private key pair. An infinite number of public/private key pairs can thus be generated by iterating an index over a particular mnemonic.
All public/private keys are inter-operable as Bitcoin public/private keys. Meaning they represent a point on the secp256k1 curve (same as what is used by Bitcoin).
Under the hood, BitClout takes the BIP39 mnemonic and generates the public/private key pairs using the BIP32 derivation path m/44'/0'/0'/0/{index}, where "index" is the index of the public/private key being generated. This means that BitClout public/private key pair generated by the node will always line up with the public/private key pairs generated by this Ian Coleman tool. An engineer can therefore “sanity check” that things are working by generating a mnemonic using bitclout.com or Ian Coleman, creating a key pair with that mnemonic, and then verifying that the public/private key pairs generated line up with what is shown on bitclout.com or Ian Coleman.
1
PATH: /api/v1/key-pair
2
METHOD: POST
3
POST PARAMS:
4
	// A BIP39 mnemonic and extra text. Mnemonic can be 12 words or
5
	// 24 words. ExtraText is optional.
6
	Mnemonic  string
7
	ExtraText string
8
	// The index of the public/private key pair to generate
9
	Index uint32
10
RETURNS:
11
  // Blank if successful. Otherwise, contains a description of the
12
  // error that occurred.
13
  Error string
14
  // The BitClout public key encoded using base58 check encoding with
15
  // prefix = [3]byte{0x11, 0xc2, 0x0}
16
  // This public key can be passed in subsequent API calls to check
17
  // balance, among other things. All encoded BitClout public keys start
18
  // with the characters “BC”
19
  PublicKeyBase58Check string
20
  // The BitClout public key encoded as a plain hex string. This should
21
  // match the public key with the corresponding index generated by the
22
  // Ian Coleman tool.
23
  // This should not be passed to subsequent API calls, it is only provided
24
  // as a reference, mainly as a sanity-check.
25
  PublicKeyHex string
26
  // The BitClout private key encoded using base58 check encoding with
27
  // prefix = [3]byte{0x4f, 0x6, 0x1b}
28
  // This private key can be passed in subsequent API calls to spend BitClout,
29
  // among other things. All BitClout private keys start with
30
  // the characters “bc”
31
  PrivateKeyBase58Check string
32
  // The BitClout private key encoded as a plain hex string. Note that
33
  // this will not directly match what is produced by the Ian Coleman
34
  // tool because the tool shows the private key encoded using
35
  // Bitcoin’s WIF format rather than as raw hex. To convert this raw hex
36
  // into Bitcoin’s WIF format you can use this simple Python script:
37
  // https://github.com/geniusprodigy/bitcoin-convertpvk
38
  // This should not be passed to subsequent API calls. It is provided as
39
  // a reference, mainly as a sanity-check.
40
  PrivateKeyHex string
Copied!
/api/v1/balance
One can check the balance of a particular public key by passing the public key to the following endpoint.
Spent transaction outputs are not returned by this endpoint. To perform operations on spent transaction outputs, one must use the “transaction-info” endpoint instead.
1
PATH: /api/v1/balance
2
METHOD: POST
3
POST PARAMS:
4
  // A BitClout public key encoded using base58 check encoding (starts
5
  // with “BC”). When this field is provided, the other params are
6
  // ignored.
7
  PublicKeyBase58Check string
8
  // Only consider UTXOs with greater than or equal to the specified number
9
  // of confirmations. This defaults to zero, which considers all UTXOs,
10
  // including those in the mempool.
11
  Confirmations uint32
12
RETURNS:
13
  // Blank if successful. Otherwise, contains a description of the
14
  // error that occurred.
15
  Error string
16
  // The balance of the public key queried in “nanos.” Note 
17
  // there are 1e9 “nanos” per BitClout, so if the balance were “1 BitClout” then
18
  // this value would be set to 1e9.
19
  ConfirmedBalanceNanos int64
20
  // The unconfirmed balance of the public key queried in “nanos.” This field
21
  // is set to zero if Confirmations is set to a value greater than zero.
22
  UnconfirmedBalanceNanos int64
23
  // BitClout uses a UTXO model similar to Bitcoin. As such, querying
24
  // the balance returns all of the UTXOs for a particular public key for
25
  // convenience. Note that a UTXO is simply a reference to a particular
26
  // output index in a previous transaction
27
  UTXOs [{
28
    // A string that uniquely identifies a previous transaction. This is
29
    // a sha256 hash of the transaction’s information encoded using
30
    // base58 check encoding. Will be empty string if this UTXO is
31
    // a block reward.
32
    TransactionIDBase58Check string
33
    // The index within this transaction that corresponds to an output
34
    // spendable by the passed-in public key.
35
    Index int64
36
    // The amount that is spendable by this UTXO in “nanos” = 1e9 BitClout.
37
    AmountNanos uint64
38
    // The pulic key entitled to spend the amount stored in this UTXO.
39
    PublicKeyBase58Check string
40
    // The number of confirmations this UTXO has. Set to zero if the
41
    // UTXO is unconfirmed.
42
    Confirmations int64
43
    // Whether or not this UTXO was a block reward.
44
    IsBlockReward bool
45
  }, ... ]
Copied!
/api/v1/transfer-bitclout
BitClout can be transferred from one public key to another using this simple API call. To transfer BitClout, one must either provide a public/private key pair.
BitClout uses a UTXO model like Bitcoin but BitClout transactions are generally simpler than Bitcoin transactions because BitClout always uses the “from public key” as the “change” public key (meaning that it does not “rotate” keys by default). For example, if a transaction sends 10 BitClout from PubA to PubB with 5 BitClout in “change” and 1 BitClout as a “miner fee,” then the transaction would look as follows:
1
Input: 16 BitClout (10 BitClout to send, 5 BitClout in change, and 1 BitClout as a fee)
2
PubB: 10 BitClout (the amount being sent from A to B)
3
PubA: 5 BitClout (change returned to A)
4
​
5
Implicit 1 BitClout is paid as a fee to the miner. The miner fee is implicitly
6
computed as (total input – total output) just like in Bitcoin.
Copied!
The maximum amount of BitClout can be sent by specifying a negative amount when calling the endpoint. We recommend running the endpoint once with DryRun set to true, inspecting the output, and then running it with DryRun set to false, which will actually broadcast the transaction.
1
PATH: /api/v1/transfer-bitclout
2
METHOD: POST
3
POST PARAMS:
4
	// A BitClout private key encoded using base58 check encoding (starts
5
	// with "bc").
6
	SenderPrivateKeyBase58Check string
7
	// A BitClout public key encoded using base58 check encoding (starts
8
	// with “BC”) that will receive the BitClout being sent.
9
	RecipientPublicKeyBase58Check string
10
	// The amount of BitClout to send in “nanos.” Note that “1 BitClout” is equal to
11
	// 1e9 nanos, so to send 1 BitClout, this value would need to be set to 1e9.
12
	AmountNanos int64
13
	// The fee rate to use for this transaction. If left unset, a default fee rate
14
	// will be used. This can be checked using the “DryRun” parameter below.
15
	MinFeeRateNanosPerKB int64
16
	// When set to true, the transaction is returned in the response but not
17
	// actually broadcast to the network. Useful for testing.
18
	DryRun bool
19
RETURNS:
20
  // Blank if successful. Otherwise, contains a description of the
21
  // error that occurred.
22
  Error string
23
  // The transaction that executes the transfer. Will not be broadcast
24
  // if DryRun is set to true.
25
  Transaction {
26
    // A string that uniquely identifies this transaction. This is a sha256 hash
27
    // of the transaction’s data encoded using base58 check encoding.
28
    TransactionIDBase58Check string
29
    // The raw hex of the transaction data. This can be fully-constructed from
30
    // the human-readable portions of this object.
31
    RawTransactionHex string
32
    // The inputs of this transaction.
33
    Inputs [{
34
        // An input in a transaction consists of the transaction ID and
35
        // the index of the output from that transaction.
36
        TransactionIDBase58Check string
37
        Index int64
38
      }, ... ]
39
    Outputs [
40
      // A transaction output is simply a public key and the
41
      // amount that is being allocated to that public key in
42
      // “nanos” where 1 BitClout = 1e9 nanos.
43
      {
44
        PublicKeyBase58Check string
45
        AmountNanos int64
46
      }, ... ]
47
    // The signature of the transaction in hex format.
48
    SignatureHex string
49
    // Will always be “0” for basic transfers
50
    TransactionType int64
51
    // Will always be empty for basic transfers
52
    TransactionMeta {}
53
    // The hash of the block in which this transaction was mined. If the
54
    // transaction is unconfirmed, this field will be empty. To look up
55
    // how many confirmations a transaction has, simply plug this value
56
    // into the "block" endpoint.
57
    BlockHashHex string
58
  }
59
  TransactionInfo {
60
    // The sum of the inputs
61
    TotalInputNanos uint64
62
    // The amount being sent to the “RecipientPublicKeyBase58Check”
63
    SpendAmountNanos uint64
64
    // The amount being returned to the “SenderPublicKeyBase58Check”
65
    ChangeAmountNanos uint64
66
    // The total fee and the fee rate (in nanos per KB) that was used for this
67
    // transaction.
68
    FeeNanos uint64
69
    FeeRateNanosPerKB uint64
70
    // Will match the public keys passed as params. Note that
71
    // SenderPublicKeyBase58Check receives the change from this transaction.
72
    SenderPublicKeyBase58Check string
73
    RecipientPublicKeyBase58Check string
74
  }
Copied!
/api/v1/transaction-info
If one has a TransactionIDBase58Check, e.g. from calling the “transfer-bitclout” endpoint, one can get the corresponding human-readable “Transaction object” by passing this transaction id to a node. Note that this endpoint will error if TXINDEX is set to false. If TXINDEX was passed to the node but it has not finished syncing the blockchain yet, this endpoint may return incomplete results. The /node-info endpoint can be used to check where a node is in its sync process (generally, syncing takes only a minute or two).
If one has a PublicKeyBase58Check (starts with “BC”), one can get all of the TransactionIDs associated with that public key sorted by oldest to newest (this will include transactions where the address is a sender and a receiver). One can also optionally get the full Transaction objects for all of the transactions in the same call.
1
PATH: /api/v1/transaction-info
2
METHOD: POST
3
POST PARAMS:
4
  // A string that uniquely identifies this transaction. E.g. from a previous
5
  // call to “transfer-bitclout”. Ignored when PublicKeyBase58Check is set.
6
  // When a transaction is looked up using its ID directly, we also scan the
7
  // mempool for it. This makes it so that a “block explorer” can easily
8
  // surface transactions associated with a particular ID.
9
  TransactionIDBase58Check string
10
  // A BitClout public key encoded using base58 check encoding (starts
11
  // with “BC”) to get transaction IDs for. When set,
12
  // TransactionIDBase58Check is ignored.
13
  PublicKeyBase58Check string
14
  // Whether or not to return full transaction info or just the TransactionIDHex
15
  // for each transaction. Full transactions are returned when this is unset.
16
  IDsOnly bool
17
RETURNS
18
  // Blank if successful. Otherwise, contains a description of the
19
  // error that occurred.
20
  Error string
21
  // The info for all transactions this public key is associated with from oldest
22
  // to newest. If “IDsOnly” is set to true, each Transaction object will contain
23
  // only TransactionIDBase58Check. Otherwise, all other fields will be set as well.
24
  Transactions [
25
    Transaction {
26
      // Always set.
27
      TransactionIDBase58Check string
28
      // Rest of fields are as defined previously, but only set if
29
      // IDsOnly is unset or false.
30
      ...
31
  }, ... ]
32
​
Copied!
/api/v1/node-info
General information about the node’s blockchain and sync state can be queried using this endpoint. The blockchain does a “headers-first” sync, meaning it first downloads all BitClout headers and then downloads all blocks. This means that, when the node is first syncing, the tip of the best “header chain” may be ahead of of its most recently downloaded block. In addition to syncing BitClout headers and BitClout blocks, a BitClout node will also sync all of the latest Bitcoin headers to power its built-in decentralized Bitcoin <> BitClout swap mechanism. For this reason, the endpoint also returns information on the node’s best Bitcoin header chain, which is distinct from its BitClout chain.
1
PATH: /api/v1/node-info
2
METHOD: POST
3
RETURNS
4
  BitCloutStatus {
5
    // A summary of what the node is currently doing.
6
    State string
7
    
8
    // We generally track the latest header we have and the latest block we have
9
    // separately since headers-first synchronization can cause the latest header
10
    // to diverge slightly from the latest block.
11
    LatestHeaderHeight     uint32
12
    LatestHeaderHash       string
13
    LatestHeaderTstampSecs uint32
14
    
15
    LatestBlockHeight     uint32
16
    LatestBlockHash       string
17
    LatestBlockTstampSecs uint32
18
    
19
    // This is non-zero unless the main header chain is fully current. It can be
20
    // an estimate in cases where we don't know exactly what the tstamp of the
21
    // current main chain is.
22
    HeadersRemaining uint32
23
    // This is non-zero unless the main header chain is fully current and all
24
    // the corresponding blocks have been downloaded.
25
    BlocksRemaining uint32
26
  }
27
  BitcoinStatus {
28
    // We download Bitcoin headers in order to power the decentralized
29
    // Bitcoin <> BitClout swap built-in to the app,
30
    // which allows users to convert Bitcoin into BitClout without needing
31
    // to trust third-parties.
32
    //
33
    // This part of the response has the same schema as BitCloutStatus, only 
34
    // the block information won’t be populated since we only download
35
    // Bitcoin headers not full Bitcoin blocks.
36
  }
37
  BitCloutOutboundPeers []PeerResponse {
38
    IP           string
39
    ProtocolPort uint16
40
    JSONPort     uint16
41
    IsSyncPeer   bool
42
  }
43
  BitCloutInboundPeers []PeerResponse{
44
    // Same schema as above
45
  }
46
  BitCloutUnconnectedPeers []PeerResponse{
47
    // Same schema as above
48
  }
49
  BitcoinSyncPeer []PeerResponse{
50
    // Same schema as above
51
  }
52
  BitcoinUnconnectedPeers []PeerResponse{
53
    // Same schema as above
54
  }
55
  // The public keys the node is currently sending block rewards to.
56
  // If no public keys have been specified then the node will not be mining.
57
  MinerPublicKeys []string
Copied!
/api/v1/block
A block’s information can be queried using either the block hash or height. To get all blocks in the chain, simply query this endpoint by enumerating the heights starting from zero and iterating up to the tip. The tip height and hash can be obtained using the /node-info endpoint.
1
PATH: /api/v1/block
2
METHOD: POST
3
POST PARAMS:
4
  // Block height. 0 corresponds to the genesis block. An error will be
5
  // returned if the height exceeds the tip. This field is ignored if HashHex is
6
  // set.
7
  Height int64
8
  // Hash of the block to return. Height is ignored if this is set.
9
  HashHex string
10
  // When set to false, only returns the header of the block requested
11
  // not the full block. Otherwise, returns the full block.
12
  FullBlock bool
13
RETURNS
14
  // Blank if successful. Otherwise, contains a description of the
15
  // error that occurred.
16
  Error string
17
  // The information contained in the block’s header.
18
  Header {
19
    // The hash of the block that was queried.
20
    BlockHashHex string
21
    // Generally set to zero
22
    Version uint32
23
    // Hash of the previous block in the chain.
24
    PrevBlockHashHex string
25
    // The merkle root of all the transactions contained within the block.
26
    TransactionMerkleRootHex string
27
    // The unix timestamp (in seconds) specifying when this block was
28
    // mined.
29
    TstampSecs uint32
30
    // The height of the block this header corresponds to.
31
    Height uint32
32
    // The nonce is encoded as a little-endian 32-bit integer. If more than 2^32
33
    // hashes are required in order to mine a block, the block reward's ExtraData
34
    // field can be twiddled to change the merkle root to give a miner a fresh set
35
    // of 2^32 header nonces to try. Note that we don't use 64 bits (or more) because
36
    // keeping the header small is important for the efficiency of light clients and
37
    // because it doesn't add much value over over just twiddling the ExtraData
38
    // every 2^32 values.
39
    Nonce uint32
40
  }
41
  // A list of Transactions, where the Transaction object is as defined previously.
42
  Transactions [
43
    Transaction {
44
    }, ... 
45
  ]
Copied!