From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3C41BC0174 for ; Fri, 24 Jan 2020 10:12:03 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 391168855C for ; Fri, 24 Jan 2020 10:12:03 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSUq2Pys7KnJ for ; Fri, 24 Jan 2020 10:12:01 +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 hemlock.osuosl.org (Postfix) with ESMTPS id 3060788552 for ; Fri, 24 Jan 2020 10:12:00 +0000 (UTC) Date: Fri, 24 Jan 2020 10:11:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1579860718; bh=BQftjUmz4geZOLXi9gUakcbrJ3KfdlnTBcOne2pdKdc=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=sTHXMihpS1vdtOk9CoV5WQOem5noIUh/4Ps0FM5J6FY44B8/qFi0LXdHETof7S5ai HgArb9hBxHr4596uVQpFCMoISH4D58BPFx/8VW5Qg9Q82HDxyUsX5vb9KKqKVpFbFQ xNgUYKRu5EGlhCSSqDaIwjr7IcwxPH9C/orpOsuE= To: ZmnSCPxj , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: 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] 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: Fri, 24 Jan 2020 10:12:03 -0000 Good morning list, A few more things to consider: Probably the correct order for this would be for the payer to instantiate t= he Scriptless Script payment to the payee first, then the payee instantiati= ng the change back to the payer. By use of some kind of Scriptless Script, it is possible to as well impleme= nt a proof-of-payment system similar to Lightning, which might be useful to= prove to an auditor that a payment has been made (without being forced to = reveal this to anyone other than the auditor). Both the payer and payee can generate a scalar. The payee provides a signed invoice (can reuse the Lightning BOLT11 invoice= format) attesting the payment point that needs to be paid, the payment poi= nt being the generator point times te payee scalar. The payer then instantiates the Scriptless Script PTLC, requiring knowledge= of the payee scalar + the payer scalar from the payee. Then the payee instantiates the change Scriptless Script PTLC, requiring kn= owledge of the payer scalar from the payer. Then the payee claims the change, which allows the payer to claim the full = transfer while revealing the payee scalar as a proof-of-payment. Regards, ZmnSCPxj > Good morning list, > > On a recent post on lightning-dev, I brought up the possibility of using = a circular self-payment to hide the actual direction of payment from third-= party snooping nodes. > Basically, instead of paying the amount to the destination, we can have a= n atomic mechanism by which the source pays a larger-than-amount payment to= the destination and the destination returns the difference instead. > > As the mechanisms on Lightning are also implementable directly on the blo= ckchain, I observe as well that we can use a similar mechanism based on Coi= nSwap 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 greate= r than the payment amount. > - Create a single transaction that consumes those inputs and outputs th= e amount to the destination and any remainder to a new address we control. > > However, we can observe as well that transactions and transaction out= puts can 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 o= r greater than the payment amount. > - Sender reveals the sum to destination. > - Destination locates some of its owned UTXO(s) that total an amount eq= ual or greater than the difference (change) of the sender total minus the p= ayment 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 p= ayment amount (change). > - Sender and destination execute the CoinSwap and complete the payment = protocol. > > 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 b= e a likely self-payment. > - A transaction with two outputs. > - This is the CoinSwap funding transaction that was offered by the = destination 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 = destination to the sender, reversing the apparent direction of payment and = obscuring 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 an= d sender respectively. > > The above is an active misleading of chain analysis. > > This is even possible today with 2p-ECDSA to make it use P2WPKH with = Scriptless Script. > > Against the above flow I must caution: > > - This involves more transactions than Payjoin, thus more expensive in = blockspace. > - The protocol can be aborted by one participant, which will lead to sp= ending onchain fees to back out of the protocol, unlike Payjoin which is at= omic with paying onchain fees. > - As I point out elsewhere, CoinSwap overhead approaches the overhead o= f setting up a temporary Lightning Network channel, thus it might actually = be better to implement all CoinSwap protocols over Lightning instead. > > Regards, > ZmnSCPxj > > > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev