Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id ED6BEC002D for ; Sat, 21 May 2022 21:36:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id CAF6241909 for ; Sat, 21 May 2022 21:36:17 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2gfUY43lC8a for ; Sat, 21 May 2022 21:36:16 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40134.protonmail.ch (mail-40134.protonmail.ch [185.70.40.134]) by smtp4.osuosl.org (Postfix) with ESMTPS id A20D6418FC for ; Sat, 21 May 2022 21:36:16 +0000 (UTC) Date: Sat, 21 May 2022 21:36:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1653168974; x=1653428174; bh=wkT1e1CEfy5tAJT3REj/mDnO1/BjUQ0ZkRz0G+mEFkM=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=qk+zVPZjfI7x+qy/WKSS3sgpEsGclmMEsyiAm5Aj6vokR/IzzuvJlmeOlhiskiMnE 1+h+2DfR0r6hMevxuBzzH05iJYXcqG0aIOOAAQ5PyQ3eUx4YFd8y928fJ/dewPACiY lfOh8l87b2b2va4vDCc+i8CyHZ8MYNHQyqrWlVtLTLDWectJ2Y9rjreg0GCOZdviDx vbHIqy35dDIVi7niQBPncC3J3yqXZrbI08vKFvLhWqBKqoTWCg1vY/fhuOFgQTt1Oh j2/i+PRHSy4sIDaKU7w+f6Zrbpczjy3RuC6efLeleHLvXM9YFNDUFkghBaH3JNWUlH MY00IcEbWhdGQ== To: ZmnSCPxj , Bitcoin Protocol Discussion From: AdamISZ Reply-To: AdamISZ Message-ID: In-Reply-To: References: <48D4B621-D862-4031-AE43-3F54D34FB0B5@voskuil.org> <01c401d86a5c$956ddbd0$c0499370$@voskuil.org> <01d901d86a64$452ef9d0$cf8ced70$@voskuil.org> Feedback-ID: 11565511:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 22 May 2022 14:29:01 +0000 Subject: Re: [bitcoin-dev] BIP proposal: Timelocked address fidelity bond for BIP39 seeds 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: Sat, 21 May 2022 21:36:18 -0000 > > > As a better analogy: I am borrowing a piece of gold, smelting it down= to make > > > a nice shiny advertisement "I am totally not a bot!!", then at the en= d of the > > > lease period, re-smelting it back and returning to you the same gold = piece > > > (with the exact same atoms constituting it), plus an interest from my= business, > > > which gained customers because of the shiny gold advertisement claimi= ng "I > > > am totally not a bot!!". > > > > > > That you use the same piece of gold for money does not preclude me us= ing > > > the gold for something else of economic value, like making a nice shi= ny > > > advertisement, so I think your analysis fails there. > > > Otherwise, your analysis is on point, but analyses something else ent= irely. Back to this analogy, I think it's imprecise in a way that's important to n= ot overlook: you cannot re-use the same gold atoms in two different adverti= sements. Use of a fidelity bond, being basically a signature, is completely= 'non-rivalrous' as I think the economists say. > Yes, that is why Tamas switched to defiads, as I had convinced him that i= t would be similar enough without actually being a covenant scam like you d= escribed. > > > In any case, I tend to agree with your other posts on the subject. For = the burn to be provably non-dilutable it must be a cost provably associated= to the scenario which relies upon the cost. This provides the global uniqu= eness constraint (under cryptographic assumptions of difficulty). > > > Indeed. > I suspect the only reason it is not yet a problem with existing JoinMarke= t and Teleport is simply that no convenient software currently exists which= allows the same bond to be used by both, thus making it safe in practice b= ut not in theory. > But the theory implies that if somebody does make such software, effectiv= ely both systems will become joined as effectively only a single identity e= xists in both systems. > This may not be a problem either since the intent is that Teleport will o= bsolete JoinMarket someday, but if other applications start using the same = scheme without requiring a commitment to a specific application, this may a= lso effectively render Teleport less useful as well. > > Regards, > ZmnSCPxj > _______________________________________________ So, general comment: it seems like both you and Eric agree with my uncertai= n intuition up-thread and therefore do we all agree that the correct soluti= on (to whatever extent there is one) is something like domain separation ta= gs, as we discussed earlier? It's still a matter of social consensus: if ap= pending "JM" to the end of a certificate signature is intended to mean that= this fidelity bond can only be used in Joinmarket and not anywhere else, w= ell we can only as individual users demand that (i.e. *I* might not accept = it in Teleport, but what if Fred down the street does? It's not enough for = me to rely on my own criteria!), and more subtly, it makes sense only if we= all have an unambiguous definition of what Joinmarket *is* - ironically it= is precisely the thing brought most into question by the achievement of re= al decentralization in a system. Cheers, waxwing/AdamISZ