From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: trilemabtc <trilemabtc@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Enc: Bitcoin cold hardwallet with (proof of creation)
Date: Wed, 29 Sep 2021 21:59:16 +0000 [thread overview]
Message-ID: <W_italE75FlmiJhJiUXVVnk47tiBwHiesTwipmNXxZQNUy7flrixctwvag5kxIrLg-oVWbIn03WlTr1QEZXC_C5M0HZqzSCpMZK6wJ16kG0=@protonmail.com> (raw)
In-Reply-To: <ognT3T2_QMnYOMCKFtV2u36lMIQVYS_gai_YzjKY9I0BycsChp02oGg1vcRWIzBiIggr28ZT2YaNnPhOVRdfBLvl_L4-4lkCfyOnUeZSfoY=@protonmail.com>
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 found 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 have" 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 ownership due to the key file.
From what I can see, the basic idea is to generate a simple 2-of-2, possibly by "just" combining the private key on the device plus a private key generated 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 exposes a public key to the software.
Then the software generates a private key from the key file the user provides 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 combine with a signature share with the privkey from the keyfile, creating a singlesig ECDSA signature.
This allows spending without having to enter revealed state.
The above allows the device to be configured with random entropy *separately* from the keyfile: when leaving "new unit" state it does *not* require the 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 able 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 touched 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 every 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, even in a 2-of-2 with a hardware device.
Regards,
ZmnSCPxj
prev parent reply other threads:[~2021-09-29 21:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1mYrKpZbXZCKxNV4GHjQYh0CSSUMTROUPrbcCSkrzbMhsMUbVkFtjlBDTPltKnf9umStMtkrZlnvmHrRErg7cqffkbD1jHr1nebFBY74h4c=@protonmail.com>
2021-09-29 17:10 ` trilemabtc
2021-09-29 21:59 ` ZmnSCPxj [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='W_italE75FlmiJhJiUXVVnk47tiBwHiesTwipmNXxZQNUy7flrixctwvag5kxIrLg-oVWbIn03WlTr1QEZXC_C5M0HZqzSCpMZK6wJ16kG0=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=trilemabtc@protonmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox