From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7AB1DC0174 for ; Tue, 21 Jan 2020 04:38:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 5C7CE8639E for ; Tue, 21 Jan 2020 04:38:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7iMvoPKu4gQF for ; Tue, 21 Jan 2020 04:38:18 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail4.protonmail.ch (mail4.protonmail.ch [185.70.40.27]) by whitealder.osuosl.org (Postfix) with ESMTPS id 42F5085E12 for ; Tue, 21 Jan 2020 04:38:18 +0000 (UTC) Date: Tue, 21 Jan 2020 04:38:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1579581495; bh=6EvGdGht5sIHI/qFP4+QvF5ckDovBdFJwJQavEGtiIY=; h=Date:To:From:Reply-To:Subject:Feedback-ID:From; b=iSdCjz9rIo900AcH90a2+l1LPOLQfojwNF0q6Sg93i5qRv4q3nrEiTraDSUv9aD5R gyLZ45xCS1+NClgWQ0RVLCkYIOhbrsq5G/op1CnIOwaq/NRblXmi4umDAnEBeoGd/5 aGfN8IZEvDaKTE3PUAKuBJf2ZGDOS3VrhNQapwjE= To: bitcoin-dev From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [bitcoin-dev] Payswap 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: Tue, 21 Jan 2020 04:38:20 -0000 Good morning list, [On a recent post on lightning-dev](https://lists.linuxfoundation.org/piper= mail/lightning-dev/2020-January/002431.html), I brought up the possibility = of using a circular self-payment to hide the actual direction of payment fr= om third-party snooping nodes. Basically, instead of paying the amount to the destination, we can have an = atomic mechanism by which the source pays a larger-than-amount payment to t= he destination and the destination returns the difference instead. As the mechanisms on Lightning are also implementable directly on the block= chain, I observe as well that we can use a similar mechanism based on CoinS= wap to mislead onchain analysis as well. The normal payment flow for a Bitoin payer is typically: * Locate some of its owned UTXO(s) that total an amount equal or greater th= an the payment amount. * Create a single transaction that consumes those inputs and outputs the am= ount to the destination and any remainder to a new address we control. However, we can observe as well that transactions and transaction outputs c= an be considered nodes and edges of a transaction graph, respectively. We can then consider the categorical dual of such a graph. Let me then present the Payswap payment flow: * Sender locates some of its owned UTXO(s) that total an amount equal or gr= eater than the payment amount. * Sender reveals the sum to destination. * Destination locates some of its owned UTXO(s) that total an amount equal = or greater than the difference (change) of the sender total minus the payme= nt amount. * Sender and destination set up an unequal CoinSwap: * Destination receives all the Sender coins. * Sender receives the difference between the Sender total and the payment= amount (change). * Sender and destination execute the CoinSwap and complete the payment prot= ocol. What appears onchain are: * A transaction with a single output. * This is the CoinSwap funding transaction that was offered by the sender= and claimed by the destination. * As a single-output transaction, this looks to chain analysis to be a li= kely self-payment. * A transaction with two outputs. * This is the CoinSwap funding transaction that was offered by the destin= ation and claimed by the sender. * The output that goes back to the destination looks like a change output= according to chain analysis. * The output that goes to the sender looks like a payment from the destin= ation to the sender, reversing the apparent direction of payment and obscur= ing the amount paid. * Two more transaction that complete the protocol, each spending one of the= above and moving the funds to unilateral control of the destination and se= nder respectively. The above is an active misleading of chain analysis. This is even possible today with 2p-ECDSA to make it use P2WPKH with Script= less Script. Against the above flow I must caution: * This involves more transactions than Payjoin, thus more expensive in bloc= kspace. * The protocol can be aborted by one participant, which will lead to spendi= ng onchain fees to back out of the protocol, unlike Payjoin which is atomic= with paying onchain fees. * As I [point out elsewhere](https://lists.linuxfoundation.org/pipermail/li= ghtning-dev/2019-October/002245.html), CoinSwap overhead approaches the ove= rhead of setting up a temporary Lightning Network channel, thus it might ac= tually be better to implement all CoinSwap protocols over Lightning instead= . Regards, ZmnSCPxj