* [bitcoin-dev] Enc: Bitcoin cold hardwallet with (proof of creation)
[not found] <1mYrKpZbXZCKxNV4GHjQYh0CSSUMTROUPrbcCSkrzbMhsMUbVkFtjlBDTPltKnf9umStMtkrZlnvmHrRErg7cqffkbD1jHr1nebFBY74h4c=@protonmail.com>
@ 2021-09-29 17:10 ` trilemabtc
2021-09-29 21:59 ` ZmnSCPxj
0 siblings, 1 reply; 2+ messages in thread
From: trilemabtc @ 2021-09-29 17:10 UTC (permalink / raw)
To: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [bitcoin-dev] Enc: Bitcoin cold hardwallet with (proof of creation)
2021-09-29 17:10 ` [bitcoin-dev] Enc: Bitcoin cold hardwallet with (proof of creation) trilemabtc
@ 2021-09-29 21:59 ` ZmnSCPxj
0 siblings, 0 replies; 2+ messages in thread
From: ZmnSCPxj @ 2021-09-29 21:59 UTC (permalink / raw)
To: trilemabtc, Bitcoin Protocol Discussion
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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2021-09-29 21:59 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1mYrKpZbXZCKxNV4GHjQYh0CSSUMTROUPrbcCSkrzbMhsMUbVkFtjlBDTPltKnf9umStMtkrZlnvmHrRErg7cqffkbD1jHr1nebFBY74h4c=@protonmail.com>
2021-09-29 17:10 ` [bitcoin-dev] Enc: Bitcoin cold hardwallet with (proof of creation) trilemabtc
2021-09-29 21:59 ` ZmnSCPxj
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox