Coinomi wallet coin support

gistfile1.md

Overview - Adding support for a new currency in Coinomi

The Coinomi wallet can support any kind of cryptographic currency because it adopts the model of a thin wallet.

A thin wallet will delegate most of the complexity to a trusted server, while still maintaining control of the private keys by using a deterministic key chain BIP44. It is different than SPV in that it doesn't need to perform any header or transaction merkle root validations (although it is optionally possible).

The advantage of a thin wallet is that it is light weight and can easily work with low-specs devices and consumes small amounts of network bandwidth. Some assets like Peercoin, CounterParty or Mastercoin can only work with this model because as SPV is not enough to validate transactions. The disadvantage is that it needs a trusted service to get the state of the network. A known attack for an SPV wallet is to hide transactions, in a thin wallet it is possible to also simulate payments (but not steal coins from the wallet). Those threats are mitigated by using trusted servers and third party block chain explorers.

Bitcoin-like currencies

Bitcoin forks, like Litecoin, Dogecoin, Peercoin are easy to implement as they share most of the transaction and header formats and signing algorithms.

Those are the components to make this happen:

• An electrum indexing server that connects via JSON RPC to a full node of the specific coin. The adaptations that need to be done to the electrum server depend on some factors:

  • Does the getblockhash return the header hash as double SHA256 (like LTC,DOGE,PPC) or it hashes the header with a different algorithm? Darkcoin uses X11, while Blackcoin uses Scrypt.
  • Are the fields of getblock standard? For example Peercoin encodes the block timestamp in a human readable format, while the standard Bitcoin RPC uses a Unix epoch
  • Is the transaction binary structure the same as in Bitcoin? For example a Peercoin adds a timestamp after the version field, NuBits adds a asset type field after locktime.
  • Not standard or non financial outputs, like in Namecoin

  For each coin a separate electrum configutation file is needed with the most important part:

    # Litecoin specific network parameters
    [network]
    pubkey_address = 48
    script_address = 5
    genesis_hash = 12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2
  

  The pubkey_address is the pay to public key address version and the script_address the pay to script hash. The genesis_hash the is hash of block 0 of that coin and can get it with getblockhash 0 RPC call to our full node daemon.

  Currently each coin customization is in a different branch but longterm will merge them in one package. The repository of the customized electrum server https://github.com/erasmospunk/electrum-server

• Bitcoinj support if the transaction structure is different. The most recent stable branch is coinomi-0.12

• Coinomi core library support:

  • An new subclass of CoinType in the com.coinomi.core.coins package. Existing coin types are a good template to base on.
  • An entry to the com.coinomi.core.coins.CoinID enum
  • If a custom integration is needed because of a different transaction structure or a different fee calculations the following places are good candidates: com.coinomi.core.wallet.WalletPocket and com.coinomi.core.wallet.WalletPocketProtobufSerializer

• For the Android wallet integration it only needs some entries to the com.coinomi.wallet.Constants:

  • DEFAULT_COINS_SERVERS, the addresses of the electrum servers (minimum 2 servers)
  • COINS_ICONS, an icon resource for the coin
  • Optionaly a third party block explorer in COINS_BLOCK_EXPLORERS
  • An entry to SUPPORTED_COINS to enable the coin

Bitcoin meta currencies

There are several currencies that use existing blockchains as a transfer layer but maintain their own separate state. Security-wise, those coins cannot use SPV as it is not enough to just verify if a transaction was included in a block, so a thin wallet is the only way to go. The effort to add support for those coins is more than Bitcoin forks but some infrastructure can be reused (transaction signing clientside, bitcoind RPC serverside).

Here are some coins that fall in this category:

• CounterParty, Bitcoin blockchain
• MasterCoin, Bitcoin blockchain
• Colored coins, Bitcoin blockchain
• DogeParty, Dogecoin blockchain

Those currencies allow the creation of assets, most notable are: MaidSafeCoin and StorjCoin

I have researched CounterParty support, the strategy is similar to the CounterWallet (web based):

• The server runs counterpartyd (instead of an electrum server) that connects to the bitcoind
• The client connects to the server via web sockets to get the balance, past transactions, etc
• To sent coins the client asks the server for a transaction template. It inspects the transaction for a sanity check (is the sending address the correct one?) and signs it as a usual Bitcoin transaction.

Non-Bitcoin currencies

Those currencies don't share any code with Bitcoin and thus need a completely new infrastructure.

Here are some coins/networks that fall in this category:

• Ripple
• NXT
• BitShares
• Ethereum
• Stelar (Ripple fork)
• Monero and Bytecoin (Cryptonote based)
• Hyperledger

Most of those currencies allow the creation of assets.

Not a lot of research has been done about those coins.

Third party services

While they are not currencies by themselves, third party services allow the sending and receiving of value.

Some third parties that could be integrated:

• Banks, those include services like PostPay in Italy.
• Payment networks like PayPal and prepaid credit cards.
• Established Bitcoin wallet like Coinbase.
• Cryptocurrency exchanges.

Not all of those services allow easy integration or can be used as a send-only mechanism.