Date: Wed, 16 Sep 2020 01:04:29 +0000
To: Tom Trevethan <tom@commerceblock.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <2Abk4Gqv5hJyGtA8Gg1WCP5RNuyUFkmRn1uUKp_mdUaXrRTz4SDBTPi0MGU7D5jj36VSzrqsIiO5lMR4gGRApRX2jyp8vXDeHBnFt-6ca-g=@protonmail.com>
In-Reply-To: <CAJvkSseOx8mwYowLEnfKVEUuM5xsiYkbLdAvtaYxPpu4jY9pCg@mail.gmail.com>
References: <CAJvkSseOx8mwYowLEnfKVEUuM5xsiYkbLdAvtaYxPpu4jY9pCg@mail.gmail.com>
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.
Precedence: list

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