From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3AE7DC0012 for ; Wed, 30 Mar 2022 11:58:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 29CD1843B8 for ; Wed, 30 Mar 2022 11:58:46 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.351 X-Spam-Level: X-Spam-Status: No, score=-0.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_BL_SPAMCOP_NET=1.347, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=towardsliberty.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3pN-qy5yKU8 for ; Wed, 30 Mar 2022 11:58:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from subsea-epitome.host4coins.net (subsea-epitome.host4coins.net [185.150.162.112]) by smtp1.osuosl.org (Postfix) with ESMTPS id D2668842ED for ; Wed, 30 Mar 2022 11:58:44 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by subsea-epitome.host4coins.net (Postfix) with ESMTP id CBC8E81936 for ; Wed, 30 Mar 2022 11:58:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= towardsliberty.com; h=content-transfer-encoding:content-type :content-type:subject:subject:from:from:content-language :user-agent:mime-version:date:date:message-id; s=default; t= 1648641470; x=1650455871; bh=JWjDeGwIQhXGjS58mNL/Xg8Wx840APlXZLX p9HuaPmc=; b=fU49lzZvxV8ne7LrPMz9vlImbO9eX28y//oSOnfZYf0aAEmfttP vTbcFY8hYRSDXK0U93TDf7Msg9xfZouLcKVpbH74LL7EatEqMs/8CPDpDGbJhkvd gQAutXHQeqsqeJw/937u5qJzVW0pKy/wRs6g7Nnc3SdsjYB9109uqPCs= X-Virus-Scanned: Debian amavisd-new at subsea-epitome.host4coins.net Received: from subsea-epitome.host4coins.net ([127.0.0.1]) by localhost (subsea-epitome.host4coins.net [127.0.0.1]) (amavisd-new, port 10026) with LMTP id m3CtxXKnIEOw for ; Wed, 30 Mar 2022 11:57:50 +0000 (UTC) Received: from [10.137.0.32] (tor-exit-01.darklab.sh [89.58.27.84]) (Authenticated sender: max@towardsliberty.com) by subsea-epitome.host4coins.net (Postfix) with ESMTPSA id 5245481726 for ; Wed, 30 Mar 2022 11:57:50 +0000 (UTC) Message-ID: Date: Wed, 30 Mar 2022 13:57:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US From: Max Hillebrand To: bitcoin-dev@lists.linuxfoundation.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 30 Mar 2022 13:11:52 +0000 Subject: [bitcoin-dev] WabiSabi P2EP / Wormhole 2.0 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: Wed, 30 Mar 2022 11:58:46 -0000 Hello List, tl;dr, users of WabiSabi coinjoin can pay arbitrary amounts of bitcoin, so that the sender does not learn the address/output of the receiver, and the receiver does not learn the input of the sender. This improves the previously proposed 'Wormhole' for Chaumian blind signature coinjoin, by allowing arbitrary amount payments and by reducing block space for change decomposition. https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg08622.html Assume that the sender and the receiver are both online and have a direct communication channel [P2EP]. The sender registers an input [let's say 1 btc value] with a third-party WabiSabi coordinator. In exchange, the sender receives a keyed-verified-anonymous-credential. The sender can present the 1 btc credential, and request a reissuance of two new credentials worth for example 0.3 btc and 0.7 btc. Since Pedersen commitments are the attributes of the KVAC, the coordinator does not learn any of those amounts. Next, the sender gives the receiver through the P2EP connection the KVAC corresponding to the amount that is due pay. Now the receiver presents this credential to the coordinator, and requests a reissuance, which can again be split up into two credentials, for example 0.1 and 0.2. At this point, the sender can no longer present the old credential, the coordinator ensures double spending protection. Later during output registration, the sender registers with the coordinator his "payment change outputs", which again can be decomposed client side into multiple outputs, let's say 0.5 and 0.2. Likewise, the receiver presents his KVACs, and registers his desired output addresses directly with the coordinator. After output registration, the coordinator aggregates the PSBT with all registered inputs and outputs, and presents the unsigned coinjoin transaction to all Alices [Tor identities who registered inputs]. Since the sender does not know what the receivers output address is, he has to ask the receiver through the P2EP connection if this coinjoin is good. If response is ACK, then the sender signs for his inputs and registers the signatures with the coordinator. If all inputs sign, we have a successful coinjoin, which includes a payment, where the sender never learns the address of the receiver, and the receiver never learns the inputs or change outputs of the sender. The coordinator can not differentiate users who make self-spends from those who do payments, this is entirely client side. Of course the sender still knows the amount of bitcoin of the credential that he passed on to the receiver [the invoiced payment amount]. However, similar to PayJoin, the receiver can likewise register inputs with the coordinator in the same round. Unlike PayJoin, there are many other inputs who do not belong to sender or receiver, which provides the desired anonymity set. Such a receiver will have the KVAC originated from his own input[s], as well as the KVAC that the sender gave him. Two KVACs can be reissued to one, thus anonymous consolidation of inputs + payment amount is possible. Since neither the coordinator, nor the sender, know the input[s] of the receiver, the final amount on-chain [even if only one receiver output is created] does not correspond to the payment amount, thus the sender can not identify the output of the receiver based on amounts. A blinded coinjoin coordinator is a PSBT whiteboard, where users purchase eCash tokens by registering inputs, and users spend eCash tokens in order to register outputs. Users can self-spend the eCash to increase anonymity set of those access rights. However, nothing prevents the user to make an actual eCash "payment" to someone else, effectively abdicating the right to register outputs. If [and only if] the final coinjoin has sufficient number of inputs and outputs to provide effective blockchain ambiguity, then the resulting payment has breathtaking privacy guarantees. Skol Max Hillebrand