Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D51C4137D for ; Fri, 4 Oct 2019 09:21:44 +0000 (UTC) X-Greylist: delayed 00:06:00 by SQLgrey-1.7.6 Received: from astrotown.de (astrotown.de [198.50.146.142]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 4FBF734F for ; Fri, 4 Oct 2019 09:21:43 +0000 (UTC) Received: from saulos-imac.fritz.box (ipbcc3afab.dynamic.kabel-deutschland.de [188.195.175.171]) by astrotown.de (Postfix) with ESMTPSA id EFD6F2C60682 for ; Fri, 4 Oct 2019 05:15:41 -0400 (EDT) From: Saulo Fonseca Content-Type: multipart/alternative; boundary="Apple-Mail=_1C0B04CE-23E4-4165-91CF-DB8DEDF49EC4" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <4E84E4B0-7354-4681-985F-3DBFAA4E856F@astrotown.de> Date: Fri, 4 Oct 2019 11:15:40 +0200 To: Christian Decker via bitcoin-dev X-Mailer: Apple Mail (2.3445.9.1) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 04 Oct 2019 09:42:41 +0000 Subject: [bitcoin-dev] ChainWallet - A way to prevent loss of funds by physical violence X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Oct 2019 09:21:45 -0000 --Apple-Mail=_1C0B04CE-23E4-4165-91CF-DB8DEDF49EC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone If you are a hodler, I like to propose the creation of a key stretching = as a new layer of protection over your current wallet. I call it = ChainWallet. Whatever is the method used to generate your private key, = we can do the following: newPrivKey =3D sha256(sha256(sha256(=E2=80=A6sha256(privKey)=E2=80=A6))) NewWallet =3D PubAddress(newPrivKey) In this way we create a chain of hashes over your private key and = generate a new wallet from it. If the chain is very long (billions or = trillions of hashes) it will take a long time to be created. If you = don=E2=80=99t keep the newPrivKey, the only way to move coins in the = NewWallet is to generate the chain again. The length of the chain can be easy memorized as an exponent such as = 2^40 or 10^12. What is that gut for? You will not be able to move your coins in an = unplanned way such as being tortured by a kidnaper. You can create a = wallet that takes days or even months to return the final address. Comparison with a BrainWallet If the first privKey is the hash of a password, your ChainWallet can be = compared to a BrainWallet with a chain added to it. BrainWallets have a = bad reputation because it is possible to create a brute-force attack = against it. There are reports where the attacker was able to guess the = password by generating hundreds of thousands of hashes per second. But, = if you use a ChainWallet that takes one second to be generated, it means = that the speed of an attack would be reduced to one guess per second. = This makes a brute force attack practically impossible. Entropy The ChainWallet adds only a few bits of entropy to your key. The idea = here is not to increase the entropy, but to add =E2=80=9Ctime=E2=80=9D = as part of the puzzle. SHA-256 I am suggesting the use of SHA-256 because it is the most popular hash = algorithm in the crypto community. But you could use SHA-512 or a slower = hash algorithm such as Bcrypt to do it. But keep in mind that other hash = algorithms can reduce the entropy. The idea is to add time to the key generation. If you use many SHA-256 = or a few SHA-512, as long as both need the same time to be generated, = there is no difference. Other hashes have the advantage that a hardware implementation of it is = not widespread. ASICs Someone could mention that ASICs get more and more powerful and could = crack a ChainWallet. But they have a huge hash rate because they = calculate it in parallel. A ChainWallet requires that the output of a = hash would be the input of the next calculation. This dramatically = reduces the speed of a hardware implementation of such algorithms. Let=E2=80=99s pick an example: The Bitfury Clarke has 8.154 cores and = runs 120 Gh/s. This means that each core can perform about 14.72 Mh/s. = This speed is all that you can get with one of the best ASIC on the = market. 17.72 Mh/s is only about 17,7 times faster than a typical = computer. This speed can only increase slowly, as technology needs time = to make the transistors run faster. So, the best way to generate a = ChainWallet is by using such an ASIC core. Misuse Someone could argue that people would misuse it by picking easy to = remember passwords or small chain length. A wallet implementation could = solve it by forcing a minimum length for the chain and block commonly = used words for the password. It is a matter of design. Theft The major advantage of a ChainWallet is the ability to avoid a theft. If = your wallet takes a really long time to be generated and someone tries = to force you to give your private key, you would not be able to do it, = even if you really want. You could also give away a wrong password or = chain length and he/she is not able to verify it. The chances are very = small that he/she will wait weeks of months for the chain generation of = even that he/she is able to do the chain calculation. Final Thoughts A ChainWallet could be used as an alternative to BIP39. Instead of = keeping 24 words, you would have a password and two numbers, a base and = an exponent, that defines the length of the chain. This is easier to = memorize, so you do not need to write it down. This is only meant as an additional option along with all others = available in the crypto environment, such as multisig and smart = contracts. As for those other ideas, the ChainWallet is not applicable = in every case. When the day arrives at which you want to stop hodling and transferring = your coins to another location, you should re-generate your wallet in a = planned way with the same original private key and length of the chain. = Then, after waiting until the program concludes, you will get the new = private key back. Web Links =09 The original idea can be found on this post: https://www.reddit.com/user/sauloqf/comments/a3q8dt/chainwallet = A proof of concept in C++ can be found on this link: https://github.com/Saulo-Fonseca/ChainWallet = The community is testing the concept for a while. You can find = discussions on this links: = https://www.reddit.com/r/Bitcoin/comments/cya467/chainwallet_challenge_get= _01_btc_if_you_solve_it = = https://www.reddit.com/r/Bitcoin/comments/d9ltec/does_someone_know_how_to_= submit_a_bip_for_bitcoin = Saulo Fonseca --Apple-Mail=_1C0B04CE-23E4-4165-91CF-DB8DEDF49EC4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi everyone

If you are a hodler, I like to = propose the creation of a key stretching as a new layer of protection = over your current wallet. I call it ChainWallet. Whatever is the method = used to generate your private key, we can do the following:

  • newPrivKey =3D = sha256(sha256(sha256(=E2=80=A6sha256(privKey)=E2=80=A6)))
  • NewWallet =3D PubAddress(newPrivKey)
In this way we create a chain of hashes over your private key = and generate a new wallet from it. If the chain is very long (billions = or trillions of hashes) it will take a long time to be created. If you = don=E2=80=99t keep the newPrivKey, the only way to move coins in the = NewWallet is to generate the chain again.

The length of the chain can be easy = memorized as an exponent such as 2^40 or 10^12.

What is that gut for? You will not be = able to move your coins in an unplanned way such as being tortured by a = kidnaper. You can create a wallet that takes days or even months to = return the final address.

Comparison with a BrainWallet

If the first privKey is = the hash of a password, your ChainWallet can be compared to a = BrainWallet with a chain added to it. BrainWallets have a bad reputation = because it is possible to create a brute-force attack against it. There = are reports where the attacker was able to guess the password by = generating hundreds of thousands of hashes per second. But, if you use a = ChainWallet that takes one second to be generated, it means that the = speed of an attack would be reduced to one guess per second. This makes = a brute force attack practically impossible.

Entropy

The ChainWallet adds = only a few bits of entropy to your key. The idea here is not to increase = the entropy, but to add =E2=80=9Ctime=E2=80=9D as part of the = puzzle.

SHA-256

I am suggesting the use of SHA-256 because it is the most = popular hash algorithm in the crypto community. But you could use = SHA-512 or a slower hash algorithm such as Bcrypt to do it. But keep in = mind that other hash algorithms can reduce the entropy.

The idea is to add time = to the key generation. If you use many SHA-256 or a few SHA-512, as long = as both need the same time to be generated, there is no = difference.

Other hashes have the advantage that a hardware = implementation of it is not widespread.

ASICs

Someone could mention = that ASICs get more and more powerful and could crack a ChainWallet. But = they have a huge hash rate because they calculate it in parallel. A = ChainWallet requires that the output of a hash would be the input of the = next calculation. This dramatically reduces the speed of a hardware = implementation of such algorithms.

Let=E2=80=99s pick an example: =  The Bitfury Clarke has 8.154 cores and runs 120 Gh/s. This means = that each core can perform about 14.72 Mh/s. This speed is all that you = can get with one of the best ASIC on the market. 17.72 Mh/s is only = about 17,7 times faster than a typical computer. This speed can only = increase slowly, as technology needs time to make the transistors run = faster. So, the best way to generate a ChainWallet is by using such an = ASIC core.

Misuse

Someone could argue that people would misuse it by picking = easy to remember passwords or small chain length. A wallet = implementation could solve it by forcing a minimum length for the chain = and block commonly used words for the password. It is a matter of = design.

Theft

The major advantage of a ChainWallet is the ability to avoid = a theft. If your wallet takes a really long time to be generated and = someone tries to force you to give your private key, you would not be = able to do it, even if you really want. You could also give away a wrong = password or chain length and he/she is not able to verify it. The = chances are very small that he/she will wait weeks of months for the = chain generation of even that he/she is able to do the chain = calculation.

Final Thoughts

A ChainWallet could be used as an = alternative to BIP39. Instead of keeping 24 words, you would have a = password and two numbers, a base and an exponent, that defines the = length of the chain. This is easier to memorize, so you do not need to = write it down.

This is only meant as an additional option along with all = others available in the crypto environment, such as multisig and smart = contracts. As for those other ideas, the ChainWallet is not applicable = in every case.

When the day arrives at which you want to stop hodling and = transferring your coins to another location, you should re-generate your = wallet in a planned way with the same original private key and length of = the chain. Then, after waiting until the program concludes, you will get = the new private key back.

Web Links
=
The original idea can be found on this = post:


A proof = of concept in C++ can be found on this link:


The community is testing = the concept for a while. You can find discussions on this = links:



Saulo Fonseca

= --Apple-Mail=_1C0B04CE-23E4-4165-91CF-DB8DEDF49EC4--