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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
