Bitcoin Wiki - User contributions [en]

API reference (JSON-RPC)

2024-10-28T10:14:08Z

V: The link is broken, and, moreover, it just redirects to Wikipedia from the site.

== Controlling Bitcoin Core ==

Run ''bitcoind'' or ''bitcoin-qt -server''. You can control it via the command-line bitcoin-cli utility or by [http://json-rpc.org/wiki/specification HTTP JSON-RPC] commands.

You must create a bitcoin.conf configuration file setting an rpcuser and rpcpassword; see [[Running Bitcoin]] for details.

Now run:
$ ./bitcoind -daemon
bitcoin server starting
$ ./bitcoin-cli -rpcwait help
# shows the help text

A [[Original Bitcoin client/API Calls list|list of RPC calls]] will be shown.

$ ./bitcoin-cli getbalance
2000.00000

If you are learning the API, it is a very good idea to use the test network (run bitcoind -testnet and bitcoin-cli -testnet).

== JSON-RPC ==

Running Bitcoin with the -server argument (or running bitcoind) tells it to function as a [http://json-rpc.org/wiki/specification HTTP JSON-RPC] server, but
[http://en.wikipedia.org/wiki/Basic_access_authentication Basic access authentication] must be used when communicating with it, and, for security, by default, the server only accepts connections from other processes on the same machine. If your HTTP or JSON library requires you to specify which 'realm' is authenticated, use 'jsonrpc'.

Bitcoin supports SSL (https) JSON-RPC connections beginning with version 0.3.14. See the [[Enabling SSL on original client daemon|rpcssl wiki page]] for setup instructions and a list of all bitcoin.conf configuration options.

Allowing arbitrary machines to access the JSON-RPC port (using the rpcallowip [[Running_Bitcoin|configuration option]]) is dangerous and '''strongly discouraged'''-- access should be strictly limited to trusted machines.

== Proper money handling ==

See the [[Proper Money Handling (JSON-RPC)|proper money handling page]] for notes on avoiding rounding errors when handling bitcoin values.

== Languages ==

=== Python ===

[http://json-rpc.org/wiki/python-json-rpc python-jsonrpc] is the official JSON-RPC implementation for Python.
It automatically generates Python methods for RPC calls.
However, due to its design for supporting old versions of Python, it is also rather inefficient.
[[User:jgarzik|jgarzik]] has forked it as [https://github.com/jgarzik/python-bitcoinrpc Python-BitcoinRPC] and optimized it for current versions.
Generally, this version is recommended.

While BitcoinRPC lacks a few obscure features from jsonrpc, software using only the ServiceProxy class can be written the same to work with either version the user might choose to install:

<source lang="python">
from jsonrpc import ServiceProxy

access = ServiceProxy("http://user:password@127.0.0.1:8332")
access.getblockchaininfo()
access.listreceivedbyaddress(6)
#access.sendtoaddress("11yEmxiMso2RsFVfBcCa616npBvGgxiBX", 10)
</source>

The latest version of python-bitcoinrpc has a new syntax.
<source lang="python">
from bitcoinrpc.authproxy import AuthServiceProxy
</source>

=== Ruby ===

<source lang="ruby">
require 'net/http'
require 'uri'
require 'json'

class BitcoinRPC
def initialize(service_url)
@uri = URI.parse(service_url)
end

def method_missing(name, *args)
post_body = { 'method' => name, 'params' => args, 'id' => 'jsonrpc' }.to_json
resp = JSON.parse( http_post_request(post_body) )
raise JSONRPCError, resp['error'] if resp['error']
resp['result']
end

def http_post_request(post_body)
http = Net::HTTP.new(@uri.host, @uri.port)
request = Net::HTTP::Post.new(@uri.request_uri)
request.basic_auth @uri.user, @uri.password
request.content_type = 'application/json'
request.body = post_body
http.request(request).body
end

class JSONRPCError < RuntimeError; end
end

if $0 == __FILE__
h = BitcoinRPC.new('http://user:password@127.0.0.1:8332')
p h.getbalance
p h.getblockchaininfo
p h.getnewaddress
p h.dumpprivkey( h.getnewaddress )
# also see: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list
end
</source>

=== Erlang ===
Get the rebar dependency from https://github.com/edescourtis/ebitcoind . By default the client will use the configuration in <code>$HOME/.bitcoin/bitcoin.conf</code> or you can instead specify a URI like this:
<source lang="erlang">ebitcoind:start_link(<<"http://user:password@localhost:8332/">>).</source>

Here is a usage example:
<source lang="erlang">
1> {ok,Pid} = ebitcoind:start_link().
{ok,<0.177.0>}
2> ebitcoind:getbalance(Pid).
8437.02478294
3> ebitcoind:getblockchaininfo(Pid).
{ok, #{<<"balance">> => 8437.02478294,
<<"blocks">> => 260404,
<<"connections">> => 8,
<<"difficulty">> => 148819199.80509263,
<<"errors">> => <<>>,
<<"keypoololdest">> => 1420307921,
<<"keypoolsize">> => 102,
<<"paytxfee">> => 0.0,
<<"protocolversion">> => 70002,
<<"proxy">> => <<>>,
<<"relayfee">> => 1.0e-5,
<<"testnet">> => false,
<<"timeoffset">> => -3,
<<"version">> => 90300,
<<"walletversion">> => 60000}}
4> ebitcoind:setgenerate(Pid,true).
{ok, null}
5> ebitcoind:getblocktemplate(Pid, #{}).
{ok,#{<<"bits">> => <<"181b0dca">>,
<<"coinbaseaux">> => #{<<"flags">> => <<"062f503253482f">>},
<<"coinbasevalue">> => 2518690558,
<<"curtime">> => 1420421249,
<<"height">> => 337533,
<<"mintime">> => 1420416332,
<<"mutable">> => [<<"time">>,<<"transactions">>,<<"prevblock">>],
<<"noncerange">> => <<"00000000ffffffff">>,
<<"previousblockhash">> => <<"000000000000000017ce0a0d328bf84cc597785844393e899e9a971a81679a5f">>,
<<"sigoplimit">> => 20000,
<<"sizelimit">> => 1000000,
<<"target">> => <<"00000000000000001b0dca00000000000000000000000000000000000000"...>>,
<<"transactions">> => [#{<<"data">> => <<"01000000049b47ce225d29bff7c18b7df7d7df4693523a52"...>>,
<<"depends">> => [],
<<"fee">> => 0,
<<"hash">> => <<"6d0d76e1f27b3a6f7325923710dcdb4107c9"...>>,
<<"sigops">> => 1},
...
</source>

=== PHP ===

The [http://jsonrpcphp.org/ JSON-RPC PHP] library also makes it very easy to connect to Bitcoin. For example:

<source lang="php">
require_once 'jsonRPCClient.php';

$bitcoin = new jsonRPCClient('http://user:password@127.0.0.1:8332/');

echo "<pre>\n";
print_r($bitcoin->getblockchaininfo()); echo "\n";
echo "Received: ".$bitcoin->getreceivedbylabel("Your Address")."\n";
echo "</pre>";
</source>

'''Note:''' The jsonRPCClient library uses fopen() and will throw an exception saying "Unable to connect" if it receives a 404 or 500 error from bitcoind. This prevents you from being able to see error messages generated by bitcoind (as they are sent with status 404 or 500). The [https://github.com/aceat64/EasyBitcoin-PHP EasyBitcoin-PHP library] is similar in function to JSON-RPC PHP but does not have this issue.

=== Java ===

The easiest way to tell Java to use HTTP Basic authentication is to set a default Authenticator:

<source lang="java">
final String rpcuser ="...";
final String rpcpassword ="...";

Authenticator.setDefault(new Authenticator() {
protected PasswordAuthentication getPasswordAuthentication() {
return new PasswordAuthentication (rpcuser, rpcpassword.toCharArray());
}
});
</source>

Once that is done, [http://json-rpc.org/wiki/implementations any JSON-RPC library for Java] (or ordinary URL POSTs) may be used to communicate with the Bitcoin server.

Instead of writing your own implementation, consider using one of the existing wrappers like [https://github.com/johannbarbie/BitcoindClient4J BitcoindClient4J], [https://github.com/priiduneemre/btcd-cli4j btcd-cli4j] or [[Bitcoin-JSON-RPC-Client|Bitcoin-JSON-RPC-Client]] instead.

=== Perl ===

The JSON::RPC package from CPAN can be used to communicate with Bitcoin. You must set the client's credentials; for example:

<source lang="perl">
use JSON::RPC::Client;
use Data::Dumper;

my $client = new JSON::RPC::Client;

$client->ua->credentials(
'localhost:8332', 'jsonrpc', 'user' => 'password' # REPLACE WITH YOUR bitcoin.conf rpcuser/rpcpassword
);

my $uri = 'http://localhost:8332/';
my $obj = {
method => 'getblockchaininfo',
params => [],
};

my $res = $client->call( $uri, $obj );

if ($res){
if ($res->is_error) { print "Error : ", $res->error_message; }
else { print Dumper($res->result); }
} else {
print $client->status_line;
}
</source>

=== Go ===

The [https://github.com/btcsuite/btcrpcclient btcrpcclient package] can be used to communicate with Bitcoin. You must provide credentials to match the client you are communicating with.

<source lang="go">
package main

import (
"github.com/btcsuite/btcd/chaincfg"
"github.com/btcsuite/btcrpcclient"
"github.com/btcsuite/btcutil"
"log"
)

func main() {
// create new client instance
client, err := btcrpcclient.New(&btcrpcclient.ConnConfig{
HTTPPostMode: true,
DisableTLS: true,
Host: "127.0.0.1:8332",
User: "rpcUsername",
Pass: "rpcPassword",
}, nil)
if err != nil {
log.Fatalf("error creating new btc client: %v", err)
}

// list accounts
accounts, err := client.ListAccounts()
if err != nil {
log.Fatalf("error listing accounts: %v", err)
}
// iterate over accounts (map[string]btcutil.Amount) and write to stdout
for label, amount := range accounts {
log.Printf("%s: %s", label, amount)
}

// prepare a sendMany transaction
receiver1, err := btcutil.DecodeAddress("1someAddressThatIsActuallyReal", &chaincfg.MainNetParams)
if err != nil {
log.Fatalf("address receiver1 seems to be invalid: %v", err)
}
receiver2, err := btcutil.DecodeAddress("1anotherAddressThatsPrettyReal", &chaincfg.MainNetParams)
if err != nil {
log.Fatalf("address receiver2 seems to be invalid: %v", err)
}
receivers := map[btcutil.Address]btcutil.Amount{
receiver1: 42, // 42 satoshi
receiver2: 100, // 100 satoshi
}

// create and send the sendMany tx
txSha, err := client.SendMany("some-account-label-from-which-to-send", receivers)
if err != nil {
log.Fatalf("error sendMany: %v", err)
}
log.Printf("sendMany completed! tx sha is: %s", txSha.String())
}
</source>

=== .NET (C#) ===
The communication with the RPC service can be achieved using the standard http request/response objects.
A library for serializing and deserializing Json will make your life a lot easier:

Json.NET ( http://james.newtonking.com/json ) is a high performance JSON package for .NET. It is also available via NuGet from the package manager console ( Install-Package Newtonsoft.Json ).

The following example uses Json.NET:

<source lang="csharp">
HttpWebRequest webRequest = (HttpWebRequest)WebRequest.Create("http://localhost.:8332");
webRequest.Credentials = new NetworkCredential("user", "pwd");
/// important, otherwise the service can't desirialse your request properly
webRequest.ContentType = "application/json-rpc";
webRequest.Method = "POST";

JObject joe = new JObject();
joe.Add(new JProperty("jsonrpc", "1.0"));
joe.Add(new JProperty("id", "1"));
joe.Add(new JProperty("method", Method));
// params is a collection values which the method requires..
if (Params.Keys.Count == 0)
{
joe.Add(new JProperty("params", new JArray()));
}
else
{
JArray props = new JArray();
// add the props in the reverse order!
for (int i = Params.Keys.Count - 1; i >= 0; i--)
{
.... // add the params
}
joe.Add(new JProperty("params", props));
}

// serialize json for the request
string s = JsonConvert.SerializeObject(joe);
byte[] byteArray = Encoding.UTF8.GetBytes(s);
webRequest.ContentLength = byteArray.Length;
Stream dataStream = webRequest.GetRequestStream();
dataStream.Write(byteArray, 0, byteArray.Length);
dataStream.Close();

WebResponse webResponse = webRequest.GetResponse();

... // deserialze the response
</source>

There is also a wrapper for Json.NET called Bitnet (https://sourceforge.net/projects/bitnet)
implementing Bitcoin API in more convenient way:

<source lang="csharp">
BitnetClient bc = new BitnetClient("http://127.0.0.1:8332");
bc.Credentials = new NetworkCredential("user", "pass");

var p = bc.GetDifficulty();
Console.WriteLine("Difficulty:" + p.ToString());

var inf = bc.GetBlockchainInfo();
Console.WriteLine("Balance:" + inf["balance"]);
</source>

A more complete library and wrapper for Bitcoin is [https://github.com/GeorgeKimionis/BitcoinLib BitcoinLib] (https://github.com/GeorgeKimionis/BitcoinLib) which is also available via [https://www.nuget.org/packages/BitcoinLib/ NuGet] from the package manager console (Install-Package BitcoinLib).

Querying the daemon with [https://github.com/GeorgeKimionis/BitcoinLib BitcoinLib] is as simple as:

<source lang="csharp">
IBitcoinService bitcoinService = new BitcoinService();

var networkDifficulty = bitcoinService.GetDifficulty();
var myBalance = bitcoinService.GetBalance();
</source>

=== Node.js ===

* [https://github.com/ruimarinho/bitcoin-core bitcoin-core] (npm: [https://www.npmjs.com/package/bitcoin-core bitcoin-core])

Example using bitcoin-core:

<source lang="javascript">
const Client = require('bitcoin-core');
const client = new Client({
network: 'regtest',
username: 'user',
password: 'pass',
port: 18443
});

client.getBlockchainInfo().then((help) => console.log(help));
</source>

=== Deno ===

* Github: [https://github.com/timonson/gentle_rpc gentle_rpc] or deno.land: [https://deno.land/x/gentle_rpc gentle_rpc]

gentle_rpc is a TypeScript JSON-RPC 2.0 library for Deno and the browser, it works perfectly with lowercase function names. There is also a transpiled JavaScript bundle in the repository which you can import directly into the browser.

Example using gentle_rpc:

<source lang="typescript">
import { createRemote } from "https://deno.land/x/gentle_rpc/mod.ts";

const Node = new URL("http://127.0.0.1");
Node.port = "18332";
Node.username = "BitcoinUser";
Node.password = "BitcoinPassword";

const remote = createRemote(Node);
const info = await remote.call("getblockchaininfo");
console.log(info);
</source>

=== Command line (cURL) ===

You can also send commands and see results using [http://curl.haxx.se/ cURL] or some other command-line HTTP-fetching utility; for example:

<source lang="bash">
curl --user user --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "getblockchaininfo", "params": [] }'
-H 'content-type: text/plain;' http://127.0.0.1:8332/
</source>

You will be prompted for your rpcpassword, and then will see something like:

<source lang="javascript">
{"result":{"balance":0.000000000000000,"blocks":59952,"connections":48,"proxy":"","generate":false,
"genproclimit":-1,"difficulty":16.61907875185736},"error":null,"id":"curltest"}
</source>

=== Command line (jsonrpc-cli) ===

[https://github.com/dan-da/jsonrpc-cli jsonrpc-cli] provides simple json queries from the command-line with highlighted json results (colors) and the ability to view/debug raw http requests and responses.

<source lang="bash">
jsonrpc-cli --user=rpcuser --pass=rpcpassword http://localhost:8332/ getblockchaininfo
</source>

<source lang="javascript">
{
"version": 109900,
"protocolversion": 70002,
"walletversion": 60000,
"balance": 0,
"blocks": 588597,
"timeoffset": -1,
"connections": 9,
"proxy": "127.0.0.1:9050",
"difficulty": 9013786945891.682,
"testnet": false,
"keypoololdest": 1463279619,
"keypoolsize": 101,
"paytxfee": 0,
"relayfee": 1.0e-5,
"errors": null
}
</source>

=== Clojure ===

[https://github.com/aviad/clj-btc clj-btc] is a Clojure wrapper for the bitcoin API.

<source lang="clojure">
user=> (require '[clj-btc.core :as btc])
nil
user=> (btc/getblockchaininfo)
{"timeoffset" 0, "protocolversion" 70001, "blocks" 111908, "errors" "",
"testnet" true, "proxy" "", "connections" 4, "version" 80500,
"keypoololdest" 1380388750, "paytxfee" 0E-8M,
"difficulty" 4642.44443532M, "keypoolsize" 101, "balance" 0E-8M,
"walletversion" 60000}
</source>

=== C ===
The C API for processing JSON is [https://jansson.readthedocs.org/en/latest/ Jansson]. C applications like [https://github.com/bitcoin/libblkmaker libblkmaker] use [[API_reference_(JSON-RPC)#Command_line_.28cURL.29|cURL]] for making the calls and Jansson for interpreting the JSON that cURL fetches.

For example basic usage (which can be easily modified for Bitcoin RPC), see the Jansson example [https://jansson.readthedocs.org/en/latest/_downloads/github_commits.c github_commits.c] and [https://jansson.readthedocs.org/en/latest/tutorial.html#the-github-repo-commits-api the associated tutorial].

The following does with libcurl what the [[API_reference_(JSON-RPC)#Command_line_.28cURL.29|cURL example above]] does:<source lang="c">#include <stdlib.h>

#include <curl/curl.h>

int main()
{
CURL *curl = curl_easy_init();
struct curl_slist *headers = NULL;

if (curl) {
const char *data =
"{\"jsonrpc\": \"1.0\", \"id\":\"curltest\", \"method\": \"getblockchaininfo\", \"params\": [] }";

headers = curl_slist_append(headers, "content-type: text/plain;");
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers);

curl_easy_setopt(curl, CURLOPT_URL, "http://127.0.0.1:8332/");

curl_easy_setopt(curl, CURLOPT_POSTFIELDSIZE, (long) strlen(data));
curl_easy_setopt(curl, CURLOPT_POSTFIELDS, data);

curl_easy_setopt(curl, CURLOPT_USERPWD,
"bitcoinrpcUSERNAME:bitcoinrpcPASSWORD");

curl_easy_setopt(curl, CURLOPT_USE_SSL, CURLUSESSL_TRY);

curl_easy_perform(curl);
}
return 0;
}
</source>This output can be parsed with Jansson, ''à la'' the Jansson tutorial linked to above.

(source: [https://bitcoin.stackexchange.com/a/41158/4334 Bitcoin StackExchange])

=== Qt/C++ ===

[https://bitbucket.org/devonit/qjsonrpc/overview QJsonRpc] is a Qt/C++ implementation of the JSON-RPC protocol. It integrates nicely with Qt, leveraging Qt's meta object system in order to provide services over the JSON-RPC protocol. QJsonRpc is licensed under the LGPLv2.1.

<source lang="cpp">
/*
* Copyright (C) 2012-2013 Matt Broadstone
* Contact: http://bitbucket.org/devonit/qjsonrpc
*
* This file is part of the QJsonRpc Library.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*/
#include <QCoreApplication>
#include <QAuthenticator>
#include <QStringList>
#include <QDebug>

#include "qjsonrpchttpclient.h"

class HttpClient : public QJsonRpcHttpClient
{
Q_OBJECT
public:
HttpClient(const QString &endpoint, QObject *parent = 0)
: QJsonRpcHttpClient(endpoint, parent)
{
// defaults added for my local test server
m_username = "bitcoinrpc";
m_password = "232fb3276bbb7437d265298ea48bdc46";
}

void setUsername(const QString &username) {
m_username = username;
}

void setPassword(const QString &password) {
m_password = password;
}

private Q_SLOTS:
virtual void handleAuthenticationRequired(QNetworkReply *reply, QAuthenticator * authenticator)
{
Q_UNUSED(reply)
authenticator->setUser(m_username);
authenticator->setPassword(m_password);
}

private:
QString m_username;
QString m_password;

};

int main(int argc, char **argv)
{
QCoreApplication app(argc, argv);
if (app.arguments().size() < 2) {
qDebug() << "usage: " << argv[0] << "[-u username] [-p password] <command> <arguments>";
return -1;
}

HttpClient client("http://127.0.0.1:8332");
if (app.arguments().contains("-u")) {
int idx = app.arguments().indexOf("-u");
app.arguments().removeAt(idx);
if(idx<app.arguments().count())
client.setUsername(app.arguments().takeAt(idx));
else qDebug()<<"-u value not defined";
}

if (app.arguments().contains("-p")) {
int idx = app.arguments().indexOf("-p");
app.arguments().removeAt(idx);
if(idx<app.arguments().count())
client.setPassword(app.arguments().takeAt(idx));
else qDebug()<<"-p value not defined";
}

QJsonRpcMessage message = QJsonRpcMessage::createRequest(app.arguments().at(1));
QJsonRpcMessage response = client.sendMessageBlocking(message);
if (response.type() == QJsonRpcMessage::Error) {
qDebug() << response.errorData();
return -1;
}

qDebug() << response.toJson();
}
</source>

== Multi-wallet RPC calls ==

[[Bitcoin Knots]] 0.13.1 added support for loading multiple, separate wallets.
Multi-wallet can be enabled by using more than one <code>-wallet</code> argument when starting Bitcoin, either on the command line or in the Bitcoin config file.
This was also included in [[Bitcoin Core]] 0.15.

Wallet-level RPC calls (like <code>importaddress</code> or <code>listtransactions</code>) can specify which wallet file will be accessed. This is done by setting the HTTP endpoint in the JSON-RPC request in the format <code><RPC IP address>:<RPC port>/wallet/<wallet name></code>, for example <code>https://127.0.0.1:8332/wallet/wallet1.dat</code>.

The command line utility bitcoin-cli can specify the wallet file using the <code>-rpcwallet</code> flag, for example <code>bitcoin-cli -rpcwallet=wallet1.dat getbalance</code>

For more details see the [https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.15.0.md#multi-wallet-support Bitcoin Core 0.15 release notes]

Alternatively (but not available in Bitcoin Core at this time), an additional parameter can be specified to <code>-rpcauth</code> naming a default wallet for JSON-RPC accesses to the normal endpoint.

== See Also==

* The Bitcoin Core documentation: https://github.com/bitcoin/bitcoin/blob/master/doc/JSON-RPC-interface.md#json-rpc-interface
* The Bitcoin Core RPC help for each call: https://bitcoincore.org/en/doc/
* The Bitcoin Core RPC error codes: https://github.com/bitcoin/bitcoin/blob/master/src/rpc/protocol.h
* Bitcoin Core RPC API version changes https://masonicboom.github.io/btcrpcapi/

* [[Original_Bitcoin_client/API_Calls_list|API calls list]]
* [[Running Bitcoin]]
* [[Lazy API]]
* [[PHP developer intro]]
* [[Raw_Transactions|Raw Transactions API]]
* [https://gourl.io/bitcoin-payment-gateway-api.html GoUrl Bitcoin PHP Payment API]
* [http://blockchain.info/api/json_rpc_api Web Based JSON RPC interface.]

[[Category:Technical]]
[[Category:Developer]]
[[zh-cn:API_reference_(JSON-RPC)]]

{{Bitcoin Core documentation}}

Full node

2024-10-18T20:25:56Z

V: Fixed current block subsidy value.

Any computer that connects to the Bitcoin [[network]] is called a '''node'''. Nodes that fully verify all of the rules of Bitcoin are called '''full nodes'''. The most popular software implementation of full nodes is called [[Bitcoin Core]], its latest release can be found [https://github.com/bitcoin/bitcoin/releases on the github page].

==What makes a full node?==

Full nodes download every block and transaction and check them against Bitcoin's consensus rules. Here are examples of consensus rules, though there are many more:
* Blocks may only [[controlled supply|create]] a certain number of bitcoins. (Currently 3.125 BTC per block.)
* Transactions must have correct signatures for the bitcoins being spent.
* Transactions/blocks must be in the correct data format.
* Within a single [[block chain]], a transaction output cannot be double-spent.

If a transaction or block violates the consensus rules, then it is absolutely rejected, even if every other node on the network thinks that it is valid. This is one of the most important characteristics of full nodes: they do what's right ''no matter what''. For full nodes, miners actually have fairly limited power: they can only reorder or remove transactions, and only by spending a lot of computing power. A powerful miner is able to execute [[Weaknesses#Attacker_has_a_lot_of_computing_power|some serious attacks]], but because full nodes rely on miners only for a few things, miners could not completely change or destroy Bitcoin.

Nodes that have different ''consensus'' rules are actually using two different networks/currencies. Changing any of the consensus rules requires a [[hard fork]], which can be thought of as creating a new currency and having everyone move to it. Consensus rules are different from ''policy'' rules, which specify how a node or miner prioritizes or discourages certain things. Policy rules can be changed freely, and different nodes can have different policy rules. Because all full nodes must use ''exactly'' the same consensus rules in order to remain compatible with each other, even duplicating bugs and oddities in the original consensus rules, creating a full node from scratch is extremely difficult and dangerous. It is therefore recommended that everyone who wishes to run a full node uses software based on the [[reference client]], which is the only client guaranteed to behave correctly.

At minimum, a full node must download every transaction that has ever taken place, all new transactions, and all block headers. Additionally, full nodes must store information about every unspent transaction output until it is spent. By default full nodes are inefficient in that they download each new transaction at least twice, and they store the entire block chain (more than 165 GB as of 20180214) forever, even though only the unspent transaction outputs (<2 GB) are required. Performance can improved by enabling <code>[https://bitcointalk.org/index.php?topic=1377345.0 -blocksonly]</code> mode and enabling [https://bitcoin.org/en/release/v0.12.0#wallet-pruning pruning].

===Archival Nodes===

A subset of full nodes also accept incoming connections and upload old blocks to other peers on the network. This happens if the software is run with <code>-listen=1</code> as is default. Contrary to some popular misconceptions, being an archival node is not necessary to being a full node. If a user's bandwidth is constrained then they can use <code>-listen=0</code>, if their disk space is constrained they can use pruning, all the while still being a fully-validating node that enforces bitcoin's consensus rules and contributing to bitcoin's overall security.

== Why should you use a full node wallet ==

==== Summary ====
Running a full node is the only way you can use Bitcoin in a trustless way. You will know for sure that all the rules of Bitcoin are being followed, for example that no bitcoins are spent not belonging to the owner, that no coins were spent twice, that no inflation happens outside of the [[Controlled_supply|schedule]] and that all the rules needed to make the system work (e.g. [[difficulty]]) are followed. Full nodes are currently the most [[Privacy|private]] way to use Bitcoin, with nobody else learning which bitcoin [[Address|addresses]] belong to you. Full nodes are the most secure way to use Bitcoin, they do not suffer from many attacks that affect lightweight wallets.

=== Economic strength ===

This is by far the most important reason for running a full node, though it is a little difficult to understand.

As explained previously, full nodes enforce the consensus rules no matter what. However, lightweight nodes do not do this. Lightweight nodes do whatever the majority of mining power says. Therefore, if most of the miners got together to increase their block reward, for example, lightweight nodes would blindly go along with it. If this ever happened, the network would split such that lightweight nodes and full nodes would end up on separate networks, using separate currencies. People using lightweight nodes would be unable to transact with people using full nodes. If all businesses and many users are using full nodes, then this network split is not a ''critical'' problem because users of lightweight clients will quickly notice that they can't send or receive bitcoins to/from most of the people who they usually do business with, and so they'll stop using Bitcoin until the evil miners are overcome, which is the appropriate response. ''However'', if almost everyone on the network is using lightweight nodes in this situation, then everyone would continue being able to transact with each other, and so Bitcoin could very well end up "hijacked" by evil miners.

In practice, miners are unlikely to attempt anything like the above scenario as long as full nodes are prevalent because the miners would lose a lot of money. But the incentives completely change if everyone uses lightweight nodes. In that case, miners definitely ''do'' have an incentive to change Bitcoin's rules in their favor. It is only reasonably secure to use a lightweight node ''because'' most of the Bitcoin economy uses full nodes.

Therefore, it is critical for Bitcoin's survival that the great majority of the Bitcoin economy be backed by full nodes, not lightweight nodes. This is especially important for Bitcoin businesses, which have more economic weight. To contribute to Bitcoin's economic strength, you must actually use a full node for your real transactions (or use a lightweight node connected to a full node that you personally control). Just running a full node on a server somewhere does not contribute to Bitcoin's economic strength.

More details https://www.reddit.com/r/BitcoinBeginners/comments/3eq3y7/full_node_question/ctk4lnd

=== Privacy ===

Downloading the entire blockchain is the most private way to operate a wallet. All other lightweight solutions leak information about which addresses are yours because they must query third-party servers. The Electrum servers will know which addresses belong to you and can link them together. Despite bloom filtering, SPV nodes based on BitcoinJ [[BIP37 privacy problems|do not provide much privacy]] against nodes who connected directly to the wallet.<ref>[https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/ Privacy in BitcoinJ ]</ref>

For some use cases, such privacy may not be required. But an important reason to run a full node and use it as a wallet is to get the full privacy benefits.

=== Security ===

Lightweight nodes are sometimes able to be temporarily tricked into accepting transactions or blocks that are not actually valid. This could cause serious financial damage, especially for websites that automatically process Bitcoin transactions. Full nodes provide the maximum security possible, and so they should be used by all businesses, and also by regular users whenever doing so is convenient.

=== Network services ===

Full nodes may provide various services to other network participants (if the software is run with <code>-listen=1</code> as is default). This is especially important for lightweight nodes.

These services include:
* Filtering transactions and blocks on behalf of lightweight nodes so that lightweight nodes do not need to download every transaction ever made on the network in order to find their own transactions.
* Serving historical full blocks to nodes that have been offline for a while.
* Transmitting new transactions from users to miners.
* Broadcasting new blocks from miners to other nodes.

For the most part, these services are only usefully performed by full nodes that are listening on port 8333. The more full nodes that accept incoming connections there are, the more users the Bitcoin network can support. Although if there is ever a shortage, lots of archival nodes can be easily created by cheaply renting VPS or AWS space.

=== Some are incentivizing it ===
Bitnodes ran a program to incentivize full node operators until the end of 2015.<ref>[https://bitcoinmagazine.com/19620/bitnodes-project-issues-first-incentives-node-operators/ Bitnodes Project Issues First Incentives For Node Operators by Joel Dalas] of [http://bitcoinmagazine.com/ <i>Bitcoin Magazine</i>]; cf. https://blog.bitcoinfoundation.org/bitnodes-project-2015-q1-report-peer-index-and-incentivized-full-nodes/</ref>

== How to run a full node ==

If you run the [[Bitcoin Core]]/[[bitcoind]] wallet, you are running a full node. If you open port 8333, you will contribute to the network's capacity. If you actually use the wallet feature, or if you use a lightweight client like [[MultiBit]] but configure it to connect exclusively to your full node, then you will contribute to the network's economic strength and receive protection from some possible attacks against lightweight nodes.

There are a few alternate full node implementations, but they are not recommended for serious use because it is currently difficult to determine whether they implement the consensus rules with 100% accuracy. Even very slight inaccuracies could cause serious problems for the users of these alternate clients. Example of implementations [https://bitcore.io/guides/full-node/ Bitcore], [[libbitcoin]], [[btcd]].

=== Tips and tricks for running a node ===

For [[Bitcoin Core]]:

* Bandwidth consumption can be reduced using this guide: https://btcinformation.org/en/full-node#reduce-traffic

* Requirement for disk space can be reduced using this guide: https://btcinformation.org/en/full-node#reduce-storage See also the [https://github.com/bitcoin/bitcoin/blob/v0.11.0/doc/release-notes.md#block-file-pruning release notes which explain pruning].

* This site has a nice predefined template for generating bitcoin config files https://jlopp.github.io/bitcoin-core-config-generator/

* Improve sync speed by increasing the dbcache value in configuration. This value controls how many megabytes of RAM to use for the database cache, increase it to as much as your hardware allows to reduce the disk operations and increase speed.

* To store the blockchain files on an external hard drive use <tt>-datadir</tt>. e.g. <tt>-datadir=/path/to/your/bitcoin/directory</tt>.

* Store the chainstate directory on an SSD drive to improve the speed.<ref>[https://www.reddit.com/r/Bitcoin/comments/7iaa3t/if_you_run_a_full_node_on_a_hdd_put_your/ If you run a full node on a hdd put your chainstate directory on an external ssd].</ref>
** See [[Splitting the data directory]]

See Also: [[Running Bitcoin]]

== See Also ==

* [[Clearing Up Misconceptions About Full Nodes]]

* [[Why Your Business Should Use a Full Node to Accept Bitcoin]]

* [[Bitcoin is not ruled by miners]]

==References==
<references />

[[Category:Technical]]
[[Category:Privacy]]

{{Bitcoin Core documentation}}