From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Max Hillebrand <max@towardsliberty•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] ***UNCHECKED*** Wormhole: Sending and receiving bitcoin anonymously
Date: Thu, 16 Jan 2020 02:11:44 +0000 [thread overview]
Message-ID: <T410nnBIHG8Gr2T8ir9OLa9e2SPi2EagjGntUByw-u1ELuJGU7Hh5cGHoBRlYJKbaXXbchECb-a-1HXHrQlx7wGoN1YeNocpXlnkiveddkc=@protonmail.com> (raw)
In-Reply-To: <96dc101e-30ba-9833-7ba0-41eda910d3cc@towardsliberty.com>
Good morning Max,
It seems similar very closely to TumbleBit, at least in the overall protocol.
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 thoroughcontemplation and minor tweaks, I would now like to request your
> feedback on the conceptual design and possible implementation.
>
> Cheers
> Max
>
> Wormhole
>
> =========
>
> 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, utilizinga 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:
> -- Equal value denominations are 1, 2, 4, 8, 16, 32 bitcoin
> -- Anonymity set for each denomination is 100
> -- Wormhole protocol is opt-in for some unknown number 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
> -- `maxInputsPerRegistraion` not reached
> -- `maxInputPerTx` not reached
> -- `blindedOutput` never registered
> -- each input
> --- not already registered for this round
> --- UTXO not banned
> --- proof
> --- unspent
> --- if coinbase, confirmations > 100
>
>
> --- must be SegWit v0 [maybe also v1] bech32
> --- is from unconfirmed CoinJoin 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 = hash of all registered inputs`
> - W sends `roundHash` to A1 and B1
>
> ### Output Registration
>
> - Starts when `confirmedUniquelds == registeredInputs` OR `timeout && confirmedUniquelds >= 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 == registeredInputs` OR `timeout` [go signing,
> even if there are missing outputs to identify them and ban them as they
> 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 == 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 inputs
>
> - 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 = 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 D95C 42AC3C57Please verify it on my website,
> github and on the bottom
> right corner of my videos.
prev parent reply other threads:[~2020-01-16 2:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-15 21:23 Max Hillebrand
2020-01-16 2:11 ` ZmnSCPxj [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='T410nnBIHG8Gr2T8ir9OLa9e2SPi2EagjGntUByw-u1ELuJGU7Hh5cGHoBRlYJKbaXXbchECb-a-1HXHrQlx7wGoN1YeNocpXlnkiveddkc=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=max@towardsliberty$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox