The core Bitcoin network can scale to much higher transaction rates than are seen today, assuming that nodes in the network are primarily running on high end servers rather than desktops. Bitcoin was designed to support lightweight clients that only process small parts of the block chain (see ''simplified payment verification'' below for more details on this). A configuration in which the vast majority of users sync lightweight clients to more powerful backbone nodes is capable of scaling to millions of users and tens of thousands of transactions per second.

==Scalability targets==

VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 47,000 tps. [http://www.visa.com/blogarchives/us/2013/10/10/stress-test-prepares-visanet-for-the-most-wonderful-time-of-the-year/index.html]

PayPal, in contrast, handles around 4 million transactions per day for an average of 46 tps or a probably peak rate of 100 tps.

Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.

==Current bottlenecks==

Today the Bitcoin network is restricted to a sustained rate of 7 tps by some artificial limits. These were put in place to stop people from ballooning the size of the block chain before the network and community was ready for it. Once those limits are lifted, the maximum transaction rate will go up significantly.

==CPU==

The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.

The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some ECDSA signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.

Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core [http://ark.intel.com/products/53469 Intel Core i7-2670QM 2.2Ghz processor]. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.

As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity for signature checking unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2012 the network is handling 0.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.

Of course Bitcoin does other things beyond signature checking, most obviously, managing the database. We use LevelDB which does the bulk of the heavy lifting on a separate thread, and is capable of very high read/write loads. Overall Bitcoin's CPU usage is dominated by ECDSA.

==Network==

Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.

That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.

This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.

When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.

==Storage==

At very high transaction rates each block can be over half a gigabyte in size.

It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.

Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.

The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. It is quite possible that the set will always fit in memory on dedicated server class machines, if hardware advances faster than Bitcoin usage does.

==Optimizations==

The description above applies to the current software with only minor optimizations assumed (the type that can and have been done by one man in a few weeks).

However there is potential for even greater optimizations to be made in future, at the cost of some additional complexity.

===CPU===

Pieter Wuille has implemented a custom verifier tuned for secp256k1 that can go beyond 20,000 signature verifications per second. It would require careful review by professional cryptographers to gain as much confidence as OpenSSL, but this can easily halve CPU load.

Algorithms exist to accelerate batch verification over elliptic curve signatures. This means if there are several inputs that are signing with the same key, it's possible to check their signatures simultaneously for another 9x speedup. This is a somewhat more complex implementation, however, it can work with existing signatures (clients don't need upgrading).

Newly developed digital signature algorithms, like [http://ed25519.cr.yp.to/ed25519-20110705.pdf ed25519] have extremely efficient software implementations that can reach speeds of nearly 80,000 verifications per second, even on an old Westmere CPU. That is a 10x improvement over secp256k1, and most likely is even higher on more modern CPUs. Supporting this in Bitcoin would mean a chain fork. This ECC algorithm has also been shown to be [http://eprint.iacr.org/2014/198 easily accelerated using GPUs], yielding scalar point multiplication times of less than a microsecond (i.e. a million point multiplications per second).

At these speeds it is likely that disk and memory bandwidth would become the primary limiting factor, rather than signature checking.

===Simplified payment verification===


It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. [[bitcoinj]] is an implementation of this mode.

In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block.

As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg, you only really need to store say 5000 blocks).

The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.

Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.

See also: [[Thin Client Security]].

== Related work ==
There are a few proposals for optimizing Bitcoin's scalability. Some of these require an alt-chain / hard fork.

* [https://bitcointalk.org/index.php?topic=88208.0 Ultimate blockchain compression] - the idea that the blockchain can be compressed to achieve "trust-free lite nodes"
* [http://www.bitfreak.info/files/pp2p-ccmbc-rev1.pdf The Finite Blockchain] paper that describes splitting the blockchain into three data structures, each better suited for its purpose. The three data structures are a finite blockchain (keep N blocks into the past), an "account tree" which keeps account balance for every address with a non-zero balance, and a "proof chain" which is an (ever growing) slimmed down version of the blockchain.

[[Category:Technical]]

API reference (JSON-RPC)

2014-08-11T00:48:54Z

Pietrod21: /* Python */

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

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>

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

== 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/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/conformal/btcnet"
"github.com/conformal/btcrpcclient"
"github.com/conformal/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", &btcnet.MainNetParams)
if err != nil {
log.Fatalf("address receiver1 seems to be invalid: %v", err)
}
receiver2, err := btcutil.DecodeAddress("1anotherAddressThatsPrettyReal", &btcnet.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 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>

== 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)]]

2014-04-23T13:33:42Z

Pietrod21: /* Screenshots */

[[Image:HolyTransaction_Logo.png|300px]]

[https://www.holytransaction.com HolyTransaction] is a multi currency online wallet for nontechnical users that offers a simple and instant exchange among top cryptocurrencies. Users can send and receive cryptocurrency from mobile wallet or over social networks, such as Facebook, LinkedIn and Twitter.

==Specifications==

With just an email, users can send and receive Bitcoin from anyone, instantly.
Multi-currency, Mobile support, Instant Exchange, Instant GiftCode, Cold-Storage Security, Google Authenticator 2FA, QR Codes, transaction history, exchange history, Open API for merchants and more. Android and iOS friendly.

==History==

* HolyTransaction Beta launch: February 16th 2014

==External Links==

* [https://www.holytransaction.com HolyTransaction] Official website
* [https://bitcointalk.org/index.php?topic=472248.0 on BitcoinTalk] BitcoinTalk
* [https://twitter.com/NoveltyLab@NobeltyLab] Twitter
* [http://www.facebook.com/HolyTransaction HolyTransaction Facebook] Facebook page
* [https://plus.googleapis.com/108905880098500076417 HolyTransaction on Google+ ] Google+ page

==Software development==
* [http://noveltylab.com NoveltyLab]

==Screenshots==
[[Image:Holytransaction_Screenshot_1.png‎‎|400px]]
[[Image:Holytransaction_Screenshot_2.png‎‎|400px]]

[[Category:EWallets]]
[[Category:Wallets]]
[[Category:Services]]
[[Category:Financial]]
[[Category:Clients]]
[[Category:Frontends]]

HolyTransaction

2014-04-23T13:33:08Z

Pietrod21: /* Screenshots */

[[Image:HolyTransaction_Logo.png|300px]]

[https://www.holytransaction.com HolyTransaction] is a multi currency online wallet for nontechnical users that offers a simple and instant exchange among top cryptocurrencies. Users can send and receive cryptocurrency from mobile wallet or over social networks, such as Facebook, LinkedIn and Twitter.

==Specifications==

With just an email, users can send and receive Bitcoin from anyone, instantly.
Multi-currency, Mobile support, Instant Exchange, Instant GiftCode, Cold-Storage Security, Google Authenticator 2FA, QR Codes, transaction history, exchange history, Open API for merchants and more. Android and iOS friendly.

==History==

* HolyTransaction Beta launch: February 16th 2014

==External Links==

* [https://www.holytransaction.com HolyTransaction] Official website
* [https://bitcointalk.org/index.php?topic=472248.0 on BitcoinTalk] BitcoinTalk
* [https://twitter.com/NoveltyLab@NobeltyLab] Twitter
* [http://www.facebook.com/HolyTransaction HolyTransaction Facebook] Facebook page
* [https://plus.googleapis.com/108905880098500076417 HolyTransaction on Google+ ] Google+ page

==Software development==
* [http://noveltylab.com NoveltyLab]

==Screenshots==
[[Image:Holytransaction_Screenshot_1.png‎‎|400px]]
[[Image:Holytransaction_Screenshot_2.png‎‎|400px]]
[[Image:Holytransaction_Screenshot_3.png‎‎|400px]]

[[Category:EWallets]]
[[Category:Wallets]]
[[Category:Services]]
[[Category:Financial]]
[[Category:Clients]]
[[Category:Frontends]]

HolyTransaction

2014-04-23T13:31:50Z

Pietrod21:

File:HolyTransaction Logo.png

2014-04-23T13:29:36Z

Pietrod21: HolyTransaction Logo

HolyTransaction Logo

HolyTransaction

2014-04-23T13:20:53Z

Pietrod21: HolyTransaction

[[Image:Logo_Holytransaction.png‎‎|300px]]

[https://www.holytransaction.com HolyTransaction] is a multi currency online wallet for nontechnical users that offers a simple and instant exchange among top cryptocurrencies. Users can send and receive cryptocurrency from mobile wallet or over social networks, such as Facebook, LinkedIn and Twitter.

==Specifications==

With just an email, users can send and receive Bitcoin from anyone, instantly.
Multi-currency, Mobile support, Instant Exchange, Instant GiftCode, Cold-Storage Security, Google Authenticator 2FA, QR Codes, transaction history, exchange history, Open API for merchants and more. Android and iOS friendly.

==History==

* HolyTransaction Beta launch: February 16th 2014

==External Links==

* [https://www.holytransaction.com HolyTransaction] Official website
* [https://bitcointalk.org/index.php?topic=472248.0 on BitcoinTalk] BitcoinTalk
* [https://twitter.com/NoveltyLab@NobeltyLab] Twitter
* [http://www.facebook.com/HolyTransaction HolyTransaction Facebook] Facebook page
* [https://plus.googleapis.com/108905880098500076417 HolyTransaction on Google+ ] Google+ page

==Software development==
* [http://noveltylab.com NoveltyLab]

==Screenshots==
[[Image:Holytransaction_Screenshot_1.png‎‎|400px]]

[[Category:EWallets]]
[[Category:Wallets]]
[[Category:Services]]
[[Category:Financial]]
[[Category:Clients]]
[[Category:Frontends]]