-
Notifications
You must be signed in to change notification settings - Fork 62
Design Considerations (FAQs)
This wiki contains a list of design tradeoffs and decisions that we made at BitHyve to ensure that people get the best user experience possible for their bitcoin wallets. None of these decisions are final and they are constantly evolving, but we think it is wise to let our users know why the app they use does some stuff the way it does right now.
2FA is becoming increasingly more popular as a way to authenticate services but the BitHyve normal account only uses a pin. This is because we aim to reach out to people who might not know how to use authenticator app and would still like to tip their toes into the cryptocurrency world. It is essential to have easy and frictionless feature for an audience that is not good at handling technology. More experienced users can always choose to go for the secure account but users with little experience using cryptocurrency products are better off with simple pin based authentication. Further the secure account is used to add extra security so that larger funds can be sweeped into these accounts and be save from accidental transfers and or security risks. The savings account is geared towards smaller balances and for daily usage. For example I may not want to have a 2FA based on google authentication for buying a coffee or for making a small transfer.
Having a single device which controls funds greatly reduces the resiliency to loss or theft. This is primarily why Hexa offers a multisig (ie secure) account, which does not rely on a single device and uses 2 Factor authentication in order to be able to spend funds.
A multisig or secure account is where you need more than one device's confirmation in order to be able to spend your bitcoins. Secure accounts require the signature of two of the following three parties:
- The encrypted private key stored on your phone's memory. This is in your control.
- The backup phrase for the additional signatory. This is in your control.
- The BitHyve Oracle. This is used for two factor authentication.
The encrypted private key is stored on your device and will sign your transactions by default. The backup phrase will not sign automatically since this would again bring back the issue of relying on a single device. The BitHyve Oracle will authenticate against the two factor authentication code that you provide and will sign the transaction if this is valid. It is recommended that this 2FA code generating device be on a separate device in order to realize the benefit of a multisig account.
In order to generate a new transaction with the secure account, the user woud select the amount, sign the transaction using his private key and pass the transaction hex, the 2FA code and the walletID to the Oracle. The Oracle after authenticating the user signs the transaction and broadcasts it to the blockchain.
The Bithyve Oracle stores the SHA512 hash of the user's seed in order to identify who is making requests to the server. The same is used for Hexa's health check scheme. The service provider we use can identify your ip but the Oracle itself does not log any information about ips. We do plan to add native tor support to hexa in future releases to anonymise ip requests made to the Oracle.
We run our own full nodes and electrs instance. We do not log any requests to either of the instances. We use blockcypher as a fall back balance service in the event Bithyve's node services are down.
We will be looking to target in future releases. Our research repo contains some of the stuff that we've been exploring that would make this easier. Having custom vault accounts presents many different use cases and the challenge is in identifying those that are most relevant to our users and those that can create a seamless user experience backed by a good technical solution.
There is no distinction between a single device and a multi device authentication scheme if both the parts required for authentication are on the same device. This other key would be available to users in case they want to recover funds / sweep funds to another address.
The Bithyve Oracle cannot spend funds without your consent in any way and neither does Hexa make its users dependent on it for spending or withdrawing their money. Users of Hexa can freely move their funds around, as should be the case with a non custodial wallet.
We plan to use proven Key Management services and Hardware Security Modules to handle the private keys of the oracle. In the future, we would be exploring to see if 2FA can also be done on the same KMS/HSM server.
Hacking the Bithyve Oracle would give you control over one of the spending keys but
- this event would be detectable
- you can sweep your funds into another address without the Bithyve Oracle
Hence, even in the worst scenario, this does not lead to loss / theft of funds.
Running your own BitHyve server instance is on the cards and will be designed in a way similar to Samourai's Dojo. You need not depend on Bithyve for spending your funds since you possess 2/3 keys required to spend your funds. Bithyve's signature comes in only when you lose access to your wallet and would like to restore your secure account. Bithyve on its own cannot spend any of your funds since it possesses only 1/3 keys required to spend from the multisig account.
There is no data to sell to people. If selling people random hashes were profitable, miners would be richer :)
You can sweep your funds onto another account using ga-recovery
This is something that we're looking into and will be present in future releases. Our preliminary implementation focuses primarily on SSS and the benefits it can offer over current solutions.
Lightning is one of the most exciting innovations recently and we are actively researching into it and looking at adding support to lightning. With lightning come various possibilities such as offline payments and DLCs, which is also something that we're looking to target in future releases. This presents many user scenarios and the challenge is in identifying the user scenarios most relevant to our users and also the scenarios most challenging in the real world and create a seamless user experience backed by a secure technical solution.
We're a small team of highly enthusiastic people and we are sad that we don't have the time to implement everything that we want to. But with the bitcoin community's support and feedback, we can continue doing what we like to do and implement many more cool features.
Do you have a cool feature / idea that you would like to propose? Get in touch with one of our team members or open an issue and we'll add it to our roadmap!