Bitcoin Clearing Engine

Our Bitcoin Clearing Engine, BCE, is written on the basis of bitcoinJ library, an open source Java implementation of the Bitcoin protocol, which allows it to maintain a wallet and send/receive transactions without needing a local copy of Bitcoin Core.

BCE can be easily integrated with any front end system to serve bitcoin operations.

 

Main Features:

1. Hosting multiple customer wallets.

2. Cold storage wallets and hot wallets for daily bitcoin operations.

3. Scalable and Extensible on demand architecture.

4. Queuing system for concurrent clearing transactions.

5. Robust API for integration with third party systems.

6. Web based management console with role based permissions.

7. Notification system to technical and financial admins via e-mail and sms.

8. Secure architecture.

9. Build in backup mechanism.

10. Easy to install and integrate.

11. 100% source code provided to the customer.

12. Premium support packages available.

13. Written in Java, can be easily customized and upgraded.

14. Reporting and Accounting system integrated.

15. Hash Malleability attack bulletproof.

 

Clearing Mechanisms:

BCE was designed to be able to host customer wallets and

A. enable securely sending/receiving bitcoins by these wallets.

B. enable the financial administrator of the system to send to bitcoins from hot wallets. This process is utilized during deposits of fiat to virtual currencies.

C. enable the financial administrator of the system to withdraw from customer wallets and send to a master wallet. This process is utilized during withdrawal of bitcoin to fiat currencies.

 

Hot Wallets:

These are the types of wallets which act as a buffer between cold storage and the customer wallets. These wallets hold small amounts of bitcoins and perform the send/receive operations.

By following the hot wallets architecture, there are two significant benefits.

A. Multiple sends to different addresses can be performed in parallel from different hot wallets. (Because for each transaction any type of wallet has to wait for the blockchain conformations, thus making it not able to spend again while waiting for confirmations and change)

 

B. Small amounts of bitcoins are held in multiple wallets, which eliminates a single point of hacking and the ability to renew sending addresses.

 

Filling and Emptying Hot Wallets:

An automated process has been implemented to send and receive bitcoins by the hot wallets. The “filling” hot wallets process sends to newly created (by the system) hot wallets from a master wallet, which is in turn temporarily filled from cold storage.

The reverse process empties the “hot wallets” and sends them back to either cold storage or the temporary master wallet.

The number of hot wallets and the amount to be send, is set by the administrator from the administrative console, depending on the needs of the business. The number of hot wallets in service, is directly proportional to the concurrent send operations that can be performed.

 

Hot Wallets Servicing Algorithm:

Requests to send bitcoins to customer wallets come in from the front system, this could be a web e-commerce portal or exchange. The requests are passed in the queuing system and in turn routed to the next available hot wallet with the nearest amount of bitcoins available.

 

For instance, if 3 hot wallets exist, each with balance of 9, 11 and 13 bitcoins, for a request to send 10 btc, it will be routed to the nearest number, which is the second wallet with 11 bitcoins. This is done to minimize the number of send operations and thus minimize mining fees.

There is a threshold setting which determines the minimum bitcoin amount that each hot wallet can reach. If the hot wallet reaches that amount or less, the hot wallet automatically sends the remaining amount back to the master wallet and the hot wallet is retired and never used again. That remaining amount will be resend later to a new hot wallet from the master wallet.

With this process, new hot wallets are being created constantly, thus making the backtrack process very hard and eliminates the possibility of a hacker deriving private keys from public keys because of multiple transactions.

 

Servicing Large Amount Request:

A request to send bitcoins to a customer wallet is considered large when the amount requested, is larger than any of the current balance of the hot wallets.

For instance, for the three wallets,each with balance of 9, 11 and 13 bitcoins, a request to send 14 bitcoins will not be able to be processed automatically.

Sending from multiple hot wallets is a possible solution, however that would reduce the concurrency rate of the system (sending from one hot wallet to the other and waiting for change and confirmations) and would in some cases increase mining fees, if the amount requested transactions from multiple hot wallets.

Therefore, the system puts large requests in queue and immediately notifies the administrator. The administrator only needs to approve this transaction where a new hot wallet will be created and filled from the master wallet with the exact amount of the request and send it to the customer wallet. The hot wallet is retired after finishing this request.

 

API Description:

The built in API allows to perform the following functions:

A. Send bitcoins from master, customer, hot wallets.

B. Get balance updates for any existing wallet under the control of the system.

C. Create new customer wallet.

D. Create hot wallets.

E. Process large amount requests.

 

Security:

BCE is designed to never reach the internet directly. All communication is encrypted via GRE and directed to a custom made proxy which in turn connects to our own bitcoin nodes, instead of connecting to the bitcoin network directly.

Our bitcoin nodes keep an updated version of the blockchain in optimized databases which serve fast the requests of the BCE, thus, eliminating attacks coming in from the bitcoin network ports.

The nodes also serve wallet synchronization, therefore eliminating the need to wait for the blockchain.

Backup:

All the private keys and wallet files are immediately backed up to multiple physical locations via encrypted tunnels. The keys and files are stored in an encrypted format on database which reside on encrypted partition file systems. Thus eliminating the possibility of stealing keys, even if hard drives from backup locations are stolen.

 

Recovery:

In the case of a system failure and data loss, an automated recovery process is implemented which can restore services and balances from the backup files.

 

Virtualization:

BCE is created to be fully compatible with virtualization, in the sense that allows bringing up and connecting multiple instances of the engine, in order to scale up on demand.

A load balancer application residing in front allows updating the system’s reporting and accounting system.