pull down to refresh

Recoverbull: the new approach to hot wallet backuprecoverbull.com
419 sats \ 1 comment \ @0xbitcoiner 1h bitcoin
The open-source protocol that separates cloud storage and private keys for simple and secure hot wallet backup.
Self-custody represents one of the foundations of financial sovereignty made possible by Bitcoin. This concept is based on the well-known principle “not your keys, not your coins”. This maxim, however, entails an enormous responsibility: the protection of private keys that control the funds. Backup management is the most critical element.
The current standard method, the 12 or 24-word seed phrase defined by the BIP39 standard, is an ingenious solution. However, for the average user, it introduces a series of risks and complexities that can completely nullify the benefits of self-custody.

A new paradigm for hot wallet backups

Recoverbull was born as a response to the pitfalls of traditional software wallet backup. It is an open-source protocol developed by Bull Bitcoin, designed to make backups secure and accessible to everyone, regardless of technical skills. Its philosophy is based on a series of principles:
  • accessibility for all: the protocol is built on the assumption that users can be “uneducated, imprudent, unmotivated, inexperienced or incompetent”, without this compromising the security of their funds;
  • anonymity: the protocol avoids collecting any personal data, since any information, including the simple fact of owning bitcoin, can be used by an attacker;
  • simplicity and speed: the backup creation process is designed to be completed in less than two minutes, eliminating the complexity and friction that lead many users to postpone this operation;
  • no possession of keys: the service that facilitates the backup never takes possession of the user’s private keys, neither in plain text nor encrypted, to avoid being classified as a regulated financial service provider;
  • open standards and portability: the protocol leverages known technologies and open standards, ensuring that users are not tied to a single provider and that their backups remain portable.
...read more at atlas21.com
write
preview
related posts
105 sats \ 0 replies \ @Scoresby 1h
The Key Server correctly enforcing rate-limit of fetch requests is the most critical component of the Recoverbull protocol. A Recoverbull server could decide whatever rate-limiting parameters it wants. Our recommendation is a limit of 3 attempts per day per identifier. While other methods of rate-limiting may be useful (for example to prevent ddos attacks) they are not strictly required. The reason the rate-limit is so critical is that we expect the password chosen by the user to be very weak.
So, the key-server could probably brute force all the keys it's holding. But this is kinda okay because
User anonymity is also a critical component of the security model. The key server should neither collect nor store any information that may be able to identify the user. In case the key server database is compromised, or in case the key server is malicious, any personal information could lead to targeted attacks against the user. Emails and phone numbers can be traced to the legal identity of an end-user, revealing that the end-user is a Bitcoin holder.
But even if the key server collects and stores personal information about its users,
The key server does not have any method of identifying where the encrypted backup may be stored. This is why the protocol specifies that the key server should wipe the identifier from memory on a daily basis. The identifier is used to enforce rate-limiting, but since rate-limiting is enforced on a daily basis, the key server does not need to have the identifier for longer than 1 day. The identifier is the only link between an encrypted backup key and a backup file. Without the identifier, even in the case of a legally binding request for information to obtain a backup key for a given backup file, the key server could not comply with that request, unless the user has performed a fetch request with the correct authentication key that same day.
This is an interesting approach, but I'm not sure it's that much better. If the key server vanishes, users are in a heap of trouble unless they have a separate backup for their keys. So maybe it's nice to have a way to store your keys in the cloud without worrying (too much) that they get compromised, but you'd still want to have normal backups.
reply