Date: Thu, 16 Jan 2020 02:11:44 +0000
To: Max Hillebrand <max@towardsliberty.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <T410nnBIHG8Gr2T8ir9OLa9e2SPi2EagjGntUByw-u1ELuJGU7Hh5cGHoBRlYJKbaXXbchECb-a-1HXHrQlx7wGoN1YeNocpXlnkiveddkc=@protonmail.com>
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
Precedence: list

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.