Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id B61ADC002D for ; Mon, 2 May 2022 09:23:54 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 9A7F860E74 for ; Mon, 2 May 2022 09:23:54 +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: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=riseup.net Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJFsrsyEGdty for ; Mon, 2 May 2022 09:23:53 +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 smtp3.osuosl.org (Postfix) with ESMTPS id BE3F260592 for ; Mon, 2 May 2022 09:23:53 +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 4KsHhn13kqzDsLF; Mon, 2 May 2022 02:23:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1651483433; bh=blfPIUPU1ugtcrdLjRQUdDQ4k9CJJu0pJbhamnQji4A=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=ZIFS1H45qcHiS0zy2zLANWDerC/pxIMvvCy/4S83KMTZzPnXkWrrzU8jiWxIy3o+m YEEqiGSFh49CDZ+Y2nEnOUk3bxCHB8xzyQZjIh2CQ11kYnu35F2EVQtDTjP8i8ZZ/z 4E2840WZ7SGYILdSTuW+xyof8L3bkLEvHZuH5wS8= X-Riseup-User-ID: 6805601393607068E5DFC5BB0B8C5543A17CDAD247E076140E62644CD74ACD9A Received: from [127.0.0.1] (localhost [127.0.0.1]) by fews2.riseup.net (Postfix) with ESMTPSA id 4KsHhm30nCz20Rs; Mon, 2 May 2022 02:23:52 -0700 (PDT) Message-ID: <4a6ef305-cf67-dce3-aed3-ab0a28aa758f@riseup.net> Date: Mon, 2 May 2022 10:23:50 +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> 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: Mon, 02 May 2022 09:23:54 -0000 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. JoinMarket takers since the start have checked that a fidelity bond doesn't appear twice. The technique doesn't deserve a section in the BIP because this BIP is only about specifying the wallets that hold fidelity bond UTXOs for makers, not takers which receive fidelity bond messages. In JoinMarket this is done in this code here: https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/6b05f65260a487cd22f175ba64d499fbe8122530/jmclient/jmclient/taker.py#L1020-L1021 Best, CB On 01/05/2022 12:41, ZmnSCPxj wrote: > Good morning again Chris, > > I wonder if there would be an incentive to *rent* out a fidelity bond, i.e. I am interested in application A, you are interested in application B, and you rent my fidelity bond for application B. > We can use a pay-for-signature protocol now that Taproot is available, so that the signature for the certificate for your usage of application B can only be completed if I reveal a secret via a signature on another Taproot UTXO that gets me the rent for the fidelity bond. > > I do not know if this would count as "abuse" or just plain "economic sensibility". > But a time may come where people just offer fidelity bonds for lease without actually caring about the actual applications it is being used *for*. > If the point is simply to make it costly to show your existence, whether you pay for the fidelity bond by renting it, or by acquiring your own Bitcoins and foregoing the ability to utilize it for some amount of time (which should cost closely to renting the fidelity bond from a provider), should probably not matter economically. > > You mention that JoinMarket clients now check for fidelity bonds not being used across multiple makers, how is this done exactly, and does the technique not deserve a section in this BIP? > > Regards, > ZmnSCPxj