[bitcoin-dev] Enc: Bitcoin cold hardwallet with (proof of creation)

[bitcoin-dev] Enc: Bitcoin cold hardwallet with (proof of creation)

[trilemabtc]

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----

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!

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEExdl2BaappAJ3lpcJRT5Yw3Ri1V0FAmFUnXgACgkQRT5Yw3Ri

1V1KHw//Z6TOk4YATwsvdLYcZ+6xUmruETzKUZ27kYp/Fvy6wYo8de6I1+fzRH4M

gcMp+Jz4oD6hmY+Kcpg1bDo7fOKWnFFf+HgxzRhxRTh39I35EYXKEYboLzqeXm43

jEViRFSBnJHZNx4YV5UlTIFMczQ17Ew60N7n3Av9OWykOgDcafgbOTMKlBsePRsI

SQnUkqnh//1GFw8w9q0VS/7lD4dCHbPlASpd9LemVlKJGyCAvPGhXSwC6ay4vK6j

iWdRkEFGXbjuhVzhLbte0Pg9W/psKW7wg1JttG1EkxBep49o9preNHrFNe4KgQ3S

ggn9qm9KOaYSxh9ZMFKMx4Pif3vIcMROtm/OJk1U0E+WCBb3ymEZBWf6E2bRlwmN

uZ7/EbCCk7jiM+l4LYZO26OzSABR8aodo7HSsFYVwOq3zVWQx5ixy8Y0BjLhK9C0

XySSpU0aBzr39Szap8UBDgYarmuusu3m0o7ASvA6YSg1rifv2mIYAQ2ad/Cxwqxg

RC8c3JhW+WLNJKl6DXAv6LhAkBfUZNW6cESe8Uo1JDPs0I5XXDS0mIRi5x3Clz5N

QffEHupuQQjVtICJZl7zNvLFPUdn9EaRC6ZAGyuVU+7vNvpQOCBH2bdxLM1Zie6D

HoN+Q8kGvlqyWxWuXsWY5nbRWQEoi09Z94zKLdYRdLOW9NtsShM=

=3H+p

-----END PGP SIGNATURE-----

[-- Attachment #2: Type: text/html, Size: 4798 bytes --]

Re: [bitcoin-dev] Enc: Bitcoin cold hardwallet with (proof of creation)

[ZmnSCPxj]

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