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. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev