Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6A2F5C016F for ; Sat, 13 Jun 2020 00:45:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 4D2A588C9B for ; Sat, 13 Jun 2020 00:45:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcXmtDoo2FJ6 for ; Sat, 13 Jun 2020 00:45:25 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) by whitealder.osuosl.org (Postfix) with ESMTPS id 57C6188C99 for ; Sat, 13 Jun 2020 00:45:25 +0000 (UTC) Date: Sat, 13 Jun 2020 00:45:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1592009122; bh=fD5NRKhQU80FrXgukOUSbzvNXLenJ5BF57/YvrpoUWU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=umMVx8VgqWNcO2L/4R1H4qhcE+OU+7oagy4RQcn7EB9+woG5OKtrbjn3GxiZbyIp1 UfdRRhf2y64WWUg/tOae9yd27JBNmgeXMzBZ4plPpiiSyr6hLOLgvwiDPypys1xnBh 1z7HytX91La+gztdNwMhRnnXz05XleIpxeW0alKk= To: Antoine Riard From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <7cWQJzkWNEZCI2fYYrJCFxrmGfDGFAtsOyGpXRmB-g4Qhm2jzhyxLtuOIpJAr2CMJjAjri12lmR-h96ev3NWqaTgDtc_NN0yhyVxuIlBuzU=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] CoinPool, exploring generic payment pools for Fun and Privacy 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, 13 Jun 2020 00:45:27 -0000 Good morning Antoine, > Yes, that's part of future research, defining better *in-pool* observer. = Sadly, right now, even if you use mask construction inside, it's quite easy= to trace leaves by value weight. Of course, you can enforce equal-value le= aves, as for a regular onchain CoinJoin. I think it comes with a higher onc= hain cost in case of pool breakage. Perhaps not necessarily. An advantage of WabiSabi is I can pretend to be two or more participants. For example, I can pretend to be "Alice" and "Bob", and pretend that "Alice= " owes a life debt to "Bob". At initial state setup, I put a 1.0 BTC coin as "Alice" and a 0.5 BTC coin = as "Bob". Now, at each state update I need to sign as "Alice" and "Bob". However, after the first initial state, I can use a new persona "Bobby" to = *own* my coins, even though I still have to sign as "Alice" and "Bob" in ev= ery state update. What the other pool participants see is that the 1.0 BTC "Alice" coin and t= he 0.5 BTC "Bob" coin are merged into the 1.5 BTC "Bobby" coin. What they cannot be sure of is: * "Alice" paid to "Bob", who is now pretending to be "Bobby". * "Bob" paid to "Alice", who is now pretending to be "Bobby". * "Alice" and "Bob" are the same person, and is also pretending to be "Bobb= y". All the other participants know is that whoever owns the coin *now* is stil= l part of the pool, but cannot be sure which participant *really* owns whic= h coin, and whether participants are sockpuppets (which is why it should us= e n-of-n at each state update, incidentally). In effect, it "imports" the possibility of PayJoin inside the CoinPool cons= truction. Regards, ZmnSCPxj