Bitcoin Wiki - User contributions [en]

API reference (JSON-RPC)

2015-04-30T15:46:51Z

Jcv: /* Go */

== Controlling Bitcoin ==

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.

To access the server you should find a [http://json-rpc.org/wiki/implementations suitable library] for your language.

== Proper money handling ==

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

== 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.getinfo()
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.getinfo
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:getinfo(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->getinfo()); 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 to write your wrapper you can use [[Bitcoin-JSON-RPC-Client|this implementation]] or [https://github.com/johannbarbie/BitcoindClient4J this one] .

== 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 => 'getinfo',
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 serialising 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.GetInfo();
Console.WriteLine("Balance:" + inf["balance"]);
</source>

A more complete library and wrapper for Bitcoin (also for Litecoin and all Bitcoin clones) 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();

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

== Node.js ==

* [https://github.com/freewil/node-bitcoin node-bitcoin] (npm: bitcoin)

Example using node-bitcoin:

<source lang="javascript">
var bitcoin = require('bitcoin');
var client = new bitcoin.Client({
host: 'localhost',
port: 8332,
user: 'user',
pass: 'pass'
});

client.getDifficulty(function(err, difficulty) {
if (err) {
return console.error(err);
}

console.log('Difficulty: ' + difficulty);
});
</source>

Example using Kapitalize:

<source lang='javascript'>
var client = require('kapitalize')()

client.auth('user', 'password')

client
.getInfo()
.getDifficulty(function(err, difficulty) {
console.log('Dificulty: ', difficulty)
})
</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": "getinfo", "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>

== 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/getinfo)
{"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>

== 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);
client.setUsername(app.arguments().takeAt(idx));
}

if (app.arguments().contains("-p")) {
int idx = app.arguments().indexOf("-p");
app.arguments().removeAt(idx);
client.setPassword(app.arguments().takeAt(idx));
}

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>

== See Also==

* [[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)]]

Proper Money Handling (JSON-RPC)

2015-04-30T12:08:07Z

Jcv: /* Go */

== Overview ==
The original bitcoin client stores all bitcoin values as 64-bit integers, with 1 BTC stored as 100,000,000 (one-hundred-million of the smallest possible bitcoin unit). Values are expressed as double-precision Numbers in the JSON API, with 1 BTC expressed as 1.00000000

If you are writing software that uses the JSON-RPC interface you need to be aware of possible floating-point conversion issues. You, or the JSON library you are using, should convert amounts to either a fixed-point Decimal representation (with 8 digits after the decimal point) or ideally a 64-bit integer representation. In either case, rounding values is required.

Improper value handling can lead to embarrassing errors; for example, if you truncate instead of doing proper rounding and your software will display the value "0.1 BTC" as "0.09999999 BTC" (or, worse, "0.09 BTC").

The original bitcoin client does proper, full-precision rounding for all values passed to it via the RPC interface. So, for example, if the value 0.1 is converted to the value "0.099999999999" by your JSON-RPC library, that value will be rounded to the nearest 0.00000001 bitcoin and will be treated as exactly 0.10 BTC.

The rest of this page gives sample code for various JSON libraries and programming languages.

== BASH ==
<source lang="bash">
function JSONtoAmount() {
printf '%.8f' "$1" | tr -d '.'
}
</source>

== C/C++ ==
C/C++ JSON libraries return the JavaScript Number type as type 'double'. To convert, without loss of precision, from a double to a 64-bit integer multiply by 100,000,000 and round to the nearest integer:
int64_t JSONtoAmount(double value) {
return (int64_t)(value * 1e8 + (value < 0.0 ? -.5 : .5));
}

To convert to a JSON value divide by 100,000,000.0, and make sure your JSON implementation outputs doubles with 8 or more digits after the decimal point:
double forJSON = (double)amount / 1e8;

== ECMAScript ==

function JSONtoAmount(value) {
return Math.round(1e8 * value);
}
== Java ==

public long JSONtoAmount(double value){
return (long)(value*100000000L);
}

== Perl ==
sub JSONtoAmount {
return sprintf '%.0f', 1e8 * shift;
}

== Go ==
The [https://github.com/btcsuite/btcd/btcjson btcjson package] provides a more complete version of this function (error checking and so on), but for illustrative purposes, this is useful.

func JSONToAmount(jsonAmount float64) (int64) {
var amount int64
tempVal := 1e8 * jsonAmount
if tempVal < 0 {
tempVal = tempVal - 0.5
}
if tempVal > 0 {
tempVal = tempVal + 0.5
}
// Then just rely on the integer truncating
amount = int64(tempVal)
return amount
}

== PHP ==
function JSONtoAmount($value) {
return round($value * 1e8);
}

== Python ==
def JSONtoAmount(value):
return long(round(value * 1e8))
def AmountToJSON(amount):
return float(amount / 1e8)

== Common Lisp ==
(defun json-to-amount (n)
(coerce (round (* n 1e8)) 'integer))

'''CAUTION''': The CL-JSON library parses numbers as ''single'' precision floating-point by
default. The default parsing behavior can be overridden as follows:

(set-custom-vars :real (lambda (n)
(json::parse-number (concatenate 'string n "d0"))))
[[Category:Technical]]
[[Category:Developer]]

[[de:Korrektes_Handling_von_Geldbeträgen_(JSON-RPC)]]

Clients

2015-04-30T12:07:32Z

Jcv: /* For developers */

==Overview==
A bitcoin client is the end-user software that facilitates [[private key]] generation and security, payment sending on behalf of a private key, and optionally provides:
* Useful information about the state of the network and transactions.
* Information related to the private keys under its management.
* Syndication of network events to other peer clients.

This table compares the features of the different clients. All of the listed clients are open-source.

===Feature key===

; Wallet Security : How well the client protects your [[private key]]s from people with access to the machine the wallet is stored on. The private keys can be encrypted, for example. The private keys can also be either stored on your device or on a remote server.
; Network Security : Clients which more fully implement the Bitcoin network protocol are safer -- they can't be as easily tricked by powerful attackers. A client which ''fully'' implements the protocol will always use the correct [[block chain]] and will never allow [[double-spending|double-spends]] or invalid transactions to exist in the block chain under any circumstances. Clients which only ''partially'' implement the protocol typically trust that 50% or more of the network's mining power is honest. Some clients trust one or more ''remote servers'' to protect them from double-spends and other network attacks.
; Setup Time : Some clients require that you download and verify a large amount of data before you can send or receive BTC.
; Maturity : When the project was started.

===Table===


{| class='wikitable' style='text-align: center'
! Client !! Get Started !! Audience !! Wallet Security !! Network Security !! Backups !! Setup Time !! Disk Space !! Maturity !! Multi-user !! Available for
|-
! [[Airbitz]]
|| [https://airbitz.co/app Download] || {{CLBest|Everyone}} || {{CLGood|Encrypted, on-device. Server backup}} || Partial || {{CLGood|Automatic}} || {{CLBest|Instant}} || {{CLGood|20 MB}} || Oct 2014 || {{CLBest|Multi-wallet}} || {{CLAndroid}}{{CLiOS}}
|-
! [[Armory]]
|| [https://bitcoinarmory.com/download Download] || Power users || {{CLGood|Encrypted, on-device}} || Addon || {{CLBest|One-time}} || {{CLBad|Hours}} || {{CLBad|40+ GB}} || Jul 2011 || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLMac}}{{CLWin}}
|-
! [[Bitcoin Core]]
|| [http://sourceforge.net/projects/bitcoin/files/Bitcoin/ Download] || {{CLGood|End-users}} || {{CLGood|Encrypted, on-device}} || {{CLBest|Full}} || Manual || {{CLBad|Hours}} || {{CLBad|20+ GB}} || {{CLGood|May 2011}} || No || {{CLLinux}}{{CLMac}}{{CLWin}}
|-
! [[bitcoind]]
|| [http://sourceforge.net/projects/bitcoin/files/Bitcoin/ Download] || Programmers || {{CLGood|Encrypted, on-device}} || {{CLBest|Full}} || Manual || {{CLBad|Hours}} || {{CLBad|20+ GB}} || {{CLBest|Aug 2009}} || {{CLGood|Virtual accounts}} || {{CLLinux}}{{CLWin}}
|-
! [[Bitcoin Wallet]]
|| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Google Play] [https://appworld.blackberry.com/webstore/content/23952882/ BlackBerry World] || {{CLGood|End-users}} || {{CLGood|Isolated, on-device}} || Partial || Manual || {{CLBest|Instant}} || {{CLGood|15 MB}} || {{CLGood|Mar 2011}} || on JB tablets || {{CLAndroid}} [[file:ico-blackberry.png]]
|-
! [[Electrum]]
|| [https://electrum.org/download.html Download] || Power users || {{CLGood|Encrypted, on-device}} || Minimal || {{CLBest|Memorized}} || {{CLGood|Minutes}} || {{CLGood|5 MB}} || Nov 2011 || No || {{CLAndroid}}{{CLLinux}}{{CLMac}}{{CLWin}}
|-
! [[GreenAddress]]
|| [https://greenaddress.it Web] [https://chrome.google.com/webstore/detail/greenaddressit/dgbimgjoijjemhdamicmljbncacfndmp ChromeApp] [https://play.google.com/store/apps/details?id=it.greenaddress.cordova&hl=en Google Play] || {{CLBest|Everyone}} || {{CLGood|Encrypted, on-device}} || {{CLBad|Remote}} || Memorized/Manual || {{CLBest|Instant}} || {{CLBest|None}} || Apr 2013 || {{CLBest|Yes}} || {{CLAndroid}}{{CLLinux}}{{CLMac}}{{CLWin}}
|-
! [[Gocoin]]
|| [https://github.com/piotrnar/gocoin Build yourself] || Power users || Designated offline PC || {{CLBest|Full}} || {{CLBest|Memorized}} || {{CLBad|Hours}} || {{CLBad|20+GB}} || May 2013 || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLMac}}{{CLWin}}{{CLFreeBSD}}
|-
! [[MultiBit]]
|| [https://multibit.org/releases.html Download] || {{CLGood|End-users}} || {{CLGood|Encrypted, on-device}} || Partial || {{CLGood|Automatic (local)}} || {{CLBest|Seconds}} || 50 MB || Jul 2011 || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLMac}}{{CLWin}}
|-
! [[Mycelium]]
|| [https://mycelium.com/download Download] [https://play.google.com/store/apps/details?id=com.mycelium.wallet Google Play]|| {{CLBest|Everyone}} || {{CLGood|Isolated, on-device}} || Partial || Manual, encrypted || {{CLBest|Instant}} || {{CLGood|10 MB}} || Sep 2013 || No || {{CLAndroid}}{{CLiOS}}
|-
! [[BlockChain.info#Wallet|My Wallet]]
|| [https://blockchain.info/wallet/new Web-based] || {{CLBest|Everyone}} || {{CLBad|Encrypted, on a blockchain.info server}} || {{CLBad|Remote}} || {{CLGood|Automatic}} || {{CLGood|Minutes}} || {{CLBest|None}} || Dec 2011 || {{CLBest|Yes}} || {{CLAndroid}}{{CLiOS}}{{CLLinux}}{{CLMac}}{{CLWin}}
|}



==For developers==

This table shows additional information about various Bitcoin clients that may be relevant to developers.

{| class='wikitable' style='text-align: center'
! Client !! Website !! Source Code !! License !! Discussion !! Architecture
|-
! Armory
|| [http://bitcoinarmory.com/ Link] ||[https://github.com/etotheipi/BitcoinArmory/ Github] || AGPLv3 || [https://bitcointalk.org/index.php?board=97.0 Bitcointalk] || Integrated
|-
! Bitcoin Wallet
|| [https://github.com/schildbach/bitcoin-wallet Link] || [https://github.com/schildbach/bitcoin-wallet Github] [https://code.google.com/p/bitcoin-wallet/source/checkout Google Code] || GPLv3 || [https://plus.google.com/b/101256420499771441772/communities/105515929887248493912 Google+ community] / [https://bitcointalk.org/index.php?board=100.0 Bitcointalk] || [[Thin Client Security#Simplified Payment Verification (SPV)|SPV]]
|-
! Bitcoin Core / bitcoind
|| [http://bitcoin.org/ Link] || [https://github.com/bitcoin/bitcoin Github] || MIT || [https://lists.sourceforge.net/lists/listinfo/bitcoin-development Sourceforge] || Integrated
|-
! Electrum
|| [http://ecdsa.org/electrum/ Link] || [https://gitorious.org/electrum Gitorious] || GPLv3 || [https://lists.sourceforge.net/lists/listinfo/electrum-discuss Sourceforge] || [[Thin Client Security#Simplified Payment Verification (SPV)|SPV]]
|-
! GreenAddress
|| [https://greenaddress.it/ Link] || [https://github.com/greenaddress/ Github] || LGPLv3 || [https://bitcointalk.org/index.php?topic=521988.0 Bitcointalk] || [[Server-Client+SPV(Electrum)]]
|-
! MultiBit
|| [http://multibit.org/ Link] || [https://github.com/jim618/multibit Github] || MIT || [https://groups.google.com/forum/?fromgroups#!forum/bitcoin-multibit Google Groups] || [[Thin Client Security#Simplified Payment Verification (SPV)|SPV]]
|-
! My Wallet
|| [https://blockchain.info/wallet/ Link] || [https://github.com/blockchain/My-Wallet/ Github] || BSD* || None || [[Thin Client Security#Server-Trusting Clients|Server-Client]]
|-
! bits of proof
|| [http://bitsofproof.com Link] || [https://github.com/bitsofproof/supernode Github] || Apache 2.0 || [https://bitcointalk.org/index.php?topic=122013.0 Bitcointalk] || [[Thin Client Security#Server-Trusting Clients|Server-Client]]
|-
! Gocoin
|| [http://www.assets-otc.com/gocoin Link] || [https://github.com/piotrnar/gocoin Github] || ? || [https://bitcointalk.org/index.php?topic=199306.0 Bitcointalk] || Integrated
|-
! btcd
|| [https://github.com/btcsuite/btcd Link] || [https://github.com/btcsuite/btcd Github] || ISC || [https://github.com/btcsuite/btcd#irc-server irc] || [[Thin Client Security#Server-Trusting Clients|Server-Client]]
|}

==See Also==
* [[Software#Bitcoin_clients|List of clients]]
* [[Bitcoin Ladder]]

<references/>

API reference (JSON-RPC)

2015-04-30T11:50:24Z

Jcv: /* Go */

== Controlling Bitcoin ==

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.

To access the server you should find a [http://json-rpc.org/wiki/implementations suitable library] for your language.

== Proper money handling ==

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

== 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.getinfo()
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.getinfo
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:getinfo(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->getinfo()); 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 to write your wrapper you can use [[Bitcoin-JSON-RPC-Client|this implementation]] or [https://github.com/johannbarbie/BitcoindClient4J this one] .

== 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 => 'getinfo',
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 serialising 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.GetInfo();
Console.WriteLine("Balance:" + inf["balance"]);
</source>

A more complete library and wrapper for Bitcoin (also for Litecoin and all Bitcoin clones) 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();

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

== Node.js ==

* [https://github.com/freewil/node-bitcoin node-bitcoin] (npm: bitcoin)

Example using node-bitcoin:

<source lang="javascript">
var bitcoin = require('bitcoin');
var client = new bitcoin.Client({
host: 'localhost',
port: 8332,
user: 'user',
pass: 'pass'
});

client.getDifficulty(function(err, difficulty) {
if (err) {
return console.error(err);
}

console.log('Difficulty: ' + difficulty);
});
</source>

Example using Kapitalize:

<source lang='javascript'>
var client = require('kapitalize')()

client.auth('user', 'password')

client
.getInfo()
.getDifficulty(function(err, difficulty) {
console.log('Dificulty: ', difficulty)
})
</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": "getinfo", "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>

== 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/getinfo)
{"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>

== 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);
client.setUsername(app.arguments().takeAt(idx));
}

if (app.arguments().contains("-p")) {
int idx = app.arguments().indexOf("-p");
app.arguments().removeAt(idx);
client.setPassword(app.arguments().takeAt(idx));
}

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>

== See Also==

* [[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)]]

How to accept Bitcoin, for small businesses

2014-04-01T20:20:02Z

Jcv:

{{merge|Merchant Howto}}

This guide is intended for small business owners who wish to help promote Bitcoin by accepting it as payment for goods and services. It's written with the assumption that you operate a regular business that sells goods or services for regular national currency such as dollars, and that you wish to accept Bitcoin as another legal way to pay, and that you intend to pay taxes on your Bitcoin income just like any other income.

With Bitcoin being touted as a way to conduct anonymous transactions and as way to compete with government currency, many small business owners wonder what's the right way to accept and account Bitcoin, or if it's legal or ethical, or whether and how they should pay taxes on income received through Bitcoin.

As far as we know, Bitcoin isn't yet formally recognized by governments and authorities as a "currency". But in practice, Bitcoin is likely no different than accepting payment in other forms, such as cash, or gold, or scrip, or gift cards or foreign currency. We think that it is pretty much the same as the local businesses of Great Barrington, Massachusetts choosing to accept their locally-printed [http://www.reuters.com/article/2007/06/19/us-usa-economy-berkshares-idUSN0530157720070619 "Berkshire Bucks"] to support their local economy.

====Starting to accept Bitcoin for transactions====
Accepting Bitcoin at a small business is best started in whichever manner keeps the accounting simple for you. This will vary by the type of business you are operating.

===Start with a sign===
[[{{ns:file}}:WeAcceptBitcoin.png‎]]

If you expect that the number of people interested in using Bitcoin is small, you might simply start by posting a sign or a note: "We Accept Bitcoin", and ask people to contact you directly in order to make a payment. Even if hardly anybody uses Bitcoin as a payment method, you're helping Bitcoin in two ways: one, by increasing awareness, and two, by making your customers more willing to accept Bitcoin as payment from others in the future, because now they know somewhere they can spend it.

===Utilize a merchant solution===
If you sell things on your website (goods or services), you'll want to use a [[#Merchant Services|Bitcoin merchant solution]] to accept the Bitcoins (you can usually opt to have them converted to USD or other currencies automatically with some services).

If you sell things in a brick and mortar shop, customers can pay using hardware terminals, touch screen apps or simple wallet addresses through QR Codes.

[[File:Bitcoin-pos-terminal.png|200 px|alt=Bitcoin POS Terminal|Coinkite terminal]] [[File:Mobile_Web_App_Bitcoin_Register.jpeg|100 px|alt=Bitcoin POS Terminal|CoinBox terminal]]

===Smart Phone or Tablet===
You can use a wallet address with any wallet. For that it's best if you can place a QR code near your register to which the customers can scan with their phone and pay (use http://ma.eatgold.com/accept to make a QR code sign).

==== Examples ====

* [[File:BitcoinRegister.gif|20px|link=http://coinbox.it/merchant]][http://coinbox.it/merchant CoinBox]
* [[File:BIPS.gif|20px|link=https://bips.me]] [https://bips.me BIPS]
* [http://www.blockchain.info/wallet Blockchain.info]
* [https://www.xcoinmoney.com/ xCoinMoney] Online wallet for instant payment and subscriptions
* [https://coinbase.com/docs/merchant_tools/point_of_sale Coinbase]
* [[File:Coinkite.gif|20px|link=https://coinkite.com/promo/wikibiz]] [https://coinkite.com/promo/wikibiz Coinkite]
* [[File:gocoin-logo.png|20px|link=https://www.gocoin.com]] [https://www.gocoin.com GoCoin International Payment Processing for accepting Bitcoin and Litecoin payments]
* [http://www.mycoinsolution.com My Coin Solution] - Bitcoin consulting services and solutions
* [[File:Coin_Of_Sale_logo.png|20px|link=https://coinofsale.com]] [https://coinofsale.com Coin Of Sale] - device-independent Bitcoin POS payment system for retail merchants

===Point-of-Sale hardware terminal===
With custom hardware you can integrate with existing registers and point-of-sales solutions (example: [[File:Coinkite.gif|20px|link=https://coinkite.com/promo/wikibiz]] [https://coinkite.com/promo/wikibiz Coinkite]).

===Accounting===
When a customer makes a payment, you might simply issue a credit to their account. Ideally, you want to enter it in a way that suggests you received a payment. You could consider entering it as a "discount", but you may want to consider whether this inappropriately disguises the nature of the transaction. If on the other hand, you're giving "discounts" for Bitcoins, but then you are selling the Bitcoins for currency and then counting that as income, then chances are good that your calculation of income is making up for it. Ask your accountant.

===Businesses that offer gift cards===
If your business sells gift cards or gift certificates, you may find that the easiest way to accept Bitcoin is to accept it only for the purchase of gift cards, and then require the gift cards to be used for actual purchases of goods or services. This way, the accounting practices you already have in place for processing gift cards can be put to use. The accounting for Bitcoins would then be minimized to tracking sales of a single SKU.

This method is also ideal for retail food establishments and convenience stores, where the payment of Bitcoins through a mobile phone for a small daily food purchase might be cumbersome or disruptive, especially in front of a line of other customers. Bitcoins in this case would be best used to reload prepaid cards that can then be swiped at point-of-sale.

If you don't accept gift cards, but you already accept credit cards through a swipe terminal, consider the possibility that you could add a retail gift card system through the swipe terminal you already own. Many point-of-sale terminals, including ones from VeriFone®, are designed around the ability to support multiple applications on the same terminal. Gift cards are also highly profitable because of "breakage", or in other words, the fact that a significant percentage of them never get redeemed.

You could consider adding a private label gift card program from a provider who specializes in this, not just as a jumpstart to accepting Bitcoins, but as an extra boost to income. A private label gift card service provider necessarily have to handle your funds - they can simply provide a solution that keeps track of the balance on the cards on your behalf, including features that allow users to check their balances by phone or by web. Such a solution, of course, is also what makes the cards swipeable through the card reader.

===Businesses that mail invoices===
Does your business send out invoices to customers? Adding one line may make a huge impact for the Bitcoin economy. Perhaps you list it as a payment option just after Visa, MasterCard, and American Express, even if that means your customer must call or e-mail to make a payment.

If you have access to the programming expertise such that you can generate Bitcoin addresses programmatically, consider generating a brand new Bitcoin address for each invoice, and print it on the invoice. When a Bitcoin payment arrives, you'll automatically know where it should arrive.

Customers might wonder how much BTC they should pay in order to satisfy an invoice in full. Your invoice might suggest an amount. For example, if your invoice is for $100 and BTC's are currently worth $1.24 each, your invoice might suggest that it can be paid in full ''"with a payment of 80.65 BTC if paid by (date)"''.

You might be able to anticipate the possibility that even though a Bitcoin address can be printed on an invoice or payment stub, that they are very cumbersome for most people to type, especially being a mix of uppercase and lowercase letters. However, you should probably still do it anyway. The customer is probably going to want some paper trail for his payment. Giving him a pre-printed payment stub with a pre-printed address will satisfy that, because the customer can independently and publicly prove through [[Block Explorer]] that the payment took place.

Does your business have a website? On your invoice, consider allowing them to go to a special URL to get the address to make a Bitcoin payment just by typing in their invoice number. For example, ''ht<nowiki>tps://ww</nowiki>w.yoursite.com/paybtc'' with a form they can enter their invoice number, or just ''ht<nowiki>tps://ww</nowiki>w.yoursite.com/paybtc/60365'' for paying invoice #60365. This way, they can see the Bitcoin address, copy and paste it directly into their Bitcoin client.

Use a brand new address for each invoice whenever possible, and use it only once. This benefits the customer as it removes any ambiguity as to which customer is making which payment and for which invoice.

Known payment systems supporting invoicing, and recurring invoice setup, [[File:BIPS.gif|20px|link=https://bips.me/checkout/invoice/cb/bb]] [https://bips.me/checkout/invoice/cb/bb BIPS]

Online wallet supporting invoicing, subscriptions and recurrent payments, [https://www.xcoinmoney.com/info/sending-paying-invoices xCoinMoney]

===Avoiding fraud===

You should also consider the possible risk that fraudsters could send counterfeit invoices to your customers, and entice them to make a payment to a Bitcoin address they control, instead of you. While that isn't likely in general - it depends on how well a fraudster could find out who your customers are in the first place - it would certainly be an unpleasant situation if it ever happened. One way you could control that is, whenever possible, never let people try to type Bitcoin addresses off payment stubs - instead, force people to get the full Bitcoin address from your website via secure SSL. But, still print ''most'' of the address on the payment stub (perhaps with four or five characters starred out), so that the customer's need for a paper trail can be satisfied, so they can prove they paid if there is ever a dispute.

==Setting Prices==

When a business accepts bitcoins for payment, there generally is the need to convert them to the currencies used for paying suppliers, employees and shareholders. Some merchants set prices based on the current market rate at the time the price quote is presented to the customer (merchant services like [[File:BIPS.gif|20px|link=https://bips.me]] [https://bips.me BIPS], [http://www.bit-pay.com Bit-pay], [https://coinbase.com Coinbase] or [http://paysius.com Paysius] do this automatically).

[[Bitcoin Prices]] lists the exchange rate for many currencies on multiple exchanges.

When prices are determined using an automated process, the current market rate can be based on either a current price or on a weighted average basis. [[Bitcoin Charts]] provides a [http://bitcoincharts.com/about/markets-api data feed that provides weighted prices].

When bitcoin funds for purchases are received, some merchants instantly exchange those proceeds into the preferred currency used (again done automatically by [[File:BIPS.gif|20px|link=https://bips.me]] [https://bips.me BIPS], [http://www.bit-pay.com Bit-pay] or [https://coinbase.com Coinbase]. Hedging for each transaction can nearly entirely eliminate exchange rate risk that the business is exposed to when accepting bitcoins for payment.

==Contract==

A sales contract might be used to ensure that specific terms are met to lessen the chances of a misunderstanding. For instance, the party sending payment is responsible for paying any [[transaction fee]] that might be necessary. A contract might specify that a transaction fee must be paid and what amount, so as to prevent the situation where the transaction is considered a low priority transaction and thus isn't confirmed quickly.

Other items that might be addressed in a contract:

* Requirement and handling of escrow through an [[:Category:Escrow_services|escrow service]].
* Jurisdiction for disputes.
* Refund policy (particularly with the exchange rate being volatile)

==Paying taxes on Bitcoin income==
[[Tax compliance]] is a topic of concern for small businesses. We aren't accountants or lawyers, and can't give legal or accounting advice.

But in many respects, Bitcoin transactions work very much like cash. Just like Bitcoin, cash is anonymous and doesn't leave a paper trail, yet is widely used in commerce every day.

Ask yourself how you would handle a cash transaction. Do you accept cash transactions? Do you normally pay taxes on cash transactions? The answer for Bitcoin should probably be the same.

As for how to decide what a Bitcoin transaction is worth... the IRS, as far as we know, has never issued a guide mentioning how to value Bitcoin transactions. But they probably have rules and guidelines on how to value transactions made in foreign currency or "cash equivalents". We imagine the accounting would be similar.

With Bitcoins, there's likely to be some difference between the value of BTC when you received them as payment, versus when you go to exchange them for another currency like USD, should you decide to do so. This scenario, likewise, would be no different if you accepted foreign currency or gold as payment. Under some scenarios, it might make sense to book the dollar value of BTC income as it is received, and then to book any difference incurred when it is exchanged for fiat currency. Under others, it might make sense to book the whole thing at the time of exchange.

Perhaps you might talk to your accountant. You don't need to get into a discussion with your accountant about block chains and private keys or the philosophy behind a decentralized currency. By comparing the fundamentals of Bitcoins to accounting concepts already well understood by the public, you can probably get all the answers you need. What would you ask your accountant if you decided that you wanted to accept ''Berkshire Bucks'' or 1-ounce gold coins as payment?

== Merchant Services ==
* [http://blockchain.info/api/api_receive Blockchain.info] Free APIs to process bitcoin payments. No sign up or account needed.
* [[File:BitcoinRegister.gif|20px|link=http://coinbox.it/merchant]] [http://coinbox.it/merchant CoinBox] Bitcoin Point of Sales application for Android, with integration into various exchanges. Similar to Square.
* [[File:BIPS.gif|20px|link=https://bips.me]] [https://bips.me BIPS] Payment Service Provider (PSP) specializing in the technical aspects of accepting cryptocurrencies - such as bitcoin. Supports Bitcoin Web Payments, Mobile Checkout, In-store Bitcoin Payments and Bitcoin Invoicing with recurring billing in bitcoin.
* [https://www.bitpay.com BitPay] Bitcoin payment processor with mobile checkout solution
* [https://www.xcoinmoney.com/ xCoinMoney] Online wallet for instant payment and subscriptions.
* [https://www.bitpagos.net BitPagos] Bitcoin and Credit Card payment processor
* [https://www.btcmerch.com BTCMerch] Payment processor for bitcoins and other cryptocurrencies. 0.5% transaction fee. Sandbox is available.
* [https://bitmerch.com BitMerch] Provides HTML buttons to start accepting bitcoins instantly. No server side setup required.
* [https://coinbase.com/docs/merchant_tools/payment_buttons Coinbase] Offers payment buttons, checkout pages, shopping cart integration, and daily cash out to USD.
* [[File:Coinkite.gif|20px|link=https://coinkite.com]] [https://coinkite.com/faq/terminal Coinkite] Full-reserve banking, payment buttons, invoice pages, hardware POS terminals, and Debit-Cards.
* [https://mtgox.com/merchant MTGOX] Bitcoin payment processing
* [https://www.okpay.com/en/services/accept-payments/index.html OKPAY] Bitcoin payment processing for merchants
* [http://fasterco.in Fasterco.in] Bitcoin payment processing for merchants and day-traders
* [http://snowcron.com Snowcron] Bitcoin Store Engine: Handles payments, sends your customers information they ordered (reg. codes, passwords...) No web programming required.
* [[File:gocoin-logo.png|20px|link=https://www.gocoin.com]] [https://www.gocoin.com/docs GoCoin International payment gateway and processing platform for Merchants]
* [https://coinvoice.com/ Coinvoice] Invoice in USD or BTC, Get paid in USD or BTC.

== Help this article ==

This article is a stub, please add to it!

==See Also==

* [[Merchant Howto]]
* [[In-store Transactions]]
* [[Tax compliance]]
* [[Securing online services]]
* [[BitCoins Mobile]] provides accurate up to date pricing from multiple exchanges from your Apple iPad, iPhone, or iPod Touch.
* [[Bitcoin PayFlow]] automates the process for accepting bitcoins
* [[Lazy API]] The lazy (and possibly easiest?) way to accept bitcoin payments on your website

[[Category:ECommerce]]
[[Category:Local]]

[[de:Bitcoin_als_Geschäft_akzeptieren]]

Thin Client Security

2014-03-07T19:41:19Z

Jcv: /* btcd] */

Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page will refer to all such clients as "thin clients". This page is meant to be a place to try to make sense of the security and trust implications of the various schemes.

== Block Height vs. Depth ==

It is important to distinguish between block height verification and block depth verification.

A client verifies the height H of a block by checking that there are H block '''before''' it, all of which are well-formed and obey the maximum-difficulty-adjustment-rate rule. Currently only the Satoshi client, libbitcoin, and btcd do block height verification. Block height is the fundamental anchor of trustless security in the Bitcoin system.

A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients substitute block depth for block height as a transaction validity check. All clients use block depth as a measure of the liklihood of a [[Chain_Reorganization|blockchain reorganization]] producing a new longer fork which excludes the transaction (i.e. [[Orphan_Block|orphaning]] its block).

See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].

== Full-Chain Clients ==

The "thick" bitcoin client downloads a copy of the entire chain, including all transactions (not just headers). It will be used as the reference point for security comparisions below.

=== Block '''Height''' as a Transaction Validity Check ===

A full-chain client trusts the difficultywise-longest [https://en.bitcoin.it/wiki/Protocol_rules#Blocks well-formed] blockchain it can find. Any transaction on the difficultywise-longest well-formed chain is considered valid. Therefore, the validity of a transaction is determined by its height -- i.e. how many blocks come ''before'' it. A transaction's ''depth'' (the number of blocks ''after'' it) is used to determine the likelihood of the transaction being invalidated due to the emergence of a longer fork.

==== [[bitcoind|bitcoin core]] ====

==== [https://github.com/conformal/btcd btcd] ====

== Header-Only Clients ==

These client downloads a complete copy of the headers for all blocks in the entire blockchain. This means that the download and storage requirements scale linearly with the amount of time since bitcoin was invented; it would be preferable to have the scaling be logarithmic or even constant.

=== Simplified Payment Verification (SPV) ===

This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].

==== Block '''Depth''' as a Transaction Validity Check ====

As Satoshi writes, "[the thin client] can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it." If we take "X" to be the "number of blocks added after it", then SPV essentially trusts that a transaction X blocks deep in the chain does not have inputs which were already spent further back in the chain. Therefore, the validity of a transaction is determined by its depth -- i.e. how many blocks come ''after'' it. Other thin client protocols also include this assumption.

This is very different from the trust model in the "thick" client: the thick client verifies that a transaction's inputs are unspent by actually checking the whole chain up to that point -- there is no "X blocks deep" involved here. The thick client uses "X blocks deep" (aka "confirmations") only once it has already decided that a transaction is valid (i.e. no [[Double-spending|double-spends]]). At that point it uses "X blocks deep" to decide how likely it is that a longer fork in the chain will emerge which excludes that transaction.

It is very important to understand how the same property ("X blocks deep") is used to verify two different properties in the thick client and SPV cases. '''The thick client never uses block depth as a measure of transaction validity; the SPV client does'''.

This is a concern in a situation where an SPV client is subjected to a double-spend attack by somebody who controls its network connection. For example, suppose you are at a wi-fi cafe and are paying for something using your smartphone -- the cafe owner controls your network connection. Satoshi acknowledges this implicitly when he writes that "the verification is reliable as long as honest nodes control the network" -- to be completely pedantic, this means that the verification is reliable as long as honest nodes control '''the part of the network that the SPV client is able to communicate with'''. In an attack-by-ISP scenario this may not be a sufficiently strong security property. The attacker would not need to overpower "the rest of the network" because the client is unable to communicate with it.

==== [[BitCoinJ|bitcoinj]] ====

Simplified Payment Verification is the verification mechanism used in [[BitCoinJ|bitcoinj]].

A security analysis of some of the issues in bitcoinj can be found [http://code.google.com/p/bitcoinj/wiki/SecurityModel here]; however:

* The claim that "picking 10 nodes and requiring all of them to be consistent needs much less trust" overlooks the problem of [https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes "cancer nodes"] and [http://en.wikipedia.org/wiki/Sybil_attack Sybil attacks].
* Many of the security claims are qualified by some form of "if you don't think an attacker controls your internet connection"; see the previous section for a discussion of why this is problematic.

==== [https://bitcointalk.org/index.php?topic=128055.0 picocoin] ====

Simplified Payment Verification is the verification mechanism used in picocoin.

The library (libccoin) that picocoin is based on includes code for validating scripts and blocks; this could potentially be used to implement a full-chain client.

==== [[Electrum]] ====

ThomasV [https://en.bitcoin.it/w/index.php?title=Thin_Client_Security&action=historysubmit&diff=42844&oldid=36519 claims] that "Electrum, it is doing SPV since 2012".

=== Unused Output Tree in the Blockchain (UOT) ===

There have been several proposals (the first appears to be [https://bitcointalk.org/index.php?topic=21995.0 this one] by gmaxwell, who called it an "open transaction tree", although the term "open" is now taken to mean "not yet mined into the blockchain" rather than "unspent") to form a tree of unused transaction outputs at each block in the chain, hash it as a Merkle tree, and encode the root hash in the block chain (probably as part of the coinbase input). This will be called an Unused Output Tree (UOT). The first detailed proposal so far appears to be [https://en.bitcoin.it/wiki/User:DiThi/MTUT Alberto Torres' proposal]; etotheipi's [https://bitcointalk.org/index.php?topic=88208.0 ultimate blockchain compression] is a variant of this.

If such UOT hashes were included in the blockchain, a client which shipped with a [https://en.bitcoin.it/wiki/Vocabulary checkpoint] block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing a UOT.

This would also let a thin client reduce the question of "is this output unspent" to the question of "is this block super-well-formed" where "well-formed" means "well-formed according to the normal blockchain rules and additionally has an Unused Output Tree which is accurate and truthful". This is still a long way from the low level of trust involved in the thick client, but it is a major improvement over all existing proposals.

It is unlikely that bitcoin would ever arrive at a state where every single block had a UOT, since this would require upgrading 100% of the miners on the network, or else convincing enough miners to reject blocks which do not contain a UOT. The latter strategy risks creating blockchain forks, which can be expensive (in reward terms) to miners. Therefore, any UOT strategy would need to cope with the fact that not every block contains a UOT.

Hostile miners may insert blocks into the chain which have what claims to be a UOT, but which is actually invalid. It is unlikely that such blocks could be kept out of the chain because, again, this would require adding a new block well-formedness criterion, and miners implementing this new criterion would risk "mining on the wrong side" of a fork, which could cost them a lot of money. Therefore, any UOT strategy would need to cope with the fact that not every block containing a UOT entry can be trusted.

Note that at the present moment no standard format for such Unused Output Tree hashes has been agreed upon, nor do any of the blocks in the chain contain them. The [https://bitcointalk.org/index.php?topic=91954 ultraprune] feature added to bitcoind-0.8 maintains a similar data structure on the client's disk. It does not put this data structure or its hash anywhere in the blockchain.

== Server-Trusting Clients ==

These clients involve some (usually low) level of trust in the server they rely upon. Mechanisms for authenticating the server, and for confirming that the server has not been compromised, are usually not explained.

All thin clients listed below currently connect to a single server, and are vulnerable to an attack similar to a double-spend. The attack can be run by that single server - the server can just lie to them that they received a Bitcoin transaction, and they, assuming the server does not lie, perform some service, transfer funds or send goods without actually receiving any Bitcoin in exchange. Therefore, they are implicitly trusting it.

Future enhancements have been suggested that will have the client talk to multiple servers and broadcast transactions and query all of them. Unfortunately it is well known to security researchers that this does not actually increase security; it simply makes the exploits more complicated and difficult to find. Security researchers have a name for this phenomenon: it is called a "Sybil attack"<ref>http://en.wikipedia.org/wiki/Sybil_attack</ref>. [https://bitcointalk.org/index.php?topic=88208.msg975201#msg975201 This post] on bitcointalk explains how some governments (notably Iran and China) already perform these sorts of attacks on their own citizens, with the coerced assistance of SSL certificate authorities.

Clients with a checkpoint (even a very old one) that download and validate the headers for the whole blockchain are [http://bitcoinmedia.com/the-irc-bootstrap-method-is-flawed/#comment-4243 not vulnerable] to Sybil attacks in the following sense: they can always ensure that an attack would cost more than the amount being stolen.

=== [[BCCAPI]] ===

== Other ==

* A [http://sourceforge.net/mailarchive/message.php?msg_id=28633866 thread] on bitcoin-dev
* A [http://bitcoin.stackexchange.com/questions/2584/is-reclaiming-disk-space-already-implemented-how-effective-will-it-be/2589 question] on bitcoin.stackexchange.com
* The [https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes "cancer nodes"] paragraph explains some of the issues with thin clients that base security on trusting whatever "a majority of the IP addresses I can see" say.
* [http://bitcoin.stackexchange.com/questions/2613/how-secure-are-various-models-of-bitcoin-clients related discussion on Stack Exchange]
* A hypothesized [https://bitcointalk.org/index.php?topic=134318.msg1441171#msg1441171 intermediate security class] between SPV and full-chain validation.

<references>

[[Category:Technical]]
[[category:Clients]]
[[Category:Security]]

Thin Client Security

2014-03-07T19:33:16Z

Jcv: /* Block Height as a Transaction Validity Check */

Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page will refer to all such clients as "thin clients". This page is meant to be a place to try to make sense of the security and trust implications of the various schemes.

== Block Height vs. Depth ==

It is important to distinguish between block height verification and block depth verification.

A client verifies the height H of a block by checking that there are H block '''before''' it, all of which are well-formed and obey the maximum-difficulty-adjustment-rate rule. Currently only the Satoshi client, libbitcoin, and btcd do block height verification. Block height is the fundamental anchor of trustless security in the Bitcoin system.

A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients substitute block depth for block height as a transaction validity check. All clients use block depth as a measure of the liklihood of a [[Chain_Reorganization|blockchain reorganization]] producing a new longer fork which excludes the transaction (i.e. [[Orphan_Block|orphaning]] its block).

See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].

== Full-Chain Clients ==

The "thick" bitcoin client downloads a copy of the entire chain, including all transactions (not just headers). It will be used as the reference point for security comparisions below.

=== Block '''Height''' as a Transaction Validity Check ===

A full-chain client trusts the difficultywise-longest [https://en.bitcoin.it/wiki/Protocol_rules#Blocks well-formed] blockchain it can find. Any transaction on the difficultywise-longest well-formed chain is considered valid. Therefore, the validity of a transaction is determined by its height -- i.e. how many blocks come ''before'' it. A transaction's ''depth'' (the number of blocks ''after'' it) is used to determine the likelihood of the transaction being invalidated due to the emergence of a longer fork.

==== [[bitcoind|bitcoin core]] ====

==== [https://github.com/conformal/btcd btcd]] ====

== Header-Only Clients ==

These client downloads a complete copy of the headers for all blocks in the entire blockchain. This means that the download and storage requirements scale linearly with the amount of time since bitcoin was invented; it would be preferable to have the scaling be logarithmic or even constant.

=== Simplified Payment Verification (SPV) ===

This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].

==== Block '''Depth''' as a Transaction Validity Check ====

As Satoshi writes, "[the thin client] can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it." If we take "X" to be the "number of blocks added after it", then SPV essentially trusts that a transaction X blocks deep in the chain does not have inputs which were already spent further back in the chain. Therefore, the validity of a transaction is determined by its depth -- i.e. how many blocks come ''after'' it. Other thin client protocols also include this assumption.

This is very different from the trust model in the "thick" client: the thick client verifies that a transaction's inputs are unspent by actually checking the whole chain up to that point -- there is no "X blocks deep" involved here. The thick client uses "X blocks deep" (aka "confirmations") only once it has already decided that a transaction is valid (i.e. no [[Double-spending|double-spends]]). At that point it uses "X blocks deep" to decide how likely it is that a longer fork in the chain will emerge which excludes that transaction.

It is very important to understand how the same property ("X blocks deep") is used to verify two different properties in the thick client and SPV cases. '''The thick client never uses block depth as a measure of transaction validity; the SPV client does'''.

This is a concern in a situation where an SPV client is subjected to a double-spend attack by somebody who controls its network connection. For example, suppose you are at a wi-fi cafe and are paying for something using your smartphone -- the cafe owner controls your network connection. Satoshi acknowledges this implicitly when he writes that "the verification is reliable as long as honest nodes control the network" -- to be completely pedantic, this means that the verification is reliable as long as honest nodes control '''the part of the network that the SPV client is able to communicate with'''. In an attack-by-ISP scenario this may not be a sufficiently strong security property. The attacker would not need to overpower "the rest of the network" because the client is unable to communicate with it.

==== [[BitCoinJ|bitcoinj]] ====

Simplified Payment Verification is the verification mechanism used in [[BitCoinJ|bitcoinj]].

A security analysis of some of the issues in bitcoinj can be found [http://code.google.com/p/bitcoinj/wiki/SecurityModel here]; however:

* The claim that "picking 10 nodes and requiring all of them to be consistent needs much less trust" overlooks the problem of [https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes "cancer nodes"] and [http://en.wikipedia.org/wiki/Sybil_attack Sybil attacks].
* Many of the security claims are qualified by some form of "if you don't think an attacker controls your internet connection"; see the previous section for a discussion of why this is problematic.

==== [https://bitcointalk.org/index.php?topic=128055.0 picocoin] ====

Simplified Payment Verification is the verification mechanism used in picocoin.

The library (libccoin) that picocoin is based on includes code for validating scripts and blocks; this could potentially be used to implement a full-chain client.

==== [[Electrum]] ====

ThomasV [https://en.bitcoin.it/w/index.php?title=Thin_Client_Security&action=historysubmit&diff=42844&oldid=36519 claims] that "Electrum, it is doing SPV since 2012".

=== Unused Output Tree in the Blockchain (UOT) ===

There have been several proposals (the first appears to be [https://bitcointalk.org/index.php?topic=21995.0 this one] by gmaxwell, who called it an "open transaction tree", although the term "open" is now taken to mean "not yet mined into the blockchain" rather than "unspent") to form a tree of unused transaction outputs at each block in the chain, hash it as a Merkle tree, and encode the root hash in the block chain (probably as part of the coinbase input). This will be called an Unused Output Tree (UOT). The first detailed proposal so far appears to be [https://en.bitcoin.it/wiki/User:DiThi/MTUT Alberto Torres' proposal]; etotheipi's [https://bitcointalk.org/index.php?topic=88208.0 ultimate blockchain compression] is a variant of this.

If such UOT hashes were included in the blockchain, a client which shipped with a [https://en.bitcoin.it/wiki/Vocabulary checkpoint] block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing a UOT.

This would also let a thin client reduce the question of "is this output unspent" to the question of "is this block super-well-formed" where "well-formed" means "well-formed according to the normal blockchain rules and additionally has an Unused Output Tree which is accurate and truthful". This is still a long way from the low level of trust involved in the thick client, but it is a major improvement over all existing proposals.

It is unlikely that bitcoin would ever arrive at a state where every single block had a UOT, since this would require upgrading 100% of the miners on the network, or else convincing enough miners to reject blocks which do not contain a UOT. The latter strategy risks creating blockchain forks, which can be expensive (in reward terms) to miners. Therefore, any UOT strategy would need to cope with the fact that not every block contains a UOT.

Hostile miners may insert blocks into the chain which have what claims to be a UOT, but which is actually invalid. It is unlikely that such blocks could be kept out of the chain because, again, this would require adding a new block well-formedness criterion, and miners implementing this new criterion would risk "mining on the wrong side" of a fork, which could cost them a lot of money. Therefore, any UOT strategy would need to cope with the fact that not every block containing a UOT entry can be trusted.

Note that at the present moment no standard format for such Unused Output Tree hashes has been agreed upon, nor do any of the blocks in the chain contain them. The [https://bitcointalk.org/index.php?topic=91954 ultraprune] feature added to bitcoind-0.8 maintains a similar data structure on the client's disk. It does not put this data structure or its hash anywhere in the blockchain.

== Server-Trusting Clients ==

These clients involve some (usually low) level of trust in the server they rely upon. Mechanisms for authenticating the server, and for confirming that the server has not been compromised, are usually not explained.

All thin clients listed below currently connect to a single server, and are vulnerable to an attack similar to a double-spend. The attack can be run by that single server - the server can just lie to them that they received a Bitcoin transaction, and they, assuming the server does not lie, perform some service, transfer funds or send goods without actually receiving any Bitcoin in exchange. Therefore, they are implicitly trusting it.

Future enhancements have been suggested that will have the client talk to multiple servers and broadcast transactions and query all of them. Unfortunately it is well known to security researchers that this does not actually increase security; it simply makes the exploits more complicated and difficult to find. Security researchers have a name for this phenomenon: it is called a "Sybil attack"<ref>http://en.wikipedia.org/wiki/Sybil_attack</ref>. [https://bitcointalk.org/index.php?topic=88208.msg975201#msg975201 This post] on bitcointalk explains how some governments (notably Iran and China) already perform these sorts of attacks on their own citizens, with the coerced assistance of SSL certificate authorities.

Clients with a checkpoint (even a very old one) that download and validate the headers for the whole blockchain are [http://bitcoinmedia.com/the-irc-bootstrap-method-is-flawed/#comment-4243 not vulnerable] to Sybil attacks in the following sense: they can always ensure that an attack would cost more than the amount being stolen.

=== [[BCCAPI]] ===

== Other ==

* A [http://sourceforge.net/mailarchive/message.php?msg_id=28633866 thread] on bitcoin-dev
* A [http://bitcoin.stackexchange.com/questions/2584/is-reclaiming-disk-space-already-implemented-how-effective-will-it-be/2589 question] on bitcoin.stackexchange.com
* The [https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes "cancer nodes"] paragraph explains some of the issues with thin clients that base security on trusting whatever "a majority of the IP addresses I can see" say.
* [http://bitcoin.stackexchange.com/questions/2613/how-secure-are-various-models-of-bitcoin-clients related discussion on Stack Exchange]
* A hypothesized [https://bitcointalk.org/index.php?topic=134318.msg1441171#msg1441171 intermediate security class] between SPV and full-chain validation.

<references>

[[Category:Technical]]
[[category:Clients]]
[[Category:Security]]

Thin Client Security

2014-03-07T19:22:24Z

Jcv: /* Block Height vs. Depth */

Recently there have been a number of proposals for bitcoin clients which do not store a complete copy of every block in the entire block chain. This page will refer to all such clients as "thin clients". This page is meant to be a place to try to make sense of the security and trust implications of the various schemes.

== Block Height vs. Depth ==

It is important to distinguish between block height verification and block depth verification.

A client verifies the height H of a block by checking that there are H block '''before''' it, all of which are well-formed and obey the maximum-difficulty-adjustment-rate rule. Currently only the Satoshi client, libbitcoin, and btcd do block height verification. Block height is the fundamental anchor of trustless security in the Bitcoin system.

A client verifies the depth D of a block by checking that there are D blocks '''after''' it (also called "confirmations"), all of which are well-formed. SPV clients substitute block depth for block height as a transaction validity check. All clients use block depth as a measure of the liklihood of a [[Chain_Reorganization|blockchain reorganization]] producing a new longer fork which excludes the transaction (i.e. [[Orphan_Block|orphaning]] its block).

See also [https://bitcointalk.org/index.php?topic=88208.msg987429#msg987429 some comments on probabilistic verification of block height].

== Full-Chain Clients ==

The "thick" bitcoin client downloads a copy of the entire chain, including all transactions (not just headers). It will be used as the reference point for security comparisions below.

=== Block '''Height''' as a Transaction Validity Check ===

A full-chain client trusts the difficultywise-longest [https://en.bitcoin.it/wiki/Protocol_rules#Blocks well-formed] blockchain it can find. Any transaction on the difficultywise-longest well-formed chain is considered valid. Therefore, the validity of a transaction is determined by its height -- i.e. how many blocks come ''before'' it. A transaction's ''depth'' (the number of blocks ''after'' it) is used to determine the likelihood of the transaction being invalidated due to the emergence of a longer fork.

== Header-Only Clients ==

These client downloads a complete copy of the headers for all blocks in the entire blockchain. This means that the download and storage requirements scale linearly with the amount of time since bitcoin was invented; it would be preferable to have the scaling be logarithmic or even constant.

=== Simplified Payment Verification (SPV) ===

This scheme is described in section 8 of the [http://bitcoin.org/bitcoin.pdf original bitcoin whitepaper].

==== Block '''Depth''' as a Transaction Validity Check ====

As Satoshi writes, "[the thin client] can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it." If we take "X" to be the "number of blocks added after it", then SPV essentially trusts that a transaction X blocks deep in the chain does not have inputs which were already spent further back in the chain. Therefore, the validity of a transaction is determined by its depth -- i.e. how many blocks come ''after'' it. Other thin client protocols also include this assumption.

This is very different from the trust model in the "thick" client: the thick client verifies that a transaction's inputs are unspent by actually checking the whole chain up to that point -- there is no "X blocks deep" involved here. The thick client uses "X blocks deep" (aka "confirmations") only once it has already decided that a transaction is valid (i.e. no [[Double-spending|double-spends]]). At that point it uses "X blocks deep" to decide how likely it is that a longer fork in the chain will emerge which excludes that transaction.

It is very important to understand how the same property ("X blocks deep") is used to verify two different properties in the thick client and SPV cases. '''The thick client never uses block depth as a measure of transaction validity; the SPV client does'''.

This is a concern in a situation where an SPV client is subjected to a double-spend attack by somebody who controls its network connection. For example, suppose you are at a wi-fi cafe and are paying for something using your smartphone -- the cafe owner controls your network connection. Satoshi acknowledges this implicitly when he writes that "the verification is reliable as long as honest nodes control the network" -- to be completely pedantic, this means that the verification is reliable as long as honest nodes control '''the part of the network that the SPV client is able to communicate with'''. In an attack-by-ISP scenario this may not be a sufficiently strong security property. The attacker would not need to overpower "the rest of the network" because the client is unable to communicate with it.

==== [[BitCoinJ|bitcoinj]] ====

Simplified Payment Verification is the verification mechanism used in [[BitCoinJ|bitcoinj]].

A security analysis of some of the issues in bitcoinj can be found [http://code.google.com/p/bitcoinj/wiki/SecurityModel here]; however:

* The claim that "picking 10 nodes and requiring all of them to be consistent needs much less trust" overlooks the problem of [https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes "cancer nodes"] and [http://en.wikipedia.org/wiki/Sybil_attack Sybil attacks].
* Many of the security claims are qualified by some form of "if you don't think an attacker controls your internet connection"; see the previous section for a discussion of why this is problematic.

==== [https://bitcointalk.org/index.php?topic=128055.0 picocoin] ====

Simplified Payment Verification is the verification mechanism used in picocoin.

The library (libccoin) that picocoin is based on includes code for validating scripts and blocks; this could potentially be used to implement a full-chain client.

==== [[Electrum]] ====

ThomasV [https://en.bitcoin.it/w/index.php?title=Thin_Client_Security&action=historysubmit&diff=42844&oldid=36519 claims] that "Electrum, it is doing SPV since 2012".

=== Unused Output Tree in the Blockchain (UOT) ===

There have been several proposals (the first appears to be [https://bitcointalk.org/index.php?topic=21995.0 this one] by gmaxwell, who called it an "open transaction tree", although the term "open" is now taken to mean "not yet mined into the blockchain" rather than "unspent") to form a tree of unused transaction outputs at each block in the chain, hash it as a Merkle tree, and encode the root hash in the block chain (probably as part of the coinbase input). This will be called an Unused Output Tree (UOT). The first detailed proposal so far appears to be [https://en.bitcoin.it/wiki/User:DiThi/MTUT Alberto Torres' proposal]; etotheipi's [https://bitcointalk.org/index.php?topic=88208.0 ultimate blockchain compression] is a variant of this.

If such UOT hashes were included in the blockchain, a client which shipped with a [https://en.bitcoin.it/wiki/Vocabulary checkpoint] block that had a UOT would only need to download blocks after the checkpoint. Moreover, once the client had downloaded those blocks and confirmed their UOTs, it could discard all but the most recent block containing a UOT.

This would also let a thin client reduce the question of "is this output unspent" to the question of "is this block super-well-formed" where "well-formed" means "well-formed according to the normal blockchain rules and additionally has an Unused Output Tree which is accurate and truthful". This is still a long way from the low level of trust involved in the thick client, but it is a major improvement over all existing proposals.

It is unlikely that bitcoin would ever arrive at a state where every single block had a UOT, since this would require upgrading 100% of the miners on the network, or else convincing enough miners to reject blocks which do not contain a UOT. The latter strategy risks creating blockchain forks, which can be expensive (in reward terms) to miners. Therefore, any UOT strategy would need to cope with the fact that not every block contains a UOT.

Hostile miners may insert blocks into the chain which have what claims to be a UOT, but which is actually invalid. It is unlikely that such blocks could be kept out of the chain because, again, this would require adding a new block well-formedness criterion, and miners implementing this new criterion would risk "mining on the wrong side" of a fork, which could cost them a lot of money. Therefore, any UOT strategy would need to cope with the fact that not every block containing a UOT entry can be trusted.

Note that at the present moment no standard format for such Unused Output Tree hashes has been agreed upon, nor do any of the blocks in the chain contain them. The [https://bitcointalk.org/index.php?topic=91954 ultraprune] feature added to bitcoind-0.8 maintains a similar data structure on the client's disk. It does not put this data structure or its hash anywhere in the blockchain.

== Server-Trusting Clients ==

These clients involve some (usually low) level of trust in the server they rely upon. Mechanisms for authenticating the server, and for confirming that the server has not been compromised, are usually not explained.

All thin clients listed below currently connect to a single server, and are vulnerable to an attack similar to a double-spend. The attack can be run by that single server - the server can just lie to them that they received a Bitcoin transaction, and they, assuming the server does not lie, perform some service, transfer funds or send goods without actually receiving any Bitcoin in exchange. Therefore, they are implicitly trusting it.

Future enhancements have been suggested that will have the client talk to multiple servers and broadcast transactions and query all of them. Unfortunately it is well known to security researchers that this does not actually increase security; it simply makes the exploits more complicated and difficult to find. Security researchers have a name for this phenomenon: it is called a "Sybil attack"<ref>http://en.wikipedia.org/wiki/Sybil_attack</ref>. [https://bitcointalk.org/index.php?topic=88208.msg975201#msg975201 This post] on bitcointalk explains how some governments (notably Iran and China) already perform these sorts of attacks on their own citizens, with the coerced assistance of SSL certificate authorities.

Clients with a checkpoint (even a very old one) that download and validate the headers for the whole blockchain are [http://bitcoinmedia.com/the-irc-bootstrap-method-is-flawed/#comment-4243 not vulnerable] to Sybil attacks in the following sense: they can always ensure that an attack would cost more than the amount being stolen.

=== [[BCCAPI]] ===

== Other ==

* A [http://sourceforge.net/mailarchive/message.php?msg_id=28633866 thread] on bitcoin-dev
* A [http://bitcoin.stackexchange.com/questions/2584/is-reclaiming-disk-space-already-implemented-how-effective-will-it-be/2589 question] on bitcoin.stackexchange.com
* The [https://en.bitcoin.it/wiki/Weaknesses#Cancer_nodes "cancer nodes"] paragraph explains some of the issues with thin clients that base security on trusting whatever "a majority of the IP addresses I can see" say.
* [http://bitcoin.stackexchange.com/questions/2613/how-secure-are-various-models-of-bitcoin-clients related discussion on Stack Exchange]
* A hypothesized [https://bitcointalk.org/index.php?topic=134318.msg1441171#msg1441171 intermediate security class] between SPV and full-chain validation.

<references>

[[Category:Technical]]
[[category:Clients]]
[[Category:Security]]

Clients

2014-03-07T15:50:07Z

Jcv: /* For developers */

==Overview==

This table compares the features of the different clients. All of the listed clients are open-source.

===Feature key===

; Wallet Security : How well the client protects your [[private key]]s from people with access to the machine the wallet is stored on. The private keys can be encrypted, for example. The private keys can also be either stored on your device or on a remote server.
; Network Security : Clients which more fully implement the Bitcoin network protocol are safer -- they can't be as easily tricked by powerful attackers. A client which ''fully'' implements the protocol will always use the correct [[block chain]] and will never allow [[double-spending|double-spends]] or invalid transactions to exist in the block chain under any circumstances. Clients which only ''partially'' implement the protocol typically trust that 50% or more of the network's mining power is honest. Some clients trust one or more ''remote servers'' to protect them from double-spends and other network attacks.
; Setup Time : Some clients require that you download and verify a large amount of data before you can send or receive BTC.
; Maturity : When the project was started.

===Table===


{| class='wikitable' style='text-align: center'
! Client !! Get Started !! Audience !! Wallet Security !! Network Security !! Backups !! Setup Time !! Disk Space !! Maturity !! Multi-user !! Available for
|-
! Armory
|| [http://bitcoinarmory.com/index.php/get-armory Download] || Power users || {{CLGood|Encrypted, on-device}} || Addon || {{CLBest|One-time}} || Varies || {{CLBad|6+ GB}} || Jul 2011 || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLWin}}
|-
! Bitcoin Wallet
|| [https://play.google.com/store/apps/details?id=de.schildbach.wallet Google Play] [https://appworld.blackberry.com/webstore/content/23952882/ BlackBerry World] || {{CLGood|End-users}} || {{CLGood|Isolated, on-device}} || Partial || Manual || {{CLBest|Instant}} || {{CLGood|15 MB}} || {{CLGood|Mar 2011}} || on JB tablets || {{CLAndroid}} [[file:ico-blackberry.png]]
|-
! {{CLGood|Bitcoin-Qt}}
|| [http://sourceforge.net/projects/bitcoin/files/Bitcoin/ Download] || {{CLGood|End-users}} || {{CLGood|Encrypted, on-device}} || {{CLBest|Full}} || Manual || {{CLBad|Hours}} || {{CLBad|6+ GB}} || {{CLGood|May 2011}} || No || {{CLLinux}}{{CLMac}}{{CLWin}}
|-
! bitcoind
|| [http://sourceforge.net/projects/bitcoin/files/Bitcoin/ Download] || Programmers || {{CLGood|Encrypted, on-device}} || {{CLBest|Full}} || Manual || {{CLBad|Hours}} || {{CLBad|6+ GB}} || {{CLBest|Aug 2009}} || {{CLGood|Virtual accounts}} || {{CLLinux}}{{CLWin}}
|-
! Electrum
|| [http://ecdsa.org/electrum/ Download] || Power users || {{CLGood|Encrypted, on-device}} || Minimal || {{CLBest|Memorized}} || {{CLGood|Minutes}} || {{CLGood|5 MB}} || Nov 2011 || No || {{CLLinux}}{{CLMac}}{{CLWin}}
|-
! MultiBit
|| [https://multibit.org/releases.html Download] || {{CLGood|End-users}} || {{CLGood|Encrypted, on-device}} || Partial || {{CLGood|Automatic (local)}} || {{CLBest|Seconds}} || 50 MB || Jul 2011 || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLMac}}{{CLWin}}
|-
! My Wallet
|| [https://blockchain.info/wallet/new Web-based] || {{CLBest|Everyone}} || Encrypted, on a server || {{CLBad|Remote}} || {{CLGood|Automatic}} || {{CLGood|Minutes}} || {{CLBest|None}} || Dec 2011 || {{CLBest|Yes}} || {{CLAndroid}}{{CLiOS}}{{CLLinux}}{{CLMac}}{{CLWin}}
|-
! Gocoin
|| [https://github.com/piotrnar/gocoin Build yourself] || Power users || Designated offline PC || {{CLBest|Full}} || {{CLBest|Memorized}} || {{CLBad|Hours}} || {{CLBad|6+GB}} || May 2013 || {{CLBest|Multi-wallet}} || {{CLLinux}}{{CLMac}}{{CLWin}}
|}



==For developers==

This table shows additional information about various Bitcoin clients that may be relevant to developers.

{| class='wikitable' style='text-align: center'
! Client !! Website !! Source Code !! License !! Discussion !! Architecture
|-
! Armory
|| [http://bitcoinarmory.com/ Link] ||[https://github.com/etotheipi/BitcoinArmory/ Github] || AGPLv3 || [https://bitcointalk.org/index.php?board=97.0 Bitcointalk] || Integrated
|-
! Bitcoin Wallet
|| [https://github.com/schildbach/bitcoin-wallet Link] || [https://github.com/schildbach/bitcoin-wallet Github] [https://code.google.com/p/bitcoin-wallet/source/checkout Google Code] || GPLv3 || [https://plus.google.com/b/101256420499771441772/communities/105515929887248493912 Google+ community] / [https://bitcointalk.org/index.php?board=100.0 Bitcointalk] || [[Thin Client Security#Simplified Payment Verification (SPV)|SPV]]
|-
! Bitcoin-Qt / bitcoind
|| [http://bitcoin.org/ Link] || [https://github.com/bitcoin/bitcoin Github] || MIT || [https://lists.sourceforge.net/lists/listinfo/bitcoin-development Sourceforge] || Integrated
|-
! Electrum
|| [http://ecdsa.org/electrum/ Link] || [https://gitorious.org/electrum Gitorious] || GPLv3 || [https://lists.sourceforge.net/lists/listinfo/electrum-discuss Sourceforge] || [[Thin Client Security#Simplified Payment Verification (SPV)|SPV]
|-
! MultiBit
|| [http://multibit.org/ Link] || [https://github.com/jim618/multibit Github] || MIT || [https://groups.google.com/forum/?fromgroups#!forum/bitcoin-multibit Google Groups] || [[Thin Client Security#Simplified Payment Verification (SPV)|SPV]]
|-
! My Wallet
|| [https://blockchain.info/wallet/ Link] || [https://github.com/blockchain/My-Wallet/ Github] || BSD* || None || [[Thin Client Security#Server-Trusting Clients|Server-Client]]
|-
! bits of proof
|| [http://bitsofproof.com Link] || [https://github.com/bitsofproof/supernode Github] || Apache 2.0 || [https://bitcointalk.org/index.php?topic=122013.0 Bitcointalk] || [[Thin Client Security#Server-Trusting Clients|Server-Client]]
|-
! Gocoin
|| [http://www.assets-otc.com/gocoin Link] || [https://github.com/piotrnar/gocoin Github] || ? || [https://bitcointalk.org/index.php?topic=199306.0 Bitcointalk] || Integrated
|-
! btcd
|| [https://github.com/conformal/btcd Link] || [https://github.com/conformal/btcd Github] || ISC || [https://github.com/conformal/btcd#irc-server irc] || [[Thin Client Security#Server-Trusting Clients|Server-Client]]
|}

==See Also==
* [[Software#Bitcoin_clients|List of clients]]
* [[Bitcoin Ladder]]

<references/>

Software

2014-03-07T15:43:36Z

Jcv: /* Bitcoin clients */

List of Bitcoin-related '''software'''. See also [[:Category:Software|Category:Software]].

Be sure to keep on top of the latest [[CVEs|security vulnerabilities]]!

==Bitcoin clients==
===Bitcoin clients===
::''Main article and feature comparison: [[Clients]]''
*[[Bitcoin-Qt]] - C++/Qt based tabbed UI. Linux/MacOSX/Windows. Full-featured [[Thin Client Security|thick client]] that downloads the entire [[block chain]], using code from the original Bitcoin client.
*[[bitcoind]] - GUI-less version of the original Bitcoin client, providing a [[API reference (JSON-RPC)|JSON-RPC]] interface
*[[MultiBit]] - lightweight [[Thin Client Security|thin client]] for Windows, MacOS and Linux with support for opening multiple wallets simultaneously
*[[Electrum]] - a "blazing fast, open-source, multi-OS Bitcoin client/wallet with a very active community" - also a [[Thin Client Security|thin client]].
*[[Bitcoin-js-remote]] - JavaScript RPC client, support for QR codes
*[https://github.com/TheSeven/Bitcoin-WebUI Bitcoin WebUI] - JavaScript RPC client
*[https://github.com/zamgo/bitcoin-webskin Bitcoin Webskin] - PHP web interface to bitcoind and namecoind
*[https://bitcointalk.org/index.php?topic=50721.0 subvertx] - command line bitcoin tools
*[[Bitcoiner]] - Java RPC client (Android)
*[[Armory]] - Python-based client currently in beta-level
*[[Spesmilo]] - Python/PySide RPC client (abandoned)
*[[Gocoin]] - WebUI client written in Go language, with a cold deterministic brain-wallet.
*[https://github.com/conformal/btcd btcd] An alternative full node bitcoin implementation written in Go (golang).

====Frontends to eWallet====
*[https://blockchain.info/wallet Blockchain] - Javascript bitcoin client with client side encryption.
*[https://en.bitcoin.it/wiki/Xcoinmoney xCoinMoney] Advanced API to create invoices for subscription.

====Experimental====
*[[Freecoin]] - C++ client, supports alternative currencies like [https://bitcointalk.org/index.php?topic=9493.0 Beertoken]
*[[BitDroid]] - Java client
*[[Bitdollar]] - C++/Qt client, unstable beta version

===Libraries===
*[https://bitcointalk.org/index.php?topic=30646.0 libbitcoin]
*[[BitCoinJ]] - Java client library, early development stage but used in live projects already
*[[BCCAPI]] (Bitcoin Client API) - a java library designed for making secure light-weight bitcoin clients.

==Bitcoin Trade Data==
*[[Bitcoin Charts]] – Prices, volume, and extensive charting on virtually all Bitcoin markets.
*[[MtGox Live]] - An innovative chart showing a live feed of [[MtGox]] trades and market depth. (Must Use Chrome)
*[http://btccharts.com BTCCharts] - An innovative chart showing a live feed of multiple markets, currencies and timeframes.
*[http://MY-BTC.info MY-BTC.INFO] - A free profit/loss portfolio manager for Bitcoins and other digital currencies including many charts.
*[http://BitcoinExchangeRate.org BitcoinExchangeRate.org] - Bitcoin and USD converter with convenient URL scheme and Auto-updating Portfolio Spreadsheet.
*[[Bitcoin Sentiment Index]] - A financial index that collects and disseminates sentiment data about bitcoin.
*[[Preev]] - Bitcoin converter with live exchange rates.
*[[Skami]] - Bitcoin Market Exchange comparison charts.
*[[BitcoinSentiment]] - Crowdvoting site offering means of voting and viewing voters sentiment towards bitcoin.
*[[TradingView]] – network where traders exchange ideas about Bitcoin using advanced free online charts

==Bitcoin software==

===Web interfaces for merchants===

*[[BitMerch]] - Embeddable HTML buttons, instant sign-up, instant payouts, automatic price adjustment for other currencies. No programming skills required to set up.
*[[Bitcoin Evolution]] - Non wallet-based Buy Now button to insert into websites (handles sales tracking; client must be used for actual transaction)
*[[BitPay]] - Buy Now buttons, Checkout posts/callbacks, Mobile Checkout, JSON API
*[[Btceconomy]] - a JavaScript widget listing items for sale
*[[BTCMerch]] - Payment processor for bitcoins and other cryptocurrencies. 0.5% transaction fee. Sandbox is available.
*[https://coinbase.com/merchants Coinbase] - Provides bitcoin payment processing for Overstock.com, Reddit, Khan Academy, OkCupid, and more.
*[[GoCoin]] - Payment gateway for bitcoin and litecoin. Supports JavaScript, PHP, Java, Ruby, and .NET
*[[Javascript Bitcoin Converter]] - currency conversion
*[[WalletBit]] - Easy JavaScript Buy Now buttons, Instant Payment Notification, Application Programming Interface (JSON API), Mobile Checkout, QR-Code
* [https://PikaPay.com PikaPay] ([[PikaPay|info]]) Buy Now buttons, Twitter Integration, JSON API

===Shopping Cart Integration in eCommerce-Systems===
*[[GoCoin]] - Plugin for WooCommerce support and coming soon Magento
*[[Zen Cart Bitcoin Payment Module]] - a payment module that interacts with bitcoind for the Zen Cart eCommerce shopping chart.
*[https://coinbase.com/docs/merchant_tools/shopping_cart_plugins Coinbase Shopping Cart Plugins] - Supports Wordpress, WooCommerce, Magento, Zencart, WP e-commerce, and more.
*[[Karsha Shopping Cart Interface]] - is a mobile payment-interface which enables its users to accept payments.
*[[Bitcoin-Cash]] - an easy to use payment module for xt:Commerce
*[[BitPay]] - bitcoin plugins for Magento, Opencart, Zencart, PHP, JSON API
*[[WalletBit]] - Plugins for PrestaShop, OpenCart, PHP, JSON API
* [https://www.xcoinmoney.com/info/api-general-info xCoinMoney] Advanced API for instant payment and subscriptions
*[[OpenCart Bitcoin]] - An OpenCart payment module that communicates with a bitcoin client using JSON RPC.
*[[OsCommerce_Bitcoin_Payment_Module|OsCommerce Bitcoin Payment Module]] - a payment module that uses a python monitoring script to interact with bitcoind for OsCommerce
* [http://drupal.org/project/uc_bitcoin Drupal Ubercart Bitcoin payment method] enables you to accept Bitcoin as payment for your Drupal/Ubercart enabled website product/services.

=== Enterprise server ===
*[http://bitsofproof.com Bits of Proof] - a modular enterprise-ready implementation of the Bitcoin protocol.

===Web apps===
*[[Bitcoin Central]] - currency exchange
*[https://en.bitcoin.it/wiki/Coinbase_(business) Coinbase] - an international digital wallet that allows you to securely buy, use, and accept bitcoin currency
*[[Coinnext]] - Cryptocurrency Exchange
*[[Bitcoin Poker Room]] - poker site
*[[Abe]] - block chain viewer
*[[Simplecoin]] - PHP web frontend for a pool
*[[bitcoin_simple_php_tools]] simple php tools for webmasters
* [http://www.coinsummary.com/ CoinSummary] - multi-coin wallet manager with built-in valuation in Bitcoin and major world currencies.

===Browser extensions===
*[[Bitcoin Extension]] - check balance and send bitcoins (Chrome)
*[[Bitcoin Prices (extension)]] - monitoring price (Firefox)
*[[Bitcoin Ticker]] - monitoring price (Chrome)
*[[Biticker]] - Bitcoin ticker, currency converter and history price graph (Chrome)
*[https://chrome.google.com/webstore/detail/bitcoin-microformats/bkanicejfbhlidgjkpenmddnacjengld?hl=en Bitcoin Microformats] Show bitcoin address metadata embedded in a page (Chrome)
*[https://chrome.google.com/webstore/detail/bitcoin-address-lookup/pmlblkdmadbidammhjiponepngbfcpge?hl=en Bitcoin Address Lookup] Right click an address to view its value. (Chrome)

===PC apps===
*[https://sourceforge.net/projects/bitcointrader/ Qt Bitcoin Trader] - Open Source Mt.Gox, BTC-e, Bitstamp, Bitfinex and BTCChina trading client for Windows, Mac OS X and Linux
*[[http://www.mybtc-trader.com MyBTC-Trader.com]] - a MtGox Bitcoin trading client for windows with GUI
*[[Mining Explorer]] - monitoring tool for bitcoin mining
*[[Bitcoin SMS Alert]] - sends SMS text alerts to a user's phone based on BTC price / percent thresholds.
*[[BTConvert]] - currency conversion
*[[Sierra Chart MtGox Bridge]] - real-time charting
*[[BitTicker]] - monitoring price (Mac OS X)
*[[ToyTrader]] - a command line trading tool for [[MtGox]]
*[[goxsh]] - a command-line frontend to the [[MtGox|Mt. Gox Bitcoin Exchange]] (Python)
*[[MyBitcoins gadget]] - monitoring pool earnings / price (Windows gadget)
*[[Bitcoin QR Popup]] - streamlined interface to bitcoin for POS systems (Windows)
*[http://gnome-help.org/content/show.php/Bitcoin+Rate?content=138572 Bitcoin Rate] - Desktop widget with BTC exchange rate (KDE)
*[http://kde-apps.org/content/show.php?content=142344 Bitcoin Monitor] - Desktop widget to monitor status of your Bitcoin miners on mining pools (KDE)

===Mobile apps===
==== iPhone / iPad ====
*[https://blockchain.info/wallet/iphone-app Blockchain] - Fully featured iphone bitcoin app.
*[[Bitcoin Ticker (iPhone)]] - monitoring price w/push notifications
*[[BitCoins Mobile]] - First iPad native app! Live market data, news feeds, mining pool statistics, full screen exchange price charts, bitcoin network statistical charts. (iPad only, iPhone/iPod Touch coming soon!)
*[https://github.com/teeman/BitcoinTrader BitcoinTrader] - Spend/receive BTC via QR codes, trade, deposit/withdraw, etc. Supports Mt. Gox, TradeHill, ExchB, CampBX, and InstaWallet.
*[[Bit-pay]] - Mobile Checkout, set prices in any currency and receive mobile-to-mobile payment
*[http://blog.coinbase.com/post/64824441934/the-coinbase-ios-app-has-launched Coinbase iPhone App]
*[[Easywallet.org]] - Web based wallet, works with QR Code scanner on iPhone/iPad/iPod touch
*[https://itunes.apple.com/us/app/btc-miner/id648411895?ls=1&mt=8 BTC Miner (iPhone)] - monitor mining results from various mining pools on iPhone/iPad/iPod touch
*[[BitTick]] - Real-time Bitcoin ticker. Real-time currency convert(support 50+ currency. USD, GBP, EUR, CNY, JPY, CAD, RUB, AUD, BRL, NZD, PLN, KRW…)

==== Android ====
* Direct link to Android Market bitcoin apps. https://play.google.com/store/search?q=bitcoin
*[[BitCare]] - Track bitcoin wallet balance, trade on Mt.Gox, monitor mining pool hashrate, balance, worker status.
*[[Bitcoin Alert]] - monitoring price (Android)
*[[Bitcoin-android]] - Does not appear to be being maitained anymore. https://market.android.com/details?id=com.bitcoinandroid
*[[Bitcoin Wallet Balance]] - view your balance in real time on your android phone
*[[Bitcoin Wallet]] - This is the most functional Android bitcoin wallet application. https://market.android.com/details?id=de.schildbach.wallet
*[[BitcoinSpinner]] - Single address, easy to use, lightweight and open source client. Keys stored on device.
*[[BitcoinX]] - monitoring price (Android)
*[[BitPay]] - https://market.android.com/details?id=com.bitcoin.bitpay (Is not related to the bit-pay.com online payment processor.)
*[[Bridgewalker]] - euro-denominated wallet for the Bitcoin economy
*[https://blockchain.info/wallet/android-app Blockchain] - Lightweight Android Bitcoin Client - Also works with blockchain.info web interface and iphone app.
*[https://play.google.com/store/apps/details?id=com.coinbase.android&hl=en Coinbase Wallet] - supports buying, selling, sending, requesting, and more.
*[https://play.google.com/store/apps/details?id=com.coinbase.android.merchant&hl=en Coinbase Merchant] - makes it easy to accept bitcoin at a retail location
*[[http://coincliff.com CoinCliff]] - Monitors price and fires alarms to wake you up, or notifications, as in text messages (Android)
*[[Easywallet.org]] - Web based wallet, works with QR Code scanner on Android devices
*[[Miner Status]] - monitoring miner status (Android)
*[[SMS Bitcoins]] - transactions by SMS

==== Windows Phone 7 ====
*Direct link to Windows Phone Marketplace Bitcoin apps: [http://www.windowsphone.com/en-us/store/search?q=bitcoin]

==== Windows Phone 8 ====
*[[Bitcoin Can]] - Monitoring prices, account balances and mobile trading on multiple exchanges including MtGox, Coinbase, and CampBX. http://www.windowsphone.com/en-us/store/app/bitcoin-can/57fcf4d6-497a-4663-8da3-93cb26c83b11

see also [[Bitcoin Payment Apps]]

===Operating systems===
*[[MinePeon]] - Bitcoin mining on the Raspberry PI
*BAMT - a minimal Linux based OS intended for headless mining. Initially announced [https://bitcointalk.org/index.php?topic=65915.0 here] (not maintained)
*[[LinuxCoin]] - a lightweight Debian-based OS, with the Bitcoin client and GPU mining software (not maintained)

===Mining apps===
Main page: [[Mining software]]
*[[50Miner]] - A GUI frontend for Windows(Poclbm, Phoenix, DiabloMiner, cgminer)
*[[BFGMiner]] - Modular ASIC/FPGA/GPU miner in C
*[http://www.groupfabric.com/bitcoin-miner/ Bitcoin Miner by GroupFabric] - Free easy-to-use DirectX GPU miner on the Windows Store
*[[BTCMiner]] - Bitcoin Miner for ZTEX FPGA Boards
*[[Bit Moose]] - Run Miners as a Windows Service.
*[[Poclbm]] - Python/OpenCL GPU miner ([[Poclbm-gui|GUI(Windows & MacOS X)]])
*[[CGMiner]] - ASIC/FPGA/GPU miner in C
*[[Poclbm-mod]] - more efficient version of [[Poclbm]] ([[Poclbm-mod-gui|GUI]])
*[[DiabloMiner]] - Java/OpenCL GPU miner ([[DiabloMiner.app|MAC OS X GUI]])
*[[RPC Miner]] - remote RPC miner ([[RPCminer.app|MAC OS X GUI]])
*[[Phoenix miner]] - miner
*[[Cpu Miner]] - miner
*[[Ufasoft miner]] - miner
*[[Pyminer]] - Python miner, reference implementation
*[[Remote miner]] - mining pool software
*[[Open Source FGPA Bitcoin Miner]] - a miner that makes use of an FPGA Board
*[https://github.com/mkburza/Flash-Player-Bitcoin-Miner Flash Player Bitcoin Miner] - A proof of concept Adobe Flash Player miner
*[http://fabulouspanda.co.uk/macminer/ MacMiner] - A native Mac OS X Bitcoin/Litecoin miner based on cgminer, bfgminer, cpuminer and poclbm
*[[Asteroid]] - Mac-specific GUI based on cgminer
*[[MultiMiner]] - GUI based on cgminer/bfgminer for Windows, OS X and Linux, allows switching between currencies based on profitability

===Mining Pool Servers (backend)===
Main page: [[Poolservers]]

*[[ecoinpool]] - Erlang poolserver (not maintained)
*[[Eloipool]] - Fast Python3 poolserver
*[[Pushpoold]] - Old mining poolserver in C (not maintained)
*[[Poold]] - Old Python mining poolserver (not maintained)
*[[PoolServerJ]] - Java mining poolserver (not maintained)

===Utilities, libraries, and interfaces:===
*[[BitcoinCrypto]] - a lightweight Bitcoin crypto library for Java/Android
*[[Bitcoin Dissector]] - a wireshark dissector for the bitcoin protocol
*[[Bitcointools]] - a set of Python tools accessing the transaction database and the wallet
*[[Finance::MtGox]] - a Perl module which interfaces with the Mt. Gox API
*[[libblkmaker]] - C library implementation of [[getblocktemplate]] decentralized mining protocol
*[[python-blkmaker]] - Python module implementation of [[getblocktemplate]] decentralized mining protocol

===Lists of software===
*[[BitGit]] - list of Bitcoin-related opensource projects hosted at Git

===Developer resources===
*[[:Category:Developer|Category:Developer]]
*[[:Category:Technical|Category:Technical]]
*[[Original Bitcoin client/API calls list]]
*[[API reference (JSON-RPC)]]
*[[PHP_developer_intro|PHP Developer Introduction]]

===Other===
*[[Namecoin]] - a distributed naming system based on Bitcoin technology
*[[Bitcoin Consultancy]] - an organization providing open source software and Bitcoin-related consulting
*[[Open Transactions]] - a financial crypto and digital cash software library, complementary to Bitcoin
*[[Moneychanger]] - Java-based GUI for [[Open Transactions]]
*[http://btcnames.org/ BTCnames] - a webbased aliasing service which allows to handle unlimited names for your BTC deposit hashes
*[[Devcoin]] - the open source developer coin

[[Category:Software|*]]

Software

2014-03-07T15:43:23Z

Jcv: /* Bitcoin clients */

List of Bitcoin-related '''software'''. See also [[:Category:Software|Category:Software]].

Be sure to keep on top of the latest [[CVEs|security vulnerabilities]]!

==Bitcoin clients==
===Bitcoin clients===
::''Main article and feature comparison: [[Clients]]''
*[[Bitcoin-Qt]] - C++/Qt based tabbed UI. Linux/MacOSX/Windows. Full-featured [[Thin Client Security|thick client]] that downloads the entire [[block chain]], using code from the original Bitcoin client.
*[[bitcoind]] - GUI-less version of the original Bitcoin client, providing a [[API reference (JSON-RPC)|JSON-RPC]] interface
*[[MultiBit]] - lightweight [[Thin Client Security|thin client]] for Windows, MacOS and Linux with support for opening multiple wallets simultaneously
*[[Electrum]] - a "blazing fast, open-source, multi-OS Bitcoin client/wallet with a very active community" - also a [[Thin Client Security|thin client]].
*[[Bitcoin-js-remote]] - JavaScript RPC client, support for QR codes
*[https://github.com/TheSeven/Bitcoin-WebUI Bitcoin WebUI] - JavaScript RPC client
*[https://github.com/zamgo/bitcoin-webskin Bitcoin Webskin] - PHP web interface to bitcoind and namecoind
*[https://bitcointalk.org/index.php?topic=50721.0 subvertx] - command line bitcoin tools
*[[Bitcoiner]] - Java RPC client (Android)
*[[Armory]] - Python-based client currently in beta-level
*[[Spesmilo]] - Python/PySide RPC client (abandoned)
*[[Gocoin]] - WebUI client written in Go language, with a cold deterministic brain-wallet.
*[https://github.com/conformal/btcd btcd] An alternative full node bitcoin implementation written in Go (golang)

====Frontends to eWallet====
*[https://blockchain.info/wallet Blockchain] - Javascript bitcoin client with client side encryption.
*[https://en.bitcoin.it/wiki/Xcoinmoney xCoinMoney] Advanced API to create invoices for subscription.

====Experimental====
*[[Freecoin]] - C++ client, supports alternative currencies like [https://bitcointalk.org/index.php?topic=9493.0 Beertoken]
*[[BitDroid]] - Java client
*[[Bitdollar]] - C++/Qt client, unstable beta version

===Libraries===
*[https://bitcointalk.org/index.php?topic=30646.0 libbitcoin]
*[[BitCoinJ]] - Java client library, early development stage but used in live projects already
*[[BCCAPI]] (Bitcoin Client API) - a java library designed for making secure light-weight bitcoin clients.

==Bitcoin Trade Data==
*[[Bitcoin Charts]] – Prices, volume, and extensive charting on virtually all Bitcoin markets.
*[[MtGox Live]] - An innovative chart showing a live feed of [[MtGox]] trades and market depth. (Must Use Chrome)
*[http://btccharts.com BTCCharts] - An innovative chart showing a live feed of multiple markets, currencies and timeframes.
*[http://MY-BTC.info MY-BTC.INFO] - A free profit/loss portfolio manager for Bitcoins and other digital currencies including many charts.
*[http://BitcoinExchangeRate.org BitcoinExchangeRate.org] - Bitcoin and USD converter with convenient URL scheme and Auto-updating Portfolio Spreadsheet.
*[[Bitcoin Sentiment Index]] - A financial index that collects and disseminates sentiment data about bitcoin.
*[[Preev]] - Bitcoin converter with live exchange rates.
*[[Skami]] - Bitcoin Market Exchange comparison charts.
*[[BitcoinSentiment]] - Crowdvoting site offering means of voting and viewing voters sentiment towards bitcoin.
*[[TradingView]] – network where traders exchange ideas about Bitcoin using advanced free online charts

==Bitcoin software==

===Web interfaces for merchants===

*[[BitMerch]] - Embeddable HTML buttons, instant sign-up, instant payouts, automatic price adjustment for other currencies. No programming skills required to set up.
*[[Bitcoin Evolution]] - Non wallet-based Buy Now button to insert into websites (handles sales tracking; client must be used for actual transaction)
*[[BitPay]] - Buy Now buttons, Checkout posts/callbacks, Mobile Checkout, JSON API
*[[Btceconomy]] - a JavaScript widget listing items for sale
*[[BTCMerch]] - Payment processor for bitcoins and other cryptocurrencies. 0.5% transaction fee. Sandbox is available.
*[https://coinbase.com/merchants Coinbase] - Provides bitcoin payment processing for Overstock.com, Reddit, Khan Academy, OkCupid, and more.
*[[GoCoin]] - Payment gateway for bitcoin and litecoin. Supports JavaScript, PHP, Java, Ruby, and .NET
*[[Javascript Bitcoin Converter]] - currency conversion
*[[WalletBit]] - Easy JavaScript Buy Now buttons, Instant Payment Notification, Application Programming Interface (JSON API), Mobile Checkout, QR-Code
* [https://PikaPay.com PikaPay] ([[PikaPay|info]]) Buy Now buttons, Twitter Integration, JSON API

===Shopping Cart Integration in eCommerce-Systems===
*[[GoCoin]] - Plugin for WooCommerce support and coming soon Magento
*[[Zen Cart Bitcoin Payment Module]] - a payment module that interacts with bitcoind for the Zen Cart eCommerce shopping chart.
*[https://coinbase.com/docs/merchant_tools/shopping_cart_plugins Coinbase Shopping Cart Plugins] - Supports Wordpress, WooCommerce, Magento, Zencart, WP e-commerce, and more.
*[[Karsha Shopping Cart Interface]] - is a mobile payment-interface which enables its users to accept payments.
*[[Bitcoin-Cash]] - an easy to use payment module for xt:Commerce
*[[BitPay]] - bitcoin plugins for Magento, Opencart, Zencart, PHP, JSON API
*[[WalletBit]] - Plugins for PrestaShop, OpenCart, PHP, JSON API
* [https://www.xcoinmoney.com/info/api-general-info xCoinMoney] Advanced API for instant payment and subscriptions
*[[OpenCart Bitcoin]] - An OpenCart payment module that communicates with a bitcoin client using JSON RPC.
*[[OsCommerce_Bitcoin_Payment_Module|OsCommerce Bitcoin Payment Module]] - a payment module that uses a python monitoring script to interact with bitcoind for OsCommerce
* [http://drupal.org/project/uc_bitcoin Drupal Ubercart Bitcoin payment method] enables you to accept Bitcoin as payment for your Drupal/Ubercart enabled website product/services.

=== Enterprise server ===
*[http://bitsofproof.com Bits of Proof] - a modular enterprise-ready implementation of the Bitcoin protocol.

===Web apps===
*[[Bitcoin Central]] - currency exchange
*[https://en.bitcoin.it/wiki/Coinbase_(business) Coinbase] - an international digital wallet that allows you to securely buy, use, and accept bitcoin currency
*[[Coinnext]] - Cryptocurrency Exchange
*[[Bitcoin Poker Room]] - poker site
*[[Abe]] - block chain viewer
*[[Simplecoin]] - PHP web frontend for a pool
*[[bitcoin_simple_php_tools]] simple php tools for webmasters
* [http://www.coinsummary.com/ CoinSummary] - multi-coin wallet manager with built-in valuation in Bitcoin and major world currencies.

===Browser extensions===
*[[Bitcoin Extension]] - check balance and send bitcoins (Chrome)
*[[Bitcoin Prices (extension)]] - monitoring price (Firefox)
*[[Bitcoin Ticker]] - monitoring price (Chrome)
*[[Biticker]] - Bitcoin ticker, currency converter and history price graph (Chrome)
*[https://chrome.google.com/webstore/detail/bitcoin-microformats/bkanicejfbhlidgjkpenmddnacjengld?hl=en Bitcoin Microformats] Show bitcoin address metadata embedded in a page (Chrome)
*[https://chrome.google.com/webstore/detail/bitcoin-address-lookup/pmlblkdmadbidammhjiponepngbfcpge?hl=en Bitcoin Address Lookup] Right click an address to view its value. (Chrome)

===PC apps===
*[https://sourceforge.net/projects/bitcointrader/ Qt Bitcoin Trader] - Open Source Mt.Gox, BTC-e, Bitstamp, Bitfinex and BTCChina trading client for Windows, Mac OS X and Linux
*[[http://www.mybtc-trader.com MyBTC-Trader.com]] - a MtGox Bitcoin trading client for windows with GUI
*[[Mining Explorer]] - monitoring tool for bitcoin mining
*[[Bitcoin SMS Alert]] - sends SMS text alerts to a user's phone based on BTC price / percent thresholds.
*[[BTConvert]] - currency conversion
*[[Sierra Chart MtGox Bridge]] - real-time charting
*[[BitTicker]] - monitoring price (Mac OS X)
*[[ToyTrader]] - a command line trading tool for [[MtGox]]
*[[goxsh]] - a command-line frontend to the [[MtGox|Mt. Gox Bitcoin Exchange]] (Python)
*[[MyBitcoins gadget]] - monitoring pool earnings / price (Windows gadget)
*[[Bitcoin QR Popup]] - streamlined interface to bitcoin for POS systems (Windows)
*[http://gnome-help.org/content/show.php/Bitcoin+Rate?content=138572 Bitcoin Rate] - Desktop widget with BTC exchange rate (KDE)
*[http://kde-apps.org/content/show.php?content=142344 Bitcoin Monitor] - Desktop widget to monitor status of your Bitcoin miners on mining pools (KDE)

===Mobile apps===
==== iPhone / iPad ====
*[https://blockchain.info/wallet/iphone-app Blockchain] - Fully featured iphone bitcoin app.
*[[Bitcoin Ticker (iPhone)]] - monitoring price w/push notifications
*[[BitCoins Mobile]] - First iPad native app! Live market data, news feeds, mining pool statistics, full screen exchange price charts, bitcoin network statistical charts. (iPad only, iPhone/iPod Touch coming soon!)
*[https://github.com/teeman/BitcoinTrader BitcoinTrader] - Spend/receive BTC via QR codes, trade, deposit/withdraw, etc. Supports Mt. Gox, TradeHill, ExchB, CampBX, and InstaWallet.
*[[Bit-pay]] - Mobile Checkout, set prices in any currency and receive mobile-to-mobile payment
*[http://blog.coinbase.com/post/64824441934/the-coinbase-ios-app-has-launched Coinbase iPhone App]
*[[Easywallet.org]] - Web based wallet, works with QR Code scanner on iPhone/iPad/iPod touch
*[https://itunes.apple.com/us/app/btc-miner/id648411895?ls=1&mt=8 BTC Miner (iPhone)] - monitor mining results from various mining pools on iPhone/iPad/iPod touch
*[[BitTick]] - Real-time Bitcoin ticker. Real-time currency convert(support 50+ currency. USD, GBP, EUR, CNY, JPY, CAD, RUB, AUD, BRL, NZD, PLN, KRW…)

==== Android ====
* Direct link to Android Market bitcoin apps. https://play.google.com/store/search?q=bitcoin
*[[BitCare]] - Track bitcoin wallet balance, trade on Mt.Gox, monitor mining pool hashrate, balance, worker status.
*[[Bitcoin Alert]] - monitoring price (Android)
*[[Bitcoin-android]] - Does not appear to be being maitained anymore. https://market.android.com/details?id=com.bitcoinandroid
*[[Bitcoin Wallet Balance]] - view your balance in real time on your android phone
*[[Bitcoin Wallet]] - This is the most functional Android bitcoin wallet application. https://market.android.com/details?id=de.schildbach.wallet
*[[BitcoinSpinner]] - Single address, easy to use, lightweight and open source client. Keys stored on device.
*[[BitcoinX]] - monitoring price (Android)
*[[BitPay]] - https://market.android.com/details?id=com.bitcoin.bitpay (Is not related to the bit-pay.com online payment processor.)
*[[Bridgewalker]] - euro-denominated wallet for the Bitcoin economy
*[https://blockchain.info/wallet/android-app Blockchain] - Lightweight Android Bitcoin Client - Also works with blockchain.info web interface and iphone app.
*[https://play.google.com/store/apps/details?id=com.coinbase.android&hl=en Coinbase Wallet] - supports buying, selling, sending, requesting, and more.
*[https://play.google.com/store/apps/details?id=com.coinbase.android.merchant&hl=en Coinbase Merchant] - makes it easy to accept bitcoin at a retail location
*[[http://coincliff.com CoinCliff]] - Monitors price and fires alarms to wake you up, or notifications, as in text messages (Android)
*[[Easywallet.org]] - Web based wallet, works with QR Code scanner on Android devices
*[[Miner Status]] - monitoring miner status (Android)
*[[SMS Bitcoins]] - transactions by SMS

==== Windows Phone 7 ====
*Direct link to Windows Phone Marketplace Bitcoin apps: [http://www.windowsphone.com/en-us/store/search?q=bitcoin]

==== Windows Phone 8 ====
*[[Bitcoin Can]] - Monitoring prices, account balances and mobile trading on multiple exchanges including MtGox, Coinbase, and CampBX. http://www.windowsphone.com/en-us/store/app/bitcoin-can/57fcf4d6-497a-4663-8da3-93cb26c83b11

see also [[Bitcoin Payment Apps]]

===Operating systems===
*[[MinePeon]] - Bitcoin mining on the Raspberry PI
*BAMT - a minimal Linux based OS intended for headless mining. Initially announced [https://bitcointalk.org/index.php?topic=65915.0 here] (not maintained)
*[[LinuxCoin]] - a lightweight Debian-based OS, with the Bitcoin client and GPU mining software (not maintained)

===Mining apps===
Main page: [[Mining software]]
*[[50Miner]] - A GUI frontend for Windows(Poclbm, Phoenix, DiabloMiner, cgminer)
*[[BFGMiner]] - Modular ASIC/FPGA/GPU miner in C
*[http://www.groupfabric.com/bitcoin-miner/ Bitcoin Miner by GroupFabric] - Free easy-to-use DirectX GPU miner on the Windows Store
*[[BTCMiner]] - Bitcoin Miner for ZTEX FPGA Boards
*[[Bit Moose]] - Run Miners as a Windows Service.
*[[Poclbm]] - Python/OpenCL GPU miner ([[Poclbm-gui|GUI(Windows & MacOS X)]])
*[[CGMiner]] - ASIC/FPGA/GPU miner in C
*[[Poclbm-mod]] - more efficient version of [[Poclbm]] ([[Poclbm-mod-gui|GUI]])
*[[DiabloMiner]] - Java/OpenCL GPU miner ([[DiabloMiner.app|MAC OS X GUI]])
*[[RPC Miner]] - remote RPC miner ([[RPCminer.app|MAC OS X GUI]])
*[[Phoenix miner]] - miner
*[[Cpu Miner]] - miner
*[[Ufasoft miner]] - miner
*[[Pyminer]] - Python miner, reference implementation
*[[Remote miner]] - mining pool software
*[[Open Source FGPA Bitcoin Miner]] - a miner that makes use of an FPGA Board
*[https://github.com/mkburza/Flash-Player-Bitcoin-Miner Flash Player Bitcoin Miner] - A proof of concept Adobe Flash Player miner
*[http://fabulouspanda.co.uk/macminer/ MacMiner] - A native Mac OS X Bitcoin/Litecoin miner based on cgminer, bfgminer, cpuminer and poclbm
*[[Asteroid]] - Mac-specific GUI based on cgminer
*[[MultiMiner]] - GUI based on cgminer/bfgminer for Windows, OS X and Linux, allows switching between currencies based on profitability

===Mining Pool Servers (backend)===
Main page: [[Poolservers]]

*[[ecoinpool]] - Erlang poolserver (not maintained)
*[[Eloipool]] - Fast Python3 poolserver
*[[Pushpoold]] - Old mining poolserver in C (not maintained)
*[[Poold]] - Old Python mining poolserver (not maintained)
*[[PoolServerJ]] - Java mining poolserver (not maintained)

===Utilities, libraries, and interfaces:===
*[[BitcoinCrypto]] - a lightweight Bitcoin crypto library for Java/Android
*[[Bitcoin Dissector]] - a wireshark dissector for the bitcoin protocol
*[[Bitcointools]] - a set of Python tools accessing the transaction database and the wallet
*[[Finance::MtGox]] - a Perl module which interfaces with the Mt. Gox API
*[[libblkmaker]] - C library implementation of [[getblocktemplate]] decentralized mining protocol
*[[python-blkmaker]] - Python module implementation of [[getblocktemplate]] decentralized mining protocol

===Lists of software===
*[[BitGit]] - list of Bitcoin-related opensource projects hosted at Git

===Developer resources===
*[[:Category:Developer|Category:Developer]]
*[[:Category:Technical|Category:Technical]]
*[[Original Bitcoin client/API calls list]]
*[[API reference (JSON-RPC)]]
*[[PHP_developer_intro|PHP Developer Introduction]]

===Other===
*[[Namecoin]] - a distributed naming system based on Bitcoin technology
*[[Bitcoin Consultancy]] - an organization providing open source software and Bitcoin-related consulting
*[[Open Transactions]] - a financial crypto and digital cash software library, complementary to Bitcoin
*[[Moneychanger]] - Java-based GUI for [[Open Transactions]]
*[http://btcnames.org/ BTCnames] - a webbased aliasing service which allows to handle unlimited names for your BTC deposit hashes
*[[Devcoin]] - the open source developer coin

[[Category:Software|*]]

Original Bitcoin client/API calls list

2013-10-22T21:32:21Z

Jcv: /* Full list */

Bitcoin API call list (as of version 0.8.0)

== Common operations ==

=== Listing my bitcoin addresses ===

Listing the bitcoin [[address|addresses]] in your wallet is easily done via ''listreceivedbyaddress''. It normally lists only addresses which already have received transactions, however you can list all the addresses by setting the first argument to 0, and the second one to true.

[[accounts explained|Accounts]] are used to organize addresses.

== Full list ==

Required arguments are denoted inside < and > Optional arguments are inside [ and ].

{|class="wikitable"
! Command !! Parameters !! Description !! Requires unlocked wallet? (v0.4.0+)
|-
| addmultisigaddress || <nrequired> <'["key","key"]'> [account] || Add a nrequired-to-sign multisignature address to the wallet. Each key is a bitcoin address or hex-encoded public key. If [account] is specified, assign address to [account]. || N
|-
| addnode || <node> <add/remove/onetry> || '''version 0.8''' Attempts add or remove <node> from the addnode list or try a connection to <node> once. || N
|-
| backupwallet || <destination> || Safely copies wallet.dat to destination, which can be a directory or a path with filename. || N
|-
| createmultisig || <nrequired> <'["key,"key"]'> || Creates a multi-signature address and returns a json object ||
|-
| createrawtransaction || [{"txid":txid,"vout":n},...] {address:amount,...} || '''version 0.7''' Creates a [[Raw Transactions|raw transaction]] spending given inputs. || N
|-
| decoderawtransaction || <hex string> || '''version 0.7''' Produces a human-readable JSON object for a [[Raw Transactions|raw transaction]]. || N
|-
| dumpprivkey || <bitcoinaddress> || Reveals the private key corresponding to <bitcoinaddress> || Y
|-
| encryptwallet || <passphrase> || Encrypts the wallet with <passphrase>. || N
|-
| getaccount || <bitcoinaddress> || Returns the account associated with the given address. || N
|-
| getaccountaddress || <account> || Returns the current bitcoin address for receiving payments to this account. || N
|-
| getaddednodeinfo || <dns> [node] || '''version 0.8''' Returns information about the given added node, or all added nodes
(note that onetry addnodes are not listed here)
If dns is false, only a list of added nodes will be provided,
otherwise connected information will also be available.
|-
| getaddressesbyaccount || <account> || Returns the list of addresses for the given account. || N
|-
| getbalance || [account] [minconf=1] || If [account] is not specified, returns the server's total available balance. If [account] is specified, returns the balance in the account. || N
|-
| getbestblockhash || || '''recent git checkouts only''' Returns the hash of the best (tip) block in the longest block chain. || N
|-
| getblock || <hash> || Returns information about the block with the given hash. || N
|-
| getblockcount || || Returns the number of blocks in the longest block chain. || N
|-
| getblockhash || <index> || Returns hash of block in best-block-chain at <index>; index 0 is the [[genesis block]] || N
|-
| getblocknumber || || '''Deprecated'''. '''Removed in version 0.7'''. Use getblockcount. || N
|-
| getblocktemplate || [params] || Returns data needed to construct a block to work on. See [[ BIP_0022]] for more info on params.|| N
|-
| getconnectioncount || || Returns the number of connections to other nodes. || N
|-
| getdifficulty || || Returns the proof-of-work difficulty as a multiple of the minimum difficulty. || N
|-
| getgenerate || || Returns true or false whether bitcoind is currently generating hashes || N
|-
| gethashespersec || || Returns a recent hashes per second performance measurement while generating. || N
|-
| getinfo || || Returns an object containing various state info. || N
|-
| getmemorypool || [data] || '''Replaced in v0.7.0 with getblocktemplate, submitblock, getrawmempool``` || N
|-
| getmininginfo || || Returns an object containing mining-related information:
* blocks
* currentblocksize
* currentblocktx
* difficulty
* errors
* generate
* genproclimit
* hashespersec
* pooledtx
* testnet
|| N
|-
| getnewaddress || [account] || Returns a new bitcoin address for receiving payments. If [account] is specified (recommended), it is added to the address book so payments received with the address will be credited to [account]. || N
|-
| getpeerinfo || || '''version 0.7''' Returns data about each connected node. || N
|-
| getrawchangeaddress || [account]|| '''recent git checkouts only''' Returns a new Bitcoin address, for receiving change. This is for use with raw transactions, NOT normal use. || Y
|-
| getrawmempool || || '''version 0.7''' Returns all transaction ids in memory pool || N
|-
| getrawtransaction || <txid> [verbose=0] || '''version 0.7''' Returns [[Raw Transactions|raw transaction]] representation for given transaction id. || N
|-
| getreceivedbyaccount || [account] [minconf=1] || Returns the total amount received by addresses with [account] in transactions with at least [minconf] confirmations. If [account] not provided return will include all transactions to all accounts. (version 0.3.24) || N
|-
| getreceivedbyaddress || <bitcoinaddress> [minconf=1] || Returns the total amount received by <bitcoinaddress> in transactions with at least [minconf] confirmations. While some might consider this obvious, value reported by this only considers *receiving* transactions. It does not check payments that have been made *from* this address. In other words, this is not "getaddressbalance". Works only for addresses in the local wallet, external addresses will always show 0. || N
|-
| gettransaction || <txid> || Returns an object about the given transaction containing:
* "amount" : total amount of the transaction
* "confirmations" : number of confirmations of the transaction
* "txid" : the transaction ID
* "time" : time associated with the transaction<ref>From block timestamp, unless transaction was already in memory pool then the local time when the client added the transaction to its memory pool</ref>.
* "details" - An array of objects containing:
** "account"
** "address"
** "category"
** "amount"
** "fee"
|| N
|-
| gettxout || <txid> <n> [includemempool=true] || Returns details about an unspent transaction output (UTXO) || N
|-
| gettxoutsetinfo || || Returns statistics about the unspent transaction output (UTXO) set || N
|-
| [[getwork]] || [data] || If [data] is not specified, returns formatted hash data to work on:
* "midstate" : precomputed hash state after hashing the first half of the data
* "data" : block data
* "hash1" : formatted hash buffer for second hash
* "target" : little endian hash target
If [data] is specified, tries to solve the block and returns true if it was successful.
|| N
|-
| help || [command] || List commands, or get help for a command. || N
|-
| importprivkey || <bitcoinprivkey> [label] [rescan=true]|| Adds a private key (as returned by dumpprivkey) to your wallet. This may take a while, as a [[How_to_import_private_keys#Import_Private_key.28s.29|rescan]] is done, looking for existing transactions. '''Optional [rescan] parameter added in 0.8.0.''' || Y
|-
| keypoolrefill || || Fills the keypool, requires wallet passphrase to be set. || Y
|-
| listaccounts || [minconf=1] || Returns Object that has account names as keys, account balances as values. || N
|-
| listaddressgroupings || || '''version 0.7''' Returns all addresses in the wallet and info used for coincontrol. || N
|-
| listreceivedbyaccount || [minconf=1] [includeempty=false] || Returns an array of objects containing:
* "account" : the account of the receiving addresses
* "amount" : total amount received by addresses with this account
* "confirmations" : number of confirmations of the most recent transaction included
|| N
|-
| listreceivedbyaddress || [minconf=1] [includeempty=false] || Returns an array of objects containing:
* "address" : receiving address
* "account" : the account of the receiving address
* "amount" : total amount received by the address
* "confirmations" : number of confirmations of the most recent transaction included
To get a list of accounts on the system, execute bitcoind listreceivedbyaddress 0 true
|| N
|-
| listsinceblock|| [blockhash] [target-confirmations] || Get all transactions in blocks since block [blockhash], or all transactions if omitted. || N
|-
| listtransactions || [account] [count=10] [from=0] || Returns up to [count] most recent transactions skipping the first [from] transactions for account [account]. If [account] not provided will return recent transaction from all accounts.
|| N
|-
| listunspent || [minconf=1] [maxconf=999999] || '''version 0.7''' Returns array of unspent transaction inputs in the wallet. || N
|-
| listlockunspent || || '''version 0.8''' Returns list of temporarily unspendable outputs
|-
| lockunspent || <unlock?> [array-of-objects] || '''version 0.8''' Updates list of temporarily unspendable outputs
|-
| move || <fromaccount> <toaccount> <amount> [minconf=1] [comment] || Move from one account in your wallet to another || N
|-
| sendfrom || <fromaccount> <tobitcoinaddress> <amount> [minconf=1] [comment] [comment-to] || <amount> is a real and is rounded to 8 decimal places. Will send the given amount to the given address, ensuring the account has a valid balance using [minconf] confirmations. Returns the transaction ID if successful (not in JSON object). || Y
|-
| sendmany || <fromaccount> {address:amount,...} [minconf=1] [comment] || amounts are double-precision floating point numbers || Y
|-
| sendrawtransaction || <hexstring> || '''version 0.7''' Submits [[Raw Transactions|raw transaction]] (serialized, hex-encoded) to local node and network. || N
|-
| sendtoaddress || <bitcoinaddress> <amount> [comment] [comment-to] || <amount> is a real and is rounded to 8 decimal places. Returns the transaction ID <txid> if successful. || Y
|-
| setaccount || <bitcoinaddress> <account> || Sets the account associated with the given address. Assigning address that is already assigned to the same account will create a new address associated with that account. || N
|-
| setgenerate || <generate> [genproclimit] || <generate> is true or false to turn generation on or off. Generation is limited to [genproclimit] processors, -1 is unlimited. || N
|-
| settxfee || <amount> || <amount> is a real and is rounded to the nearest 0.00000001 || N
|-
| signmessage || <bitcoinaddress> <message> || Sign a message with the private key of an address. || Y
|-
| signrawtransaction || <hexstring> [{"txid":txid,"vout":n,"scriptPubKey":hex},...] [<privatekey1>,...] || '''version 0.7''' Adds signatures to a [[Raw Transactions|raw transaction]] and returns the resulting raw transaction. || Y/N
|-
| stop || || Stop bitcoin server. || N
|-
| submitblock || <hex data> [optional-params-obj] || Attempts to submit new block to network. || N
|-
| validateaddress || <bitcoinaddress> || Return information about <bitcoinaddress>. || N
|-
| verifymessage || <bitcoinaddress> <signature> <message> || Verify a signed message. || N
|-
| walletlock || || 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. || N
|-
| walletpassphrase || <passphrase> <timeout> || Stores the wallet decryption key in memory for <timeout> seconds. || N
|-
| walletpassphrasechange || <oldpassphrase> <newpassphrase> || Changes the wallet passphrase from <oldpassphrase> to <newpassphrase>. || N

|}

==Error Codes==

I don't see a list of error codes, so I figured I could just paste them here, or on some other page as I find them.

{| class="wikitable"
|-
! Raw !! Error !! Code !! Notes
|-
| { [Error: value is type str, expected real] code: -1 } || value is type str, expected real || -1
|-
| { [Error: Invalid amount] code: -3 } || Invalid amount || -3
|-
| { [Error: Insufficient funds] code: -4 }|| Insufficient funds || -4 || seems to happen when they need to pay a fee

|-
| { [Error: Account has insufficient funds] code: -6 } || Account has insufficient funds || -6
|}

==See Also==

* [[Original Bitcoin client]]
* [[Protocol specification]]
* [[API reference (JSON-RPC)]]
* [[Lazy_API]]
* [[Elis-API]] - A more detailed version of this page - for developers!
* [http://code.gogulski.com/bitcoin-php/class_bitcoin_client.html PHP BitcoinClient Class Reference]

==References==
<references />

[[Category:Technical]]
[[Category:Developer]]

Original Bitcoin client/API calls list

2013-10-11T20:46:35Z

Jcv: /* Full list */

Bitcoin API call list (as of version 0.8.0)

== Common operations ==

=== Listing my bitcoin addresses ===

Listing the bitcoin [[address|addresses]] in your wallet is easily done via ''listreceivedbyaddress''. It normally lists only addresses which already have received transactions, however you can list all the addresses by setting the first argument to 0, and the second one to true.

[[accounts explained|Accounts]] are used to organize addresses.

== Full list ==

Required arguments are denoted inside < and > Optional arguments are inside [ and ].

{|class="wikitable"
! Command !! Parameters !! Description !! Requires unlocked wallet? (v0.4.0+)
|-
| addmultisigaddress || <nrequired> <'["key","key"]'> [account] || Add a nrequired-to-sign multisignature address to the wallet. Each key is a bitcoin address or hex-encoded public key. If [account] is specified, assign address to [account]. || N
|-
| addnode || <node> <add/remove/onetry> || '''version 0.8''' Attempts add or remove <node> from the addnode list or try a connection to <node> once. || N
|-
| backupwallet || <destination> || Safely copies wallet.dat to destination, which can be a directory or a path with filename. || N
|-
| createmultisig || <nrequired> <'["key,"key"]'> || Creates a multi-signature address and returns a json object ||
|-
| createrawtransaction || [{"txid":txid,"vout":n},...] {address:amount,...} || '''version 0.7''' Creates a [[Raw Transactions|raw transaction]] spending given inputs. || N
|-
| decoderawtransaction || <hex string> || '''version 0.7''' Produces a human-readable JSON object for a [[Raw Transactions|raw transaction]]. || N
|-
| dumpprivkey || <bitcoinaddress> || Reveals the private key corresponding to <bitcoinaddress> || Y
|-
| encryptwallet || <passphrase> || Encrypts the wallet with <passphrase>. || N
|-
| getaccount || <bitcoinaddress> || Returns the account associated with the given address. || N
|-
| getaccountaddress || <account> || Returns the current bitcoin address for receiving payments to this account. || N
|-
| getaddednodeinfo || <dns> [node] || '''version 0.8''' Returns information about the given added node, or all added nodes
(note that onetry addnodes are not listed here)
If dns is false, only a list of added nodes will be provided,
otherwise connected information will also be available.
|-
| getaddressesbyaccount || <account> || Returns the list of addresses for the given account. || N
|-
| getbalance || [account] [minconf=1] || If [account] is not specified, returns the server's total available balance. If [account] is specified, returns the balance in the account. || N
|-
| getbestblockhash || || '''recent git checkouts only''' Returns the hash of the best (tip) block in the longest block chain. || N
|-
| getblock || <hash> || Returns information about the block with the given hash. || N
|-
| getblockcount || || Returns the number of blocks in the longest block chain. || N
|-
| getblockhash || <index> || Returns hash of block in best-block-chain at <index>; index 0 is the [[genesis block]] || N
|-
| getblocknumber || || '''Deprecated'''. '''Removed in version 0.7'''. Use getblockcount. || N
|-
| getblocktemplate || [params] || Returns data needed to construct a block to work on || N
|-
| getconnectioncount || || Returns the number of connections to other nodes. || N
|-
| getdifficulty || || Returns the proof-of-work difficulty as a multiple of the minimum difficulty. || N
|-
| getgenerate || || Returns true or false whether bitcoind is currently generating hashes || N
|-
| gethashespersec || || Returns a recent hashes per second performance measurement while generating. || N
|-
| getinfo || || Returns an object containing various state info. || N
|-
| getmemorypool || [data] || '''Replaced in v0.7.0 with getblocktemplate, submitblock, getrawmempool``` || N
|-
| getmininginfo || || Returns an object containing mining-related information:
* blocks
* currentblocksize
* currentblocktx
* difficulty
* errors
* generate
* genproclimit
* hashespersec
* pooledtx
* testnet
|| N
|-
| getnewaddress || [account] || Returns a new bitcoin address for receiving payments. If [account] is specified (recommended), it is added to the address book so payments received with the address will be credited to [account]. || N
|-
| getpeerinfo || || '''version 0.7''' Returns data about each connected node. || N
|-
| getrawchangeaddress || [account]|| '''recent git checkouts only''' Returns a new Bitcoin address, for receiving change. This is for use with raw transactions, NOT normal use. || Y
|-
| getrawmempool || || '''version 0.7''' Returns all transaction ids in memory pool || N
|-
| getrawtransaction || <txid> [verbose=0] || '''version 0.7''' Returns [[Raw Transactions|raw transaction]] representation for given transaction id. || N
|-
| getreceivedbyaccount || [account] [minconf=1] || Returns the total amount received by addresses with [account] in transactions with at least [minconf] confirmations. If [account] not provided return will include all transactions to all accounts. (version 0.3.24) || N
|-
| getreceivedbyaddress || <bitcoinaddress> [minconf=1] || Returns the total amount received by <bitcoinaddress> in transactions with at least [minconf] confirmations. While some might consider this obvious, value reported by this only considers *receiving* transactions. It does not check payments that have been made *from* this address. In other words, this is not "getaddressbalance". Works only for addresses in the local wallet, external addresses will always show 0. || N
|-
| gettransaction || <txid> || Returns an object about the given transaction containing:
* "amount" : total amount of the transaction
* "confirmations" : number of confirmations of the transaction
* "txid" : the transaction ID
* "time" : time associated with the transaction<ref>From block timestamp, unless transaction was already in memory pool then the local time when the client added the transaction to its memory pool</ref>.
* "details" - An array of objects containing:
** "account"
** "address"
** "category"
** "amount"
** "fee"
|| N
|-
| gettxout || <txid> <n> [includemempool=true] || Returns details about an unspent transaction output (UTXO) || N
|-
| gettxoutsetinfo || || Returns statistics about the unspent transaction output (UTXO) set || N
|-
| [[getwork]] || [data] || If [data] is not specified, returns formatted hash data to work on:
* "midstate" : precomputed hash state after hashing the first half of the data
* "data" : block data
* "hash1" : formatted hash buffer for second hash
* "target" : little endian hash target
If [data] is specified, tries to solve the block and returns true if it was successful.
|| N
|-
| help || [command] || List commands, or get help for a command. || N
|-
| importprivkey || <bitcoinprivkey> [label] [rescan=true]|| Adds a private key (as returned by dumpprivkey) to your wallet. This may take a while, as a [[How_to_import_private_keys#Import_Private_key.28s.29|rescan]] is done, looking for existing transactions. '''Optional [rescan] parameter added in 0.8.0.''' || Y
|-
| keypoolrefill || || Fills the keypool, requires wallet passphrase to be set. || Y
|-
| listaccounts || [minconf=1] || Returns Object that has account names as keys, account balances as values. || N
|-
| listaddressgroupings || || '''version 0.7''' Returns all addresses in the wallet and info used for coincontrol. || N
|-
| listreceivedbyaccount || [minconf=1] [includeempty=false] || Returns an array of objects containing:
* "account" : the account of the receiving addresses
* "amount" : total amount received by addresses with this account
* "confirmations" : number of confirmations of the most recent transaction included
|| N
|-
| listreceivedbyaddress || [minconf=1] [includeempty=false] || Returns an array of objects containing:
* "address" : receiving address
* "account" : the account of the receiving address
* "amount" : total amount received by the address
* "confirmations" : number of confirmations of the most recent transaction included
To get a list of accounts on the system, execute bitcoind listreceivedbyaddress 0 true
|| N
|-
| listsinceblock|| [blockhash] [target-confirmations] || Get all transactions in blocks since block [blockhash], or all transactions if omitted. || N
|-
| listtransactions || [account] [count=10] [from=0] || Returns up to [count] most recent transactions skipping the first [from] transactions for account [account]. If [account] not provided will return recent transaction from all accounts.
|| N
|-
| listunspent || [minconf=1] [maxconf=999999] || '''version 0.7''' Returns array of unspent transaction inputs in the wallet. || N
|-
| listlockunspent || || '''version 0.8''' Returns list of temporarily unspendable outputs
|-
| lockunspent || <unlock?> [array-of-objects] || '''version 0.8''' Updates list of temporarily unspendable outputs
|-
| move || <fromaccount> <toaccount> <amount> [minconf=1] [comment] || Move from one account in your wallet to another || N
|-
| sendfrom || <fromaccount> <tobitcoinaddress> <amount> [minconf=1] [comment] [comment-to] || <amount> is a real and is rounded to 8 decimal places. Will send the given amount to the given address, ensuring the account has a valid balance using [minconf] confirmations. Returns the transaction ID if successful (not in JSON object). || Y
|-
| sendmany || <fromaccount> {address:amount,...} [minconf=1] [comment] || amounts are double-precision floating point numbers || Y
|-
| sendrawtransaction || <hexstring> || '''version 0.7''' Submits [[Raw Transactions|raw transaction]] (serialized, hex-encoded) to local node and network. || N
|-
| sendtoaddress || <bitcoinaddress> <amount> [comment] [comment-to] || <amount> is a real and is rounded to 8 decimal places. Returns the transaction ID <txid> if successful. || Y
|-
| setaccount || <bitcoinaddress> <account> || Sets the account associated with the given address. Assigning address that is already assigned to the same account will create a new address associated with that account. || N
|-
| setgenerate || <generate> [genproclimit] || <generate> is true or false to turn generation on or off. Generation is limited to [genproclimit] processors, -1 is unlimited. || N
|-
| settxfee || <amount> || <amount> is a real and is rounded to the nearest 0.00000001 || N
|-
| signmessage || <bitcoinaddress> <message> || Sign a message with the private key of an address. || Y
|-
| signrawtransaction || <hexstring> [{"txid":txid,"vout":n,"scriptPubKey":hex},...] [<privatekey1>,...] || '''version 0.7''' Adds signatures to a [[Raw Transactions|raw transaction]] and returns the resulting raw transaction. || Y/N
|-
| stop || || Stop bitcoin server. || N
|-
| submitblock || <hex data> [optional-params-obj] || Attempts to submit new block to network. || N
|-
| validateaddress || <bitcoinaddress> || Return information about <bitcoinaddress>. || N
|-
| verifymessage || <bitcoinaddress> <signature> <message> || Verify a signed message. || N
|-
| walletlock || || 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. || N
|-
| walletpassphrase || <passphrase> <timeout> || Stores the wallet decryption key in memory for <timeout> seconds. || N
|-
| walletpassphrasechange || <oldpassphrase> <newpassphrase> || Changes the wallet passphrase from <oldpassphrase> to <newpassphrase>. || N

|}

==Error Codes==

I don't see a list of error codes, so I figured I could just paste them here, or on some other page as I find them.

{| class="wikitable"
|-
! Raw !! Error !! Code !! Notes
|-
| { [Error: value is type str, expected real] code: -1 } || value is type str, expected real || -1
|-
| { [Error: Invalid amount] code: -3 } || Invalid amount || -3
|-
| { [Error: Insufficient funds] code: -4 }|| Insufficient funds || -4 || seems to happen when they need to pay a fee

|-
| { [Error: Account has insufficient funds] code: -6 } || Account has insufficient funds || -6
|}

==See Also==

* [[Original Bitcoin client]]
* [[Protocol specification]]
* [[API reference (JSON-RPC)]]
* [[Lazy_API]]
* [[Elis-API]] - A more detailed version of this page - for developers!
* [http://code.gogulski.com/bitcoin-php/class_bitcoin_client.html PHP BitcoinClient Class Reference]

==References==
<references />

[[Category:Technical]]
[[Category:Developer]]

Original Bitcoin client/API calls list

2013-10-11T19:35:36Z

Jcv: /* Full list */

Bitcoin API call list (as of version 0.8.0)

== Common operations ==

=== Listing my bitcoin addresses ===

Listing the bitcoin [[address|addresses]] in your wallet is easily done via ''listreceivedbyaddress''. It normally lists only addresses which already have received transactions, however you can list all the addresses by setting the first argument to 0, and the second one to true.

[[accounts explained|Accounts]] are used to organize addresses.

== Full list ==

Required arguments are denoted inside < and > Optional arguments are inside [ and ].

{|class="wikitable"
! Command !! Parameters !! Description !! Requires unlocked wallet? (v0.4.0+)
|-
| addmultisigaddress || <nrequired> <'["key","key"]'> [account] || Add a nrequired-to-sign multisignature address to the wallet. Each key is a bitcoin address or hex-encoded public key. If [account] is specified, assign address to [account]. || N
|-
| addnode || <node> <add/remove/onetry> || '''version 0.8''' Attempts add or remove <node> from the addnode list or try a connection to <node> once. || N
|-
| backupwallet || <destination> || Safely copies wallet.dat to destination, which can be a directory or a path with filename. || N
|-
| createmultisig || <nrequired> <'["key,"key"]'> || Creates a multi-signature address and returns a json object ||
|-
| createrawtransaction || [{"txid":txid,"vout":n},...] {address:amount,...} || '''version 0.7''' Creates a [[Raw Transactions|raw transaction]] spending given inputs. || N
|-
| decoderawtransaction || <hex string> || '''version 0.7''' Produces a human-readable JSON object for a [[Raw Transactions|raw transaction]]. || N
|-
| dumpprivkey || <bitcoinaddress> || Reveals the private key corresponding to <bitcoinaddress> || Y
|-
| encryptwallet || <passphrase> || Encrypts the wallet with <passphrase>. || N
|-
| getaccount || <bitcoinaddress> || Returns the account associated with the given address. || N
|-
| getaccountaddress || <account> || Returns the current bitcoin address for receiving payments to this account. || N
|-
| getaddednodeinfo || <dns> [node] || '''version 0.8''' Returns information about the given added node, or all added nodes
(note that onetry addnodes are not listed here)
If dns is false, only a list of added nodes will be provided,
otherwise connected information will also be available.
|-
| getaddressesbyaccount || <account> || Returns the list of addresses for the given account. || N
|-
| getbalance || [account] [minconf=1] || If [account] is not specified, returns the server's total available balance. If [account] is specified, returns the balance in the account. || N
|-
| getbestblockhash || || '''version 0.8.4''' Returns the hash of the best (tip) block in the longest block chain. || N
|-
| getblock || <hash> || Returns information about the block with the given hash. || N
|-
| getblockcount || || Returns the number of blocks in the longest block chain. || N
|-
| getblockhash || <index> || Returns hash of block in best-block-chain at <index>; index 0 is the [[genesis block]] || N
|-
| getblocknumber || || '''Deprecated'''. '''Removed in version 0.7'''. Use getblockcount. || N
|-
| getblocktemplate || [params] || Returns data needed to construct a block to work on || N
|-
| getconnectioncount || || Returns the number of connections to other nodes. || N
|-
| getdifficulty || || Returns the proof-of-work difficulty as a multiple of the minimum difficulty. || N
|-
| getgenerate || || Returns true or false whether bitcoind is currently generating hashes || N
|-
| gethashespersec || || Returns a recent hashes per second performance measurement while generating. || N
|-
| getinfo || || Returns an object containing various state info. || N
|-
| getmemorypool || [data] || '''Replaced in v0.7.0 with getblocktemplate, submitblock, getrawmempool``` || N
|-
| getmininginfo || || Returns an object containing mining-related information:
* blocks
* currentblocksize
* currentblocktx
* difficulty
* errors
* generate
* genproclimit
* hashespersec
* pooledtx
* testnet
|| N
|-
| getnewaddress || [account] || Returns a new bitcoin address for receiving payments. If [account] is specified (recommended), it is added to the address book so payments received with the address will be credited to [account]. || N
|-
| getpeerinfo || || '''version 0.7''' Returns data about each connected node. || N
|-
| getrawchangeaddress || [account]|| '''version 0.8.4''' Returns a new Bitcoin address, for receiving change. This is for use with raw transactions, NOT normal use. || Y
|-
| getrawmempool || || '''version 0.7''' Returns all transaction ids in memory pool || N
|-
| getrawtransaction || <txid> [verbose=0] || '''version 0.7''' Returns [[Raw Transactions|raw transaction]] representation for given transaction id. || N
|-
| getreceivedbyaccount || [account] [minconf=1] || Returns the total amount received by addresses with [account] in transactions with at least [minconf] confirmations. If [account] not provided return will include all transactions to all accounts. (version 0.3.24) || N
|-
| getreceivedbyaddress || <bitcoinaddress> [minconf=1] || Returns the total amount received by <bitcoinaddress> in transactions with at least [minconf] confirmations. While some might consider this obvious, value reported by this only considers *receiving* transactions. It does not check payments that have been made *from* this address. In other words, this is not "getaddressbalance". Works only for addresses in the local wallet, external addresses will always show 0. || N
|-
| gettransaction || <txid> || Returns an object about the given transaction containing:
* "amount" : total amount of the transaction
* "confirmations" : number of confirmations of the transaction
* "txid" : the transaction ID
* "time" : time associated with the transaction<ref>From block timestamp, unless transaction was already in memory pool then the local time when the client added the transaction to its memory pool</ref>.
* "details" - An array of objects containing:
** "account"
** "address"
** "category"
** "amount"
** "fee"
|| N
|-
| gettxout || <txid> <n> [includemempool=true] || Returns details about an unspent transaction output (UTXO) || N
|-
| gettxoutsetinfo || || Returns statistics about the unspent transaction output (UTXO) set || N
|-
| [[getwork]] || [data] || If [data] is not specified, returns formatted hash data to work on:
* "midstate" : precomputed hash state after hashing the first half of the data
* "data" : block data
* "hash1" : formatted hash buffer for second hash
* "target" : little endian hash target
If [data] is specified, tries to solve the block and returns true if it was successful.
|| N
|-
| help || [command] || List commands, or get help for a command. || N
|-
| importprivkey || <bitcoinprivkey> [label] [rescan=true]|| Adds a private key (as returned by dumpprivkey) to your wallet. This may take a while, as a [[How_to_import_private_keys#Import_Private_key.28s.29|rescan]] is done, looking for existing transactions. '''Optional [rescan] parameter added in 0.8.0.''' || Y
|-
| keypoolrefill || || Fills the keypool, requires wallet passphrase to be set. || Y
|-
| listaccounts || [minconf=1] || Returns Object that has account names as keys, account balances as values. || N
|-
| listaddressgroupings || || '''version 0.7''' Returns all addresses in the wallet and info used for coincontrol. || N
|-
| listreceivedbyaccount || [minconf=1] [includeempty=false] || Returns an array of objects containing:
* "account" : the account of the receiving addresses
* "amount" : total amount received by addresses with this account
* "confirmations" : number of confirmations of the most recent transaction included
|| N
|-
| listreceivedbyaddress || [minconf=1] [includeempty=false] || Returns an array of objects containing:
* "address" : receiving address
* "account" : the account of the receiving address
* "amount" : total amount received by the address
* "confirmations" : number of confirmations of the most recent transaction included
To get a list of accounts on the system, execute bitcoind listreceivedbyaddress 0 true
|| N
|-
| listsinceblock|| [blockhash] [target-confirmations] || Get all transactions in blocks since block [blockhash], or all transactions if omitted. || N
|-
| listtransactions || [account] [count=10] [from=0] || Returns up to [count] most recent transactions skipping the first [from] transactions for account [account]. If [account] not provided will return recent transaction from all accounts.
|| N
|-
| listunspent || [minconf=1] [maxconf=999999] || '''version 0.7''' Returns array of unspent transaction inputs in the wallet. || N
|-
| listlockunspent || || '''version 0.8''' Returns list of temporarily unspendable outputs
|-
| lockunspent || <unlock?> [array-of-objects] || '''version 0.8''' Updates list of temporarily unspendable outputs
|-
| move || <fromaccount> <toaccount> <amount> [minconf=1] [comment] || Move from one account in your wallet to another || N
|-
| sendfrom || <fromaccount> <tobitcoinaddress> <amount> [minconf=1] [comment] [comment-to] || <amount> is a real and is rounded to 8 decimal places. Will send the given amount to the given address, ensuring the account has a valid balance using [minconf] confirmations. Returns the transaction ID if successful (not in JSON object). || Y
|-
| sendmany || <fromaccount> {address:amount,...} [minconf=1] [comment] || amounts are double-precision floating point numbers || Y
|-
| sendrawtransaction || <hexstring> || '''version 0.7''' Submits [[Raw Transactions|raw transaction]] (serialized, hex-encoded) to local node and network. || N
|-
| sendtoaddress || <bitcoinaddress> <amount> [comment] [comment-to] || <amount> is a real and is rounded to 8 decimal places. Returns the transaction ID <txid> if successful. || Y
|-
| setaccount || <bitcoinaddress> <account> || Sets the account associated with the given address. Assigning address that is already assigned to the same account will create a new address associated with that account. || N
|-
| setgenerate || <generate> [genproclimit] || <generate> is true or false to turn generation on or off. Generation is limited to [genproclimit] processors, -1 is unlimited. || N
|-
| settxfee || <amount> || <amount> is a real and is rounded to the nearest 0.00000001 || N
|-
| signmessage || <bitcoinaddress> <message> || Sign a message with the private key of an address. || Y
|-
| signrawtransaction || <hexstring> [{"txid":txid,"vout":n,"scriptPubKey":hex},...] [<privatekey1>,...] || '''version 0.7''' Adds signatures to a [[Raw Transactions|raw transaction]] and returns the resulting raw transaction. || Y/N
|-
| stop || || Stop bitcoin server. || N
|-
| submitblock || <hex data> [optional-params-obj] || Attempts to submit new block to network. || N
|-
| validateaddress || <bitcoinaddress> || Return information about <bitcoinaddress>. || N
|-
| verifymessage || <bitcoinaddress> <signature> <message> || Verify a signed message. || N
|-
| walletlock || || 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. || N
|-
| walletpassphrase || <passphrase> <timeout> || Stores the wallet decryption key in memory for <timeout> seconds. || N
|-
| walletpassphrasechange || <oldpassphrase> <newpassphrase> || Changes the wallet passphrase from <oldpassphrase> to <newpassphrase>. || N

|}

==Error Codes==

I don't see a list of error codes, so I figured I could just paste them here, or on some other page as I find them.

{| class="wikitable"
|-
! Raw !! Error !! Code !! Notes
|-
| { [Error: value is type str, expected real] code: -1 } || value is type str, expected real || -1
|-
| { [Error: Invalid amount] code: -3 } || Invalid amount || -3
|-
| { [Error: Insufficient funds] code: -4 }|| Insufficient funds || -4 || seems to happen when they need to pay a fee

|-
| { [Error: Account has insufficient funds] code: -6 } || Account has insufficient funds || -6
|}

==See Also==

* [[Original Bitcoin client]]
* [[Protocol specification]]
* [[API reference (JSON-RPC)]]
* [[Lazy_API]]
* [[Elis-API]] - A more detailed version of this page - for developers!
* [http://code.gogulski.com/bitcoin-php/class_bitcoin_client.html PHP BitcoinClient Class Reference]

==References==
<references />

[[Category:Technical]]
[[Category:Developer]]

API reference (JSON-RPC)

2013-10-11T19:00:00Z

Jcv: /* Perl */

== Controlling Bitcoin ==

Run ''bitcoind'' or ''bitcoin-qt -server''. You can control it via the command-line 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
$ ./bitcoind help
# shows the help text

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

$ ./bitcoind getbalance
2000.00000

== 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.

To access the server you should find a [http://json-rpc.org/wiki/implementations suitable library] for your language.

== Proper money handling ==

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

== 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.getinfo()
access.listreceivedbyaddress(6)
#access.sendtoaddress("11yEmxiMso2RsFVfBcCa616npBvGgxiBX", 10)
</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.getinfo
p h.getnewaddress
p h.dumpprivkey( h.getnewaddress )
# also see: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list
end
</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->getinfo()); echo "\n";
echo "Received: ".$bitcoin->getreceivedbylabel("Your Address")."\n";
echo "</pre>";
</source>

== 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, any JSON-RPC library for Java (or ordinary URL POSTs) may be used to communicate with the Bitcoin server.

== 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 => 'getinfo',
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/conformal/btcjson btcjson package] can be used to communicate with Bitcoin. You must provide credentials to match the client you are communicating with.

<source lang="go">
import "github.com/conformal/btcjson"
msg, err := btcjson.CreateMessage("getinfo")
if err != nil {
// Do your error handling
}
// Use your username and password here.
reply, err := btcjson.RpcCommand("user", "password", "localhost:8332", msg)
</source>

== .NET (C#) ==
The communication with rpc service can be achieved using the standard httprequest/response objects.
A library for serialising and deserialising Json will make your life a lot easier:

* JayRock for .NET 4.0
* Json.Net for .NET 2.0 and above

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.GetInfo();
Console.WriteLine("Balance:" + inf["balance"]);
</source>

== Node.js ==

* [https://github.com/freewil/node-bitcoin node-bitcoin] (npm: bitcoin)

Example using node-bitcoin:

<source lang="javascript">
var bitcoin = require('bitcoin');
var client = new bitcoin.Client({
host: 'localhost',
port: 8332,
user: 'user',
pass: 'pass'
});

client.getDifficulty(function(err, difficulty) {
if (err) {
return console.error(err);
}

console.log('Difficulty: ' + difficulty);
});
</source>

Example using Kapitalize:

<source lang='javascript'>
var client = require('kapitalize')()

client.auth('user', 'password')

client
.getInfo()
.getDifficulty(function(err, difficulty) {
console.log('Dificulty: ', difficulty)
})
</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": "getinfo", "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>

== 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/getinfo)
{"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>

== See Also==

* [[Original_Bitcoin_client/API_Calls_list|API calls list]]
* [[Running Bitcoin]]
* [[Lazy API]]
* [[PHP developer intro]]
* [[Raw_Transactions|Raw Transactions API]]
* [http://blockchain.info/api/json_rpc_api Web Based JSON RPC interface.]

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

Proper Money Handling (JSON-RPC)

2013-10-11T18:53:29Z

Jcv: /* Perl */

== Overview ==
The original bitcoin client stores all bitcoin values as 64-bit integers, with 1 BTC stored as 100,000,000 (one-hundred-million of the smallest possible bitcoin unit). Values are expressed as double-precision Numbers in the JSON API, with 1 BTC expressed as 1.00000000

If you are writing software that uses the JSON-RPC interface you need to be aware of possible floating-point conversion issues. You, or the JSON library you are using, should convert amounts to either a fixed-point Decimal representation (with 8 digits after the decimal point) or ideally a 64-bit integer representation. In either case, rounding values is required.

Improper value handling can lead to embarrassing errors; for example, if you truncate instead of doing proper rounding and your software will display the value "0.1 BTC" as "0.09999999 BTC" (or, worse, "0.09 BTC").

The original bitcoin client does proper, full-precision rounding for all values passed to it via the RPC interface. So, for example, if the value 0.1 is converted to the value "0.099999999999" by your JSON-RPC library, that value will be rounded to the nearest 0.00000001 bitcoin and will be treated as exactly 0.10 BTC.

The rest of this page gives sample code for various JSON libraries and programming languages.

== BASH ==
<source lang="bash">
function JSONtoAmount() {
printf '%.8f' "$1" | tr -d '.'
}
</source>

== C/C++ ==
C/C++ JSON libraries return the JavaScript Number type as type 'double'. To convert, without loss of precision, from a double to a 64-bit integer multiply by 100,000,000 and round to the nearest integer:
int64_t JSONtoAmount(double value) {
return (int64_t)(value * 1e8 + (value < 0.0 ? -.5 : .5));
}

To convert to a JSON value divide by 100,000,000.0, and make sure your JSON implementation outputs doubles with 8 or more digits after the decimal point:
double forJSON = (double)amount / 1e8;

== ECMAScript ==

function JSONtoAmount(value) {
return Math.round(1e8 * value);
}

== Perl ==
sub JSONtoAmount {
return sprintf '%.0f', 1e8 * shift;
}

== Go ==
The [https://github.com/conformal/btcjson btcjson package] provides a more complete version of this function (error checking and so on), but for illustrative purposes, this is useful.

func JSONToAmount(jsonAmount float64) (int64) {
var amount int64
tempVal := 1e8 * jsonAmount
if tempVal < 0 {
tempVal = tempVal - 0.5
}
if tempVal > 0 {
tempVal = tempVal + 0.5
}
// Then just rely on the integer truncating
amount = int64(tempVal)
return amount
}

== PHP ==
function JSONtoAmount($value) {
return round($value * 1e8);
}

== Python ==
def JSONtoAmount(value):
return long(round(value * 1e8))
def AmountToJSON(amount):
return float(amount / 1e8)

== Common Lisp ==
(defun json-to-amount (n)
(coerce (round (* n 1e8)) 'integer))

'''CAUTION''': The CL-JSON library parses numbers as ''single'' precision floating-point by
default. The default parsing behavior can be overridden as follows:

(set-custom-vars :real (lambda (n)
(json::parse-number (concatenate 'string n "d0"))))
[[Category:Technical]]
[[Category:Developer]]

[[de:Korrektes_Handling_von_Geldbeträgen_(JSON-RPC)]]