The Airbitz mobile digital wallet implements a decentralized, secure, peer-to-peer synchronized, and backed up bitcoin wallet with a clean, easy to use interface. Integrated with the wallet is a proximity enabled and searchable business directory to help consumers find merchants that accept bitcoin as payment.
The Airbitz wallet is a fully client-side wallet that creates, manages, and encrypts private keys, public keys, and transactions on the client device and uses server side assistance for backup and synchronization of encrypted data and for authenticating users. Airbitz users retain full control of their private keys at all times with neither Airbitz nor third parties having access to private keys or transaction data. Sending and detecting of received funds is done through publicly accessible Libbitcoin Obelisk nodes.
The Airbitz mobile wallet is implemented using a GUI written in the native language and platform of the device. iOS implementations are written in Objective-C in Apple’s NS framework and Android devices are written in Java. Common wallet functionality is implemented in a cross platform C/C++ library which is compiled into the platform and operating system of each device. This is referred to as the Airbitz Core or ABC. ABC implements all account and wallet creation, user authentication, management of transaction data, encryption, and synchronization across devices. Compiled into the ABC library is the Libbitcoin library which is used for core bitcoin protocol operations such as private/public key creation and transaction signing. ABC utilizes the libbitcoin-client library to talk directly to open source Obelisk bitcoin full nodes which also run Libbitcoin.
The ABC architecture is inherently “client-strong” meaning nearly all wallet logic exists and operates on the client device. Servers exists only to assist in authentication, for encrypted backups, and as nodes on the bitcoin network. ABC leaves control of the private keys entirely in the hands of the user or application which controls the login and password of the account. Airbitz servers have no capability of spending funds on users’ behalf.
ABC utilizes a “95% decentralized” client-server architecture which utilizes 3 separate types of servers.
New account creation is initiated on the client device by taking the user selected login & password and hashing it with a pre-defined, public salt (S1) into L1 & LP1. The client then creates a random value, RepoAcctKey, which is the name of the Git repo it will use to sync the account directory on the client. The RepoAcctKey is encrypted with a random 256 bit key (MK) and referred to as ERepoAcctKey.
The user’s login + password are then hashed again using another pre-defined, public salt (S2) and hashed into LP2. The MK is encrypted using LP2 as the key.
The client then sends L1, LP1, ERepoAcctKey, and RepoAcctKey to the auth server for account creation. The auth server verifies that L1 doesn’t already exist as an account, and if so, hashes LP1 again to create LP1’ and saves L1, LP1’, and ERepoAcctKey as an entry in the SQL database. The auth-server then creates a repo on each sync-server with the name equal to RepoAcctKey. RepoAcctKey is NOT saved after repo creation.
After repo creation, the client can now sync account directory data to the sync-servers using RepoAccountKey as the Git repo name.
To create a wallet in the account, the client generates another unique wallet uuid then generates a unique Git repo name (RepoWalletKey_
The clients sends L1, LP1, RepoWalletKey_
The client can now create a local directory on the device corresponding with the wallet_uuid and sync its contents using the RepoWalletKey_
The private BIP32 seed for wallet_uuid is created, encrypted with MK, and stored in the account directory.
This system disassociates the actual contents of an account and corresponding wallets from the database SQL row associated with the account login & password.
In this manner, any information in the account or wallet repos cannot be associated back to a login in the auth-server.
All encryption utilizing AES256 encryption with proper randomized IV values. Hashing is implemented using Scrypt with N,r,p paraments of (16384,1,1) for LP1 & L1, (32768,8,1) for LP1’, and variable parameters for LP2 ranging from (16384,1,1) to (163840,8,1) depending on the speed of the client device.
Airbitz stores account specific information in the Account directory which is Git sync’ed to the RepoAcctKey repo. The Account directory contains encrypted private seeds for each wallet in the account, general account settings, encrypted wallet repo keys (ERepoWalletKey
The wallet directories are named after the random uuid values of each wallet. Each wallet directory contains the public addresses and transaction IDs of each wallet hashed for privacy. In addition, the metadata of each transaction is also encrypted and saved in the wallet directories and backed up to sync-servers.
Before any wallet is used, the BIP32 HD private seed is encrypted and backed up to sync-servers. ABC ensures that the private key is successfully synced before allowing any operations on the wallet. This ensures that any damage to the device will still allow keys to be recovered.
Every transaction in ABC will either create a new receive public address or a new change address for sent funds. New addresses are created from the HD private seed, and transaction addresses and data are lazily backed up to sync-servers within a specified time interval. Lost transaction data and new public addresses is non-critical as they can always be regenerated by the private seed which is always backed-up.
To help minimize corrupted private or public keys due to random memory corruption, ABC will pre-generate 10 addresses ‘ahead’ of the currently needed public address and store them in the encrypted wallet repo. When a new address is needed, it is again generated by the public seed and compared to the previously generated addresses. If they differ, ABC assumes a corrupted address and skips the address, moving to the next in the BIP32 chain. Upon successfully selecting a public address, ABC verifies the remaining pre-generated addresses, and generates yet another address for future use.
ABC is compiled with the Libbitcoin library originally developed for Dark Wallet. Queries of the blockchain access the network utilizing the Libbitcoin client library and connecting to Obelisk servers which are the server component of Libbitcoin. ABC retrieves a list of Obelisk servers from the auth-server and randomly chooses which server to connect to. Should one of the servers be unavailable, it will connect to the next server in its list. ABC apps can also force a rotation to a different Obelisk server.