From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 69E12C0051 for ; Wed, 16 Sep 2020 01:04:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 4C293229D4 for ; Wed, 16 Sep 2020 01:04:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sGz09-RXX8A for ; Wed, 16 Sep 2020 01:04:35 +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 silver.osuosl.org (Postfix) with ESMTPS id B85FF204D9 for ; Wed, 16 Sep 2020 01:04:35 +0000 (UTC) Date: Wed, 16 Sep 2020 01:04:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1600218272; bh=VjVtRom+tE8dMXF+vY6bxJra4A23vPxWUmsugPz1P5k=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; b=GkgRt4deiOjWpuDFxY4qMM5nl8ue86Ue5bd3tYIUQI12WOnY3jr9b+ErlZ19MEnNZ JwhL/KqVHnfeLFsFL/1xvkrSvWJ4lyJ21BHAMQAOENJfSlLQKV/ckcSx+ZWZf0dTcA VE4qX67lMKwKlzQTQIOwZK4zZrrF3dHIFli+sfDI= To: Tom Trevethan , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <2Abk4Gqv5hJyGtA8Gg1WCP5RNuyUFkmRn1uUKp_mdUaXrRTz4SDBTPi0MGU7D5jj36VSzrqsIiO5lMR4gGRApRX2jyp8vXDeHBnFt-6ca-g=@protonmail.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] Statechain coinswap: assigning blame for failure in a two-stage transfer protocol. 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: Wed, 16 Sep 2020 01:04:38 -0000 Good morning Tom, > Here is a high-level description of how this blinding can operate - with = the aim that the conductor does learn how the ownership of individual coins= has changed. > For example, imagine 4 individuals (A,B,C and D) who own equal value stat= ecoins utxo1, utxo2, utxo3 and utxo4 respectively. They want to swap owners= hip privately, trusting the conductor/SCE to enforce atomicity. In other wo= rds, the conductor will randomly assign each statecoin to one of the owners= (the mix), but will not be able to gain knowledge of that assignment. > 1. A,B,C and D signal their participation by signing the swap_token (whic= h has details of the swap) with the proof-key of their input coin. (A state= coin address is formed of a concatenation of the proof key and backup addre= ss). > 2. Each of A,B,C and D then generate a new statecoin address (where they = what to receive the swapped coin), which they blind (encrypt) and sign with= the proof key of their input coin: add1, add2, add3 and add4 and send to t= he conductor. > 3. The conductor authenticates each signature and then signs each payload= (i.e. the blinded destination addresses) with a blinded signature scheme a= nd returns these signatures to A,B,C and D. > 4. Each of A,B,C and D then reconnects over TOR with a new identity. > 5. Each of A,B,C and D then send their unblinded destination address with= the conductor signature to the conductor (the conductor now knows that the= se 4 addresses belong to A,B,C and D, but not which ones map to each input.= ) > 6. The conductor randomly assigns each address to one of utxo1, utxo2, ut= xo3 and utxo4 (e.g. utxo1:add3, utxo2:add1, utxo3:add4 and utxo4:add2) and = requests each participant to initiate the transfer to the given address. > 7. Each participant then finalises each transfer - if any transfer fails = (due to a participant disappearing or acting maliciously) then all transfer= s are reverted - here atomicity is guaranteed by the SCE. Okay, I suppose this is much too high-level a view, and I have no idea what= you mean by "statecoin" exactly. Let me try to fill in the details and correct me if I am wrong okay? I imagine that the `add1` etc. are implemented as 2-of-2 between the purpor= ted owner and the tr\*sted signing module. The owner of that address can easily create this knowing only the pubkey of= the tr\*sted signing module. The initial `utxo1`... are also in similar 2-of-2s. (they cannot be unilateral control, since then a participant can broadcast = a replacement transaction, even without RBF, almost directly to miners.) So when the coordinator talks to Alice, who owns `utxo1` and destination `a= ddr1`, it provides partially-signed transactions of `utxo#:addr#`. Alice then checks that its `addr1` is on one of those transactions, with th= e correct amount, then provides a signature for the `utxo1:addr#` transacti= on. However, then the coordinator, who happens to be in cahoots with Bob, Charl= ie, and Dave, simply broadcasts that transaction without soliciting the `ut= xo#:addr1` transaction. So it seems to me that this requires tr\*st that the coordinator is not goi= ng to collude with other participants. This is strictly worse than say Wasabi, where the coordinator colluding wit= h other participants only allows the coordinator to break privacy, not outr= ight steal funds. It seems to me that the trust-minimized CoinSwap plan by belcher_ is superi= or to this, with reduced scope for theft. The plan by belcher_ is potentially compatible with using watchtowers that = can be used for both CoinSwap and Lightning as well (if we design it well) = with the watchtower potentially not even learning whether it is watching a = CoinSwap or a Lightning channel. Though of course I could be misunderstanding the scheme itself. Is my understanding correct? Regards, ZmnSCPxj