@Read.Cash
edited
Recoverable Bitcoin Cash wallets **Please note, this is an unproven idea and a request for comments.** Please avoid premature claims until at least a few experts confirm that this is indeed possible and secure. There is only one way to make something secure - to spread the algorithm as wide as possible and have experts poke the holes in it. Discussion is here or in the comments below. **Feedback overview will be updated here as it happens, positive or negative.** https://old.reddit.com/r/btc/comments/e309ir/recoverable_bitcoin_cash_wallets/ (!) Negative feedback from BigBlocksIfTrue, presenting an interesting vector of attack. Positive feedback from **Karol Trzeszczkowski** (who is definitely an expert in my opinion): "This is absolutely going to work, don't worry about that" https://read.cash/@Read.Cash/recoverable-bitcoin-cash-wallets-8dc2ed40#comment-f6492971 https://old.reddit.com/r/btc/comments/e309ir/recoverable_bitcoin_cash_wallets/f8zicdh/ Positive feedback from **btcfork**: "Don't see a reason this couldn't work, and am quite excited by the idea." https://old.reddit.com/r/btc/comments/e2x6zn/thank_you_bitcoin_sv_supporter_for_helping/f8zrqq9/ Positive feedback from **bit-architect**: "Beautiful! Very well done" (with caveats) https://old.reddit.com/r/btc/comments/e309ir/recoverable_bitcoin_cash_wallets/f923izd/ Steve Shadders from Bitcoin SV points out that it would be possible to create a scheme with similar characteristics on Bitcoin SV next February (but you'd need to safekeep something like a paper wallet) . https://old.reddit.com/r/btc/comments/e309ir/recoverable_bitcoin_cash_wallets/f929ilh/?context=3 Interesting, how sometimes people trying to troll you suddenly make you realize something even bigger about the thing you support (namely: Bitcoin Cash). Today, I've read this on Reddit:
When at first I read this, I thought the guy was talking about Bitcoin (BTC)'s "Replace-by-Fee", but a cursory glance at his history showed he supports Bitcoin SV and dislikes BTC. Why would he be talking about "recoverability", if SV is no better in this regard than Bitcoin Cash, is beyond my understanding. https://old.reddit.com/user/Vlad2Vlad https://rcimg.net/images/8dc2ed40/GlUnQw8e8GmbIgfFafc8jUPfJPgHVOlOsNxreK8a.png Having **"recoverable" coins** is pretty important (that means that if you lose your private key, you can still recover the access to them), while at the same time you should have the ability to **spend your coins daily**. (Ok, this point doesn't ring a bell with Bitcoin BTC supporters, I understand) It seems that these both points are **possible on Bitcoin Cash today**. Actually, it can be even be used to safely recover stolen phone's wallet (from the example) if the thief haven't spent the money yet. A short intro to Bitcoin Cash contracts A "contract" in Bitcoin Cash allows you to define who can spend the coins. You basically always send the money to a "locking" mechanism and whoever can unlock it - gets to spend the money.
Your regular Bitcoin Cash address is a locking mechanism that says "whoever signs a message with the private key that matches in some complex way the number I have written here gets to spend this particular coin" (it's a bit more complex, read our other article for more details if you are interested in details about the contracts). https://read.cash/@Read.Cash/how-to-use-bitcoin-cash-with-javascript-including-bitcoin-cash-contracts-08fdc194#bitcoin-cash-contracts-p2sh
You actually have a whole programming language in Bitcoin**s** (all of them) that allows pretty complex interaction: Bitcoin Script (again, see previous article for more details). https://read.cash/@Read.Cash/how-to-use-bitcoin-cash-with-javascript-including-bitcoin-cash-contracts-08fdc194#bitcoin-cash-contracts-p2sh Multi-sig short introduction You also have something like 2-of-3 multi-signature in Bitcoin Script, which was long thought of as the solution to recoverability. Hopefully, that changes today. Multi-signature means that you can give 3 different private keys (very big numbers) to friends or institutions you trust and if you need to spend your coins - you can contact two of them and ask them to sign a transaction for you. Alas, it's not convenient and not secure. Let me explain. Not very secure and inconvenient way for the recovery of the coins You (actually, your wallet) can construct a special contract address and send your money to it, which has **two** unlocking functions "regularSpend" and "recover".
If you call the first one ("**RegularSpend**") - it is the usual spending: private key, address, change address, business as usual:
Or, alternatively, you can send the change to a new address, constructed in the same way - it's all the same, just **a bit** more secure.
Let's say you've **lost your private key** and can't sign a transaction. Typically, that means you're out of luck and lost your coins forever. The second function could be a "recovery" multi-signature unlocking mechanism, where multiple trusted parties (Mom, bank, lawyer) can recover your money and then send any amount **anywhere**. So, for 2-of-3 multi-signature that can look like this:
This is **definitely** possible on Bitcoin Cash and **probably** on BTC and BSV, so we're not any better in this regard. Now, you can spend your funds daily using the first function, all your change goes the the new contract addresses, which **also** contain the recovery function. **Downsides:** you need to have **2-3 trusted third parties**; they must manage the keys for you; they need to be very technically advanced to sign a transaction on your behalf; if they aren't reliable and lose 2 keys - you're out of luck; some of them can collude and send your money anywhere. A better solution (not yet the best) When I was writing the previous article about the contracts - the first and the easiest contract that I've explained was very simple. You can supply a "word" that would unlock your funds. So, like you say "read.cash" and you can spend the coins. Seriously, this address: ppfuzf5f52ypwm0jrnnfqtwafrtfx0zgcshtux8zk3 has **$5** in it as of this writing. These $5 are there courtesy of **btcfork**'s chaintip. Reward for the technically advanced or for fast learner! https://explorer.bitcoin.com/bch/address/bitcoincash:ppfuzf5f52ypwm0jrnnfqtwafrtfx0zgcshtux8zk3 https://read.cash/@btcfork https://old.reddit.com/message/messages/kdzwa7 **To take it** you need to just say `read.cash` in Bitcoin Script and that's it, you don't need my private key. Up for grabs! You can even see one spending transaction here (I made it for the demonstration purposes): https://rest.bitcoin.com/v2/transaction/details/4e39ffb313c816d0fffe7f6ccd5d6839020377a524fbd98a3168b73aeaf1a876
Can we modify our recovery idea using this new knowledge?
It's almost cool - now you can do your regular spending and you can use an additional way to recover your funds, kind of like a "password", to recover your money if you have lost your private key. It has a security problem, obviously. Even though nobody knows **what** unlocks this address ppfuzf5f52ypwm0jrnnfqtwafrtfx0zgcshtux8zk3, still if someone can guess that it is "read.cash" - they can send your money anywhere! And it's cheap to guess - you can probably brute-force it in a few minutes to few days. https://explorer.bitcoin.com/bch/address/bitcoincash:ppfuzf5f52ypwm0jrnnfqtwafrtfx0zgcshtux8zk3 Sidenote: If you're wondering what "ppfuz.." address does even have to do with the script - it's actually an encoded hash of the locking script. When you lock the money - you don't reveal what the "locking" script is, just its hash. Again, previous article covers it in details. The best solution Here's the kicker. **Bitcoin Cash** has a great operation `CHECKDATASIG` (here's the story), which checks if the signature of the raw data matches some public key. https://medium.com/@Mengerian/the-story-of-op-checkdatasig-c2b1b38e801a **Bitcoin (BTC)** didn't implement it and is against it. **Can't use it there.** **Bitcoin SV** split away **just** to avoid adding this operation. **Can't use it there**. For many of us it was a non-issue, which added some nice things to Bitcoin Cash. What's important, `CHECKDATASIG` enables us to do something interesting (among other things) - it enables us to limit "where" the money goes. https://read.cash/@pein/bch-covenants-with-spedn-4a980ed3#fancier-things
Can you feel it coming? The power of the recoverable wallets **exclusively on Bitcoin Cash**? We can now restrict "where" the money would go if somebody uses the secret word. That means we can do things like this:
Or this:
Obviously, even if somebody guesses that your recovery word is "mom" - they'll only be able to send the money to your Mom's wallet. They won't be able to send the money anywhere. This is not possible to do without CHECKDATASIG operation, therefore it's **possible exclusively on Bitcoin Cash**. (Unlike Bitcoin BTC and Bitcoin SV) Ok, let's talk about limitations and problems. Spending reveals the contract There is a small problem though - when you spend the money - you reveal what was in the contract. That, in turn, reveals your "recovery" words. So, your first coffee would reveal the recovery word. We can avoid it by doing what we do to store the passwords - by storing a salted hash of the password, which cannot be easily decrypted, instead of storing the plain-text password. We don't do something like this: verify password == "mom" but rather verify hash("abc#431!$" + password) == "871293fe891a298....3e289" # where, "871293fe891a298....3e289" is the result of hash("abc#431!$mom") # and "abc#431!$" is a random string called "salt" Even though it doesn't even make sense to spend the time guessing your recovery word, since all it can do is send the money to your another trusted account (a minor inconvenience at best). The salt can be probably stored in an `OP_RETURN` output, since it's needed for the recovery, at least for the **first spending**. If the contract was already spent once - the salt can be recovered from the previous spending transaction, **probably** enabling the application of this to **SLP tokens**, which require at least 1 OP_RETURN. (I defer to experts on whether this is really possible) https://read.cash/@Read.Cash/how-do-slp-tokens-on-bitcoin-cash-work-74805db3 The wallet of the future **If this idea really works** that would mean that now when you create a wallet you can, for example add someones address as a "recovery" address with an associated "recovery" word, or you can buy another cheap phone, install a mobile wallet, use its address as a "recovery" address and just forget about the phone until recovery is needed. You can probably even have some institution's address, like a bank, in the worst case. Lost private key? Just type in your recovery word `phone` and your last address (more on "how to recover the last address" in the next section) and your wallet will send your money to your phone, from where you can move them to your "recoverable" wallet again.
Be aware though that contract spending is a bit more expensive, than regular spending, so instead of typical $0.001 transaction fee, you'd pay something like $0.002 or maybe $0.003 each time you spend the money, because of the transaction size. And you can use your wallet for your **daily spending** just as your regular Bitcoin Cash wallet - it will just send your change back to the contract or to a new contract using a nonce. **I defer to experts** on whether any "replay" attacks are possible here with reusing the old contract. If they are possible - then the new contract should be used each time with a random nonce, not a problem. Recovering the last address Ok, there's one more problem to solve. Even if you can recover the funds - you still need to remember **where** the funds are, like this address: `ppfuzf5f52ypwm0jrnnfqtwafrtfx0zgcshtux8zk3` and if the address changes after each spending - that means there will be a new address each time. The good part: the address itself is **not a secret**. The wallet can publish it as widely as possible or store in on third-party servers in the open or use brute-force approach from any last-known address or transaction. One way to do it is to use one last known "root" address - from there we can find all the UTXOs that stem from that transaction and try to brute-force them using the provided recovery word.
**In the worst case** the owner can even attempt to brute-force spending **all UTXOs** (unspent transaction outputs) **in existence** using the recovery password, which is slow, but feasible. There aren't that many. We can also **filter some UTXOs out** that doesn't match some user-provided information about when their last spending was done. Like if the user last used the wallet 2-3 days ago - try only UTXOs around that time.
The constantly happening brute-force means though, that the "recovery" word should still be at least a bit harder than "mom" to avoid accidental recoveries (which again is more of a nuisance, rather than a security problem). Possible solutions for accidental recoveries Maybe the wallet **can add something like the birthdate** and wallet provider name (anything easily recallable by user later) to the recovery word of the user to avoid "accidental" recoveries. We're only trying to prevent accidents, there is no point for hackers to try to actively be stealing your funds, since in the end, they can only send it to trusted wallet. We can use Satoshi-style `hash(hash(...))` comparison to avoid disclosing personal information: verify hash("abc#431!$" + "3298470923874") == "871293fe891a298....3e289" # where "3298470923874" is hash(birthday + provider + password) # and, "871293fe891a298....3e289" is the result # of hash(salt + hash(birthday + provider + password)) Conclusion Again, I ask for everybody to wait for experts to weigh in on whether this is something great or it's a spectacular failure, but even if it is - hopefully at least that was an enjoyable read. It's also possible that I've invented something that was already widely known. Anyway... Let's keep the innovation on Bitcoin Cash going! https://read.cash/@Read.Cash/whats-so-great-about-bitcoin-cash-26bdb6f0
https://twitter.com/readcash1/status/1200092171975700480 By the way, **read.cash uses Bitcoin Cash exclusively** to upvote the authors (though you can deposit and withdraw other cryptocurrencies to your non-custodial browser-only wallet). You don't even need an account to upvote the articles. Join us if you are an author (you don't even need to understand Bitcoin Cash to earn it!) and especially if you are a software developer that might benefit from having your own sponsorship program promoted by our affiliates. More about us. https://read.cash/register https://read.cash/@Read.Cash/how-to-grow-the-bitcoin-cash-ecosystem-our-vision-part-2-d30a9c07 https://read.cash/@Read.Cash/our-affiliate-program-e616a825 https://read.cash/@Read.Cash/what-is-readcash-7b0bfcfc
10 comments
> These $5 is there courtesy of btcfork's chaintip Ahaha, I like it! Now back to reading your fantastic article.
:) 👍
> These $5 is Damn it. I've read the article like 5 times for typos! How did that "is" get there? :)
From my perspective, the person claiming that regular people will never use non-recoverable money is probably wrong - practically everyone used or use physical non-recoverable cash in the last 10 years. From a cost perspective, the added cost to every transaction, while small, might be undesirable. One way to work with this here though, is to use this passwording scheme for savings rather than spending. This extra costs might also be solved in the future when we adopt a new transaction format. From a privacy perspective, there's some interesting quirks here, like the incentive to use a common password so that your addresses are not uniquely recognizable, and to recover other peoples money whenever you need to recover yours to hide who may or may not have been the initiator of the recovery. From a security perspective though, I think that's where the main pain point is. The mechanism relies on humans to effectively remember passwords. And not just passwords, but specifically passwords they do not frequently use. I have a hard time remembering my old passwords and since this recovery is for an event where things have gone wrong, I'm not sure human memory is the better option, compared to making backups easier with physical hardware. This is an interesting idea, and it could very well get some use, but I would personally rather see a common standard for how to do NFC backups, then have people apply physical security to their recovery assets.
Actually, you can use the simplest password possible, like "mom", but the wallet would have to do some simple password-stretching, like 1) add user's email or birthday to the password 2) add wallet's provider name - some things that are easily rememberable for user, but will help avoid collisions for accidental recovery. All we're trying to do is to prevent accidental collisions in recovery, since there is no point why would hackers dedicate resources to that, since they can't claim the money - it'll go to "mom's wallet" anyway. But as an afterthought I think we need to go even deeper Satoshi-style and compare `hash(hash(email + password + providername)) == hash(hash(email + password + providername))` to avoid disclosing email (or birthday)
Now that the [$5 is safe](https://read.cash/@BigBlockIfTrue/grand-theft-readcash-3f13fb46), a more serious reply to the proposal. :) I like the idea of exploring what you can do with spending constraints. Tobias Ruck already demonstrated the possible UX improvement for smart card payments. This fits in the same category of ideas. However, this category of solutions comes also comes with increased transaction size and fees and reduced possibilities for privacy (emulate Ethereum-like accounts, get Ethereum-like poor privacy), so we must carefully evaluate whether the benefits exceed the costs. Advanced spending constraints could reduce the need to maintain separate hot and cold wallets for some use cases. For example, transactions exceeding some daily/weekly limit could require additional authorisation, not unlike spending constraints in the banking system. In case of a lost/stolen wallet, this could help you to reclaim your wallet's contents before a finder/thief can. The main problem I see is that the solution is designed for when you lose your private key, but you can only send to pre-selected trusted wallets. But if you are able to keep the private key for this trusted wallet safe, why can't you simply keep a safe back-up of your main wallet as well? You can even encrypt this wallet back-up with a password, or even write down the encrypted back-up on a piece of paper (existing wallet software can do this today). You also need to keep some record of the public address where the funds are, so you could simply keep the encrypted seed words in the same place. Another issue is the likely brute-forceability of the password, since there is no rate limit for guessing (and everyone can see the challenge publicly on the blockchain). To prevent this, you both need long passwords (e.g. 20 characters or more) and a lot of sequential rounds of hashing to attach a real computational cost to each guess. People are notoriously bad at remembering long complex passwords the seldomly use. I agree with Jonathan Silverblood's comment that safekeeping a (possibly encrypted) physical back-up is much easier overall - and also more secure against evil mothers.
You're claiming in one paragraph that people are really bad with something as simple as making and keeping a long password and then you suggest that people are better off keeping _encrypted_ private key... Ok, I agree and it was pointed in Steve Shadders comments that yeah, this whole scheme **in theoretical sense** is basically safekeeping a second private key. However, again, we're talking about _people_. It's easier to safekeep a phone, than a piece of paper. It's easier if your relative has a wallet installed for you, rather than tracking where that encrypted file is on the internet. As for the brute-force I'll have to again return to the idea that no dedicated hacker would spend time brute-forcing people's wallets, since he got _nothing to win_ from it, except maybe schoolyard bragging rights. So, my point is that we need to protect from accidental recoveries rather than malice. In that case I think the scheme that I replied to Jonathan is more than enough - stretch a password with email/birthday+wallet provider name and you have low/near zero (in case of an email) change of accidental recovery. `hello@read.cash|bitcoincom|phone` would do as a password. Again, like I said to Jonathan - we can use hash(hash()) to protect the privacy. Again, there's a whole section on why you don't NEED to keep account of your public addresses (it's nice, but you don't need it). The space to search is not that big (UTXOs for last few days as specified by user about his/her last usage). Personally, I trust my wife's phone (where I would have a spare wallet installed that she wouldn't use) much more than any cloud provider to safekeep my encrypted private key (and myself that I would remember the password for that key) and not delete my account because of some stupid reason. That's _assuming_ I'm smart enough to encrypt my private key and safekeep it. This is the third time I explain this. Either I'm stupid and fail to see something obvious, or it's the case of "If your ideas are any good, you'll have to ram them down people's throats." - Howard Aiken
While I'd generally recommend people to encrypt their hard drive anyway (once remembered, you'll never forget this password because you use it daily), you could also give an unencrypted back-up to your mother/wife if you trust her. I think it is confusing that you say "password", but you really mean something more like "username". A password protects against malice, a username just identifies. You enter your username into a recovery programme, and then it sends all your funds to a pre-chosen secondary wallet. I can see an advantage of choosing your username yourself instead of remembering the seed words the gods randomly select for you. But even then I feel like you can just store the primary wallet's seed along with the secondary wallet - an attacker who can get hold of the secondary wallet could guess the username anyway. If the secondary wallet is safe, you can also safely store your primary wallet's seed words there (my solution). If the secondary wallet is not safe, then the guessable "password" (your solution) will not provide adequate security either. An attacker who accesses the secondary wallet can steal your funds *in either case*. This is why I don't understand the intended advantage of your solution compared to my solution (unless you add other useful spending constraints). BTW if you store the hashed username on-chain and the username contains personal data like day of birth, then you still need to protect it against brute-forces to prevent people from stealing your personal data (even if they can't steal the money).
That's an interesting vector - hacking the recovery wallet first. The attacker would hack the wallet of my wife and then it's an easy guess for him that my "username" could be "wife". This is definitely something that needs thinking. > If the secondary wallet is safe, you can also safely store your primary wallet's seed words there I still have a feeling that this is not necessarily true. For example, it's very easy to install a secondary wallet on someone else's phone and forget about it at all. No passwords, no safekeeping at all. As long as that user has the phone - the phone safekeeps the private key. On the other hand - it's not exactly easy to store "primary key" safely on the phone. Where would someone keep it? Probably in "Notes" application. I think you'd agree that a good wallet would protect private key better than "Notes", right? That's why I have a feeling that this is not exactly if A therefore B: "If the secondary wallet is safe, you can also safely store your primary wallet's seed words there", but rather B is much more complex ritual for humans than A.
For the notes-on-phone case I would say the secondary wallet is *not* safe. If you can come up with a good solution for this case, that would indeed be useful. :)