Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 28DE5C002D for ; Tue, 10 May 2022 12:31:12 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 17622416C0 for ; Tue, 10 May 2022 12:31:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, 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 CZKmrAOMeH2r for ; Tue, 10 May 2022 12:31:09 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by smtp4.osuosl.org (Postfix) with ESMTPS id 702D540331 for ; Tue, 10 May 2022 12:31:09 +0000 (UTC) Date: Tue, 10 May 2022 12:31:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1652185866; bh=7q0P5aY3gexue2lD+R4WD50JRFStxJrJaQTovXkYxVA=; 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=jHAEErm5TDVDSC6xyJUeuUqLRIvt6qLu17+uHJdjaIuLwSlBtAzDKY6ob9k5426pk 38QylAAKcgxXDd86T5LytbWKTbDJTGc9JPQ2OhoK5anrj1Kf3NrJ3JH4xmx150y5MN 5xtnG+1NZanesqsp7G0ZhYOxYMgZ+8InCrJbt83o5cEQAyXNBswkJOLQ+iIXBTVCod 8B4Xp/9oG0TFq+fYh5qp09VL8V6jc9eh2iWrC25L5XEEf+K5g3aL8ZIzFAdGCDVuUA YuYpZkYMua9Az1mUZb2jtzjRSPEKdtZZLCKGBYLqtjQ8zA43GcrPDhh8MtbJQqgiS/ HI+3nJaDZOJ2w== To: Chris Belcher , Bitcoin Protocol Discussion From: AdamISZ Reply-To: AdamISZ Message-ID: In-Reply-To: <82948428-29a3-e50a-a54a-520a83f39bba@riseup.net> References: <22c80504-e648-e021-866e-ca5a5db3b247@riseup.net> <82948428-29a3-e50a-a54a-520a83f39bba@riseup.net> 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: Tue, 10 May 2022 12:34:47 +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: Tue, 10 May 2022 12:31:12 -0000 ------- Original Message ------- On Sunday, May 1st, 2022 at 11:01, Chris Belcher via bitcoin-dev wrote: > Hello ZmnSCPxj, > > This is an intended feature. I'm thinking that the same fidelity bond > can be used to running a JoinMarket maker as well as a Teleport > (Coinswap) maker. > > I don't believe it's abusable. It would be a problem if the same > fidelity bond is used by two makers in the same application, but > JoinMarket takers are already coded to check for this, and Teleport > takers will soon as well. Using the same bond across different > applications is fine. > > Best, > CB > Hi Chris, Zmn, list, I've noodled about this a few times in the past (especially when trying to = figure out an LSAG style ring sig based FB for privacy, but that does not s= eem workable), and I can't decide the right perspective on it. A user sacrifices X amount of time-value-of-money (henceforth TVOM) by comm= itting in Joinmarket with FB1. He then uses the same FB1 in Teleport, let's= say. If he gets benefit Y from using FB1 in Joinmarket, and benefit Z in T= eleport, then presumably he'll only do it if (probabilistically) he thinks = Y+Z > X. But as an assessor of FB1 in Joinmarket, I don't know if it's also being us= ed for Teleport, and more importantly, if it's being used somewhere else I'= m not even aware of. Now I'm not an economist I admit, so I might not be in= tuit-ing this situation right, but it fees to me like the right answer is "= It's fine for a closed system, but not an open one." (i.e. if the set of po= ssible usages is not something that all participants have fixed in advance,= then there is an effective Sybilling problem, like I'm, as an assessor, th= inking that sacrificed value 100 is there, whereas actually it's only 15, o= r whatever.) As I mentioned in https://github.com/JoinMarket-Org/joinmarket-clientserver= /issues/993#issuecomment-1110784059 , I did wonder about domain separation = tags because of this, and as I vaguely alluded to there, I'm really not sur= e about it. If it was me I'd want to include domain separation via part of the signed m= essage, since I don't see how it hurts? For scenarios where reuse is fine, = reuse can still happen. Cheers, waxwing/AdamISZ