The reliability of the Bitcoin system is assured primarily by encryption. The system's main vulnerability is the Bitcoin wallet, created as a file on the computer. If a hacker (or a computer virus) gains access to the computer and can read this file, he (it) will be able to transfer all the money to his (its) anonymous account where it will be nearly impossible to find. It will also be impossible to prove to anyone that you did not voluntarily transfer the money to your own anonymous account.

Our Bitcoincard, a stand-alone device that in effect acts as an electronic wallet, can be used to hide the wallet in a safe place (outside the computer, making it inaccessible to hackers).

It is worth noting in this regard that:

- digital signature keys are created and stored inside the card, and never leave it;
- the card does not have an operating system or the ability to download additional software, which protects the card from attacks by viruses;
- the exchange protocol with the outside world is simple and protected by encryption;
- if the wallet is lost, the money is also lost; - the card is completely anonymous;
- the card has unmatched energy efficiency, and does not need to be charged;
- the card has unprecedented processing power for an ordinary smart card;
- the cards communicate using their own radio protocol, and do not require any communications infrastructure.

In essence, Bitcoincards are Bitcoin clients and support the following operations:

- creation of an electronic wallet (addresses);
- receipt of coins from Bitcoin clients;
- transfer of coins to Bitcoin clients;
- transfer of coins from card to card (bypassing the Bitcoin system during transfer, but with subsequent confirmation in the system).

Bitcoincards only interact with the outside world (the Bitcoin system) through the radio. The card contains a chip with a low-power radio transmitter.
In addition to the traditional Bitcoin system, two components are needed for the functioning of the Bitcoincard:
- a gateway to ensure interaction between the card and an IP network by radio;
- a server to ensure interaction between the card and the Bitcoin system.
The gateway is a very simple device that only receives packets by radio from the Bitcoincard and transfers them to the server using IP, and transfers IP packets by radio from the server to the card. The gateway can be a separate small device with an Ethernet connection and an antenna, or a USB dongle with an antenna connected to a portable device (notebook), computer or, for example, a payment terminal. Additional software is installed when the USB dongle is connected to a computer.
The server is the intermediary between the Bitcoincard and the Bitcoin system, and performs the following functions:
- receipt of payments from Bitcoincards (with confirmation of receipt) and transfer of payments in the Bitcoin system;
- check of the validation and status of all transactions addressed to the cards (number of confirmations in the ledger);
- division of large transactions addressed to the card into several transactions (if several outputs are addressed to one card);
- establishes a connection with several Bitcoin nodes;
- supports a copy of the ledger;

Characteristics of the card:
- limited capacity, memory and energy reserve;
- lack of a permanent connection with the outside world;
- limit on the size of transactions accepted, transferred and processed (currently no more than two inputs and two outputs);
- the card does not have resources to store a copy of the ledger (and must therefore trust the server); for this a special key is introduced for signing messages between the card and the server. To conserve the card’s resources, this key can be shorter than those used in Bitcoin. But not much shorter: if a hacker is able to capture this key, he could "convince" the card that his payment has been confirmed (not a dire consequence for the system as a whole, but unpleasant for the cardholder: the card will accept this payment, but when an attempt to settle accounts is made the payment will not be accepted by the system). However, to conduct such an attack the hacker, in addition to forming a "false" (double) payment, will have to "squat" on the communications line (either between the gateway and the server or between the card and the gateway) or set up a fake "access point". The ability for key exhaustion is also limited by the validity period of the request of the card. Every card has its own key for communication with the server, to reduce the likelihood of the entire system being compromised.
- if there are several servers in the system, one of them can be singled out as the main server responsible for confirming the certificates of all other servers. The signature of the main server is "embedded" into the card on initialization. The gateway chooses the server. The servers are connected to one another and support a general database of open keys of cards (not Bitcoin keys, but for connection with the server).

How it works.

Receipt of coins on the card.

1) The card enters the coverage area of the gateway, and after being switched on hears the beacons;
2) The card requests the updates (incoming payments) since the last communications session;
3) The server either answers that there are no updates, or transfers an incoming transaction with a tag indicating whether there are more;
4) If the tag indicates that there are more transactions, the card requests the next incoming transaction until there are no more;
5) Then the card requests and updates the status of each unconfirmed transaction;
6) The amount of the payments received is shown on the screen.

Transfer of coins from a card.

1) The card enters the coverage area of the gateway, and after being switched on hears the beacons;
2) The user chooses the address of the payment recipient from the address book (or types it on the keyboard) and enters the amount of the transfer;
3) The card forms and signs the transaction;
4) The card broadcasts the transaction (several times until the server confirms receipt);
5) The gateway hears the transaction and transfers it to the server, then sends the server's response to the card;
6) If confirmation of receipt is not received, the transaction is stored in the unsent transaction buffer to be sent later;
7) The card then requests the status of the transaction (number of confirmations) from the server and shows it on the screen.

Transfer of coins from card to card (in the absence of a connection to the server).

1) At the press of a button, the recipient's card broadcasts its address (possibly together with a user name). At the same time, the screen shows the control numbers of the address
2) The recipient's card hears the address and offers to enter it in the address book, showing the user name and control numbers of the address on the screen (the control numbers can be checked by the recipient and the sender);
3) The sender chooses the payment recipient and the amount, and the card forms and signs the transaction;
4) The sender's card broadcasts the transaction (several times until the recipient's card confirms receipt), while simultaneously depositing it in the deferred transaction buffer for transfer to the server when a connection appears;
5) The recipient's card accepts the transaction and confirms its receipt;
6) The recipient's card places the received transaction in the wallet marked "unconfirmed", while simultaneously depositing it in the deferred transaction buffer for transfer to the server when a connection appears (whoever connects first will transfer the transaction to the server);
7) On connection with the server, the recipient's card transfers the deferred transaction to the server and receives confirmation of receipt;
8) The recipient's card requests the status of the transaction, and, if the transaction is confirmed by six block chains, it marks it as confirmed in its wallet and can then use it to make payments.

Details of the structure of the transaction. Each transaction has a set of inputs (sources of coins) and outputs (payment recipients). The total amount of coins on all inputs and outputs must coincide. If there are more inputs than outputs, the difference is sent as a tip to the nodes that processed the transactions. If there are fewer inputs than outputs, the transaction is considered invalid and is rejected by the system. The input (source of the coins) of the transaction is the link to the output of a previously performed transaction, signed by the payment recipient. The output of the transaction is the Bitcoin address (which is also the public key) of the recipient under the transaction. To ensure that the recipient can use the coins transferred to him, he must form a transaction with the input being a link to the output of this transaction, signed by the recipient (knowledge of the private key is necessary to do so).