Date: Wed, 29 Sep 2021 21:59:16 +0000
To: trilemabtc <trilemabtc@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <W_italE75FlmiJhJiUXVVnk47tiBwHiesTwipmNXxZQNUy7flrixctwvag5kxIrLg-oVWbIn03WlTr1QEZXC_C5M0HZqzSCpMZK6wJ16kG0=@protonmail.com>
In-Reply-To: <ognT3T2_QMnYOMCKFtV2u36lMIQVYS_gai_YzjKY9I0BycsChp02oGg1vcRWIzBiIggr28ZT2YaNnPhOVRdfBLvl_L4-4lkCfyOnUeZSfoY=@protonmail.com>
References: <1mYrKpZbXZCKxNV4GHjQYh0CSSUMTROUPrbcCSkrzbMhsMUbVkFtjlBDTPltKnf9umStMtkrZlnvmHrRErg7cqffkbD1jHr1nebFBY74h4c=@protonmail.com>
 <ognT3T2_QMnYOMCKFtV2u36lMIQVYS_gai_YzjKY9I0BycsChp02oGg1vcRWIzBiIggr28ZT2YaNnPhOVRdfBLvl_L4-4lkCfyOnUeZSfoY=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Enc: Bitcoin cold hardwallet with (proof of
	creation)
Precedence: list

Good morning trilemabtc,

> Hash: SHA256
>
> In search of more freedom, I thought of a hardwallet that makes the funds=
 unseizable, using proof of creation (another step with key file), only the=
 creator can reveal the private keys, more details about the idea can be fo=
und in the directory: https://github.com/trilemabtc/safedime I'm not a dev,=
 but the concept is well defined and I believe that the elements to execute=
 the project already exist. Hugs!


Comparing it to OpenDime is somewhat confusing, especially when you insist =
that creator is the only one who can reveal the privkey.
It seems to be more of the old saw of "what you have + what you know" i.e. =
"the correct way to 2-factor", where the device itself is the "what you hav=
e" and your "key file" is "what you know".

In particular: "Dime" is a kind of physical coin, and the point of physical=
 coins is to transfer ownership of the coin to other people in exchange for=
 goods and services; the device you describe sacrifices this transfer of ow=
nership due to the key file.

From what I can see, the basic idea is to generate a simple 2-of-2, possibl=
y by "just" combining the private key on the device plus a private key gene=
rated from the key file.
They can be simply added or multiplied together, I believe.
Then the device stores the key generated from the entropy you provide and e=
xposes a public key to the software.
Then the software generates a private key from the key file the user provid=
es and tweaks the device pubkey to generate the Bitcoin address.
In order to spend from that address, both the key file and the device have =
to be put together.
I believe that with multiplication of two privkeys, you can use 2p-ECDSA to=
 even have the device provide a signature share that the software can combi=
ne with a signature share with the privkey from the keyfile, creating a sin=
glesig ECDSA signature.
This allows spending without having to enter revealed state.

The above allows the device to be configured with random entropy *separatel=
y* from the keyfile: when leaving "new unit" state it does *not* require th=
e key file to be given.
This is good since it reduces the possibility of malware getting access to =
both the entropy you feed to the device, and the key file, which would be a=
ble to reconstruct the final privkey and steal funds.
That is: have the entropy-giving stage ***not*** require the key file (and =
in particular, strongly recommend to do it on a computer that has never tou=
ched the key file).
This would be required anyway if you want to have "backups", i.e. separate =
device units with the same device privkey.

I also would not recommend or even mention the use of brainwallets, at all,=
 even for keyfiles.
Unless you generated it with sufficient entropy (e.g. dice) and chant it ev=
ery day to yourself (to keep it fresh in your memory, assuming the user is =
human, anyway) the risk of loss with any kind of brainwallet is too high, e=
ven in a 2-of-2 with a hardware device.

Regards,
ZmnSCPxj