From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 10FB2C077D for ; Thu, 16 Jan 2020 02:11:55 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id E368F20468 for ; Thu, 16 Jan 2020 02:11:54 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CPgk3QCnkh5 for ; Thu, 16 Jan 2020 02:11:52 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by silver.osuosl.org (Postfix) with ESMTPS id 3494920440 for ; Thu, 16 Jan 2020 02:11:52 +0000 (UTC) Date: Thu, 16 Jan 2020 02:11:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1579140709; bh=+stejLYyKzemA1gxFDpsa11snIoRG5MqaHbigem6DJA=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=YMhx4RnE6Rsi4GZQYdA+waB9BQawwugrQ7/eXmFZoPYCJ5ArFBaGBDqbZzYb3Tp0T C22D/BZ1hum0NdGVjTzFoD3nsZXJPWygPGLE0q2InA1avfrwPvrXXoTEiwM99zQHgo 5j5vT4jGdkRVpxIsh+DCnj1UyuCmF7lXu0QGijSQ= To: Max Hillebrand , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <96dc101e-30ba-9833-7ba0-41eda910d3cc@towardsliberty.com> References: <96dc101e-30ba-9833-7ba0-41eda910d3cc@towardsliberty.com> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] ***UNCHECKED*** Wormhole: Sending and receiving bitcoin anonymously 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: Thu, 16 Jan 2020 02:11:55 -0000 Good morning Max, It seems similar very closely to TumbleBit, at least in the overall protoco= l. A cursory read does not reveal any direct problems with it. Regards, ZmnSCPxj > Hello all! > > May I propose you this protocol which seemingly provides a great level > of privacy for both the sender and receiver of bitcoin. This was > initially posted to the Wasabi WalletGitHub, and after thoroughcontemplat= ion and minor tweaks, I would now like to request your > feedback on the conceptual design and possible implementation. > > Cheers > Max > > Wormhole > > =3D=3D=3D=3D=3D=3D=3D=3D=3D > > Abstract > > --------- > > A protocol to transfer bitcoin, without the receiver gaining knowledge > of the input of the sender, and without the sender gaining knowledge of > the output of the receiver, while simultaneously generating equal value > CoinJoin outputs with anonymity set. > > Introduction > > ------------- > > This is achieved by minor changes to theZeroLink CoinJoin protocol, utili= zinga centralized coordinator who cannot steal, and cannot spy. Schnorr > blind signatures are used to obfuscate the link between inputs and equal > value outputs throughout the ceremony. The coordinator does not gain > knowledge that Wormhole is used. > > Protocol > > --------- > > - Alice A [with tor identity A1 and A2] has a 5.5 bitcoin UTXO > - A sends 1 bitcoin to Bob B [with tor identity B1 and B2] > - Wasabi server W coordinates the zero link CoinJoin: > =C2=A0=C2=A0=C2=A0 -- Equal value denominations are 1, 2, 4, 8, 16, 3= 2 bitcoin > =C2=A0=C2=A0=C2=A0 -- Anonymity set for each denomination is 100 > =C2=A0=C2=A0=C2=A0 -- Wormhole protocol is opt-in for some unknown nu= mber of peers > > > ### Input Registration > > - A generates an input proof of the 5.5 bitcoin UTXO > - A generates one `blindedOutput` with 4 bitcoin, and one > `changeAddress` with 0.5 bitcoin > > - B generates one `blindedOutput` with 1 bitcoin & he sends this > to A > > - A1 sends all of the above to W > - W verifies > =C2=A0=C2=A0=C2=A0 -- `maxInputsPerRegistraion` not reached > =C2=A0=C2=A0=C2=A0 -- `maxInputPerTx` not reached > =C2=A0=C2=A0=C2=A0 -- `blindedOutput` never registered > =C2=A0=C2=A0=C2=A0 -- each input > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- not already registered= for this round > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- UTXO not banned > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- proof > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- unspent > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- if coinbase, confirmat= ions > 100 > > > --- must be SegWit v0 [maybe also v1] bech32 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 --- is from unconfirmed CoinJo= in tx > > - W generates `uniqueID` > - W signs all `blindedOutput` > - W sends `uniqueID` & `signedBlindedOutput` to A1 > > ### Connection Confirmation > > - Starts when `timeSinceLastRound > maxWaitPeriod` OR > > `registeredInputs > requiredInputs` > > - A abandons if confirmation is refused > - A1 sends `uniqueID` W > - W verifies `uniqueID`, and calculates `roundHash =3D hash of all regi= stered inputs` > - W sends `roundHash` to A1 and B1 > > ### Output Registration > > - Starts when `confirmedUniquelds =3D=3D registeredInputs` OR `timeout = && confirmedUniquelds >=3D requiredInputs` > > - A sends `signedBlindedOuput_B` to B > > - Both A and B unblind the `signedBlindedOutput` > > - Both A2 and B2 send `output` & `signature` & `roundHash` > DIRECTLY to W - they do NOT send to each other > > - W verifies `roundHash` & `signature` & `Output` > > > ### Signing > > - Starts when `outputs =3D=3D registeredInputs` OR `timeout` [go signin= g, > even if there are missing outputs to identify them and ban them as th= ey > won't sign] > > - W builds CoinJoin transaction `CJTX` and sends to A1 and B1 > and all other peers > > - A and B verify `roundHash` [by calculating hash of all `txInputs`] > - B verifies that his output is included & signs a commitment > message m where he acknowledges that it is included & sends m to A > > - A verifies that her input and her outputs are included & verifies > B signature of m [assumption that Bob provides a correct address, as > with any transaction] & signs `CJTX` > > - A1 sends `uniqueID` & `signature, inputIndex` to W - A does > NOT send this to B > > - W verifies `uniqueID` & each signature against > `inputs[uniqueID][index]` > > > ### Broadcast TX > > - Starts when `signatures =3D=3D registeredInputs` > - W broadcasts signed transaction to the Bitcoin peer-to-peer network > > > Result > > ------- > > - A has one 4 bitcoin UTXO with 100 anonset & one 0.5 bitcoin > UTXO with 1 anonset > > - B has one 1 bitcoin UTXO with 100 anonset > - W knows the input and change of A & W does not know who > controls which equal value output & W does not know that B has no inp= uts > > - A does not know the output of B, there are 99 possible coins. > - B does not know the input and outputs of A, there are 100+ > possible coins. > > > Communication > > -------------- > > This is an interactive protocol with several rounds of communication, > thus all A & B & W need to be online. The communication between > A and B can be done on any suitably private channel, including but > not limited to tor, QR codes, SD cards, or carrier pigeon. The > communication between A / B & W will be the same as used for the > regular zero link implementation, most likely tor. > > Privacy > > -------- > > The equal value zero link outputs from A and B have the anonymity > set of the total number of equal value zero link outputs in the same > transaction. Wormhole breaks the assumption that zero link is a > consolidation within the same wallet [`Input Alice =3D Output Alice + Fee= `], in a way that neither A nor B can spy on each other. W does > not know if any peer is using Wormhole, none or one or all peers > might use it. > > Questions > > ---------- > > I am not sure what information is broadcasted from W to all peers in > the round, and if Bob can get this information without revealing that he > is the receiver of a Wormhole transaction [he has no input proof]. What > information can be send from W to B directly will determine the > trust level of A passing honest messages. > > Wormhole might be used in conjunction with Pay toEndpoint orKnapsack > so that A can send a specific amount to B, with part being the equal > value zero link output, and part the P2EP change, or Knapsack > sub-transaction. > > Atomic coinswapswith Schnorr adaptor signatures might be integrated, so A= input in > `CJTX1` "pays" B output in `CJTX2`, but this might require B to know > the signature [and thus the input] of A. > > -------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ---------------------------------------------------------------------------= ------------------------------------------------------------- > > This email was signed with my PGP key E900 5F66 A86B B816 BD7D 967EBEDC D= 95C 42AC3C57Please verify it on my website, > github and on the bottom > right corner of my videos.