Bitcoin Core RPCs accept and return the byte-wise reverse of computed
SHA-256 hash values. For example, the Unix sha256sum
command displays the
SHA256(SHA256()) hash of mainnet block 300,000’s header as:
> /bin/echo -n '020000007ef055e1674d2e6551dba41cd214debbee34aeb544c7ec670000000000000000d3998963f80c5bab43fe8c26228e98d030edf4dcbe48a666f5c39e2d7a885c9102c86d536c890019593a470d' | xxd -r -p | sha256sum -b | xxd -r -p | sha256sum -b
5472ac8b1187bfcf91d6d218bbda1eb2405d7c55f1f8cc820000000000000000
The result above is also how the hash appears in the previous-header-hash part of block 300,001’s header:
020000005472ac8b1187bfcf91d6d218bbda1eb2405d7c55f1f8cc82000\ 0000000000000ab0aaa377ca3f49b1545e2ae6b0667a08f42e72d8c24ae\ 237140e28f14f3bb7c6bcc6d536c890019edd83ccf
However, Bitcoin Core’s RPCs use the byte-wise reverse for hashes, so if you
want to get information about block 300,000 using the getblock
RPC,
you need to reverse the requested hash:
> bitcoin-cli getblock \
000000000000000082ccf8f1557c5d40b21edabb18d2d691cfbf87118bac7254
(Note: hex representation uses two characters to display each byte of data, which is why the reversed string looks somewhat mangled.)
The rationale for the reversal is unknown, but it likely stems from Bitcoin Core’s use of hashes (which are byte arrays in C++) as integers for the purpose of determining whether the hash is below the network target. Whatever the reason for reversing header hashes, the reversal also extends to other hashes used in RPCs, such as TXIDs and merkle roots.
As header hashes and TXIDs are widely used as global identifiers in other Bitcoin software, this reversal of hashes has become the standard way to refer to certain objects. The table below should make clear where each byte order is used.
Data | Internal Byte Order | RPC Byte Order |
---|---|---|
Example: SHA256(SHA256(0x00)) | Hash: 1406…539a | Hash: 9a53…0614 |
Header Hashes: SHA256(SHA256(block header)) | Used when constructing block headers | Used by RPCs such as getblock ; widely used in block explorers |
Merkle Roots: SHA256(SHA256(TXIDs and merkle rows)) | Used when constructing block headers | Returned by RPCs such as getblock |
TXIDs: SHA256(SHA256(transaction)) | Used in transaction inputs | Used by RPCs such as gettransaction and transaction data parts of getblock ; widely used in wallet programs |
P2PKH Hashes: RIPEMD160(SHA256(pubkey)) | Used in both addresses and pubkey scripts | N/A: RPCs use addresses which use internal byte order |
P2SH Hashes: RIPEMD160(SHA256(redeem script)) | Used in both addresses and pubkey scripts | N/A: RPCs use addresses which use internal byte order |
Note: RPCs which return raw results, such as getrawtransaction
or the
raw mode of getblock
, always display hashes as they appear in blocks
(internal byte order).
The code below may help you check byte order by generating hashes from raw hex.
Bitcoin Core provides a remote procedure call (RPC) interface for various administrative tasks, wallet operations, and queries about network and block chain data.
If you start Bitcoin Core using bitcoin-qt
, the RPC interface is disabled by
default. To enable it, set server=1
in bitcoin.conf
or supply the -server
argument when invoking the program. If you start Bitcoin Core using bitcoind
,
the RPC interface is enabled by default.
The interface requires the user to provide a password for authenticating RPC
requests. This password can be set either using the rpcpassword
property in
bitcoin.conf
or by supplying the -rpcpassword
program argument. Optionally a
username can be set using the rpcuser
configuration value. See the Examples
Page for more information about setting Bitcoin Core configuration
values.
Open-source client libraries for the RPC interface are readily available in most
modern programming languages, so you probably don’t need to write your own from
scratch. Bitcoin Core also ships with its own compiled C++ RPC client,
bitcoin-cli
, located in the bin
directory alongside bitcoind
and
bitcoin-qt
. The bitcoin-cli
program can be used as a command-line interface
(CLI) to Bitcoin Core or for making RPC calls from applications written in
languages lacking a suitable native client. The remainder of this section
describes the Bitcoin Core RPC protocol in detail.
The Bitcoin Core RPC service listens for HTTP POST
requests on port 8332 in
mainnet mode or 18332 in testnet or regtest mode. The port number can be changed
by setting rpcport
in bitcoin.conf
. By default the RPC service binds to your
server’s localhost loopback
network interface so it’s not accessible from other servers.
Authentication is implemented using HTTP basic
authentication. RPC
HTTP requests must include a Content-Type
header set to text/plain
and a
Content-Length
header set to the size of the request body.
The format of the request body and response data is based on version 1.0 of the
JSON-RPC specification. Specifically,
the HTTP POST
data of a request must be a JSON object with the following
format:
Name | Type | Presence | Description |
---|---|---|---|
Request | object | Required (exactly 1) |
The JSON-RPC request object |
→ jsonrpc |
number (real) | Optional (0 or 1) |
Version indicator for the JSON-RPC request. Currently ignored by Bitcoin Core. |
→ id |
string | Optional (0 or 1) |
An arbitrary string that will be returned with the response. May be omitted or set to an empty string (“”) |
→ method |
string | Required (exactly 1) |
The RPC method name (e.g. getblock ). See the RPC section for a list of available methods. |
→ params |
array | Optional (0 or 1) |
An array containing positional parameter values for the RPC. May be an empty array or omitted for RPC calls that don’t have any required parameters. |
→ → Parameter |
any | Optional (0 or more) |
A parameter. May be any JSON type allowed by the particular RPC method |
In the table above and in other tables describing RPC input and output, we use the following conventions
“→” indicates an argument that is the child of a JSON array or JSON object.
For example, “→ → Parameter” above means Parameter is the child of the
params
array which itself is a child of the Request object.
Plain-text names like “Request” are unnamed in the actual JSON object
Code-style names like params
are literal strings that appear in the JSON
object.
“Type” is the JSON data type and the specific Bitcoin Core type.
“Presence” indicates whether or not a field must be present within its containing array or object. Note that an optional object may still have required children.
The HTTP response data for a RPC request is a JSON object with the following format:
Name | Type | Presence | Description |
---|---|---|---|
Response | object | Required (exactly 1) |
The JSON-RPC response object. |
→ result |
any | Required (exactly 1) |
The RPC output whose type varies by call. Has value null if an error occurred. |
→ error |
null/object | Required (exactly 1) |
An object describing the error if one occurred, otherwise null . |
→ → code |
number (int) | Required (exactly 1) |
The error code returned by the RPC function call. See rpcprotocol.h for a full list of error codes and their meanings. |
→ → message |
string | Required (exactly 1) |
A text description of the error. May be an empty string (“”). |
→ id |
string | Required (exactly 1) |
The value of id provided with the request. Has value null if the id field was omitted in the request. |
As an example, here is the JSON-RPC request object for the hash of the genesis block:
The command to send this request using bitcoin-cli
is:
Alternatively, we could POST
this request using the cURL command-line program
as follows:
The HTTP response data for this request would be:
Note: In order to minimize its size, the raw JSON response from Bitcoin Core
doesn’t include any extraneous whitespace characters. Here we’ve added
whitespace to make the object more readable. Speaking of which, bitcoin-cli
also transforms the raw response to make it more human-readable. It:
result
field if there’s no errorresult
s of type stringerror
field if there’s an errorContinuing with the example above, the output from the bitcoin-cli
command would be simply:
If there’s an error processing a request, Bitcoin Core sets the result
field
to null
and provides information about the error in the error
field. For
example, a request for the block hash at block height -1 would be met with the
following response (again, whitespace added for clarity):
If bitcoin-cli
encounters an error, it exits with a non-zero status code and
outputs the error
field as text to the process’s standard error
stream:
Starting in Bitcoin Core version 0.7.0, the RPC interface supports request
batching as described in version 2.0 of the JSON-RPC
specification. To initiate multiple
RPC requests within a single HTTP request, a client can POST
a JSON array
filled with Request objects. The HTTP response data is then a JSON array filled
with the corresponding Response objects. Depending on your usage pattern,
request batching may provide significant performance gains. The bitcoin-cli
RPC client does not support batch requests.
To keep this documentation compact and readable, the examples for each of the
available RPC calls will be given as bitcoin-cli
commands:
This translates into an JSON-RPC Request object of the form:
Warning: if you write programs using the JSON-RPC interface, you must ensure they handle high-precision real numbers correctly. See the Proper Money Handling Bitcoin Wiki article for details and example code.
addnode
RPC will have their information displayed.getpeerinfo
RPC pingtime and pingwait fields as decimal seconds. The P2P ping
message is handled in a queue with all other commands, so it measures processing backlog, not just network ping.txindex=1
in your Bitcoin Core startup settings.Note: the wallet RPCs are only available if Bitcoin Core was built with wallet support, which is the default.
wallet.dat
to the specified file, which can be a directory or a path with filename.dumpprivkey
RPC.dumpwallet
RPC). These keys will be added to the keys currently in the wallet. This call may need to rescan all or parts of the block chain for transactions affecting the newly-added keys, which may take several minutes.walletpassphrase
again before being able to call any methods which require the wallet to be unlocked.walletpassphrase
command while the wallet is already unlocked will set a new unlock time that overrides the old one.Warning: the block chain and memory pool can include arbitrary data which several of the commands below will return in hex format. If you convert this data to another format in an executable context, it could be used in an exploit. For example, displaying a pubkey script as ASCII text in a webpage could add arbitrary Javascript to that page and create a cross-site scripting (XSS) exploit. To avoid problems, please treat block chain and memory pool data as an arbitrary input from an untrusted source.
Requires wallet support.
The addmultisigaddress
RPC adds a P2SH multisig address to the wallet.
Parameter #1—the number of signatures required
Name | Type | Presence | Description |
---|---|---|---|
Required | number (int) | Required (exactly 1) |
The minimum (m) number of signatures required to spend this m-of-n multisig script |
Parameter #2—the full public keys, or addresses for known public keys
Name | Type | Presence | Description |
---|---|---|---|
Keys Or Addresses | array | Required (exactly 1) |
An array of strings with each string being a public key or address |
→ Key Or Address |
string | Required (1 or more) |
A public key against which signatures will be checked. Alternatively, this may be a P2PKH address belonging to the wallet—the corresponding public key will be substituted. There must be at least as many keys as specified by the Required parameter, and there may be more keys |
Parameter #3—the account name
Name | Type | Presence | Description |
---|---|---|---|
Account | string | Optional (0 or 1) |
The account name in which the address should be stored. Default is the default account, “” (an empty string) |
Result—a P2SH address printed and stored in the wallet
Name | Type | Presence | Description |
---|---|---|---|
result |
string (base58) | Required (exactly 1) |
The P2SH multisig address. The address will also be added to the wallet, and outputs paying that address will be tracked by the wallet |
Example from Bitcoin Core 0.10.0
Adding a 2-of-3 P2SH multisig address to the “test account” by mixing two P2PKH addresses and one full public key:
Result:
(New P2SH multisig address also stored in wallet.)
See also
The addnode
RPC attempts to add or remove a node from the addnode list, or to try a connection to a node once.
Parameter #1—hostname/IP address and port of node to add or remove
Name | Type | Presence | Description |
---|---|---|---|
Node | string | Required (exactly 1) |
The node to add as a string in the form of <IP address>:<port> . The IP address may be a hostname resolvable through DNS, an IPv4 address, an IPv4-as-IPv6 address, or an IPv6 address |
Parameter #2—whether to add or remove the node, or to try only once to connect
Name | Type | Presence | Description |
---|---|---|---|
Command | string | Required (exactly 1) |
What to do with the IP address above. Options are: • add to add a node to the addnode list. This will not connect immediately if the outgoing connection slots are full• remove to remove a node from the list. If currently connected, this will disconnect immediately• onetry to immediately attempt connection to the node even if the outgoing connection slots are full; this will only attempt the connection once |
Result—null
plus error on failed remove
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required (exactly 1) |
Always JSON null whether the node was added, removed, tried-and-connected, or tried-and-not-connected. The JSON-RPC error field will be set only if you try removing a node that is not on the addnodes list |
Example from Bitcoin Core 0.10.0
Try connecting to the following node.
Result (no output from bitcoin-cli
because result is set to null
).
See also
addnode
RPC will have their information displayed.Requires wallet support.
The backupwallet
RPC safely copies wallet.dat
to the specified file, which can be a directory or a path with filename.
Parameter #1—destination directory or filename
Name | Type | Presence | Description |
---|---|---|---|
Destination | string | Required (exactly 1) |
A filename or directory name. If a filename, it will be created or overwritten. If a directory name, the file wallet.dat will be created or overwritten within that directory |
Result—null
or error
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required (exactly 1) |
Always null whether success or failure. The JSON-RPC error and message fields will be set if a failure occurred |
Example from Bitcoin Core 0.10.0
See also
dumpwallet
RPC). These keys will be added to the keys currently in the wallet. This call may need to rescan all or parts of the block chain for transactions affecting the newly-added keys, which may take several minutes.The createmultisig
RPC creates a P2SH multi-signature address.
Parameter #1—the number of signatures required
Name | Type | Presence | Description |
---|---|---|---|
Required | number (int) | Required (exactly 1) |
The minimum (m) number of signatures required to spend this m-of-n multisig script |
Parameter #2—the full public keys, or addresses for known public keys
Name | Type | Presence | Description |
---|---|---|---|
Keys Or Addresses | array | Required (exactly 1) |
An array of strings with each string being a public key or address |
→ Key Or Address |
string | Required (1 or more) |
A public key against which signatures will be checked. If wallet support is enabled, this may be a P2PKH address belonging to the wallet—the corresponding public key will be substituted. There must be at least as many keys as specified by the Required parameter, and there may be more keys |
Result—P2SH address and hex-encoded redeem script
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
An object describing the multisig address |
→address |
string (base58) | Required (exactly 1) |
The P2SH address for this multisig redeem script |
→redeemScript |
string (hex) | Required (exactly 1) |
The multisig redeem script encoded as hex |
Example from Bitcoin Core 0.10.0
Creating a 2-of-3 P2SH multisig address by mixing two P2PKH addresses and one full public key:
Result:
See also
The createrawtransaction
RPC creates an unsigned serialized transaction that spends a previous output to a new output with a P2PKH or P2SH address. The transaction is not stored in the wallet or transmitted to the network.
Parameter #1—references to previous outputs
Name | Type | Presence | Description |
---|---|---|---|
Outpoints | array | Required (exactly 1) |
An array of objects, each one being an unspent outpoint |
→ Outpoint | object | Required (1 or more) |
An object describing a particular unspent outpoint |
→ →txid |
string (hex) | Required (exactly 1) |
The TXID of the outpoint encoded as hex in RPC byte order |
→ →vout |
number (int) | Required (exactly 1) |
The output index number (vout) of the outpoint; the first output in a transaction is index 0 |
Parameter #2—P2PKH or P2SH addresses and amounts
Name | Type | Presence | Description |
---|---|---|---|
Outputs | object | Required (exactly 1) |
The addresses and amounts to pay |
→ Address/Amount |
string : number (bitcoins) | Required (1 or more) |
A key/value pair with the address to pay as a string (key) and the amount to pay that address (value) in bitcoins |
Result—the unsigned raw transaction in hex
Name | Type | Presence | Description |
---|---|---|---|
result |
string | Required (Exactly 1) |
The resulting unsigned raw transaction in serialized transaction format encoded as hex. If the transaction couldn’t be generated, this will be set to JSON null and the JSON-RPC error field may contain an error message |
Example from Bitcoin Core 0.10.0
Result (wrapped):
See also
The decoderawtransaction
RPC decodes a serialized transaction hex string into a JSON object describing the transaction.
Parameter #1—serialized transaction in hex
Name | Type | Presence | Description |
---|---|---|---|
Serialized Transaction | string (hex) | Required (exactly 1) |
The transaction to decode in serialized transaction format |
Result—the decoded transaction
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
An object describing the decoded transaction, or JSON null if the transaction could not be decoded |
→txid |
string (hex) | Required (exactly 1) |
The transaction’s TXID encoded as hex in RPC byte order |
→version |
number (int) | Required (exactly 1) |
The transaction format version number |
→locktime |
number (int) | Required (exactly 1) |
The transaction’s locktime: either a Unix epoch date or block height; see the Locktime parsing rules |
→vin |
array | Required (exactly 1) |
An array of objects with each object being an input vector (vin) for this transaction. Input objects will have the same order within the array as they have in the transaction, so the first input listed will be input 0 |
→ → Input |
object | Required (1 or more) |
An object describing one of this transaction’s inputs. May be a regular input or a coinbase |
→ → →txid |
string | Optional (0 or 1) |
The TXID of the outpoint being spent, encoded as hex in RPC byte order. Not present if this is a coinbase transaction |
→ → →vout |
number (int) | Optional (0 or 1) |
The output index number (vout) of the outpoint being spent. The first output in a transaction has an index of 0 . Not present if this is a coinbase transaction |
→ → →scriptSig |
object | Optional (0 or 1) |
An object describing the signature script of this input. Not present if this is a coinbase transaction |
→ → → →asm |
string | Required (exactly 1) |
The signature script in decoded form with non-data-pushing opcodes listed |
→ → → →hex |
string (hex) | Required (exactly 1) |
The signature script encoded as hex |
→ → →coinbase |
string (hex) | Optional (0 or 1) |
The coinbase (similar to the hex field of a scriptSig) encoded as hex. Only present if this is a coinbase transaction |
→ → →sequence |
number (int) | Required (exactly 1) |
The input sequence number |
→vout |
array | Required (exactly 1) |
An array of objects each describing an output vector (vout) for this transaction. Output objects will have the same order within the array as they have in the transaction, so the first output listed will be output 0 |
→ → Output |
object | Required (1 or more) |
An object describing one of this transaction’s outputs |
→ → →value |
number (bitcoins) | Required (exactly 1) |
The number of bitcoins paid to this output. May be 0 |
→ → →n |
number (int) | Required (exactly 1) |
The output index number of this output within this transaction |
→ → →scriptPubKey |
object | Required (exactly 1) |
An object describing the pubkey script |
→ → → →asm |
string | Required (exactly 1) |
The pubkey script in decoded form with non-data-pushing opcodes listed |
→ → → →hex |
string (hex) | Required (exactly 1) |
The pubkey script encoded as hex |
→ → → →reqSigs |
number (int) | Optional (0 or 1) |
The number of signatures required; this is always 1 for P2PK, P2PKH, and P2SH (including P2SH multisig because the redeem script is not available in the pubkey script). It may be greater than 1 for bare multisig. This value will not be returned for nulldata or nonstandard script types (see the type key below) |
→ → → →type |
string | Optional (0 or 1) |
The type of script. This will be one of the following: • pubkey for a P2PK script• pubkeyhash for a P2PKH script• scripthash for a P2SH script• multisig for a bare multisig script• nulldata for nulldata scripts• nonstandard for unknown scripts |
→ → → →addresses |
string : array | Optional (0 or 1) |
The P2PKH or P2SH addresses used in this transaction, or the computed P2PKH address of any pubkeys in this transaction. This array will not be returned for nulldata or nonstandard script types |
→ → → → → Address |
string | Required (1 or more) |
A P2PKH or P2SH address |
Example from Bitcoin Core 0.10.0
Decode a signed one-input, three-output transaction:
Result:
See also
The decodescript
RPC decodes a hex-encoded P2SH redeem script.
Parameter #1—a hex-encoded redeem script
Name | Type | Presence | Description |
---|---|---|---|
Redeem Script | string (hex) | Required (exactly 1) |
The redeem script to decode as a hex-encoded serialized script |
Result—the decoded script
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
An object describing the decoded script, or JSON null if the script could not be decoded |
→asm |
string | Required (exactly 1) |
The redeem script in decoded form with non-data-pushing opcodes listed. May be empty |
→type |
string | Optional (0 or 1) |
The type of script. This will be one of the following: • pubkey for a P2PK script inside P2SH• pubkeyhash for a P2PKH script inside P2SH• multisig for a multisig script inside P2SH• nonstandard for unknown scripts |
→reqSigs |
number (int) | Optional (0 or 1) |
The number of signatures required; this is always 1 for P2PK or P2PKH within P2SH. It may be greater than 1 for P2SH multisig. This value will not be returned for nonstandard script types (see the type key above) |
→addresses |
array | Optional (0 or 1) |
A P2PKH addresses used in this script, or the computed P2PKH addresses of any pubkeys in this script. This array will not be returned for nonstandard script types |
→ → Address |
string | Required (1 or more) |
A P2PKH address |
→p2sh |
string (hex) | Required (exactly 1) |
The P2SH address of this redeem script |
Example from Bitcoin Core 0.10.0
A 2-of-3 P2SH multisig pubkey script:
Result:
See also
Requires wallet support. Requires an unlocked wallet or an unencrypted wallet.
The dumpprivkey
RPC returns the wallet-import-format (WIP) private key corresponding to an address. (But does not remove it from the wallet.)
Parameter #1—the address corresponding to the private key to get
Name | Type | Presence | Description |
---|---|---|---|
P2PKH Address | string (base58) | Required (exactly 1) |
The P2PKH address corresponding to the private key you want returned. Must be the address corresponding to a private key in this wallet |
Result—the private key
Name | Type | Presence | Description |
---|---|---|---|
result |
string (base58) | Required (exactly 1) |
The private key encoded as base58check using wallet import format |
Example from Bitcoin Core 0.10.0
Result:
See also
dumpprivkey
RPC.Requires wallet support. Requires an unlocked wallet or an unencrypted wallet.
The dumpwallet
RPC creates or overwrites a file with all wallet keys in a human-readable format.
Parameter #1—a filename
Name | Type | Presence | Description |
---|---|---|---|
Filename | string | Required (exactly 1) |
The file in which the wallet dump will be placed. May be prefaced by an absolute file path. An existing file with that name will be overwritten |
Result—null
or error
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required (exactly 1) |
Always null whether success or failure. The JSON-RPC error and message fields will be set if a failure occurred |
Example from Bitcoin Core 0.10.0
Create a wallet dump and then print its first 10 lines.
Results (only showing the first 10 lines):
See also
wallet.dat
to the specified file, which can be a directory or a path with filename.dumpwallet
RPC). These keys will be added to the keys currently in the wallet. This call may need to rescan all or parts of the block chain for transactions affecting the newly-added keys, which may take several minutes.Requires wallet support.
The encryptwallet
RPC encrypts the wallet with a passphrase. This is only to enable encryption for the first time. After encryption is enabled, you will need to enter the passphrase to use private keys.
Warning: if using this RPC on the command line, remember
that your shell probably saves your command lines (including the value
of the passphrase parameter). In addition, there is no RPC to completely
disable encryption. If you want to return to an unencrypted wallet, you
must create a new wallet and restore your data from a backup made with
the dumpwallet
RPC.
Parameter #1—a passphrase
Name | Type | Presence | Description |
---|---|---|---|
Passphrase | string | Required (exactly 1) |
The passphrase to use for the encrypted wallet. Must be at least one character |
Result—a notice (with program shutdown)
Name | Type | Presence | Description |
---|---|---|---|
result |
string | Required (exactly 1) |
A notice that the server is stopping and that you need to make a new backup. The wallet is now encrypted |
Example from Bitcoin Core 0.10.0
Result:
See also
walletpassphrase
command while the wallet is already unlocked will set a new unlock time that overrides the old one.walletpassphrase
again before being able to call any methods which require the wallet to be unlocked.Added in Bitcoin Core 0.10.0.
The estimatefee
RPC estimates the transaction fee per kilobyte that needs to be paid for a transaction to be included within a certain number of blocks.
Parameter #1—how many blocks the transaction may wait before being included
Name | Type | Presence | Description |
---|---|---|---|
Blocks | number (int) | Required (exactly 1) |
The maximum number of blocks a transaction should have to wait before it is predicted to be included in a block |
Result—the fee the transaction needs to pay per kilobyte
Name | Type | Presence | Description |
---|---|---|---|
result |
number (bitcoins) | Required (exactly 1) |
The estimated fee the transaction should pay in order to be included within the specified number of blocks. If the node doesn’t have enough information to make an estimate, the value -1 will be returned |
Examples from Bitcoin Core 0.10.0
Result:
Requesting data the node can’t calculate yet:
Result:
See also
Added in Bitcoin Core 0.10.0.
The estimatepriority
RPC estimates the priority that a transaction needs in order to be included within a certain number of blocks as a free high-priority transaction.
Transaction priority is relative to a transaction’s byte size.
Parameter #1—how many blocks the transaction may wait before being included as a free high-priority transaction
Name | Type | Presence | Description |
---|---|---|---|
Blocks | number (int) | Required (exactly 1) |
The maximum number of blocks a transaction should have to wait before it is predicted to be included in a block based purely on its priority |
Result—the priority a transaction needs
Name | Type | Presence | Description |
---|---|---|---|
result |
number (real) | Required (exactly 1) |
The estimated priority the transaction should have in order to be included within the specified number of blocks. If the node doesn’t have enough information to make an estimate, the value -1 will be returned |
Examples from Bitcoin Core 0.10.0
Result:
Requesting data the node can’t calculate yet:
Result:
See also
Requires wallet support.
The generate
RPC nearly instantly generates blocks (in regtest mode only)
Parameter #1—the number of blocks to generate
Name | Type | Presence | Description |
---|---|---|---|
Blocks | number (int) | Required (exactly 1) |
The number of blocks to generate. The RPC call will not return until all blocks have been generated |
Result—the generated block header hashes
Name | Type | Presence | Description |
---|---|---|---|
result |
array | Required (exactly 1) |
An array containing the block header hashes of the generated blocks (may be empty if used with generate 0 ) |
→ Header Hashes |
string (hex) | Required (1 or more) |
The hashes of the headers of the blocks generated in regtest mode, as hex in RPC byte order |
Examples from Bitcoin Core master (commit c2fa0846)
Using regtest mode, generate 2 blocks:
Result:
See also
Requires wallet support.
The getaccountaddress
RPC returns the current Bitcoin address for receiving payments to this account. If the account doesn’t exist, it creates both the account and a new address for receiving payment. Once a payment has been received to an address, future calls to this RPC for the same account will return a different address.
Parameter #1—an account name
Name | Type | Presence | Description |
---|---|---|---|
Account | string | Required (exactly 1) |
The name of an account. Use an empty string (“”) for the default account. If the account doesn’t exist, it will be created |
Result—a bitcoin address
Name | Type | Presence | Description |
---|---|---|---|
result |
string (base58) | Required (exactly 1) |
An address, belonging to the account specified, which has not yet received any payments |
Example from Bitcoin Core 0.10.0
Get an address for the default account:
Result:
See also
Requires wallet support.
The getaccount
RPC returns the name of the account associated with the given address.
Parameter #1—a Bitcoin address
Name | Type | Presence | Description |
---|---|---|---|
Address | string (base58) | Required (exactly 1) |
A P2PKH or P2SH Bitcoin address belonging either to a specific account or the default account (“”) |
Result—an account name
Name | Type | Presence | Description |
---|---|---|---|
result |
string | Required (exactly 1) |
The name of an account, or an empty string (“”, the default account) |
Example from Bitcoin Core 0.10.0
Result:
See also
The getaddednodeinfo
RPC returns information about the given added node, or all added nodes (except onetry nodes). Only nodes which have been manually added using the addnode
RPC will have their information displayed.
Parameter #1—whether to display connection information
Name | Type | Presence | Description |
---|---|---|---|
Details | bool | Required (exactly 1) |
Set to true to display detailed information about each added node; set to false to only display the IP address or hostname and port added |
Parameter #2—what node to display information about
Name | Type | Presence | Description |
---|---|---|---|
Node | string | Optional (0 or 1) |
The node to get information about in the same <IP address>:<port> format as the addnode RPC. If this parameter is not provided, information about all added nodes will be returned |
Result—a list of added nodes
Name | Type | Presence | Description |
---|---|---|---|
result |
array | Required (exactly 1) |
An array containing objects describing each added node. If no added nodes are present, the array will be empty. Nodes added with onetry will not be returned |
→ Added Node |
object | Optional (0 or more) |
An object containing details about a single added node |
→ →addednode |
string | Required (exactly 1) |
An added node in the same <IP address>:<port> format as used in the addnode RPC. This element is present for any added node whether or not the Details parameter was set to true |
→ →connected |
bool | Optional (0 or 1) |
If the Details parameter was set to true , this will be set to true if the node is currently connected and false if it is not |
→ →addresses |
array | Optional (0 or 1) |
If the Details parameter was set to true , this will be an array of addresses belonging to the added node |
→ → → Address |
object | Optional (0 or more) |
An object describing one of this node’s addresses |
→ → → →address |
string | Required (exactly 1) |
An IP address and port number of the node. If the node was added using a DNS address, this will be the resolved IP address |
→ → → →connected |
string | Required (exactly 1) |
Whether or not the local node is connected to this addnode using this IP address. Valid values are: • false for not connected• inbound if the addnode connected to us• outbound if we connected to the addnode |
Example from Bitcoin Core 0.10.0
Result (real hostname and IP address replaced):
See also
Requires wallet support.
The getaddressesbyaccount
RPC returns a list of every address assigned to a particular account.
Parameter #1—the account name
Name | Type | Presence | Description |
---|---|---|---|
Account | string | Required (exactly 1) |
The name of the account containing the addresses to get. To get addresses from the default account, pass an empty string (“”) |
Result—a list of addresses
Name | Type | Presence | Description |
---|---|---|---|
result |
array | Required (exactly 1) |
An array containing all addresses belonging to the specified account. If the account has no addresses, the array will be empty |
Address | string (base58) | Optional (1 or more) |
A P2PKH or P2SH address belonging to the account |
Example from Bitcoin Core 0.10.0
Get the addresses assigned to the account “doc test”:
Result:
See also
Requires wallet support.
The getbalance
RPC gets the balance in decimal bitcoins across all accounts or for a particular account.
Parameter #1—an account name
Name | Type | Presence | Description |
---|---|---|---|
Account | string | Optional (0 or 1) |
The name of an account to get the balance for. An empty string (“”) is the default account. The string * will get the balance for all accounts (this is the default behavior) |
Parameter #2—the minimum number of confirmations
Name | Type | Presence | Description |
---|---|---|---|
Confirmations | number (int) | Optional (0 or 1) |
The minimum number of confirmations an externally-generated transaction must have before it is counted towards the balance. Transactions generated by this node are counted immediately. Typically, externally-generated transactions are payments to this wallet and transactions generated by this node are payments to other wallets. Use 0 to count unconfirmed transactions. Default is 1 |
Parameter #3—whether to include watch-only addresses
Name | Type | Presence | Description |
---|---|---|---|
Include Watch-Only | bool | Optional (0 or 1) |
Added in Bitcoin Core 0.10.0 If set to true , include watch-only addresses in details and calculations as if they were regular addresses belonging to the wallet. If set to false (the default), treat watch-only addresses as if they didn’t belong to this wallet |
Result—the balance in bitcoins
Name | Type | Presence | Description |
---|---|---|---|
result |
number (bitcoins) | Required (exactly 1) |
The balance of the account (or all accounts) in bitcoins |
Examples from Bitcoin Core 0.10.0
Get the balance for the “test1” account, including transactions with at least one confirmation and those spent to watch-only addresses in that account.
Result:
See also
Added in Bitcoin Core 0.9.0
The getbestblockhash
RPC returns the header hash of the most recent block on the best block chain.
Parameters: none
Result—hash of the tip from the best block chain
Name | Type | Presence | Description |
---|---|---|---|
result |
string (hex) | Required (exactly 1) |
The hash of the block header from the most recent block on the best block chain, encoded as hex in RPC byte order |
Example from Bitcoin Core 0.10.0
Result:
See also
The getblock
RPC gets a block with a particular header hash from the local block database either as a JSON object or as a serialized block.
Parameter #1—header hash
Name | Type | Presence | Description |
---|---|---|---|
Header Hash | string (hex) | Required (exactly 1) |
The hash of the header of the block to get, encoded as hex in RPC byte order |
Parameter #2—JSON or hex output
Name | Type | Presence | Description |
---|---|---|---|
Format | bool | Optional (0 or 1) |
Set to false to get the block in serialized block format; set to true (the default) to get the decoded block as a JSON object |
Result (if format was false
)—a serialized block
Name | Type | Presence | Description |
---|---|---|---|
result |
string (hex)/null | Required (exactly 1) |
The requested block as a serialized block, encoded as hex, or JSON null if an error occurred |
Result (if format was true
or omitted)—a JSON block
Name | Type | Presence | Description |
---|---|---|---|
result |
object/null | Required (exactly 1) |
An object containing the requested block, or JSON null if an error occurred |
→hash |
string (hex) | Required (exactly 1) |
The hash of this block’s block header encoded as hex in RPC byte order. This is the same as the hash provided in parameter #1 |
→confirmations |
number (int) | Required (exactly 1) |
The number of confirmations the transactions in this block have, starting at 1 when this block is at the tip of the best block chain. This score will be -1 if the the block is not part of the best block chain |
→size |
number (int) | Required (exactly 1) |
The size of this block in serialized block format, counted in bytes |
→height |
number (int) | Required (exactly 1) |
The height of this block on its block chain |
→version |
number (int) | Required (exactly 1) |
This block’s version number. See block version numbers |
→merkleroot |
string (hex) | Required (exactly 1) |
The merkle root for this block, encoded as hex in RPC byte order |
→tx |
array | Required (exactly 1) |
An array containing the TXIDs of all transactions in this block. The transactions appear in the array in the same order they appear in the serialized block |
→ → TXID |
string (hex) | Required (1 or more) |
The TXID of a transaction in this block, encoded as hex in RPC byte order |
→time |
number (int) | Required (exactly 1) |
The value of the time field in the block header, indicating approximately when the block was created |
→nonce |
number (int) | Required (exactly 1) |
The nonce which was successful at turning this particular block into one that could be added to the best block chain |
→bits |
string (hex) | Required (exactly 1) |
The value of the nBits field in the block header, indicating the target threshold this block’s header had to pass |
→difficulty |
number (real) | Required (exactly 1) |
The estimated amount of work done to find this block relative to the estimated amount of work done to find block 0 |
→chainwork |
string (hex) | Required (exactly 1) |
The estimated number of block header hashes miners had to check from the genesis block to this block, encoded as big-endian hex |
→previousblockhash |
string (hex) | Optional (0 or 1) |
The hash of the header of the previous block, encoded as hex in RPC byte order. Not returned for genesis block |
→nextblockhash |
string (hex) | Optional (0 or 1) |
The hash of the next block on the best block chain, if known, encoded as hex in RPC byte order |
Example from Bitcoin Core 0.10.0
Get a block in raw hex:
Result (wrapped):
Get the same block in JSON:
Result:
See also
Added in Bitcoin Core 0.9.2
The getblockchaininfo
RPC provides information about the current state of the block chain.
Parameters: none
Result—A JSON object providing information about the block chain
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
Information about the current state of the local block chain |
→chain |
string | Required (exactly 1) |
The name of the block chain. One of main for mainnet, test for testnet, or regtest for regtest |
→blocks |
number (int) | Required (exactly 1) |
The number of validated blocks in the local best block chain. For a new node with just the hardcoded genesis block, this will be 0 |
→headers |
number (int) | Required (exactly 1) |
Added in Bitcoin Core 0.10.0 The number of validated headers in the local best headers chain. For a new node with just the hardcoded genesis block, this will be zero. This number may be higher than the number of blocks |
→bestblockhash |
string (hex) | Required (exactly 1) |
The hash of the header of the highest validated block in the best block chain, encoded as hex in RPC byte order. This is identical to the string returned by the getbestblockhash RPC |
→difficulty |
number (real) | Required (exactly 1) |
The difficulty of the highest-height block in the best block chain |
→verificationprogress |
number (real) | Required (exactly 1) | Estimate of what percentage of the block chain transactions have been verified so far, starting at 0.0 and increasing to 1.0 for fully verified. May slightly exceed 1.0 when fully synced to account for transactions in the memory pool which have been verified before being included in a block |
→chainwork |
string (hex) | Required (exactly 1) |
The estimated number of block header hashes checked from the genesis block to this block, encoded as big-endian hex |
Example from Bitcoin Core 0.10.0
Result:
See also
The getblockcount
RPC returns the number of blocks in the local best block chain.
Parameters: none
Result—the number of blocks in the local best block chain
Name | Type | Presence | Description |
---|---|---|---|
result |
number (int) | Required (exactly 1) |
The number of blocks in the local best block chain. For a new node with only the hardcoded genesis block, this number will be 0 |
Example from Bitcoin Core 0.10.0
Result:
See also
The getblockhash
RPC returns the header hash of a block at the given height in the local best block chain.
Parameter—a block height
Name | Type | Presence | Description |
---|---|---|---|
Block Height | number (int) | Required (exactly 1) |
The height of the block whose header hash should be returned. The height of the hardcoded genesis block is 0 |
Result—the block header hash
Name | Type | Presence | Description |
---|---|---|---|
result |
string (hex)/null | Required (exactly 1) |
The hash of the block at the requested height, encoded as hex in RPC byte order, or JSON null if an error occurred |
Example from Bitcoin Core 0.10.0
Result:
See also
The getblocktemplate
RPC gets a block template or proposal for use with mining software. For more
information, please see the following resources:
See also
Added in Bitcoin Core 0.10.0.
The getchaintips
RPC returns information about the highest-height block (tip) of each local block chain.
Parameters: none
Result—an array of block chain tips
Name | Type | Presence | Description |
---|---|---|---|
result |
array | Required (exactly 1) |
An array of JSON objects, with each object describing a chain tip. At least one tip—the local best block chain—will always be present |
→ Tip |
object | Required (1 or more) |
An object describing a particular chain tip. The first object will always describe the active chain (the local best block chain) |
→ →height |
number (int) | Required (exactly 1) |
The height of the highest block in the chain. A new node with only the genesis block will have a single tip with height of 0 |
→ →hash |
string (hex) | Required (exactly 1) |
The hash of the highest block in the chain, encoded as hex in RPC byte order |
→ →branchlen |
number (int) | Required (exactly 1) |
The number of blocks that are on this chain but not on the main chain. For the local best block chain, this will be 0 ; for all other chains, it will be at least 1 |
→ →status |
string | Required (exactly 1) |
The status of this chain. Valid values are: • active for the local best block chain• invalid for a chain that contains one or more invalid blocks• headers-only for a chain with valid headers whose corresponding blocks both haven’t been validated and aren’t stored locally• valid-headers for a chain with valid headers whose corresponding blocks are stored locally, but which haven’t been fully validated• valid-fork for a chain which is fully validated but which isn’t part of the local best block chain (it was probably the local best block chain at some point)• unknown for a chain whose reason for not being the active chain is unknown |
Example from Bitcoin Core 0.10.0
See also
The getconnectioncount
RPC returns the number of connections to other nodes.
Parameters: none
Result—the number of connections to other nodes
Name | Type | Presence | Description |
---|---|---|---|
result |
number (int) | Required (exactly 1) |
The total number of connections to other nodes (both inbound and outbound) |
Example from Bitcoin Core 0.10.0
Result:
See also
Parameters: none
Result—the current difficulty
Name | Type | Presence | Description |
---|---|---|---|
result |
number (real) | Required (exactly 1) |
The difficulty of creating a block with the same target threshold (nBits) as the highest-height block in the local best block chain. The number is a a multiple of the minimum difficulty |
Example from Bitcoin Core 0.10.0
Result:
See also
Requires wallet support.
The getgenerate
RPC returns true if the node is set to generate blocks using its CPU.
Parameters: none
Result—whether the server is set to generate blocks
Name | Type | Presence | Description |
---|---|---|---|
result |
bool | Required (exactly 1) |
Set to true if the server is set to generate blocks; set to false if it is not |
Example from Bitcoin Core 0.10.0
Result:
See also
Requires wallet support.
The gethashespersec
RPC was removed in Bitcoin Core master (unreleased). It returned a recent hashes per second performance measurement when the node was generating blocks.
Parameters: none
Result—the number of hashes your computer generated per second
Name | Type | Presence | Description |
---|---|---|---|
result |
number (int) | Required (exactly 1) |
If generation is enabled, the number of hashes per second your computer most recently generated. If generation is disabled, the value 0 |
Example from Bitcoin Core 0.10.0
Result:
See also
The getinfo
RPC prints various information about the node and the network.
Warning: getinfo
will be removed in a later version of Bitcoin
Core. Use the RPCs listed in the See Also subsection below instead.
Parameters: none
Result—information about the node and network
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
Information about this node and the network |
→version |
number (int) | Required (exactly 1) |
This node’s version of Bitcoin Core in its internal integer format. For example, Bitcoin Core 0.9.2 has the integer version number 90200 |
→protocolversion |
number (int) | Required (exactly 1) |
The protocol version number used by this node. See the protocol versions section for more information |
→walletversion |
number (int) | Optional (0 or 1) |
The version number of the wallet. Only returned if wallet support is enabled |
→balance |
number (bitcoins) | Optional (0 or 1) |
The balance of the wallet in bitcoins. Only returned if wallet support is enabled |
→blocks |
number (int) | Required (exactly 1) |
The number of blocks in the local best block chain. A new node with only the hardcoded genesis block will return 0 |
→timeoffset |
number (int) | Required (exactly 1) |
The offset of the node’s clock from the computer’s clock (both in UTC) in seconds. The offset may be up to 4200 seconds (70 minutes) |
→connections |
number (int) | Required (exactly 1) |
The total number of open connections (both outgoing and incoming) between this node and other nodes |
→proxy |
string | Required (exactly 1) |
The hostname/IP address and port number of the proxy, if set, or an empty string if unset |
→difficulty |
number (real) | Required (exactly 1) |
The difficulty of the highest-height block in the local best block chain |
→testnet |
bool | Required (exactly 1) |
Added in Bitcoin Core 0.10.0 Set to true if this node is on testnet; set to false if this node is on mainnet or a regtest |
→keypoololdest |
number (int) | Optional (0 or 1) |
The date as Unix epoch time when the oldest key in the wallet key pool was created; useful for only scanning blocks created since this date for transactions. Only returned if wallet support is enabled |
→keypoolsize |
number (int) | Optional (0 or 1) |
The number of keys in the wallet keypool. Only returned if wallet support is enabled |
→paytxfee |
number (bitcoins) | Optional (0 or 1) |
The minimum fee to pay per kilobyte of transaction; may be 0 . Only returned if wallet suuport is enabled |
→relayfee |
number (bitcoins) | Required (exactly 1) |
The minimum fee a low-priority transaction must pay in order for this node to accept it into its memory pool |
→unlocked_until |
number (int) | Optional (0 or 1) |
The Unix epoch time when the wallet will automatically re-lock. Only displayed if wallet encryption is enabled. Set to 0 if wallet is currently locked |
→errors |
string | Required (exactly 1) |
A plain-text description of any errors this node has encountered or detected. If there are no errors, an empty string will be returned. This is not related to the JSON-RPC error field |
Example from Bitcoin Core 0.10.0 with wallet support enabled
Result:
See also
Added in Bitcoin Core 0.10.0
The getmempoolinfo
RPC returns information about the node’s current transaction memory pool.
Parameters: none
Result—information about the transaction memory pool
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
A object containing information about the memory pool |
→size |
number (int) | Required (exactly 1) |
The number of transactions currently in the memory pool |
→bytes |
number (int) | Required (exactly 1) |
The total number of bytes in the transactions in the memory pool |
Example from Bitcoin Core 0.10.0
Result:
See also
The getmininginfo
RPC returns various mining-related information.
Parameters: none
Result—various mining-related information
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
Various mining-related information |
→blocks |
number (int) | Required (exactly 1) |
The height of the highest block on the local best block chain |
→currentblocksize |
number (int) | Required (exactly 1) |
If generation was enabled since the last time this node was restarted, this is the size in bytes of the last block built by this node for header hash checking. Otherwise, the value 0 |
→currentblocktx |
number (int) | Required (exactly 1) |
If generation was enabled since the last time this node was restarted, this is the number of transactions in the last block built by this node for header hash checking. Otherwise, this is the value 0 |
→difficulty |
number (real) | Required (exactly 1) |
If generation was enabled since the last time this node was restarted, this is the difficulty of the highest-height block in the local best block chain. Otherwise, this is the value 0 |
→errors |
string | Required (exactly 1) |
A plain-text description of any errors this node has encountered or detected. If there are no errors, an empty string will be returned. This is not related to the JSON-RPC error field |
→genproclimit |
number (int) | Required (exactly 1) |
The limit on the number of processors to use for generation. If generation was enabled since the last time this node was restarted, this is the number used in the second parameter of the setgenerate RPC (or the default). Otherwise, it is -1 |
→networkhashps |
number (int) | Required (exactly 1) |
An estimate of the number of hashes per second the network is generating to maintain the current difficulty. See the getnetworkhashps RPC for configurable access to this data |
→pooledtx |
number (int) | Required (exactly 1) |
The number of transactions in the memory pool |
→testnet |
bool | Required (exactly 1) |
Set to true if this node is running on testnet. Set to false if this node is on mainnet or a regtest |
→chain |
string | Required (exactly 1) |
Set to main for mainnet, test for testnet, and regtest for regtest |
→generate |
bool | Optional (0 or 1) |
Set to true if generation is currently enabled; set to false if generation is currently disabled. Only returned if the node has wallet support enabled |
→hashespersec |
number (int) | Optional (0 or 1) |
Removed in Bitcoin Core master (unreleased) The approximate number of hashes per second this node is generating across all CPUs, if generation is enabled. Otherwise 0 . Only returned if the node has wallet support enabled |
Example from Bitcoin Core 0.10.0
Result:
See also
The getnettotals
RPC returns information about network traffic, including bytes in, bytes out, and the current time.
Parameters: none
Result—the current bytes in, bytes out, and current time
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
An object containing information about the node’s network totals |
→totalbytesrecv |
number (int) | Required (exactly 1) |
The total number of bytes received since the node was last restarted |
→totalbytessent |
number (int) | Required (exactly 1) |
The total number of bytes sent since the node was last restarted |
→timemillis |
number (int) | Required (exactly 1) |
Unix epoch time in milliseconds according to the operating system’s clock (not the node adjusted time) |
Example from Bitcoin Core 0.10.0
Result:
See also
The getnetworkhashps
RPC returns the estimated current or historical network hashes per second based on the last n blocks.
Parameter #1—number of blocks to average
Name | Type | Presence | Description |
---|---|---|---|
Blocks | number (int) | Optional (0 or 1) |
The number of blocks to average together for calculating the estimated hashes per second. Default is 120 . Use -1 to average all blocks produced since the last difficulty change |
Parameter #2—block height
Name | Type | Presence | Description |
---|---|---|---|
Height | number (int) | Optional (0 or 1) |
The height of the last block to use for calculating the average. Defaults to -1 for the highest-height block on the local best block chain. If the specified height is higher than the highest block on the local best block chain, it will be interpreted the same as -1 |
Result—estimated hashes per second
Name | Type | Presence | Description |
---|---|---|---|
result |
number (int) | Required (exactly 1) |
The estimated number of hashes per second based on the parameters provided. May be 0 (for Height=0 , the genesis block) or a negative value if the highest-height block averaged has a block header time earlier than the lowest-height block averaged |
Example from Bitcoin Core 0.10.0
Get the average hashes per second for all the blocks since the last difficulty change before block 227255.
Result:
See also
Added in Bitcoin Core 0.9.2.
The getnetworkinfo
RPC returns information about the node’s connection to the network.
Parameters: none
Result—information about the node’s connection to the network
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
Information about this node’s connection to the network |
→version |
number | Required (exactly 1) |
This node’s version of Bitcoin Core in its internal integer format. For example, Bitcoin Core 0.9.2 has the integer version number 90200 |
→subversion |
string | Required (exactly 1) |
Added in Bitcoin Core 0.10.0 The user agent this node sends in its version message |
→protocolversion |
number (int) | Required (exactly 1) |
The protocol version number used by this node. See the protocol versions section for more information |
→timeoffset |
number (int) | Required (exactly 1) |
The offset of the node’s clock from the computer’s clock (both in UTC) in seconds. The offset may be up to 4200 seconds (70 minutes) |
→connections |
number (int) | Required (exactly 1) |
The total number of open connections (both outgoing and incoming) between this node and other nodes |
→proxy |
string | Required (exactly 1) |
The hostname/IP address and port number of the proxy, if set, or an empty string if unset |
→relayfee |
number (bitcoins) | Required (exactly 1) |
The minimum fee a low-priority transaction must pay in order for this node to accept it into its memory pool |
→localservices |
string (hex) | Required (exactly 1) |
Added in Bitcoin Core 0.10.0 The services supported by this node as advertised in its version message |
→networks |
array | Required (exactly 1) |
Added in Bitcoin Core 0.10.0 An array with three objects: one describing the IPv4 connection, one describing the IPv6 connection, and one describing the Tor hidden service (onion) connection |
→ → Network |
object | Optional (0 to 3) |
An object describing a network. If the network is unroutable, it will not be returned |
→ → →name |
string | Required (exactly 1) |
The name of the network. Either ipv4 , ipv6 , or onion |
→ → →limited |
bool | Required (exactly 1) |
Set to true if only connections to this network are allowed according to the -onlynet Bitcoin Core command-line/configuration-file parameter. Otherwise set to false |
→ → →reachable |
bool | Required (exactly 1) |
Set to true if connections can be made to or from this network. Otherwise set to false |
→ → →proxy |
string | Required (exactly 1) |
The hostname and port of any proxy being used for this network. If a proxy is not in use, an empty string |
→ → →localaddresses |
array | Required (exactly 1) |
An array of objects each describing the local addresses this node believes it listens on |
→ → → → Address |
object | Optional (0 or more) |
An object describing a particular address this node believes it listens on |
→ → → → →address |
string | Required (exactly 1) |
An IP address or .onion address this node believes it listens on. This may be manually configured, auto detected, or based on version messages this node received from its peers |
→ → → → →port |
number (int) | Required (exactly 1) |
The port number this node believes it listens on for the associated address . This may be manually configured, auto detected, or based on version messages this node received from its peers |
→ → → → →score |
number (int) | Required (exactly 1) |
The number of incoming connections during the uptime of this node that have used this address in their version message |
Example from Bitcoin Core 0.10.0
Result (actual addresses have been replaced with reserved addresses):
See also
Requires wallet support.
The getnewaddress
RPC returns a new Bitcoin address for receiving payments. If an account is specified, payments received with the address will be credited to that account.
Parameter #1—an account name
Name | Type | Presence | Description |
---|---|---|---|
Account | string | Optional (0 or 1) |
The name of the account to put the address in. The default is the default account, an empty string (“”) |
Result—a bitcoin address never previously returned
Name | Type | Presence | Description |
---|---|---|---|
result |
string (base58) | Required (exactly 1) |
A P2PKH address which has not previously been returned by this RPC. The address will be marked as a receiving address in the wallet. The address may already have been part of the keypool, so other RPCs such as the dumpwallet RPC may have disclosed it previously. If the wallet is unlocked, its keypool will also be filled to its max (by default, 100 unused keys). If the wallet is locked and its keypool is empty, this RPC will fail |
Example from Bitcoin Core 0.10.0
Create a new address in the “doc test” account:
Result:
See also
The getpeerinfo
RPC returns data about each connected network node.
Parameters: none
Result—information about each currently-connected network node
Name | Type | Presence | Description |
---|---|---|---|
result |
array | Required (exactly 1) |
An array of objects each describing one connected node. If there are no connections, the array will be empty |
→ Node |
object | Optional (0 or more) |
An object describing a particular connected node |
→ →id |
number (int) | Required (exactly 1) |
Added in Bitcoin Core 0.10.0 The node’s index number in the local node address database |
→ →addr |
string | Required (exactly 1) |
The IP address and port number used for the connection to the remote node |
→ →addrlocal |
string | Optional (0 or 1) |
Our IP address and port number according to the remote node. May be incorrect due to error or lying. Many SPV nodes set this to 127.0.0.1:8333 |
→ →services |
string (hex) | Required (exactly 1) |
The services advertised by the remote node in its version message |
→ →lastsend |
number (int) | Required (exactly 1) |
The Unix epoch time when we last successfully sent data to the TCP socket for this node |
→ →lastrecv |
number (int) | Required (exactly 1) |
The Unix epoch time when we last received data from this node |
→ →bytessent |
number (int) | Required (exactly 1) |
The total number of bytes we’ve sent to this node |
→ →bytesrecv |
number (int) | Required (exactly 1) |
The total number of bytes we’ve received from this node |
→ →conntime |
number (int) | Required (exactly 1) |
The Unix epoch time when we connected to this node |
→ →pingtime |
number (real) | Required (exactly 1) |
The number of seconds this node took to respond to our last P2P ping message |
→ →pingwait |
number (real) | Optional (0 or 1) |
The number of seconds we’ve been waiting for this node to respond to a P2P ping message. Only shown if there’s an outstanding ping message |
→ →version |
number (int) | Required (exactly 1) |
The protocol version number used by this node. See the protocol versions section for more information |
→ →subver |
string | Required (exactly 1) |
The user agent this node sends in its version message. This string will have been sanitized to prevent corrupting the JSON results. May be an empty string |
→ →inbound |
bool | Required (exactly 1) |
Set to true if this node connected to us; set to false if we connected to this node |
→ →startingheight |
number (int) | Required (exactly 1) |
The height of the remote node’s block chain when it connected to us as reported in its version message |
→ →banscore |
number (int) | Required (exactly 1) |
The ban score we’ve assigned the node based on any misbehavior it’s made. By default, Bitcoin Core disconnects when the ban score reaches 100 |
→ →synced_headers |
number (int) | Required (exactly 1) |
Added in Bitcoin Core 0.10.0 The highest-height header we have in common with this node based the last P2P headers message it sent us. If a headers message has not been received, this will be set to -1 |
→ →synced_blocks |
number (int) | Required (exactly 1) |
Added in Bitcoin Core 0.10.0 The highest-height block we have in common with this node based on P2P inv messages this node sent us. If no block inv messages have been received from this node, this will be set to -1 |
→ →syncnode |
bool | Required (exactly 1) |
Removed in Bitcoin Core 0.10.0 Whether we’re using this node as our syncnode during initial block download |
→ →inflight |
array | Required (exactly 1) |
Added in Bitcoin Core 0.10.0 An array of blocks which have been requested from this peer. May be empty |
→ → → Blocks |
number (int) | Optional (0 or more) |
The height of a block being requested from the remote peer |
→ →whitelisted |
bool | Required (exactly 1) |
Added in Bitcoin Core 0.10.0 Set to true if the remote peer has been whitelisted; otherwise, set to false . Whitelisted peers will not be banned if their ban score exceeds the maximum (100 by default). By default, peers connecting from localhost are whitelisted |
Example from Bitcoin Core 0.10.0
Result (edited to show only a single entry, with IP addresses changed to RFC5737 reserved IP addresses):
See also
addnode
RPC will have their information displayed.Requires wallet support.
The getrawchangeaddress
RPC returns a new Bitcoin address for receiving change. This is for use with raw transactions, not normal use.
Parameters: none
Result—a P2PKH address which can be used in raw transactions
Name | Type | Presence | Description |
---|---|---|---|
result |
string (base58) | Required (exactly 1) |
A P2PKH address which has not previously been returned by this RPC. The address will be removed from the keypool but not marked as a receiving address, so RPCs such as the dumpwallet RPC will show it as a change address. The address may already have been part of the keypool, so other RPCs such as the dumpwallet RPC may have disclosed it previously. If the wallet is unlocked, its keypool will also be filled to its max (by default, 100 unused keys). If the wallet is locked and its keypool is empty, this RPC will fail |
Example from Bitcoin Core 0.10.0
Result:
See also
The getrawmempool
RPC returns all transaction identifiers (TXIDs) in the memory pool as a JSON array, or detailed information about each transaction in the memory pool as a JSON object.
Parameter—desired output format
Name | Type | Presence | Description |
---|---|---|---|
Format | bool | Optional (0 or 1) |
Set to true to get verbose output describing each transaction in the memory pool; set to false (the default) to only get an array of TXIDs for transactions in the memory pool |
Result (format false
)—an array of TXIDs
Name | Type | Presence | Description |
---|---|---|---|
result |
array | Required (exactly 1) |
An array of TXIDs belonging to transactions in the memory pool. The array may be empty if there are no transactions in the memory pool |
→ TXID |
string | Optional (0 or more) |
The TXID of a transaction in the memory pool, encoded as hex in RPC byte order |
Result (format: true
)—a JSON object describing each transaction
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
A object containing transactions currently in the memory pool. May be empty |
→ TXID |
string : object | Optional (0 or more) |
The TXID of a transaction in the memory pool, encoded as hex in RPC byte order |
→ →size |
number (int) | Required (exactly 1) |
The size of the serialized transaction in bytes |
→ →fee |
number (bitcoins) | Required (exactly 1) |
The transaction fee paid by the transaction in decimal bitcoins |
→ →time |
number (int) | Required (exactly 1) |
The time the transaction entered the memory pool, Unix epoch time format |
→ →height |
number (int) | Required (exactly 1) |
The block height when the transaction entered the memory pool |
→ →startingpriority |
number (int) | Required (exactly 1) |
The priority of the transaction when it first entered the memory pool |
→ →currentpriority |
number (int) | Required (exactly 1) |
The current priority of the transaction |
→ →depends |
array | Required (exactly 1) |
An array holding TXIDs of unconfirmed transactions this transaction depends upon. Those transactions must be part of a block before this transaction can be added to a block, although all transactions may be included in the same block. The array may be empty |
→ → → Depends TXID |
string | Optional (0 or more) | The TXIDs of any unconfirmed transactions this transaction depends upon, encoded as hex in RPC byte order |
Examples from Bitcoin Core 0.10.0
The default (false
):
Result:
Verbose output (true
):
Result:
See also
The getrawtransaction
RPC gets a hex-encoded serialized transaction or a JSON object describing the transaction. By default, Bitcoin Core only stores complete transaction data for UTXOs and your own transactions, so the RPC may fail on historic transactions unless you use the non-default txindex=1
in your Bitcoin Core startup settings.
Note: if you begin using txindex=1
after downloading the block chain, you must rebuild your indexes by starting Bitcoin Core with the option -reindex
. This may take several hours to complete, during which time your node will not process new blocks or transactions. This reindex only needs to be done once.
Parameter #1—the TXID of the transaction to get
Name | Type | Presence | Description |
---|---|---|---|
TXID | string (hex) | Required (exactly 1) |
The TXID of the transaction to get, encoded as hex in RPC byte order |
Parameter #2—whether to get the serialized or decoded transaction
Name | Type | Presence | Description |
---|---|---|---|
Verbose | number (int) | Optional (0 or 1) |
Set to 0 (the default) to return the serialized transaction as hex. Set to 1 to return a decoded transaction |
Result (if transaction not found)—null
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required (exactly 1) |
If the transaction wasn’t found, the result will be JSON null . This can occur because the transaction doesn’t exist in the block chain or memory pool, or because it isn’t part of the transaction index. See the Bitcoin Core -help entry for -txindex |
Result (if verbose=0
)—the serialized transaction
Name | Type | Presence | Description |
---|---|---|---|
result |
string (hex) | Required (exactly 1) |
If the transaction was found, this will be the serialized transaction encoded as hex |
Result (if verbose=1
)—the decoded transaction
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
If the transaction was found, this will be an object describing it |
→txid |
string (hex) | Required (exactly 1) |
The transaction’s TXID encoded as hex in RPC byte order |
→version |
number (int) | Required (exactly 1) |
The transaction format version number |
→locktime |
number (int) | Required (exactly 1) |
The transaction’s locktime: either a Unix epoch date or block height; see the Locktime parsing rules |
→vin |
array | Required (exactly 1) |
An array of objects with each object being an input vector (vin) for this transaction. Input objects will have the same order within the array as they have in the transaction, so the first input listed will be input 0 |
→ → Input |
object | Required (1 or more) |
An object describing one of this transaction’s inputs. May be a regular input or a coinbase |
→ → →txid |
string | Optional (0 or 1) |
The TXID of the outpoint being spent, encoded as hex in RPC byte order. Not present if this is a coinbase transaction |
→ → →vout |
number (int) | Optional (0 or 1) |
The output index number (vout) of the outpoint being spent. The first output in a transaction has an index of 0 . Not present if this is a coinbase transaction |
→ → →scriptSig |
object | Optional (0 or 1) |
An object describing the signature script of this input. Not present if this is a coinbase transaction |
→ → → →asm |
string | Required (exactly 1) |
The signature script in decoded form with non-data-pushing opcodes listed |
→ → → →hex |
string (hex) | Required (exactly 1) |
The signature script encoded as hex |
→ → →coinbase |
string (hex) | Optional (0 or 1) |
The coinbase (similar to the hex field of a scriptSig) encoded as hex. Only present if this is a coinbase transaction |
→ → →sequence |
number (int) | Required (exactly 1) |
The input sequence number |
→vout |
array | Required (exactly 1) |
An array of objects each describing an output vector (vout) for this transaction. Output objects will have the same order within the array as they have in the transaction, so the first output listed will be output 0 |
→ → Output |
object | Required (1 or more) |
An object describing one of this transaction’s outputs |
→ → →value |
number (bitcoins) | Required (exactly 1) |
The number of bitcoins paid to this output. May be 0 |
→ → →n |
number (int) | Required (exactly 1) |
The output index number of this output within this transaction |
→ → →scriptPubKey |
object | Required (exactly 1) |
An object describing the pubkey script |
→ → → →asm |
string | Required (exactly 1) |
The pubkey script in decoded form with non-data-pushing opcodes listed |
→ → → →hex |
string (hex) | Required (exactly 1) |
The pubkey script encoded as hex |
→ → → →reqSigs |
number (int) | Optional (0 or 1) |
The number of signatures required; this is always 1 for P2PK, P2PKH, and P2SH (including P2SH multisig because the redeem script is not available in the pubkey script). It may be greater than 1 for bare multisig. This value will not be returned for nulldata or nonstandard script types (see the type key below) |
→ → → →type |
string | Optional (0 or 1) |
The type of script. This will be one of the following: • pubkey for a P2PK script• pubkeyhash for a P2PKH script• scripthash for a P2SH script• multisig for a bare multisig script• nulldata for nulldata scripts• nonstandard for unknown scripts |
→ → → →addresses |
string : array | Optional (0 or 1) |
The P2PKH or P2SH addresses used in this transaction, or the computed P2PKH address of any pubkeys in this transaction. This array will not be returned for nulldata or nonstandard script types |
→ → → → → Address |
string | Required (1 or more) |
A P2PKH or P2SH address |
→blockhash |
string (hex) | Optional (0 or 1) |
If the transaction has been included in a block on the local best block chain, this is the hash of that block encoded as hex in RPC byte order |
→confirmations |
number (int) | Required (exactly 1) |
If the transaction has been included in a block on the local best block chain, this is how many confirmations it has. Otherwise, this is 0 |
→time |
number (int) | Optional (0 or 1) |
If the transaction has been included in a block on the local best block chain, this is the block header time of that block (may be in the future) |
→blocktime |
number (int) | Optional (0 or 1) |
This field is currently identical to the time field described above |
Examples from Bitcoin Core 0.10.0
A transaction in serialized transaction format:
Result (wrapped):
Get the same transaction in JSON:
Result:
See also
Requires wallet support.
The getreceivedbyaccount
RPC returns the total amount received by addresses in a particular account from transactions with the specified number of confirmations. It does not count coinbase transactions.
Parameter #1—the account name
Name | Type | Presence | Description |
---|---|---|---|
Account | string | Required (exactly 1) |
The name of the account containing the addresses to get. For the default account, use an empty string (“”) |
Parameter #2—the minimum number of confirmations
Name | Type | Presence | Description |
---|---|---|---|
Confirmations | number (int) | Optional (0 or 1) |
The minimum number of confirmations an externally-generated transaction must have before it is counted towards the balance. Transactions generated by this node are counted immediately. Typically, externally-generated transactions are payments to this wallet and transactions generated by this node are payments to other wallets. Use 0 to count unconfirmed transactions. Default is 1 |
Result—the number of bitcoins received
Name | Type | Presence | Description |
---|---|---|---|
result |
number (bitcoins) | Required (exactly 1) |
The number of bitcoins received by the account. May be 0 |
Example from Bitcoin Core 0.10.0
Get the bitcoins received by the “doc test” account with six or more confirmations:
Result:
See also
Requires wallet support.
The getreceivedbyaddress
RPC returns the total amount received by the specified address in transactions with the specified number of confirmations. It does not count coinbase transactions.
Parameter #1—the address
Name | Type | Presence | Description |
---|---|---|---|
Address | string | Required (exactly 1) |
The address whose transactions should be tallied |
Parameter #2—the minimum number of confirmations
Name | Type | Presence | Description |
---|---|---|---|
Confirmations | number (int) | Optional (0 or 1) |
The minimum number of confirmations an externally-generated transaction must have before it is counted towards the balance. Transactions generated by this node are counted immediately. Typically, externally-generated transactions are payments to this wallet and transactions generated by this node are payments to other wallets. Use 0 to count unconfirmed transactions. Default is 1 |
Result—the number of bitcoins received
Name | Type | Presence | Description |
---|---|---|---|
result |
number (bitcoins) | Required (exactly 1) |
The number of bitcoins received by the address, excluding coinbase transactions. May be 0 |
Example from Bitcoin Core 0.10.0
Get the bitcoins received for a particular address, only counting transactions with six or more confirmations:
Result:
See also
Requires wallet support.
The gettransaction
RPC gets detailed information about an in-wallet transaction.
Parameter #1—a transaction identifier (TXID)
Name | Type | Presence | Description |
---|---|---|---|
TXID | string (hex) | Required (exactly 1) |
The TXID of the transaction to get details about. The TXID must be encoded as hex in RPC byte order |
Parameter #2—whether to include watch-only addresses in details and calculations
Name | Type | Presence | Description |
---|---|---|---|
Include Watch-Only | bool | Optional (0 or 1) |
Added in Bitcoin Core 0.10.0 If set to true , include watch-only addresses in details and calculations as if they were regular addresses belonging to the wallet. If set to false (the default), treat watch-only addresses as if they didn’t belong to this wallet |
Result—a description of the transaction
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
An object describing how the transaction affects the wallet |
→amount |
number (bitcoins) | Required (exactly 1) |
A positive number of bitcoins if this transaction increased the total wallet balance; a negative number of bitcoins if this transaction decreased the total wallet balance, or 0 if the transaction had no net effect on wallet balance |
→fee |
number (bitcoins) | Optional (0 or 1) |
If an outgoing transaction, this is the fee paid by the transaction reported as negative bitcoins |
→ confirmations |
number (int) | Required (exactly 1) |
The number of confirmations the transaction has received. Will be 0 for unconfirmed and -1 for conflicted |
→ generated |
bool | Optional (0 or 1) |
Set to true if the transaction is a coinbase. Not returned for regular transactions |
→ blockhash |
string (hex) | Optional (0 or 1) |
Only returned for confirmed transactions. The hash of the block on the local best block chain which includes this transaction, encoded as hex in RPC byte order |
→ blockindex |
number (int) | Optional (0 or 1) |
Only returned for confirmed transactions. The block height of the block on the local best block chain which includes this transaction |
→ blocktime |
number (int) | Optional (0 or 1) |
Only returned for confirmed transactions. The block header time (Unix epoch time) of the block on the local best block chain which includes this transaction |
→ txid |
string (hex) | Required (exactly 1) |
The TXID of the transaction, encoded as hex in RPC byte order |
→ walletconflicts |
array | Required (exactly 1) |
An array containing the TXIDs of other transactions that spend the same inputs (UTXOs) as this transaction. Array may be empty |
→ → TXID |
string (hex) | Optional (0 or more) |
The TXID of a conflicting transaction, encoded as hex in RPC byte order |
→ time |
number (int) | Required (exactly 1) |
A Unix epoch time when the transaction was added to the wallet |
→ timerecived |
number (int) | Required (exactly 1) |
A Unix epoch time when the transaction was detected by the local node, or the time of the block on the local best block chain that included the transaction |
→ comment |
string | Optional (0 or 1) |
For transaction originating with this wallet, a locally-stored comment added to the transaction. Only returned if a comment was added |
→ to |
string | Optional (0 or 1) |
For transaction originating with this wallet, a locally-stored comment added to the transaction identifying who the transaction was sent to. Only returned if a comment-to was added |
→details |
array | Required (exactly 1) |
An array containing one object for each input or output in the transaction which affected the wallet |
→ → involvesWatchonly |
bool | Optional (0 or 1) |
Added in Bitcoin Core 0.10.0 Set to true if the input or output involves a watch-only address. Otherwise not returned |
→ →account |
string | Required (exactly 1) |
The account which the payment was credited to or debited from. May be an empty string (“”) for the default account |
→ →address |
string (base58) | Optional (0 or 1) |
If an output, the address paid (may be someone else’s address not belonging to this wallet). If an input, the address paid in the previous output. May be empty if the address is unknown, such as when paying to a non-standard pubkey script |
→ →category |
string | Required (exactly 1) |
Set to one of the following values: • send if sending payment• receive if this wallet received payment in a regular transaction• generate if a matured and spendable coinbase• immature if a coinbase that is not spendable yet• orphan if a coinbase from a block that’s not in the local best block chain |
→ →amount |
number (bitcoins) | Required (exactly 1) |
A negative bitcoin amount if sending payment; a positive bitcoin amount if receiving payment (including coinbases) |
→ →vout |
number (int) | Required (exactly 1) |
Added in Bitcoin Core 0.10.0 For an output, the output index (vout) for this output in this transaction. For an input, the output index for the output being spent in its transaction. Because inputs list the output indexes from previous transactions, more than one entry in the details array may have the same output index |
→ →fee |
number (bitcoins) | Optional (0 or 1) |
If sending payment, the fee paid as a negative bitcoins value. May be 0 . Not returned if receiving payment |
→hex |
string (hex) | Required (exactly 1) |
The transaction in serialized transaction format |
Example from Bitcoin Core 0.10.0
Result:
See also
txindex=1
in your Bitcoin Core startup settings.The gettxout
RPC returns details about a transaction output. Only unspent transaction outputs (UTXOs) are guaranteed to be available.
Parameter #1—the TXID of the output to get
Name | Type | Presence | Description |
---|---|---|---|
TXID | string (hex) | Required (exactly 1) |
The TXID of the transaction containing the output to get, encoded as hex in RPC byte order |
Parameter #2—the output index number (vout) of the output to get
Name | Type | Presence | Description |
---|---|---|---|
Vout | number (int) | Required (exactly 1) |
The output index number (vout) of the output within the transaction; the first output in a transaction is vout 0 |
Parameter #3—whether to display unconfirmed outputs from the memory pool
Name | Type | Presence | Description |
---|---|---|---|
Unconfirmed | bool | Optional (0 or 1) |
Set to true to display unconfirmed outputs from the memory pool; set to false (the default) to only display outputs from confirmed transactions |
Result—a description of the output
Name | Type | Presence | Description |
---|---|---|---|
result |
object/null | Required (exactly 1) |
Information about the output. If output wasn’t found or if an error occurred, this will be JSON null |
→bestblock |
string (hex) | Required (exactly 1) |
The hash of the header of the block on the local best block chain which includes this transaction. The hash will encoded as hex in RPC byte order. If the transaction is not part of a block, the string will be empty |
→confirmations |
number (int) | Required (exactly 1) |
The number of confirmations received for the transaction containing this output or 0 if the transaction hasn’t been confirmed yet |
→value |
number (bitcoins) | Required (exactly 1) |
The amount of bitcoins spent to this output. May be 0 |
→scriptPubKey |
string : object | Optional (0 or 1) |
An object with information about the pubkey script. This may be null if there was no pubkey script |
→ →asm |
string | Required (exactly 1) |
The pubkey script in decoded form with non-data-pushing opcodes listed |
→ →hex |
string (hex) | Required (exactly 1) |
The pubkey script encoded as hex |
→ →reqSigs |
number (int) | Optional (0 or 1) |
The number of signatures required; this is always 1 for P2PK, P2PKH, and P2SH (including P2SH multisig because the redeem script is not available in the pubkey script). It may be greater than 1 for bare multisig. This value will not be returned for nulldata or nonstandard script types (see the type key below) |
→ →type |
string | Optional (0 or 1) |
The type of script. This will be one of the following: • pubkey for a P2PK script• pubkeyhash for a P2PKH script• scripthash for a P2SH script• multisig for a bare multisig script• nulldata for nulldata scripts• nonstandard for unknown scripts |
→ →addresses |
string : array | Optional (0 or 1) |
The P2PKH or P2SH addresses used in this transaction, or the computed P2PKH address of any pubkeys in this transaction. This array will not be returned for nulldata or nonstandard script types |
→ → → Address |
string | Required (1 or more) |
A P2PKH or P2SH address |
→version |
number (int) | Required (exactly 1) |
The transaction version number of the transaction containing the pubkey script |
→coinbase |
bool | Required (exactly 1) |
Set to true if the transaction output belonged to a coinbase transaction; set to false for all other transactions. Coinbase transactions need to have 101 confirmations before their outputs can be spent |
Example from Bitcoin Core 0.10.0
Get the UTXO from the following transaction from the first output index (“0”), searching the memory pool if necessary.
Result:
See also
txindex=1
in your Bitcoin Core startup settings.The gettxoutproof
RPC returns a hex-encoded proof that one or more specified transactions were included in a block.
NOTE: By default this function only works when there is an
unspent output in the UTXO set for this transaction. To make it always work,
you need to maintain a transaction index, using the -txindex
command line option, or
specify the block in which the transaction is included in manually (by block header hash).
Parameter #1—the transaction hashes to prove
Name | Type | Presence | Description |
---|---|---|---|
TXIDs | array | Required (exactly 1) |
A JSON array of txids to filter |
→txid |
string | Required (1 or more) |
TXIDs of the transactions to generate proof for. All transactions must be in the same block |
Parameter #2—the block to look for txids in
Name | Type | Presence | Description |
---|---|---|---|
Header hash | string | Optional (0 or 1) |
If specified, looks for txid in the block with this hash |
Result—serialized, hex-encoded data for the proof
Name | Type | Presence | Description |
---|---|---|---|
result |
string | Required (exactly 1) |
A string that is a serialized, hex-encoded data for the proof |
Example from Bitcoin Core 0.11.0
Get the hex-encoded proof that “txid” was included in block 0000000000000000140e84bf183d8d5207d65fbfae596bdf48f684d13d951847:
Result (wrapped):
See also
merkleblock
message: A description of the
format used for the proof.The gettxoutsetinfo
RPC returns statistics about the confirmed unspent transaction output (UTXO) set. Note that this call may take some time and that it only counts outputs from confirmed transactions—it does not count outputs from the memory pool.
Parameters: none
Result—statistics about the UTXO set
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
Information about the UTXO set |
→height |
number (int) | Required (exactly 1) |
The height of the local best block chain. A new node with only the hardcoded genesis block will have a height of 0 |
→bestblock |
string (hex) | Required (exactly 1) |
The hash of the header of the highest block on the local best block chain, encoded as hex in RPC byte order |
→transactions |
number (int) | Required (exactly 1) |
The number of transactions with unspent outputs |
→txouts |
number (int) | Required (exactly 1) |
The number of unspent transaction outputs |
→bytes_serialized |
number (int) | Required (exactly 1) |
The size of the serialized UTXO set in bytes; not counting overhead, this is the size of the chainstate directory in the Bitcoin Core configuration directory |
→hash_serialized |
string (hex) | Required (exactly 1) |
A SHA256(SHA256()) hash of the serialized UTXO set; useful for comparing two nodes to see if they have the same set (they should, if they always used the same serialization format and currently have the same best block). The hash is encoded as hex in RPC byte order |
→total_amount |
number (bitcoins) | Required (exactly 1) |
The total number of bitcoins in the UTXO set |
Example from Bitcoin Core 0.10.0
Result:
See also
Requires wallet support.
The getunconfirmedbalance
RPC returns the wallet’s total unconfirmed balance.
Parameters: none
Result—the balance of unconfirmed transactions paying this wallet
Name | Type | Presence | Description |
---|---|---|---|
result |
number (bitcoins) | Required (exactly 1) |
The total number of bitcoins paid to this wallet in unconfirmed transactions |
Example from Bitcoin Core 0.10.0
Result (no unconfirmed incoming payments):
See also
Requires wallet support. Added in Bitcoin Core 0.9.2.
The getwalletinfo
RPC provides information about the wallet.
Parameters: none
Result—information about the wallet
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
An object describing the wallet |
→walletversion |
number (int) | Required (exactly 1) |
The version number of the wallet |
→balance |
number (bitcoins) | Required (exactly 1) |
The balance of the wallet. The same as returned by the getbalance RPC with default parameters |
→txcount |
number (int) | Required (exactly 1) |
The total number of transactions in the wallet (both spends and receives) |
→keypoololdest |
number (int) | Required (exactly 1) |
The date as Unix epoch time when the oldest key in the wallet key pool was created; useful for only scanning blocks created since this date for transactions |
→keypoolsize |
number (int) | Required (exactly 1) |
The number of keys in the wallet keypool |
→unlocked_until |
number (int) | Optional (0 or 1) |
Only returned if the wallet was encrypted with the encryptwallet RPC. A Unix epoch date when the wallet will be locked, or 0 if the wallet is currently locked |
Example from Bitcoin Core 0.10.0
Result:
See also
The getwork
RPC was removed in Bitcoin Core 0.10.0.. If you have an older
version of Bitcoin Core, use the help
RPC to get help. For example:
help getwork
See also
The help
RPC lists all available public RPC commands, or gets help for the specified RPC. Commands which are unavailable will not be listed, such as wallet RPCs if wallet support is disabled.
Parameter—the name of the RPC to get help for
Name | Type | Presence | Description |
---|---|---|---|
RPC | string | Optional (0 or 1) |
The name of the RPC to get help for. If omitted, Bitcoin Core 0.9x will display an alphabetical list of commands; Bitcoin Core 0.10.0 will display a categorized list of commands |
Result—a list of RPCs or detailed help for a specific RPC
Name | Type | Presence | Description |
---|---|---|---|
result |
string | Required (exactly 1) |
The help text for the specified RPC or the list of commands. The bitcoin-cli command will parse this text and format it as human-readable text |
Example from Bitcoin Core 0.10.0
Command to get help about the help
RPC:
Result:
See also
Requires wallet support. Added in Bitcoin Core 0.10.0.
The importaddress
RPC adds an address or pubkey script to the wallet without the associated private key, allowing you to watch for transactions affecting that address or pubkey script without being able to spend any of its outputs.
Parameter #1—the address or pubkey script to watch
Name | Type | Presence | Description |
---|---|---|---|
Address or Script | string (base58 or hex) | Required (exactly 1) |
Either a P2PKH or P2SH address encoded in base58check, or a pubkey script encoded as hex |
Parameter #2—The account into which to place the address or pubkey script
Name | Type | Presence | Description |
---|---|---|---|
Account | string | Optional (0 or 1) |
An account name into which the address should be placed. Default is the default account, an empty string(“”) |
Parameter #3—whether to rescan the block chain
Name | Type | Presence | Description |
---|---|---|---|
Rescan | bool | Optional (0 or 1) |
Set to true (the default) to rescan the entire local block database for transactions affecting any address or pubkey script in the wallet (including transaction affecting the newly-added address or pubkey script). Set to false to not rescan the block database (rescanning can be performed at any time by restarting Bitcoin Core with the -rescan command-line argument). Rescanning may take several minutes. Notes: if the address or pubkey script is already in the wallet, the block database will not be rescanned even if this parameter is set |
Result—null
on success
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required (exactly 1) |
If the address or pubkey script is added to the wallet (or is already part of the wallet), JSON null will be returned |
Example from Bitcoin Core 0.10.0
Add an address, rescanning the local block database for any transactions matching it.
Result:
(No output; success.)
Show that the address has been added:
Result:
See also
dumpprivkey
RPC.Requires wallet support. Wallet must be unlocked.
The importprivkey
RPC adds a private key to your wallet. The key should be formatted in the wallet import format created by the dumpprivkey
RPC.
Parameter #1—the private key to import
Name | Type | Presence | Description |
---|---|---|---|
Private Key | string (base58) | Required (exactly 1) |
The private key to import into the wallet encoded in base58check using wallet import format (WIF) |
Parameter #2—the account into which the key should be placed
Name | Type | Presence | Description |
---|---|---|---|
Account | string | Optional (0 or 1) |
The name of an account to which transactions involving the key should be assigned. The default is the default account, an empty string (“”) |
Parameter #3—whether to rescan the block chain
Name | Type | Presence | Description |
---|---|---|---|
Rescan | bool | Optional (0 or 1) |
Set to true (the default) to rescan the entire local block database for transactions affecting any address or pubkey script in the wallet (including transaction affecting the newly-added address for this private key). Set to false to not rescan the block database (rescanning can be performed at any time by restarting Bitcoin Core with the -rescan command-line argument). Rescanning may take several minutes. Notes: if the address for this key is already in the wallet, the block database will not be rescanned even if this parameter is set |
Result—null
on success
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required (exactly 1) |
If the private key is added to the wallet (or is already part of the wallet), JSON null will be returned |
Example from Bitcoin Core 0.10.0
Import the private key for the address mgnucj8nYqdrPFh2JfZSB1NmUThUGnmsqe, giving it a label and scanning the entire block chain:
(Success: no result displayed.)
See also
dumpwallet
RPC). These keys will be added to the keys currently in the wallet. This call may need to rescan all or parts of the block chain for transactions affecting the newly-added keys, which may take several minutes.Requires wallet support. Requires an unlocked wallet or an unencrypted wallet.
The importwallet
RPC imports private keys from a file in wallet dump file format (see the dumpwallet
RPC). These keys will be added to the keys currently in the wallet. This call may need to rescan all or parts of the block chain for transactions affecting the newly-added keys, which may take several minutes.
Parameter #1—the file to import
Name | Type | Presence | Description |
---|---|---|---|
Filename | string | Required (exactly 1) |
The file to import. The path is relative to Bitcoin Core’s working directory |
Result—null
on success
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required (exactly 1) |
If all the keys in the file are added to the wallet (or are already part of the wallet), JSON null will be returned |
Example from Bitcoin Core 0.10.0
Import the file shown in the example subsection of the dumpwallet
RPC.
(Success: no result displayed.)
See also
dumpprivkey
RPC.Requires wallet support. Requires an unlocked wallet or an unencrypted wallet.
The keypoolrefill
RPC fills the cache of unused pre-generated keys (the keypool).
Parameter #1—the new keypool size
Name | Type | Presence | Description |
---|---|---|---|
Key Pool Size | number (int) | Optional (0 or 1) |
The new size of the keypool; if the number of keys in the keypool is less than this number, new keys will be generated. Default is 100 . The value 0 also equals the default. The value specified is for this call only—the default keypool size is not changed |
Result—null
on success
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required (exactly 1) |
If the keypool is successfully filled, JSON null will be returned |
Example from Bitcoin Core 0.10.0
Generate one extra key than the default:
(No result shown: success.)
See also
Requires wallet support.
The listaccounts
RPC lists accounts and their balances.
Parameter #1—the minimum number of confirmations a transaction must have
Name | Type | Presence | Description |
---|---|---|---|
Confirmations | number (int) | Optional (0 or 1) |
The minimum number of confirmations an externally-generated transaction must have before it is counted towards the balance. Transactions generated by this node are counted immediately. Typically, externally-generated transactions are payments to this wallet and transactions generated by this node are payments to other wallets. Use 0 to count unconfirmed transactions. Default is 1 |
Parameter #2—whether to include watch-only addresses in results
Name | Type | Presence | Description |
---|---|---|---|
Include Watch-Only | bool | Optional (0 or 1) |
Added in Bitcoin Core 0.10.0 If set to true , include watch-only addresses in details and calculations as if they were regular addresses belonging to the wallet. If set to false (the default), treat watch-only addresses as if they didn’t belong to this wallet |
Result—a list of accounts and their balances
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
A JSON array containing key/value pairs with account names and values. Must include, at the very least, the default account (“”) |
→ Account : Balance |
string : number (bitcoins) | Required (1 or more) |
The name of an account as a string paired with the balance of the account as a number of bitcoins. The number of bitcoins may be negative if the account has spent more bitcoins than it received. Accounts with zero balances and zero transactions will be displayed |
Example from Bitcoin Core 0.10.0
Display account balances with one confirmation and watch-only addresses included.
Result:
See also
Requires wallet support.
The listaddressgroupings
RPC lists groups of addresses that may have had their common ownership made public by common use as inputs in the same transaction or from being used as change from a previous transaction.
Parameters: none
Result—an array of arrays describing the groupings
Name | Type | Presence | Description |
---|---|---|---|
result |
array | Required (exactly 1) |
An array containing the groupings. May be empty |
→ Groupings |
array | Optional (0 or more) |
An array containing arrays of addresses which can be associated with each other |
→ → Address Details |
array | Required (1 or more) |
An array containing information about a particular address |
→ → → Address |
string (base58) | Required (exactly 1) |
The address in base58check format |
→ → → Balance |
number (bitcoins) | Required (exactly 1) |
The current spendable balance of the address, not counting unconfirmed transactions |
→ → → Account |
string | Optional (0 or 1) |
The account the address belongs to, if any. This field will not be returned for change addresses. The default account is an empty string (“”) |
Example from Bitcoin Core 0.10.0
Result (edited to only the first two results):
See also
Requires wallet support.
The listlockunspent
RPC returns a list of temporarily unspendable (locked) outputs.
Parameters: none
Result—an array of locked outputs
Name | Type | Presence | Description |
---|---|---|---|
result |
array | Required (exactly 1) |
An array containing all locked outputs. May be empty |
→ Output |
object | Optional (1 or more) |
An object describing a particular locked output |
→ →txid |
string (hex) | Required (exactly 1) |
The TXID of the transaction containing the locked output, encoded as hex in RPC byte order |
→ →vout |
number (int) | Required (exactly 1) |
The output index number (vout) of the locked output within the transaction. Output index 0 is the first output within the transaction |
Example from Bitcoin Core 0.10.0
Result:
See also
Requires wallet support.
The listreceivedbyaccount
RPC lists the total number of bitcoins received by each account.
Parameter #1—the minimum number of confirmations a transaction must have to be counted
Name | Type | Presence | Description |
---|---|---|---|
Confirmations | number (int) | Optional (0 or 1) |
The minimum number of confirmations an externally-generated transaction must have before it is counted towards the balance. Transactions generated by this node are counted immediately. Typically, externally-generated transactions are payments to this wallet and transactions generated by this node are payments to other wallets. Use 0 to count unconfirmed transactions. Default is 1 |
Parameter #2—whether to include empty accounts
Name | Type | Presence | Description |
---|---|---|---|
Include Empty | bool | Optional (0 or 1) |
Set to true to display accounts which have never received a payment. Set to false (the default) to only include accounts which have received a payment. Any account which has received a payment will be displayed even if its current balance is 0 |
Parameter #3—whether to include watch-only addresses in results
Name | Type | Presence | Description |
---|---|---|---|
Include Watch-Only | bool | Optional (0 or 1) |
Added in Bitcoin Core 0.10.0 If set to true , include watch-only addresses in details and calculations as if they were regular addresses belonging to the wallet. If set to false (the default), treat watch-only addresses as if they didn’t belong to this wallet |
Result—account names, balances, and minimum confirmations
Name | Type | Presence | Description |
---|---|---|---|
result |
array | Required (exactly 1) |
An array containing objects each describing an account. At the very least, the default account (“”) will be included |
→ Account |
object | Required (1 or more) |
An object describing an account |
→ →involvesWatchonly |
bool | Optional (0 or 1) |
Added in Bitcoin Core 0.10.0 Set to true if the balance of this account includes a watch-only address which has received a spendable payment (that is, a payment with at least the specified number of confirmations and which is not an immature coinbase). Otherwise not returned |
→ →account |
string | Required (exactly 1) |
The name of the account |
→ →amount |
number (bitcoins) | Required (exactly 1) |
The total amount received by this account in bitcoins |
→ →confirmations |
number (int) | Required (exactly 1) |
The number of confirmations received by the last transaction received by this account. May be 0 |
Example from Bitcoin Core 0.10.0
Get the balances for all non-empty accounts, including only transactions which have been confirmed at least six times:
Result (edited to only show the first two results):
See also
Requires wallet support.
The listreceivedbyaddress
RPC lists the total number of bitcoins received by each address.
Parameter #1—the minimum number of confirmations a transaction must have to be counted
Name | Type | Presence | Description |
---|---|---|---|
Confirmations | number (int) | Optional (0 or 1) |
The minimum number of confirmations an externally-generated transaction must have before it is counted towards the balance. Transactions generated by this node are counted immediately. Typically, externally-generated transactions are payments to this wallet and transactions generated by this node are payments to other wallets. Use 0 to count unconfirmed transactions. Default is 1 |
Parameter #2—whether to include empty accounts
Name | Type | Presence | Description |
---|---|---|---|
Include Empty | bool | Optional (0 or 1) |
Set to true to display accounts which have never received a payment. Set to false (the default) to only include accounts which have received a payment. Any account which has received a payment will be displayed even if its current balance is 0 |
Parameter #3—whether to include watch-only addresses in results
Name | Type | Presence | Description |
---|---|---|---|
Include Watch-Only | bool | Optional (0 or 1) |
Added in Bitcoin Core 0.10.0 If set to true , include watch-only addresses in details and calculations as if they were regular addresses belonging to the wallet. If set to false (the default), treat watch-only addresses as if they didn’t belong to this wallet |
Result—addresses, account names, balances, and minimum confirmations
Name | Type | Presence | Description |
---|---|---|---|
result |
array | Required (exactly 1) |
An array containing objects each describing a particular address |
→ Address |
object | Optional (0 or more) |
An object describing an address |
→ →involvesWatchonly |
bool | Optional (0 or 1) |
Added in Bitcoin Core 0.10.0 Set to true if this address is a watch-only address which has received a spendable payment (that is, a payment with at least the specified number of confirmations and which is not an immature coinbase). Otherwise not returned |
→ →address |
string (base58) | Required (exactly 1) |
The address being described encoded in base58check |
→ →account |
string | Required (exactly 1) |
The account the address belongs to; may be the default account, an empty string (“”) |
→ →amount |
number (bitcoins) | Required (exactly 1) |
The total amount the address has received in bitcoins |
→ →confirmations |
number (int) | Required (exactly 1) |
The number of confirmations of the latest transaction to the address. May be 0 for unconfirmed |
→ → TXIDs |
array | Required (exactly 1) |
An array of TXIDs belonging to transactions that pay the address |
→ → → TXID |
string | Optional (0 or more) |
The TXID of a transaction paying the address, encoded as hex in RPC byte order |
Example from Bitcoin Core 0.10.0
List addresses with balances confirmed by at least six blocks, including watch-only addresses:
Result (edit to show only two entries):
See also
Requires wallet support.
The listsinceblock
RPC gets all transactions affecting the wallet which have occurred since a particular block, plus the header hash of a block at a particular depth.
Parameter #1—a block header hash
Name | Type | Presence | Description |
---|---|---|---|
Header Hash | string (hex) | Optional (0 or 1) |
The hash of a block header encoded as hex in RPC byte order. All transactions affecting the wallet which are not in that block or any earlier block will be returned, including unconfirmed transactions. Default is the hash of the genesis block, so all transactions affecting the wallet are returned by default |
Parameter #2—the target confirmations for the lastblock field
Name | Type | Presence | Description |
---|---|---|---|
Target Confirmations | number (int) | Optional (0 or 1) |
Sets the lastblock field of the results to the header hash of a block with this many confirmations. This does not affect which transactions are returned. Default is 1 , so the hash of the most recent block on the local best block chain is returned |
Parameter #3—whether to include watch-only addresses in details and calculations
Name | Type | Presence | Description |
---|---|---|---|
Include Watch-Only | bool | Optional (0 or 1) |
Added in Bitcoin Core 0.10.0 If set to true , include watch-only addresses in details and calculations as if they were regular addresses belonging to the wallet. If set to false (the default), treat watch-only addresses as if they didn’t belong to this wallet |
Result
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
An object containing an array of transactions and the lastblock field |
→transactions |
array | Required (exactly 1) |
An array of objects each describing a particular payment to or from this wallet. The objects in this array do not describe an actual transactions, so more than one object in this array may come from the same transaction. This array may be empty |
→ → Payment |
object | Optional (0 or more) |
An payment which did not appear in the specified block or an earlier block |
→ → → involvesWatchonly |
bool | Optional (0 or 1) |
Added in Bitcoin Core 0.10.0 Set to true if the payment involves a watch-only address. Otherwise not returned |
→ → → account |
string | Required (exactly 1) |
The account which the payment was credited to or debited from. May be an empty string (“”) for the default account |
→ → → address |
string (base58) | Optional (0 or 1) |
The address paid in this payment, which may be someone else’s address not belonging to this wallet. May be empty if the address is unknown, such as when paying to a non-standard pubkey script |
→ → → category |
string | Required (exactly 1) |
Set to one of the following values: • send if sending payment• receive if this wallet received payment in a regular transaction• generate if a matured and spendable coinbase• immature if a coinbase that is not spendable yet• orphan if a coinbase from a block that’s not in the local best block chain |
→ → → amount |
number (bitcoins) | Required (exactly 1) |
A negative bitcoin amount if sending payment; a positive bitcoin amount if receiving payment (including coinbases) |
→ → → vout |
number (int) | Required (exactly 1) |
Added in Bitcoin Core 0.10.0 For an output, the output index (vout) for this output in this transaction. For an input, the output index for the output being spent in its transaction. Because inputs list the output indexes from previous transactions, more than one entry in the details array may have the same output index |
→ → → fee |
number (bitcoins) | Optional (0 or 1) |
If sending payment, the fee paid as a negative bitcoins value. May be 0 . Not returned if receiving payment |
→ → → confirmations |
number (int) | Required (exactly 1) |
The number of confirmations the transaction has received. Will be 0 for unconfirmed and -1 for conflicted |
→ → → generated |
bool | Optional (0 or 1) |
Set to true if the transaction is a coinbase. Not returned for regular transactions |
→ → → blockhash |
string (hex) | Optional (0 or 1) |
Only returned for confirmed transactions. The hash of the block on the local best block chain which includes this transaction, encoded as hex in RPC byte order |
→ → → blockindex |
number (int) | Optional (0 or 1) |
Only returned for confirmed transactions. The block height of the block on the local best block chain which includes this transaction |
→ → → blocktime |
number (int) | Optional (0 or 1) |
Only returned for confirmed transactions. The block header time (Unix epoch time) of the block on the local best block chain which includes this transaction |
→ → → txid |
string (hex) | Required (exactly 1) |
The TXID of the transaction, encoded as hex in RPC byte order |
→ → → walletconflicts |
array | Required (exactly 1) |
An array containing the TXIDs of other transactions that spend the same inputs (UTXOs) as this transaction. Array may be empty |
→ → → → TXID |
string (hex) | Optional (0 or more) |
The TXID of a conflicting transaction, encoded as hex in RPC byte order |
→ → → time |
number (int) | Required (exactly 1) |
A Unix epoch time when the transaction was added to the wallet |
→ → → timerecived |
number (int) | Required (exactly 1) |
A Unix epoch time when the transaction was detected by the local node, or the time of the block on the local best block chain that included the transaction |
→ → → comment |
string | Optional (0 or 1) |
For transaction originating with this wallet, a locally-stored comment added to the transaction. Only returned if a comment was added |
→ → → to |
string | Optional (0 or 1) |
For transaction originating with this wallet, a locally-stored comment added to the transaction identifying who the transaction was sent to. Only returned if a comment-to was added |
→lastblock |
string (hex) | Required (exactly 1) |
The header hash of the block with the number of confirmations specified in the target confirmations parameter, encoded as hex in RPC byte order |
Example from Bitcoin Core 0.10.0
Get all transactions since a particular block (including watch-only transactions) and the header hash of the sixth most recent block.
Result (edited to show only two payments):
See also
Requires wallet support.
The listtransactions
RPC returns the most recent transactions that affect the wallet.
Parameter #1—an account name to get transactions from
Name | Type | Presence | Description |
---|---|---|---|
Account | string | Optional (0 or 1) |
The name of an account to get transactinos from. Use an empty string (“”) to get transactions for the default account. Default is * to get transactions for all accounts |
Parameter #2—the number of transactions to get
Name | Type | Presence | Description |
---|---|---|---|
Count | number (int) | Optional (0 or 1) |
The number of the most recent transactions to list. Default is 10 |
Parameter #3—the number of transactions to skip
Name | Type | Presence | Description |
---|---|---|---|
Skip | number (int) | Optional (0 or 1) |
The number of the most recent transactions which should not be returned. Allows for pagination of results. Default is 0 |
Parameter #4—whether to include watch-only addresses in details and calculations
Name | Type | Presence | Description |
---|---|---|---|
Include Watch-Only | bool | Optional (0 or 1) |
Added in Bitcoin Core 0.10.0 If set to true , include watch-only addresses in details and calculations as if they were regular addresses belonging to the wallet. If set to false (the default), treat watch-only addresses as if they didn’t belong to this wallet |
Result—payment details
Name | Type | Presence | Description |
---|---|---|---|
result |
array | Required (exactly 1) |
An array containing objects, with each object describing a payment or internal accounting entry (not a transaction). More than one object in this array may come from a single transaction. Array may be empty |
→ Payment |
object | Optional (0 or more) |
A payment or internal accounting entry |
→ →account |
string | Required (exactly 1) |
The account which the payment was credited to or debited from. May be an empty string (“”) for the default account |
→ →address |
string (base58) | Optional (0 or 1) |
The address paid in this payment, which may be someone else’s address not belonging to this wallet. May be empty if the address is unknown, such as when paying to a non-standard pubkey script or if this is in the move category |
→ →category |
string | Required (exactly 1) |
Set to one of the following values: • send if sending payment• receive if this wallet received payment in a regular transaction• generate if a matured and spendable coinbase• immature if a coinbase that is not spendable yet• orphan if a coinbase from a block that’s not in the local best block chain• move if an off-block-chain move made with the move RPC |
→ →amount |
number (bitcoins) | Required (exactly 1) |
A negative bitcoin amount if sending payment; a positive bitcoin amount if receiving payment (including coinbases) |
→ →vout |
number (int) | Optional (0 or 1) |
Added in Bitcoin Core 0.10.0 For an output, the output index (vout) for this output in this transaction. For an input, the output index for the output being spent in its transaction. Because inputs list the output indexes from previous transactions, more than one entry in the details array may have the same output index. Not returned for move category payments |
→ →fee |
number (bitcoins) | Optional (0 or 1) |
If sending payment, the fee paid as a negative bitcoins value. May be 0 . Not returned if receiving payment or for move category payments |
→ →confirmations |
number (int) | Optional (0 or 1) |
The number of confirmations the transaction has received. Will be 0 for unconfirmed and -1 for conflicted. Not returned for move category payments |
→ →generated |
bool | Optional (0 or 1) |
Set to true if the transaction is a coinbase. Not returned for regular transactions or move category payments |
→ →blockhash |
string (hex) | Optional (0 or 1) |
Only returned for confirmed transactions. The hash of the block on the local best block chain which includes this transaction, encoded as hex in RPC byte order |
→ →blockindex |
number (int) | Optional (0 or 1) |
Only returned for confirmed transactions. The block height of the block on the local best block chain which includes this transaction |
→ →blocktime |
number (int) | Optional (0 or 1) |
Only returned for confirmed transactions. The block header time (Unix epoch time) of the block on the local best block chain which includes this transaction |
→ →txid |
string (hex) | Optional (0 or 1) |
The TXID of the transaction, encoded as hex in RPC byte order. Not returned for move category payments |
→ →walletconflicts |
array | Optional (0 or 1) |
An array containing the TXIDs of other transactions that spend the same inputs (UTXOs) as this transaction. Array may be empty. Not returned for move category payments |
→ → → TXID |
string (hex) | Optional (0 or more) |
The TXID of a conflicting transaction, encoded as hex in RPC byte order |
→ →time |
number (int) | Required (exactly 1) |
A Unix epoch time when the transaction was added to the wallet |
→ →timereceived |
number (int) | Optional (0 or 1) |
A Unix epoch time when the transaction was detected by the local node, or the time of the block on the local best block chain that included the transaction. Not returned for move category payments |
→ →comment |
string | Optional (0 or 1) |
For transaction originating with this wallet, a locally-stored comment added to the transaction. Only returned in regular payments if a comment was added. Always returned in move category payments. May be an empty string |
→ →to |
string | Optional (0 or 1) |
For transaction originating with this wallet, a locally-stored comment added to the transaction identifying who the transaction was sent to. Only returned if a comment-to was added. Never returned by move category payments. May be an empty string |
→ →otheraccount |
string | Optional (0 or 1) |
Only returned by move category payments. This is the account the bitcoins were moved from or moved to, as indicated by a negative or positive amount field in this payment |
Example from Bitcoin Core 0.10.0
List the most recent transaction from the account “someone else’s address2” including watch-only addresses.
Result:
See also
Requires wallet support.
The listunspent
RPC returns an array of unspent transaction outputs belonging to this wallet. Note: as of Bitcoin
Core 0.10.0, outputs affecting watch-only addresses will be returned; see
the spendable field in the results described below.
Parameter #1—the minimum number of confirmations an output must have
Name | Type | Presence | Description |
---|---|---|---|
Minimum Confirmations | number (int) | Optional (0 or 1) |
The minimum number of confirmations the transaction containing an output must have in order to be returned. Use 0 to return outputs from unconfirmed transactions. Default is 1 |
Parameter #2—the maximum number of confirmations an output may have
Name | Type | Presence | Description |
---|---|---|---|
Maximum Confirmations | number (int) | Optional (0 or 1) |
The maximum number of confirmations the transaction containing an output may have in order to be returned. Default is 9999999 (~10 million) |
Parameter #3—the addresses an output must pay
Name | Type | Presence | Description |
---|---|---|---|
Addresses | array | Optional (0 or 1) |
If present, only outputs which pay an address in this array will be returned |
→ Address |
string (base58) | Required (1 or more) |
A P2PKH or P2SH address |
Result—the list of unspent outputs
Name | Type | Presence | Description |
---|---|---|---|
result |
array | Required (exactly 1) |
An array of objects each describing an unspent output. May be empty |
→ Unspent Output |
object | Optional (0 or more) |
An object describing a particular unspent output belonging to this wallet |
→ →txid |
string (hex) | Required (exactly 1) |
The TXID of the transaction containing the output, encoded as hex in RPC byte order |
→ →vout |
number (int) | Required (exactly 1) |
The output index number (vout) of the output within its containing transaction |
→ →address |
string (base58) | Optional (0 or 1) |
The P2PKH or P2SH address the output paid. Only returned for P2PKH or P2SH output scripts |
→ →account |
string | Optional (0 or 1) |
If the address returned belongs to an account, this is the account. Otherwise not returned |
→ →scriptPubKey |
string (hex) | Required (exactly 1) |
The output script paid, encoded as hex |
→ →redeemScript |
string (hex) | Optional (0 or 1) |
If the output is a P2SH whose script belongs to this wallet, this is the redeem script |
→ →amount |
number (int) | Required (exactly 1) |
The amount paid to the output in bitcoins |
→ →confirmations |
number (int) | Required (exactly 1) |
The number of confirmations received for the transaction containing this output |
→ →spendable |
bool | Required (exactly 1) |
Added in Bitcoin Core 0.10.0 Set to true if the private key or keys needed to spend this output are part of the wallet. Set to false if not (such as for watch-only addresses) |
Example from Bitcoin Core 0.10.0
Get all outputs confirmed at least 6 times for a particular address:
Result:
See also
Requires wallet support.
The lockunspent
RPC temporarily locks or unlocks specified transaction outputs. A locked transaction output will not be chosen by automatic coin selection when spending bitcoins. Locks are stored in memory only, so nodes start with zero locked outputs and the locked output list is always cleared when a node stops or fails.
Parameter #1—whether to lock or unlock the outputs
Name | Type | Presence | Description |
---|---|---|---|
Unlock | bool | Required (exactly 1) |
Set to false to lock the outputs specified in the following parameter. Set to true to unlock the outputs specified. If this is the only argument specified and it is set to true , all outputs will be unlocked; if it is the only argument and is set to false , there will be no change |
Parameter #2—the outputs to lock or unlock
Name | Type | Presence | Description |
---|---|---|---|
Outputs | array | Optional (0 or 1) |
An array of outputs to lock or unlock |
→ Output |
object | Required (1 or more) |
An object describing a particular output |
→ →txid |
string | Required (exactly 1) |
The TXID of the transaction containing the output to lock or unlock, encoded as hex in internal byte order |
→ →vout |
number (int) | Required (exactly 1) |
The output index number (vout) of the output to lock or unlock. The first output in a transaction has an index of 0 |
Result—true
if successful
Name | Type | Presence | Description |
---|---|---|---|
result |
bool | Required (exactly 1) |
Set to true if the outputs were successfully locked or unlocked. If the outputs were already locked or unlocked, it will also return true |
Example from Bitcoin Core 0.10.0
Lock two outputs:
Result:
Verify the outputs have been locked:
Result
Unlock one of the above outputs:
Result:
Verify the output has been unlocked:
Result:
See also
Requires wallet support.
The move
RPC moves a specified amount from one account in your wallet to another using an off-block-chain transaction.
Warning: it’s allowed to move more funds than are in an account, giving the sending account a negative balance and giving the receiving account a balance that may exceed the number of bitcoins in the wallet (or the number of bitcoins in existence).
Parameter #1—from account
Name | Type | Presence | Description |
---|---|---|---|
From Account | string | Required (exactly 1) |
The name of the account to move the funds from |
Parameter #2—to account
Name | Type | Presence | Description |
---|---|---|---|
To Account | string | Required (exactly 1) |
The name of the account to move the funds to |
Parameter #3—amount to move
Name | Type | Presence | Description |
---|---|---|---|
Amount | number (bitcoins) | Required (exactly 1) |
The amount of bitcoins to move |
Parameter #4—an unused parameter
Name | Type | Presence | Description |
---|---|---|---|
Unused | number (int) | Optional (0 or 1) |
This parameter is no longer used. If parameter #5 needs to be specified, this can be any integer |
Parameter #5—a comment
Name | Type | Presence | Description |
---|---|---|---|
Comment | string | Optional (0 or 1) |
A comment to assign to this move payment |
Result—true
on success
Name | Type | Presence | Description |
---|---|---|---|
result |
bool | Required (exactly 1) |
Set to true if the move was successful |
Example from Bitcoin Core 0.10.0
Move 0.1 bitcoins from “doc test” to “test1”, giving the transaction the comment “Example move”:
Result:
See also
The ping
RPC sends a P2P ping message to all connected nodes to measure ping time. Results are provided by the getpeerinfo
RPC pingtime and pingwait fields as decimal seconds. The P2P ping
message is handled in a queue with all other commands, so it measures processing backlog, not just network ping.
Parameters: none
Result—null
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required | Always JSON null |
Example from Bitcoin Core 0.10.0
(Success: no result printed.)
Get the results using the getpeerinfo
RPC:
Results:
See also
Added in Bitcoin Core 0.10.0.
The prioritisetransaction
RPC adds virtual priority or fee to a transaction, allowing it to be accepted into blocks mined by this node (or miners which use this node) with a lower priority or fee. (It can also remove virtual priority or fee, requiring the transaction have a higher priority or fee to be accepted into a locally-mined block.)
Parameter #1—the TXID of the transaction to modify
Name | Type | Presence | Description |
---|---|---|---|
TXID | string | Required (exactly 1) |
The TXID of the transaction whose virtual priority or fee you want to modify, encoded as hex in RPC byte order |
Parameter #2—the change to make to the virtual priority
Name | Type | Presence | Description |
---|---|---|---|
Priority | number (real) | Required (exactly 1) |
If positive, the priority to add to the transaction in addition to its computed priority; if negative, the priority to subtract from the transaction’s computed priory. Computed priority is the age of each input in days since it was added to the block chain as an output (coinage) times the value of the input in satoshis (value) divided by the size of the serialized transaction (size), which is coinage * value / size |
Parameter #3—the change to make to the virtual fee
Name | Type | Presence | Description |
---|---|---|---|
Fee | number (int) | Required (exactly 1) |
Warning: this value is in satoshis, not bitcoins If positive, the virtual fee to add to the actual fee paid by the transaction; if negative, the virtual fee to subtract from the actual fee paid by the transaction. No change is made to the actual fee paid by the transaction |
Result—true
if the priority is changed
Name | Type | Presence | Description |
---|---|---|---|
result |
bool (true only) | Required (exactly 1) |
Always set to true if all three parameters are provided. Will not return an error if the TXID is not in the memory pool. If fewer or more than three arguments are provided, or if something goes wrong, will be set to null |
Example from Bitcoin Core 0.10.0
Result:
See also
Requires wallet support. Requires an unlocked wallet or an unencrypted wallet.
The sendfrom
RPC spends an amount from a local account to a bitcoin address.
Parameter #1—from account
Name | Type | Presence | Description |
---|---|---|---|
From Account | string | Required (exactly 1) |
The name of the account from which the bitcoins should be spent. Use an empty string (“”) for the default account |
Parameter #2—to address
Name | Type | Presence | Description |
---|---|---|---|
To Address | string | Required (exactly 1) |
A P2PKH or P2SH address to which the bitcoins should be sent |
Parameter #3—amount to spend
Name | Type | Presence | Description |
---|---|---|---|
Amount | number (bitcoins) | Required (exactly 1) |
The amount to spend in bitcoins. Bitcoin Core will ensure the account has sufficient bitcoins to pay this amount (but the transaction fee paid is not included in the calculation, so an account can spend a total of its balance plus the transaction fee) |
Parameter #4—minimum confirmations
Name | Type | Presence | Description |
---|---|---|---|
Confirmations | number (int) | Optional (0 or 1) |
The minimum number of confirmations an incoming transaction must have for its outputs to be credited to this account’s balance. Outgoing transactions are always counted, as are move transactions made with the move RPC. If an account doesn’t have a balance high enough to pay for this transaction, the payment will be rejected. Use 0 to spend unconfirmed incoming payments. Default is 1 |
Warning: if account1 receives an unconfirmed payment and transfers
it to account2 with the move
RPC, account2 will be able to spend those
bitcoins even if this parameter is set to 1
or higher.
Parameter #5—a comment
Name | Type | Presence | Description |
---|---|---|---|
Comment | string | Optional (0 or 1) |
A locally-stored (not broadcast) comment assigned to this transaction. Default is no comment |
Parameter #6—a comment about who the payment was sent to
Name | Type | Presence | Description |
---|---|---|---|
Comment To | string | Optional (0 or 1) |
A locally-stored (not broadcast) comment assigned to this transaction. Meant to be used for describing who the payment was sent to. Default is no comment |
Result—a TXID of the sent transaction
Name | Type | Presence | Description |
---|---|---|---|
result |
string | Required (exactly 1) |
The TXID of the sent transaction, encoded as hex in RPC byte order |
Example from Bitcoin Core 0.10.0
Spend 0.1 bitcoins from the account “test” to the address indicated below using only UTXOs with at least six confirmations, giving the transaction the comment “Example spend” and labeling the spender “Example.com”:
Result:
See also
Requires wallet support. Requires an unlocked wallet or an unencrypted wallet.
The sendmany
RPC creates and broadcasts a transaction which sends outputs to multiple addresses.
Parameter #1—from account
Name | Type | Presence | Description |
---|---|---|---|
From Account | string | Required (exactly 1) |
The name of the account from which the bitcoins should be spent. Use an empty string (“”) for the default account. Bitcoin Core will ensure the account has sufficient bitcoins to pay the total amount in the outputs field described below (but the transaction fee paid is not included in the calculation, so an account can spend a total of its balance plus the transaction fee) |
Parameter #2—the addresses and amounts to pay
Name | Type | Presence | Description |
---|---|---|---|
Outputs | object | Required (exactly 1) |
An object containing key/value pairs corresponding to the addresses and amounts to pay |
→ Address/Amount |
string (base58) : number (bitcoins) | Required (1 or more) |
A key/value pair with a base58check-encoded string containing the P2PKH or P2SH address to pay as the key, and an amount of bitcoins to pay as the value |
Parameter #3—minimum confirmations
Name | Type | Presence | Description |
---|---|---|---|
Confirmations | number (int) | Optional (0 or 1) |
The minimum number of confirmations an incoming transaction must have for its outputs to be credited to this account’s balance. Outgoing transactions are always counted, as are move transactions made with the move RPC. If an account doesn’t have a balance high enough to pay for this transaction, the payment will be rejected. Use 0 to spend unconfirmed incoming payments. Default is 1 |
Warning: if account1 receives an unconfirmed payment and transfers
it to account2 with the move
RPC, account2 will be able to spend those
bitcoins even if this parameter is set to 1
or higher.
Parameter #4—a comment
Name | Type | Presence | Description |
---|---|---|---|
Comment | string | Optional (0 or 1) |
A locally-stored (not broadcast) comment assigned to this transaction. Default is no comment |
Result—a TXID of the sent transaction
Name | Type | Presence | Description |
---|---|---|---|
result |
string | Required (exactly 1) |
The TXID of the sent transaction, encoded as hex in RPC byte order |
Example from Bitcoin Core 0.10.0
From the account test1, send 0.1 bitcoins to the first address and 0.2 bitcoins to the second address, with a comment of “Example Transaction”.
Result:
See also
The sendrawtransaction
RPC validates a transaction and broadcasts it to the peer-to-peer network.
Parameter #1—a serialized transaction to broadcast
Name | Type | Presence | Description |
---|---|---|---|
Transaction | string (hex) | Required (exactly 1) |
The serialized transaction to broadcast encoded as hex |
*Parameter #2–whether to allow high fees**
Name | Type | Presence | Description |
---|---|---|---|
Allow High Fees | bool | Optional (0 or 1) |
Set to true to allow the transaction to pay a high transaction fee. Set to false (the default) to prevent Bitcoin Core from broadcasting the transaction if it includes a high fee. Transaction fees are the sum of the inputs minus the sum of the outputs, so this high fees check helps ensures user including a change address to return most of the difference back to themselves |
Result—a TXID or error message
Name | Type | Presence | Description |
---|---|---|---|
result |
null/string (hex) | Required (exactly 1) |
If the transaction was accepted by the node for broadcast, this will be the TXID of the transaction encoded as hex in RPC byte order. If the transaction was rejected by the node, this will set to null , the JSON-RPC error field will be set to a code, and the JSON-RPC message field may contain an informative error message |
Examples from Bitcoin Core 0.10.0
Broadcast a signed transaction:
Result:
See also
Requires wallet support. Requires an unlocked wallet or an unencrypted wallet.
The sendtoaddress
RPC spends an amount to a given address.
Parameter #1—to address
Name | Type | Presence | Description |
---|---|---|---|
To Address | string | Required (exactly 1) |
A P2PKH or P2SH address to which the bitcoins should be sent |
Parameter #2—amount to spend
Name | Type | Presence | Description |
---|---|---|---|
Amount | number (bitcoins) | Required (exactly 1) |
The amount to spent in bitcoins |
Parameter #3—a comment
Name | Type | Presence | Description |
---|---|---|---|
Comment | string | Optional (0 or 1) |
A locally-stored (not broadcast) comment assigned to this transaction. Default is no comment |
Parameter #4—a comment about who the payment was sent to
Name | Type | Presence | Description |
---|---|---|---|
Comment To | string | Optional (0 or 1) |
A locally-stored (not broadcast) comment assigned to this transaction. Meant to be used for describing who the payment was sent to. Default is no comment |
Result—a TXID of the sent transaction
Name | Type | Presence | Description |
---|---|---|---|
result |
string | Required (exactly 1) |
The TXID of the sent transaction, encoded as hex in RPC byte order |
Example from Bitcoin Core 0.10.0
Spend 0.1 bitcoins to the address below with the comment “sendtoadress example” and the comment-to “Nemo From Example.com”:
Result:
See also
Requires wallet support.
The setaccount
RPC puts the specified address in the given account.
Parameter #1—a bitcoin address
Name | Type | Presence | Description |
---|---|---|---|
Address | string (base58) | Required (exactly 1) |
The P2PKH or P2SH address to put in the account. Must already belong to the wallet |
Parameter #2—an account
Name | Type | Presence | Description |
---|---|---|---|
Account | string | Required (exactly 1) |
The name of the account in which the address should be placed. May be the default account, an empty string (“”) |
Result—null
if successful
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required (exactly 1) |
Set to JSON null if the address was successfully placed in the account |
Example from Bitcoin Core 0.10.0
Put the address indicated below in the “doc test” account.
(Success: no result displayed.)
See also
Requires wallet support.
The setgenerate
RPC enables or disables hashing to attempt to find the next block.
Parameter #1—whether to enable or disable generation
Name | Type | Presence | Description |
---|---|---|---|
Enable/Disable | bool | Required (exactly 1) |
Set to true to enable generation; set to false to disable generation |
Parameter #2 (regular)—the number of processors to use
Name | Type | Presence | Description |
---|---|---|---|
Processors | number (int) | Optional (0 or 1) |
The number of processors to use. Defaults to 1 . Set to -1 to use all processors |
Parameter #2 (regtest)—the number of blocks to generate
Note: setgenerate in regtest mode has been removed in Bitcoin Core
master. See the generate
RPC for the replacement.
Name | Type | Presence | Description |
---|---|---|---|
Blocks | number (int) | Optional (0 or 1) |
In regtest mode, set to the number of blocks to generate. Defaults to 1 |
Result (regular)—generating is enabled
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required (exactly 1) |
Always JSON null |
Result (regtest)—the generated block header hashes
Name | Type | Presence | Description |
---|---|---|---|
result |
array/null | Required (exactly 1) |
An array containing the block header hashes of the generated blocks, or JSON null if no blocks were generated |
→ Header Hashes |
string (hex) | Required (1 or more) |
The hashes of the headers of the blocks generated in regtest mode, as hex in RPC byte order |
Examples from Bitcoin Core 0.10.0
Enable generation using two logical processors (on this machine, two cores of one physical processor):
(Success: no result displayed. Process manager shows 200% CPU usage.)
Using regtest mode, generate 2 blocks:
Result:
See also
Requires wallet support.
The settxfee
RPC sets the transaction fee per kilobyte paid by transactions created by this wallet.
Parameter #1—the transaction fee amount per kilobyte
Name | Type | Presence | Description |
---|---|---|---|
Transaction Fee Per Kilobyte | number (bitcoins) | Required (exactly 1) |
The transaction fee to pay, in bitcoins, for each kilobyte of transaction data. Be careful setting the fee too low—your transactions may not be relayed or included in blocks |
Result: true
on success
Name | Type | Presence | Description |
---|---|---|---|
result |
bool (true) | Required (exactly 1) |
Set to true if the fee was successfully set |
Example from Bitcoin Core 0.10.0
Set the transaction fee per kilobyte to 100,000 satoshis.
Result:
See also
Requires wallet support. Requires an unlocked wallet or an unencrypted wallet.
The signmessage
RPC signs a message with the private key of an address.
Parameter #1—the address corresponding to the private key to sign with
Name | Type | Presence | Description |
---|---|---|---|
Address | string (base58) | Required (exactly 1) |
A P2PKH address whose private key belongs to this wallet |
Parameter #2—the message to sign
Name | Type | Presence | Description |
---|---|---|---|
Message | string | Required (exactly 1) |
The message to sign |
Result—the message signature
Name | Type | Presence | Description |
---|---|---|---|
result |
string (base64) | Required (exactly 1) |
The signature of the message, encoded in base64. Note that Bitcoin Core before 0.10.0 creates signatures with random k values, so each time you sign the same message, it will create a different signature |
Example from Bitcoin Core 0.10.0
Sign a the message “Hello, World!” using the following address:
Result:
See also
The signrawtransaction
RPC signs a transaction in the serialized transaction format using private keys stored in the wallet or provided in the call.
Parameter #1—the transaction to sign
Name | Type | Presence | Description |
---|---|---|---|
Transaction | string (hex | Required (exactly 1) |
The transaction to sign as a serialized transaction |
Parameter #2—unspent transaction output details
Name | Type | Presence | Description |
---|---|---|---|
Dependencies | array | Optional (0 or 1) |
The previous outputs being spent by this transaction |
→ Output |
object | Optional (0 or more) |
An output being spent |
→ →txid |
string (hex) | Required (exactly 1) |
The TXID of the transaction the output appeared in. The TXID must be encoded in hex in RPC byte order |
→ →vout |
number (int) | Required (exactly 1) |
The index number of the output (vout) as it appeared in its transaction, with the first output being 0 |
→ →scriptPubKey |
string (hex) | Required (exactly 1) |
The output’s pubkey script encoded as hex |
→ →redeemScript |
string (hex) | Optional (0 or 1) |
If the pubkey script was a script hash, this must be the corresponding redeem script |
Parameter #3—private keys for signing
Name | Type | Presence | Description |
---|---|---|---|
Private Keys | array | Optional (0 or 1) |
An array holding private keys. If any keys are provided, only they will be used to sign the transaction (even if the wallet has other matching keys). If this array is empty or not used, and wallet support is enabled, keys from the wallet will be used |
→ Key |
string (base58) | Required (1 or more) |
A private key in base58check format to use to create a signature for this transaction |
Parameter #4—signature hash type
Name | Type | Presence | Description |
---|---|---|---|
SigHash | string | Optional (0 or 1) |
The type of signature hash to use for all of the signatures performed. (You must use separate calls to the signrawtransaction RPC if you want to use different signature hash types for different signatures. The allowed values are: ALL , NONE , SINGLE , ALL|ANYONECANPAY , NONE|ANYONECANPAY , and SINGLE|ANYONECANPAY |
Result—the transaction with any signatures made
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
The results of the signature |
→hex |
string (hex) | Required (exactly 1) |
The resulting serialized transaction encoded as hex with any signatures made inserted. If no signatures were made, this will be the same transaction provided in parameter #1 |
→complete |
bool | Required (exactly 1) |
The value true if transaction is fully signed; the value false if more signatures are required |
Example from Bitcoin Core 0.10.0
Sign the hex generated in the example section for the createrawtransaction
RPC:
Result:
See also
The stop
RPC safely shuts down the Bitcoin Core server.
Parameters: none
Result—the server is safely shut down
Name | Type | Presence | Description |
---|---|---|---|
result |
string | Required (exactly 1) |
The string “Bitcoin server stopping” |
Example from Bitcoin Core 0.10.0
Result:
See also: none
The submitblock
RPC accepts a block, verifies it is a valid addition to the block chain, and broadcasts it to the network. Extra parameters are ignored by Bitcoin Core but may be used by mining pools or other programs.
Parameter #1—the new block in serialized block format as hex
Name | Type | Presence | Description |
---|---|---|---|
Block | string (hex) | Required (exactly 1) |
The full block to submit in serialized block format as hex |
Parameter #2—additional parameters
Name | Type | Presence | Description |
---|---|---|---|
Parameters | object | Optional (0 or 1) |
A JSON object containing extra parameters. Not used directly by Bitcoin Core and also not broadcast to the network. This is available for use by mining pools and other software. A common parameter is a workid string |
Result—null
or error string
Name | Type | Presence | Description |
---|---|---|---|
result |
null/string | Required (exactly 1) |
If the block submission succeeded, set to JSON null . If submission failed, set to one of the following strings: duplicate , duplicate-invalid , inconclusive , or rejected . The JSON-RPC error field will still be set to null if submission failed for one of these reasons |
Example from Bitcoin Core 0.10.0
Submit the following block with the workid, “test”.
Result (the block above was already on a local block chain):
See also
The validateaddress
RPC returns information about the given Bitcoin address.
Parameter #1—a P2PKH or P2SH address
Name | Type | Presence | Description |
---|---|---|---|
Address | string (base58) | Required (exactly 1) |
The P2PKH or P2SH address to validate encoded in base58check format |
Result—information about the address
Name | Type | Presence | Description |
---|---|---|---|
result |
object | Required (exactly 1) |
Information about the address |
→isvalid |
bool | Required (exactly 1) |
Set to true if the address is a valid P2PKH or P2SH address; set to false otherwise |
→address |
string (base58) | Optional (0 or 1) |
If the address is valid, this is the address |
→ismine |
bool | Optional (0 or 1) |
Set to true if the address belongs to the wallet; set to false if it does not. Only returned if wallet support enabled |
→iswatchonly |
bool | Optional (0 or 1) |
Set to true if the address is watch-only. Otherwise set to false . Only returned if address is in the wallet |
→isscript |
bool | Optional (0 or 1) |
Set to true if a P2SH address; otherwise set to false . Only returned if the address is in the wallet |
→script |
string | Optional (0 or 1) |
Only returned for P2SH addresses belonging to this wallet. This is the type of script: • pubkey for a P2PK script inside P2SH• pubkeyhash for a P2PKH script inside P2SH• multisig for a multisig script inside P2SH• nonstandard for unknown scripts |
→hex |
string (hex) | Optional (0 or 1) |
Only returned for P2SH addresses belonging to this wallet. This is the redeem script encoded as hex |
→addresses |
array | Optional (0 or 1) |
Only returned for P2SH addresses belonging to the wallet. A P2PKH addresses used in this script, or the computed P2PKH addresses of any pubkeys in this script. This array will be empty for nonstandard script types |
→ → Address |
string | Optional (0 or more) |
A P2PKH address |
→sigrequired |
number (int) | Optional (0 or 1) |
Only returned for multisig P2SH addresses belonging to the wallet. The number of signatures required by this script |
→pubkey |
string (hex) | Optional (0 or 1) |
The public key corresponding to this address. Only returned if the address is a P2PKH address in the wallet |
→iscompressed |
bool | Optional (0 or 1) |
Set to true if a compressed public key or set to false if an uncompressed public key. Only returned if the address is a P2PKH address in the wallet |
→account |
string | Optional (0 or 1) |
The account this address belong to. May be an empty string for the default account. Only returned if the address belongs to the wallet |
Example from Bitcoin Core 0.10.0
Validate the following P2PKH address from the wallet:
Result:
Validate the following P2SH multisig address from the wallet:
Result:
See also
The verifychain
RPC verifies each entry in the local block chain database.
Parameter #1—how thoroughly to check each block
Name | Type | Presence | Description |
---|---|---|---|
Check Level | number (int) | Optional (0 or 1) |
How thoroughly to check each block, from 0 to 4. Default is the level set with the -checklevel command line argument; if that isn’t set, the default is 3 . Each higher level includes the tests from the lower levelsLevels are: 0. Read from disk to ensure the files are accessible 1. Ensure each block is valid 2. Make sure undo files can be read from disk and are in a valid format 3. Test each block undo to ensure it results in correct state 4. After undoing blocks, reconnect them to ensure they reconnect correctly |
Parameter #2—the number of blocks to check
Name | Type | Presence | Description |
---|---|---|---|
Number Of Blocks | number (int) | Optional (0 or 1) |
The number of blocks to verify. Set to 0 to check all blocks. Defaults to the value of the -checkblocks command-line argument; if that isn’t set, the default is 288 |
Result—verification results
Name | Type | Presence | Description |
---|---|---|---|
result |
bool | Required (exactly 1) |
Set to true if verified; set to false if verification failed for any reason |
Example from Bitcoin Core 0.10.0
Verify the most recent 10,000 blocks in the most through way:
Result (took 4 minutes and 25 seconds on a generic PC laptop; it would’ve taken much longer on mainnet):
See also
The verifymessage
RPC verifies a signed message.
Parameter #1—the address corresponding to the signing key
Name | Type | Presence | Description |
---|---|---|---|
Address | string (base58) | Required (exactly 1) |
The P2PKH address corresponding to the private key which made the signature. A P2PKH address is a hash of the public key corresponding to the private key which made the signature. When the ECDSA signature is checked, up to four possible ECDSA public keys will be reconstructed from from the signature; each key will be hashed and compared against the P2PKH address provided to see if any of them match. If there are no matches, signature validation will fail |
Parameter #2—the signature
Name | Type | Presence | Description |
---|---|---|---|
Signature | string (base64) | Required (exactly 1) |
The signature created by the signer encoded as base-64 (the format output by the signmessage RPC) |
Parameter #3—the message
Name | Type | Presence | Description |
---|---|---|---|
Message | string | Required (exactly 1) |
The message exactly as it was signed (e.g. no extra whitespace) |
Result: true
, false
, or an error
Name | Type | Presence | Description |
---|---|---|---|
result |
bool/null | Required (exactly 1) |
Set to true if the message was signed by a key corresponding to the provided P2PKH address; set to false if it was not signed by that key; set to JSON null if an error occurred |
Example from Bitcoin Core 0.10.0
Check the signature on the message created in the example for
signmessage
:
Result:
See also
The verifytxoutproof
RPC verifies that a proof points to one or more transactions in a block, returning the transactions the proof commits to and throwing an RPC error if the block is not in our best block chain.
Parameter #1—The hex-encoded proof generated by gettxoutproof
Name | Type | Presence | Description |
---|---|---|---|
proof |
string | Required | A hex-encoded proof |
Result—txid(s) which the proof commits to
Name | Type | Presence | Description |
---|---|---|---|
result |
string | Required (exactly 1) |
The txid(s) which the proof commits to, or empty array if the proof is invalid |
Example from Bitcoin Core 0.11.0
Verify a proof:
Result:
See also
merkleblock
message: A description of the
format used for the proof.Requires wallet support. Requires an unlocked wallet.
The walletlock
RPC removes the wallet encryption key from memory, locking the wallet. After calling this method, you will need to call walletpassphrase
again before being able to call any methods which require the wallet to be unlocked.
Parameters: none
Result—null
on success
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required (exactly 1) |
Always set to JSON null |
Example from Bitcoin Core 0.10.0
(Success: nothing printed.)
See also
walletpassphrase
command while the wallet is already unlocked will set a new unlock time that overrides the old one.Requires wallet support. Requires an encrypted wallet.
The walletpassphrase
RPC stores the wallet decryption key in memory for the indicated number of seconds. Issuing the walletpassphrase
command while the wallet is already unlocked will set a new unlock time that overrides the old one.
Warning: if using this RPC on the command line, remember that your shell probably saves your command lines (including the value of the passphrase parameter).
Parameter #1—the passphrase
Name | Type | Presence | Description |
---|---|---|---|
Passphrase | string | Required (exactly 1) |
The passphrase that unlocks the wallet |
Parameter #2—the number of seconds to leave the wallet unlocked
Name | Type | Presence | Description |
---|---|---|---|
Seconds | number (int) | Required (exactly 1) |
The number of seconds after which the decryption key will be automatically deleted from memory |
Result—null
on success
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required (exactly 1) |
Always set to JSON null |
Example from Bitcoin Core 0.10.0
Unlock the wallet for 10 minutes (the passphrase is “test”):
(Success: no result printed.)
See also
walletpassphrase
again before being able to call any methods which require the wallet to be unlocked.Requires wallet support. Requires an encrypted wallet.
The walletpassphrasechange
RPC changes the wallet passphrase from ‘old passphrase’ to ‘new passphrase’.
Warning: if using this RPC on the command line, remember that your shell probably saves your command lines (including the value of the passphrase parameter).
Parameter #1—the current passphrase
Name | Type | Presence | Description |
---|---|---|---|
Current Passphrase | string | Required (exactly 1) |
The current wallet passphrase |
Parameter #2—the new passphrase
Name | Type | Presence | Description |
---|---|---|---|
New Passphrase | string | Required (exactly 1) |
The new passphrase for the wallet |
Result—null
on success
Name | Type | Presence | Description |
---|---|---|---|
result |
null | Required (exactly 1) |
Always set to JSON null |
Example from Bitcoin Core 0.10.0
Change the wallet passphrase from “test” to “example”:
(Success: no result printed.)
See also
walletpassphrase
command while the wallet is already unlocked will set a new unlock time that overrides the old one.walletpassphrase
again before being able to call any methods which require the wallet to be unlocked.As of version 0.10.0, Bitcoin Core provides
an unauthenticated HTTP REST interface. The interface runs on the
same port as the JSON-RPC interface, by default port 8332 for mainnet and
port 18332 for testnet. It must be enabled by either starting Bitcoin
Core with the -rest
option or by specifying rest=1
in the
configuration file.
The interface is not intended for public access and is only accessible from localhost by default.
Warning: A web browser can access a HTTP REST interface running on localhost, possibly allowing third parties to use cross-site scripting attacks to download your transaction and block data, reducing your privacy. If you have privacy concerns, you should not run a browser on the same computer as a REST-enabled Bicoin Core node.
The interface uses standard HTTP status codes and returns a plain-text description of errors for debugging.
txindex=1
in your Bitcoin Core startup settings. New in 0.10.0Warning: the block chain and memory pool can include arbitrary data which several of the commands below will return in hex format. If you convert this data to another format in an executable context, it could be used in an exploit. For example, displaying a pubkey script as ASCII text in a webpage could add arbitrary Javascript to that page and create a cross-site scripting (XSS) exploit. To avoid problems, please treat block chain and memory pool data as an arbitrary input from an untrusted source.
The GET block
operation gets a block with a particular header hash from the local block database either as a JSON object or as a serialized block.
Request
Parameter #1—the header hash of the block to retrieve
Name | Type | Presence | Description |
---|---|---|---|
Header Hash | path (hex) | Required (exactly 1) |
The hash of the header of the block to get, encoded as hex in RPC byte order |
Parameter #2—the output format
Name | Type | Presence | Description |
---|---|---|---|
Format | suffix | Required (exactly 1) |
Set to .json for decoded block contents in JSON, or .bin or hex for a serialized block in binary or hex |
Response as JSON
Name | Type | Presence | Description |
---|---|---|---|
Result | object | Required (exactly 1) |
An object containing the requested block |
→hash |
string (hex) | Required (exactly 1) |
The hash of this block’s block header encoded as hex in RPC byte order. This is the same as the hash provided in parameter #1 |
→confirmations |
number (int) | Required (exactly 1) |
The number of confirmations the transactions in this block have, starting at 1 when this block is at the tip of the best block chain. This score will be -1 if the the block is not part of the best block chain |
→size |
number (int) | Required (exactly 1) |
The size of this block in serialized block format, counted in bytes |
→height |
number (int) | Required (exactly 1) |
The height of this block on its block chain |
→version |
number (int) | Required (exactly 1) |
This block’s version number. See block version numbers |
→merkleroot |
string (hex) | Required (exactly 1) |
The merkle root for this block, encoded as hex in RPC byte order |
→tx |
array | Required (exactly 1) |
An array containing all transactions in this block. The transactions appear in the array in the same order they appear in the serialized block |
→ → Transaction |
object | Required (1 or more) |
An object describing a particular transaction within this block |
→ → →txid |
string (hex) | Required (exactly 1) |
The transaction’s TXID encoded as hex in RPC byte order |
→ → →version |
number (int) | Required (exactly 1) |
The transaction format version number |
→ → →locktime |
number (int) | Required (exactly 1) |
The transaction’s locktime: either a Unix epoch date or block height; see the Locktime parsing rules |
→ → →vin |
array | Required (exactly 1) |
An array of objects with each object being an input vector (vin) for this transaction. Input objects will have the same order within the array as they have in the transaction, so the first input listed will be input 0 |
→ → → → Input |
object | Required (1 or more) |
An object describing one of this transaction’s inputs. May be a regular input or a coinbase |
→ → → → →txid |
string | Optional (0 or 1) |
The TXID of the outpoint being spent, encoded as hex in RPC byte order. Not present if this is a coinbase transaction |
→ → → → →vout |
number (int) | Optional (0 or 1) |
The output index number (vout) of the outpoint being spent. The first output in a transaction has an index of 0 . Not present if this is a coinbase transaction |
→ → → → →scriptSig |
object | Optional (0 or 1) |
An object describing the signature script of this input. Not present if this is a coinbase transaction |
→ → → → → →asm |
string | Required (exactly 1) |
The signature script in decoded form with non-data-pushing opcodes listed |
→ → → → → →hex |
string (hex) | Required (exactly 1) |
The signature script encoded as hex |
→ → → → →coinbase |
string (hex) | Optional (0 or 1) |
The coinbase (similar to the hex field of a scriptSig) encoded as hex. Only present if this is a coinbase transaction |
→ → → → →sequence |
number (int) | Required (exactly 1) |
The input sequence number |
→ → →vout |
array | Required (exactly 1) |
An array of objects each describing an output vector (vout) for this transaction. Output objects will have the same order within the array as they have in the transaction, so the first output listed will be output 0 |
→ → → → Output |
object | Required (1 or more) |
An object describing one of this transaction’s outputs |
→ → → → →value |
number (bitcoins) | Required (exactly 1) |
The number of bitcoins paid to this output. May be 0 |
→ → → → →n |
number (int) | Required (exactly 1) |
The output index number of this output within this transaction |
→ → → → →scriptPubKey |
object | Required (exactly 1) |
An object describing the pubkey script |
→ → → → → →asm |
string | Required (exactly 1) |
The pubkey script in decoded form with non-data-pushing opcodes listed |
→ → → → → →hex |
string (hex) | Required (exactly 1) |
The pubkey script encoded as hex |
→ → → → → →reqSigs |
number (int) | Optional (0 or 1) |
The number of signatures required; this is always 1 for P2PK, P2PKH, and P2SH (including P2SH multisig because the redeem script is not available in the pubkey script). It may be greater than 1 for bare multisig. This value will not be returned for nulldata or nonstandard script types (see the type key below) |
→ → → → → →type |
string | Optional (0 or 1) |
The type of script. This will be one of the following: • pubkey for a P2PK script• pubkeyhash for a P2PKH script• scripthash for a P2SH script• multisig for a bare multisig script• nulldata for nulldata scripts• nonstandard for unknown scripts |
→ → → → → →addresses |
string : array | Optional (0 or 1) |
The P2PKH or P2SH addresses used in this transaction, or the computed P2PKH address of any pubkeys in this transaction. This array will not be returned for nulldata or nonstandard script types |
→ → → → → → → Address |
string | Required (1 or more) |
A P2PKH or P2SH address |
→time |
number (int) | Required (exactly 1) |
The value of the time field in the block header, indicating approximately when the block was created |
→nonce |
number (int) | Required (exactly 1) |
The nonce which was successful at turning this particular block into one that could be added to the best block chain |
→bits |
string (hex) | Required (exactly 1) |
The value of the nBits field in the block header, indicating the target threshold this block’s header had to pass |
→difficulty |
number (real) | Required (exactly 1) |
The estimated amount of work done to find this block relative to the estimated amount of work done to find block 0 |
→chainwork |
string (hex) | Required (exactly 1) |
The estimated number of block header hashes miners had to check from the genesis block to this block, encoded as big-endian hex |
→previousblockhash |
string (hex) | Required (exactly 1) |
The hash of the header of the previous block, encoded as hex in RPC byte order |
→nextblockhash |
string (hex) | Optional (0 or 1) |
The hash of the next block on the best block chain, if known, encoded as hex in RPC byte order |
Examples from Bitcoin Core 0.10.0
Request a block in hex-encoded serialized block format:
Result (wrapped):
Get the same block in JSON:
Result (whitespaced added):
See also
The GET block/notxdetails
operation gets a block with a particular header hash from the local block database either as a JSON object or as a serialized block. The JSON object includes TXIDs for transactions within the block rather than the complete transactions GET block returns.
Request
Parameter #1—the header hash of the block to retrieve
Name | Type | Presence | Description |
---|---|---|---|
Header Hash | path (hex) | Required (exactly 1) |
The hash of the header of the block to get, encoded as hex in RPC byte order |
Parameter #2—the output format
Name | Type | Presence | Description |
---|---|---|---|
Format | suffix | Required (exactly 1) |
Set to .json for decoded block contents in JSON, or .bin or hex for a serialized block in binary or hex |
Response as JSON
Name | Type | Presence | Description |
---|---|---|---|
Result | object | Required (exactly 1) |
An object containing the requested block |
→hash |
string (hex) | Required (exactly 1) |
The hash of this block’s block header encoded as hex in RPC byte order. This is the same as the hash provided in parameter #1 |
→confirmations |
number (int) | Required (exactly 1) |
The number of confirmations the transactions in this block have, starting at 1 when this block is at the tip of the best block chain. This score will be -1 if the the block is not part of the best block chain |
→size |
number (int) | Required (exactly 1) |
The size of this block in serialized block format, counted in bytes |
→height |
number (int) | Required (exactly 1) |
The height of this block on its block chain |
→version |
number (int) | Required (exactly 1) |
This block’s version number. See block version numbers |
→merkleroot |
string (hex) | Required (exactly 1) |
The merkle root for this block, encoded as hex in RPC byte order |
→tx |
array | Required (exactly 1) |
An array containing all transactions in this block. The transactions appear in the array in the same order they appear in the serialized block |
→ → TXID |
string (hex) | Required (1 or more) |
The TXID of a transaction in this block, encoded as hex in RPC byte order |
→time |
number (int) | Required (exactly 1) |
The value of the time field in the block header, indicating approximately when the block was created |
→nonce |
number (int) | Required (exactly 1) |
The nonce which was successful at turning this particular block into one that could be added to the best block chain |
→bits |
string (hex) | Required (exactly 1) |
The value of the nBits field in the block header, indicating the target threshold this block’s header had to pass |
→difficulty |
number (real) | Required (exactly 1) |
The estimated amount of work done to find this block relative to the estimated amount of work done to find block 0 |
→chainwork |
string (hex) | Required (exactly 1) |
The estimated number of block header hashes miners had to check from the genesis block to this block, encoded as big-endian hex |
→previousblockhash |
string (hex) | Required (exactly 1) |
The hash of the header of the previous block, encoded as hex in RPC byte order |
→nextblockhash |
string (hex) | Optional (0 or 1) |
The hash of the next block on the best block chain, if known, encoded as hex in RPC byte order |
Examples from Bitcoin Core 0.10.0
Request a block in hex-encoded serialized block format:
Result (wrapped):
Get the same block in JSON:
Result (whitespaced added):
See also
The GET tx
operation
Note: if you begin using txindex=1
after downloading the block chain, you must rebuild your indexes by starting Bitcoin Core with the option -reindex
. This may take several hours to complete, during which time your node will not process new blocks or transactions. This reindex only needs to be done once.
Request
Parameter #1—the TXID of the transaction to retrieve
Name | Type | Presence | Description |
---|---|---|---|
TXID | path (hex) | Required (exactly 1) |
The TXID of the transaction to get, encoded as hex in RPC byte order |
Parameter #2—the output format
Name | Type | Presence | Description |
---|---|---|---|
Format | suffix | Required (exactly 1) |
Set to .json for decoded transaction contents in JSON, or .bin or hex for a serialized transaction in binary or hex |
Response as JSON
Name | Type | Presence | Description |
---|---|---|---|
Result | object | Required (exactly 1) |
An object describing the request transaction |
→txid |
string (hex) | Required (exactly 1) |
The transaction’s TXID encoded as hex in RPC byte order |
→version |
number (int) | Required (exactly 1) |
The transaction format version number |
→locktime |
number (int) | Required (exactly 1) |
The transaction’s locktime: either a Unix epoch date or block height; see the Locktime parsing rules |
→vin |
array | Required (exactly 1) |
An array of objects with each object being an input vector (vin) for this transaction. Input objects will have the same order within the array as they have in the transaction, so the first input listed will be input 0 |
→ → Input |
object | Required (1 or more) |
An object describing one of this transaction’s inputs. May be a regular input or a coinbase |
→ → →txid |
string | Optional (0 or 1) |
The TXID of the outpoint being spent, encoded as hex in RPC byte order. Not present if this is a coinbase transaction |
→ → →vout |
number (int) | Optional (0 or 1) |
The output index number (vout) of the outpoint being spent. The first output in a transaction has an index of 0 . Not present if this is a coinbase transaction |
→ → →scriptSig |
object | Optional (0 or 1) |
An object describing the signature script of this input. Not present if this is a coinbase transaction |
→ → → →asm |
string | Required (exactly 1) |
The signature script in decoded form with non-data-pushing opcodes listed |
→ → → →hex |
string (hex) | Required (exactly 1) |
The signature script encoded as hex |
→ → →coinbase |
string (hex) | Optional (0 or 1) |
The coinbase (similar to the hex field of a scriptSig) encoded as hex. Only present if this is a coinbase transaction |
→ → →sequence |
number (int) | Required (exactly 1) |
The input sequence number |
→vout |
array | Required (exactly 1) |
An array of objects each describing an output vector (vout) for this transaction. Output objects will have the same order within the array as they have in the transaction, so the first output listed will be output 0 |
→ → Output |
object | Required (1 or more) |
An object describing one of this transaction’s outputs |
→ → →value |
number (bitcoins) | Required (exactly 1) |
The number of bitcoins paid to this output. May be 0 |
→ → →n |
number (int) | Required (exactly 1) |
The output index number of this output within this transaction |
→ → →scriptPubKey |
object | Required (exactly 1) |
An object describing the pubkey script |
→ → → →asm |
string | Required (exactly 1) |
The pubkey script in decoded form with non-data-pushing opcodes listed |
→ → → →hex |
string (hex) | Required (exactly 1) |
The pubkey script encoded as hex |
→ → → →reqSigs |
number (int) | Optional (0 or 1) |
The number of signatures required; this is always 1 for P2PK, P2PKH, and P2SH (including P2SH multisig because the redeem script is not available in the pubkey script). It may be greater than 1 for bare multisig. This value will not be returned for nulldata or nonstandard script types (see the type key below) |
→ → → →type |
string | Optional (0 or 1) |
The type of script. This will be one of the following: • pubkey for a P2PK script• pubkeyhash for a P2PKH script• scripthash for a P2SH script• multisig for a bare multisig script• nulldata for nulldata scripts• nonstandard for unknown scripts |
→ → → →addresses |
string : array | Optional (0 or 1) |
The P2PKH or P2SH addresses used in this transaction, or the computed P2PKH address of any pubkeys in this transaction. This array will not be returned for nulldata or nonstandard script types |
→ → → → → Address |
string | Required (1 or more) |
A P2PKH or P2SH address |
→blockhash |
string (hex) | Optional (0 or 1) |
If the transaction has been included in a block on the local best block chain, this is the hash of that block encoded as hex in RPC byte order |
→confirmations |
number (int) | Required (exactly 1) |
If the transaction has been included in a block on the local best block chain, this is how many confirmations it has. Otherwise, this is 0 |
→time |
number (int) | Optional (0 or 1) |
If the transaction has been included in a block on the local best block chain, this is the block header time of that block (may be in the future) |
→blocktime |
number (int) | Optional (0 or 1) |
This field is currently identical to the time field described above |
Examples from Bitcoin Core 0.10.0
Request a transaction in hex-encoded serialized transaction format:
Result (wrapped):
Get the same transaction in JSON:
Result (whitespaced added):
See also
txindex=1
in your Bitcoin Core startup settings.