Date: Sat, 06 Jun 2020 01:40:18 +0000
To: Chris Belcher <belcher@riseup.net>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <Sy14DpcFGdAYL95d7e6tfkOe87oY53tJReo9CYvPT5J3Gb85AqedMheq1NbfVKUXZtZrwZqwVV4wSztikgWBAgNfTh8J5h5gXC6HDMxvsNg=@protonmail.com>
In-Reply-To: <e724b4c5-9efd-66c4-163b-492f17cafd7d@riseup.net>
References: <82d90d57-ad07-fc7d-4aca-2b227ac2068d@riseup.net>
 <CAPv7TjY9h8n-nK_CPiYCWYDcbXpT1gfRMQDgf9VUkcR532rxOw@mail.gmail.com>
 <VxL93WE7bDrK1riquTWTTEgJj9mDQ4W5CuhOgdnnDPeidw2ho6evVh4cLZLz0jEYMqejaD1tiLULVTXkNRbI5A7wSwV49qSwnXcTWCDJ96E=@protonmail.com>
 <cbf78f63-cf8c-c5d8-06ea-afc79aabc23c@riseup.net>
 <5LiZqpFxklAAbGFiiAE3ijRbIteODXKcHrXvGJ-qabgQj5hG8beFtHNbVZ-XUxETVwduJYz94UYuJGAPxBrbGeZpSClUtXYsPJBABfr03KM=@protonmail.com>
 <e724b4c5-9efd-66c4-163b-492f17cafd7d@riseup.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for
	massively improving Bitcoin privacy and fungibility
Precedence: list

Good morning Chris,

> I think I'm having trouble understanding this, does it work like this:
>
> Say we're in the 2-party coinswap case (Alice and Bob)
>
> We have Alice's funding transaction:
> Alice UTXO ---> 2of2 multisig (Alice+Bob)
>
> And we have the regular contract transaction
> 2of2 multisig (Alice+Bob) ---> Alice+timelock1 OR Bob+hashlock
>
> And you propose a second pre-signed transaction?
> 2of2 multisig (Alice+Bob) ---> Bob+timelock2

No, it is:

2of2 multisig (Alice+Bob) --(nLockTime=3Dlocktime1)-> Alice

The timelock is  imposed as a `nLockTime`, not as an `OP_CLTV` (so not in t=
he output of the tx, but part of the tx), and the backout returns the funds=
 to Alice, not sends it to Bob.
This transaction is created *before* the contract transaction.

The order is:

* Create (but not sign) Alice funding tx (Alice --> Alice+Bob).
* Create and sign Alice backout transaction (Alice+Bob -(nLockTime=3Dlockti=
me1)-> Alice).
* Create (but not sign) Bob funding tx (Bob --> Alice+Bob+sharedSecret).
* Create and sign Bob backout transaction (Alice+Bob+sharedSecret -(nLockti=
me=3Dlocktime2)-> Bob) where timelock2 < timelock1.
* Sign and broadcast funding txes.
  * At this point, even if Bob funding tx is confirmed but Alice funding tx=
 is not, Bob can recover funds with the backout, but Alice cannot steal the=
 funds (since there is no hashlock branch at this point).
* When Alice funding tx is confirmed, create and sign contract transaction =
(Alice+Bob --> Alice+timelock1 OR Bob+hashlock).
* When Bob funding tx is confirmed and Bob has received the Alice contract =
transaction, create and sign Bob contract transaction (Alice+Bob+sharedSecr=
et --> Bob+timelock2 OR Alice+hashlock).
* Continue as normal.

In effect, the backout transaction creates a temporary Spilman unidirection=
al time-bound channel.
We just reuse the same timelock on the HTLC we expect to instantiate, as th=
e time bound of the Spilman channel; the timelock exists anyway, we might a=
s well reuse it for the Spilman.

Creation of the contract tx invalidates the backout tx (the backout tx is `=
nLockTime`d, the contract tx has no such encumbrance), but the backout allo=
ws Alice and Bob to fund their txes simultaneously without risk of race los=
s.
However, they do still have to wait for (deep) confirmation before signing =
contract transactions, and Bob has to wait for the incoming contract transa=
ction as well before it signs its outgoing contract transaction.

The protocol is trivially extendable with more than one Bob.

The insight basically is that we can split CoinSwap into a "channel establi=
shment" phase and "HTLC forwarding" phase followed by "HTLC resolution" and=
 "private key handover".
HTLC forwarding and HTLC resolution are "done offchain" in the channels, an=
d channel establishment can be done in any order, including reverse.

Indeed, the Spilman channel need not have the same timelock as the HTLC it =
will eventually host: it could have a shorter timelock, since the contract =
transaction has no `nLockTime` it can be instantiated (with loss of privacy=
 due to the nonstandard script) before the Spilman timeout.

Regards,
ZmnSCPxj