Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9FCFEC002D for ; Tue, 3 May 2022 18:03:23 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 7F1A8400F8 for ; Tue, 3 May 2022 18:03:23 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=riseup.net 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 j6YMyIp4jlhi for ; Tue, 3 May 2022 18:03:22 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by smtp2.osuosl.org (Postfix) with ESMTPS id EAD7E400BF for ; Tue, 3 May 2022 18:03:22 +0000 (UTC) Received: from fews2.riseup.net (fews2-pn.riseup.net [10.0.1.84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.riseup.net", Issuer "R3" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4Kt79k2bkkzDrCQ; Tue, 3 May 2022 11:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1651601002; bh=BzF9uD2GM5FkeVEJLl9WBu29jMJVTm9ONlHyjD+on1s=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=M/Ca/uxvifikzrf3cR1znX6dhzfZWYhhDMfsnllfcmn7zltrl3dRAg2uiRYbqN9nF 8G7UtsS78e+K7owC0YYjHcukGEj9AgqEDUdU/MxZEbztMhY2S8W/llIPlBrsZRstfC FmYP/a+sftHGEqaV4KQbUaNNGeEqdD7dN5YoCisI= X-Riseup-User-ID: 275C0881DBC5E5A2296778D273BE17621CE823800E34C9B825A1A343454C5212 Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4Kt79j4Y7sz1y9N; Tue, 3 May 2022 11:03:21 -0700 (PDT) Message-ID: Date: Tue, 3 May 2022 19:03:12 +0100 MIME-Version: 1.0 Content-Language: en-US To: ZmnSCPxj References: <22c80504-e648-e021-866e-ca5a5db3b247@riseup.net> <82948428-29a3-e50a-a54a-520a83f39bba@riseup.net> <4a6ef305-cf67-dce3-aed3-ab0a28aa758f@riseup.net> From: Chris Belcher In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Bitcoin Protocol Discussion 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: Tue, 03 May 2022 18:03:23 -0000 Hello ZmnSCPxj, Such a system will have to be publicly advertised, in the same way we see centralized cryptocurrency staking shops buying ads all over the place. That's how they'll make retail hodlers aware that renting out your coins in this way is possible. If JoinMarket/Teleport users notice such ads appearing then we could change the taker code to remove the intermediate certificate keypair, and have the fidelity bond UTXO key sign the endpoint (IRC nickname or onion hostname) directly. This removes the possibility of fidelity bonds in cold storage. It would have to be done for privacy, and it wouldn't be too bad. Right now there's no cold storage solution for fidelity bonds yet JoinMarket has about 600 bitcoins locked up and advertised, which must be all on hot wallets. Best, CB On 03/05/2022 06:26, ZmnSCPxj wrote: > Good morning Chris, > >> Hello ZmnSCPxj, >> >> Renting out fidelity bonds is an interesting idea. It might happen in >> the situation where a hodler wants to generate yield but doesn't want >> the hassle of running a full node and yield generator. A big downside of >> it is that the yield generator income is random while the rent paid is a >> fixed cost, so there's a chance that the income won't cover the rent. > > The fact that *renting* is at all possible suggests to me that the following situation *could* arise: > > * A market of lessors arises. > * A surveillor creates multiple identities. > * Each fake identity rents separately from multiple lessors. > * Surveillor gets privacy data by paying out rent money to the lessor market. > > In defiads, I and Tamas pretty much concluded that rental would happen inevitably. > One could say that defiads was a kind of fidelity bond system. > Our solution for defiads was to prioritize propagating advertisements (roughly equivalent to the certificates in your system, I think) with larger bonded values * min(bonded_time, 1 year). > However, do note that we did not intend defiads to be used for privacy-sensitive applications like JoinMarket/Teleport. > > > Regards, > ZmnSCPxj