From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 66AB1C000D for ; Wed, 29 Sep 2021 21:59:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 5434440215 for ; Wed, 29 Sep 2021 21:59:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.098 X-Spam-Level: * X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3x9jpBIechm for ; Wed, 29 Sep 2021 21:59:30 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4325.protonmail.ch (mail-4325.protonmail.ch [185.70.43.25]) by smtp2.osuosl.org (Postfix) with ESMTPS id 1125D400DA for ; Wed, 29 Sep 2021 21:59:29 +0000 (UTC) Date: Wed, 29 Sep 2021 21:59:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1632952766; bh=FBiQ88fTTjnGwzMqq9IcQH38T/oSTXmZbq6D7mReqUU=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=wCSE5ZyOwWUjO7sgAb6MQNfRt4GokbEjpwB+5fPlAVQbtkHlAzGNnBgIS2LTckwgk dt+xfStJjXWh99gIXGO61OQcY58nJK+2x0/2MIsTuA2U/S9VaAm0un5jpHr7MpBPsk Kh/nQ5vWNkX9g+HMxQ1CvTdY/BvohlDOsJzkZYWk= To: trilemabtc , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <1mYrKpZbXZCKxNV4GHjQYh0CSSUMTROUPrbcCSkrzbMhsMUbVkFtjlBDTPltKnf9umStMtkrZlnvmHrRErg7cqffkbD1jHr1nebFBY74h4c=@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) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2021 21:59:31 -0000 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