Add Bither to wallets

[bithernet]

This PR adds Bither to the wallet list.

On May 7th, 2014, we published the first fully functioning version of Bither wallet for Android v0.0.4. Since then, we had provided more solutions:

1. Two open source libraries:
   • Bitheri : an Objective-C implementation of Bitcoin protocol.
   • Bitherj : a pure Java implementation of Bitcoin protocol.
2. Two mobile versions:
   • Bither for iOS
   • Bither for Android
3. Desktop versions:
   • Bither for Windows
   • Bither for Mac OSX
   • Bither for Linux

All the source codes of Bither can be found here

Bither has these special features:

1. Cold/Hot modes: you can save small amount of bitcoins on your daily (Hot) phone for simple usage, and also you can save large amount of bitcoins on your backup (Cold) phone for secure storage. Communicating between Bither Hot and Bither Cold is simple, the only thing you need to do is scanning the QR-Code.
2. XRandom: Bither will collect ambiance entropy from many different sources (Camera, Microphone, Magnetometer, Accelerometer, Light Sensor, Gravity Sensor, and so on), combined with /dev/urandom to generate true random numbers for user.
3. HDM: Hybrid model of HD and Multisig:
   • 2/3 Multisig
   • 3 keys (Cold, Hot, Server) are all based on HD
   • HD's convenience + Multisig's safety
   • BIP16, BIP32, BIP39, BIP44, RFC6979

Related discussions on bitcointalk:

• Alternative clients
• Project Developments
• Chinese

[schildbach]

With all due respect, the XRANDOM "feature" sounds like a recipe for disaster. Please have a look at https://medium.com/@octskyward/type-safety-and-rngs-40e3ec71ab3a (last paragraph).

[songchenwen]

@schildbach Thanks. I have read the article. However XRANOM mixes extra entropy with the data taken from /dev/urandom. You can check out our source code for details.

Adding entropy is not "disaster". Downgrading entropy is.

Some random number issues like last blockchain.info's problem, are because of the downgrading of entropy (using 8 bits entropy to generate random numbers).

If adding entropy from user's environment is a "disaster", does that mean rolling a dice to generate a private key is also a "disaster"?

Thanks for your article :)

[gurnec]

Not too put too fine a point on it, but I just opened an issue for what I think is a minor XRandom bug in the bither-android repo... bither/bither-android#14

I think the same issue exists in the desktop client too. (I didn't check the ios client.)

I have no idea if the bug is actually exploitable (if I had to guess, I'd guess not, but I'm no cryptographer....)

[songchenwen]

Special thanks to @gurnec for reviewing our codes.

We have carefully checked our code and made sure that this issue won't cause any trouble, although @gurnec really opened a reasonable issue and we're going to take his advices.

Everyone can check the detail about the issue here.

[bitwolaiye]

We just uploaded a demo video to youtube.com about "How to use Bither's HDM".

Also I want to remind that:

1. Bither has been working for more than eight months since the first version, with not even one reported money loss for Bither's users.
2. Bither is a much more environmentally friendly solution. Many people change their mobile phones every 1/2 years. Instead of throwing the old phones away, they can use them to run Bither Cold for secured saving their bitcoin assets.

[harding]

@bitwolaiye thanks for the demo video! Wallet reviews are time consuming, and we currently have a backlog, but Bither will be reviewed just as soon as we have time. Thanks for being patient!

[crwatkins]

I have reviewed the Bither wallet based on the current wallet requirements criteria and my evaluation is below. The summary is that I can recommend this wallet for listing.

I concur with the scoring in the pull request.

Bither

Version 1.3.1 & 1.3.4

Review version 2015050102

NOTE Most of this review was performed on version 1.3.1. 1.3.4 passes additional criteria as tagged with (v1.3.4).

Wallets

The wallet list is based on the personal evaluation of the maintainer(s) and regular contributors of this site, according to the criterias detailed below.

These requirements are meant to be updated and strengthened over time. Innovative wallets are exciting and encouraged, so if your wallet has a good reason for not following some of the rules below, please submit it anyway and we'll consider updating the rules.

NOTE Bither can (concurrently) work in four modes

1. Standard non-HD, non-multisig hot wallet where user can create individual address/key pairs (called “Private”)
2. Hot/cold wallet pair where hot wallet can monitor cold wallet address and the cold wallet holds the key and signs
   transactions created by the hot wallet
3. Multisig HD wallet (2 of 3) involving the hot wallet, the cold wallet, and the Bither server wallet (called “HDM”)
4. (v1.3.4) Standard single signature HD wallet

NOTE This means that all of the requirements (except for hardware wallets and purely hosted wallets) apply to Bither.

NOTE None of these modes are explained well. Even very experienced Bitcoin users may not be able to figure out how the different modes work without significant time and effort. Perhaps the Private mode is only still there for backward compatibility with existing wallets.

NOTE Mobile UI is a bit confusing at times; a long press is sometimes required on an icon right next an icon that does not require long press. Some functions may not be discoverable.

NOTE It is not clear what security the multisig server adds since the hot wallet automatically authenticates to the server with credentials established when the wallet is created and and the cold wallet authenticates using BitID with cold HD key 0. The multisig server does not seem to gate any operations. It’s not clear what purpose it serves.

NOTE In HDM mode, it might be slightly misleading to have a device called a cold wallet because that may imply to some that stored funds are some how safer being associated with a cold wallet in some way. However, in HDM mode, the cold wallet makes funds available in case of a server failure, but does not make the funds any safer or more secure (when the server is available).

NOTE Bither wallets have a “Check Private Keys” function which seems unnecessary. If there is a concern about corruption, the wallet should check automatically and not put the burden on the user. It is unlikely that most users will understand what this is for.

Basic requirements:

• Sufficient users and/or developers feedback can be found without concerning issues, or independent security audit(s) is available

PASS Developers are responsive in forums; no issues for concern found; no independent audit is available

1. http://www.reddit.com/r/Bitcoin/comments/2swzoi/bither_v131_with_hdm_will_be_released_in_the_next/
2. https://bitcointalk.org/index.php?topic=779682.0
3. https://twitter.com/bithernet
4. iOS app store reviews https://itunes.apple.com/us/app/bither/id899478936?mt=8
5. Google Play Store (500-1000 installs) Reviews https://play.google.com/store/apps/details?id=net.bither
6. Issues on github repositories https://github.com/bither/ are quickly addressed
7. https://bitcointalk.org/index.php?topic=696626.0

• No indication that users have been harmed considerably by any issue in relation to the wallet

PASS None noted in above sources

• No indication that security issues have been concealed, ignored, or not addressed correctly in order to prevent new or similar issues from happening in the future

PASS None noted in above sources. One example was quickly addressed bither/bither-android#14

• No indication that the wallet uses unstable or unsecure libraries

PASS No indications of any issues. Uses spongycastle v1.51.0.0, OpenSSL v1.0.110.

NOTE There is slight controversy on the usage of Bither’s XRandom feature bitcoin#724
and minor changes have been made in response to criticisms: bither/bither-android#14 Bither allows the XRandom feature to be disabled on a case-by-base basis. While it is acknowledged that only the most expert users would understand the ramifications, since it can be disabled, that allows a PASS on this issue.

NOTE The Android app requires access to many unusual capabilities of the device, most likely for XRandom to work. Users should be hesitant to give a Bitcoin wallet access to all these capabilities.

• No indication that changes to the code are not properly tested

PASS No indications not tested. Modules on github have reasonable test routines. Exact testing methodology unknown.

• Wallet was publicly announced and released since at least 3 months

PASS

Jul 2014 Original Android and iOS wallets

Jan 2015 Desktop

Feb 2015 HD/multisig support (HDM)

Apr 2015 HD support (HD single signature)

• No concerning bug is found when testing the wallet

PASS No concerning bugs found.

• Website supports HTTPS and 301 redirects HTTP requests

PASS HTTP redirects to HTTPS with a 301

• SSL certificate passes Qualys SSL Labs SSL test

PASS Overall rating: A+

• Website serving executable code or requiring authentication uses HSTS with a max-age of at least 180 days

PASS HSTS enabled with a max-age of 365 days

• The identity of CEOs and/or developers is public

PASS https://bither.net/about/index.html

• If private keys or encryption keys are stored online:

NOTE Private keys are stored online in Private mode

NOTE HD seeds are stored online in HDM mode and (v1.3.4) HD mode

• Refuses weak passwords (short passwords and/or common passwords) used to secure access to any funds, or provides an aggressive account lock-out feature in response to failed login attempts along with a strict account recovery process.

PASS (v1.3.4) Password are subject to a reasonable password strength meter and weak passwords are not accepted.

NOTE (v1.3.4) It is possible to disable the password strength check in settings.

NOTE Private keys are encrypted with AES from keys generated from passwords using Scrypt.

• If user has no access over its private keys:

N/A

• Provides 2FA authentication feature
• Reminds the user to enable 2FA by email or in the main UI of the wallet
• User session is not persistent, or requires authentication for spending
• Provides account recovery feature
  • If user has exclusive access over its private keys:
• Allows backup of the wallet

PASS Individual private keys can be backed up via QR code (tedious) from hot and cold wallets.

PASS HDM hot wallets are backed up using a HDM cold wallets. Cold wallets can be cloned for backup.

NOTE HDM HD seed can be backed up via QR code or BIP39 phrase from hot and cold wallets, but there is no way to restore Bither HDM wallets with the HD seed. See below for the method for restoring HDM wallets.

PASS (v1.3.4) HD mode seed can be backed up via QR code or BIP39 phrase.

• Restoring wallet from backup is working

PASS Individual private keys can be restored to another hot wallet using encrypted QR code option

NOTE There were many private key export options, but only the encrypted QR code option worked for recovery. The instructions should be more specific.

PASS Used the Advanced “HDM Recovery” option on new hot wallet to create an “HDM Recovery” wallet by using the cold wallet (fairly complex). Instead of an “HDM Hot” wallet as on the new original device, this created an “HDM Recovery” wallet on the new device.
This new device did not have the hot seed. The new device created transactions which were signed by both the cold wallet and the server wallet. This recovery wallet is not meant for daily operation but rather to recover funds. Funds were successfully recovered.
After HDM recovery the original device could no longer authenticate to the server to co-sign, but could continue to use the cold wallet to co-sign.

PASS Used the Clone Cold Wallet option to create a new cold wallet. Either the new or the old cold wallet could co-sign multisig transactions.

PASS (v1.3.4) HD mode wallet could be restored to desktop wallet using “Import” option.

NOTE (v1.3.4) I could not find an option on mobile (iOS or Android) to restore an HD mode wallet (only desktop)

• Source code is public and kept up to date under version control system

PASS Available on github https://github.com/bither/

• If user has no access to some of the private keys in a multi-signature wallet:

NOTE This is HDM mode

• Provides 2FA authentication feature
• Reminds the user to enable 2FA by email or in the main UI of the wallet

NOTE Server does not provide 2FA. In HDM mode the server seems to be intended more for availability
backup rather than added (second factor) security. The authentication to the server is done with a strong token. If added factor security is not expected, then this could PASS.

• User session is not persistent, or requires authentication for spending

PASS User requires password to unlock server API authentication token

• Gives control to the user over moving their funds out of the multi-signature wallet

PASS User can move funds out of multi-signature wallet without server access

• For hardware wallets:

N/A

• Uses the push model (computer malware cannot sign a transaction without user input)
• Protects the seed against unsigned firmware upgrades
• Supports importing custom seeds
• Provides source code and/or detailed specification for blackbox testing if using a closed-source Secure Element

Optional criterias (some could become requirements):

• Received independent security audit(s)

FAIL No, but have had some informal external code reviews.

• Avoid address reuse by using a new change address for each transaction

FAIL (v1.3.4) In HDM mode, change is returned to sending multisig address

PASS (v1.3.4) In HD mode, change is returned to a new change address for each transaction (m/44’/0’/0’/1/i)

FAIL In private address mode, change is returned to the sending address.

• Avoid address reuse by displaying a new receiving address for each transaction in the wallet UI

PASS (v1.3.4) In HD mode a new receiving address is displayed for each transaction

NOTE (v1.3.4) Note that in HD mode, a user should be able to manually request a new address so that an address that is not yet paid is not reused, or a new address should be displayed each time viewed (but the existing UI does not lend itself to that)

FAIL In HDM mode and Private address mode new addresses must be manually requested by the user and manually selected for receiving

• Does not show "received from" Bitcoin addresses in the UI

FAIL Received from addresses are shown in UI

NOTE Receiving address should be shown

• Uses deterministic ECDSA nonces (RFC 6979)

PASS Uses deterministic ECDSA k values. Verified by hand-generating a signature of a Bither transaction with pybitcointools (which implements RFC 6979) and verifying that the Bither signature matched.

• Provides a bug reporting policy on the website

PASS Provides support email: support@bither.net

• If user has no access over its private keys:

N/A

• Full reserve audit(s)
• Insurrance(s) against failures on their side
• Reminds the user to enable 2FA in the main UI of the wallet
• If user has exclusive access over its private keys:
  • Supports HD wallets (BIP32)

PASS HDM mode supports BIP32 with BIP44 standard path m/44’/0’/0’/0/i. BIP39 phrase had dashes between words. When dashes were replaced with spaces, independent generation of a BIP32 tree and verification of the generated multisig addresses was possible.

PASS (v1.3.4) HD mode supports BIP32 with BIP44 path m/44’/0’/0’/c/i. BIP39 phrase had dashes between words. When dashes were replaced with spaces, independent generation of the BIP32 tree and verification of the generated receive and change addresses was possible.

• Provides users with step to print or write their wallet seed on setup

PASS in HDM mode: A cold HDM wallet is set up which can recover funds with the Bither server without the hot wallet

PASS (v1.3.4) in HD mode: BIP39 phrase and QR code is available during setup

NOTE in Private mode: No explicit step during new address generation for backup of keys. Note this is not a seed, but rather individual keys (i.e. not a one time operation)

• Uses a strong KDF and key stretching for wallet storage and backups

PASS Uses Scrypt for password KDF

• On desktop platform:
  • Encrypt the wallet by default

PASS

• For hardware wallets:

N/A

• Prevents downgrading the firmware

[harding]

In the absence of critical feedback, this will be merged based on @crwatkins's reccomenation around 12:00 UTC Tuesday.

Todo for the merger:

• Rebase to fix merge conflict (current branch head is d0d717a)
• Squash down to one commit

[songchenwen]

Thank you for all your work.

I will rebase and squash soon.

[songchenwen]

The PR is rebased on the current master. And the commits are all squashed together.

Thank you again, @harding and @crwatkins .

[harding]

@songchenwen thank you for rebasing, and thank you especially for your patience and responsiveness!

I've verified that 99b7c1d produces an identical merge to the reviewed commit d0d717a.