Date: Thu, 04 Jun 2020 16:37:53 +0000
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <mW43gzUcbr5HziCafjw_a-yZb3sdNl7SrsUTBpQFnZzVwRgpSVFUZzg4u6ORXzs9fc8KeWbdpGuCPnrA3iYjdmc1O_E84hyL-Qsr3cvqVGY=@protonmail.com>
In-Reply-To: <0U3wfLU9DpPZ7pwMOAr4xned-mOcHrpje4aLLiXZOt1qGuMhhyh36kAYJMEyv9bNjH2pMEzkkKK2rkAt9BD2pv_XknjdeqxEkEFsfSr4JAc=@protonmail.com>
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>
 <0U3wfLU9DpPZ7pwMOAr4xned-mOcHrpje4aLLiXZOt1qGuMhhyh36kAYJMEyv9bNjH2pMEzkkKK2rkAt9BD2pv_XknjdeqxEkEFsfSr4JAc=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Design for a CoinSwap implementation for
	massively improving Bitcoin privacy and fungibility
Precedence: list

Good morning yet again Chris,

> > For the avoidance of theft, it is probably better for Bob to wait for A=
lice-side funding tx to confirm, probably deeply because reorgs suck.

I realized that the *other* improvement I proposed in the [CoinSwapCS issue=
](https://github.com/AdamISZ/CoinSwapCS/issues/53) would help with this.
Specifically, `nLockTime`-protected Backouts.

Suppose we have an S6 route as so, with Alice as taker and Bob1 and Bob2 as=
 makers:

    Alice -> Bob1 -> Bob2 -> Alice

We assume here that Bob1 and Bob2 directly talk to Alice and that if Bob1 w=
ants to talk to Bob2 it is done via Alice, so in the below if we say "Bob1 =
sends to Bob2" we imply that this is done via Alice.

1.  Alice solicits fresh pubkeys from Bob1 and Bob2.
2.  Alice gives timeouts L1 and L2 to Bob1, and L2 and L3 to Bob2, such tha=
t L1 > L2 > L3, as well as negotiated amount, fees, etc.
3.  Alice creates (but does NOT sign) a funding tx paying to Alice && Bob1 =
and gives the txid to Bob1.
4.  Bob1 creates and signs a tx spending from the Alice funding tx and payi=
ng to Alice, with `nLockTime =3D L1`, and gives the signature to Alice.
5.  Bob1 creates (but does NOT sign) a funding tx paying to Bob1 && Bob2 an=
d gives the txid to Bob2.
6.  Bob2 creates and signs a tx spending from the Bob1 funding tx and payin=
g to Bob1, with `nLockTime =3D L2`, and gives the signature to Bob1.
7.  Bob2 creates (but does NOT sign) a funding tx paying to Bob2 && Alice a=
nd gives the txid to Alice.
8.  Alice creates and signs a tx spending from the Bob2 funding tx and payi=
ng to Bob2, with `nLockTime =3D L3`, and gives the signature to Bob2.
9.  Alice signals everyone to sign their respecting funding txes and broadc=
ast them.

The rest of the CoinSwap protocol executes as normal once the funding txes =
are deeply confirmed.
The only thing that Bob1 (resp. Bob2) needs to wait for is that the signatu=
res for the incoming HTLC / PTLC have been received before forwarding to th=
e next hop.
This allows all funding txes to be confirmed in the same block, or even in =
some suitable random order (by having Alice send the signal out at differen=
t times/blocks to different makers).

The `nLockTime`d backout transactions are sufficient to allow everyone to r=
ecover their funds unilaterally in case one of the other funding txes do no=
t confirm.

A similar technique can be done for SAS as well, but this removes the lack =
of encumbrance in the LTC-side output of SAS, which removes the advantage o=
f having an otherwise unencumbered output.

In effect, the above creates Spilman unidirectional payment channels along =
the route, bringing the fiddly timing details offchain where it is less vis=
ible to observers.

--

However, note that this still allows a form of griefing attack.
Basically, Alice can induce Bob1 and Bob2 to lock their funds for some time=
, by completing the above ritual, but not signing and broadcasting its own =
funding tx.
Bob1 and Bob2 will have been induced to lock their funds for L2 and L3, res=
pectively, while Alice only has to RBF away its own funding tx.

Alice might do this if it is actually another maker and it wants to take ou=
t its competitors Bob1 and Bob2, reducing their available liquidity for a t=
ime and cornering the SwapMarket.


This can be mitigated by replacing step 9 with:

9.  Alice gives its signed funding tx to Bob1.
10.  Bob1 gives its signed funding tx to Bob2.
11.  Bob2 gives its signed funding tx to Alice.
12.  Alice signals everyone to broadcast their funding txes.

Then Bob1 (resp. Bob2) can monitor the mempool/blockchain and check as well=
 if its outgoing funding tx has been broadcast/confirmed, and if so broadca=
st the incoming funding tx.
Or better, if Bob1 (resp. Bob2) does not receive the Alice signal fast enou=
gh, it will broadcast its incoming funding tx anyway.

This is only a mitigation: Alice could have pre-prepared a replacement to t=
he funding tx that it broadcasts near miners just before it signals Bob1 an=
d Bob2 to broadcast all transactions.

For full protection against griefing attacks, Bob1 (resp. Bob2) have to wai=
t for the incoming funding tx to be confirmed deeply before broadcasting it=
s outgoing funding tx as well.

Regards,
ZmnSCPxj