Date: Thu, 03 Sep 2020 09:45:53 +0000
To: Chris Belcher <belcher@riseup.net>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <bqFuDDJpKgkg1DaEQ9p14lxD__yLcJmklNqSK3jhmHxjxmhRYgHGJnUDDWMKfkZTJu-VqhFkVX4P2w6ipYuHpJ6umPmwe44PQs3HoNELEg4=@protonmail.com>
In-Reply-To: <0ac3fecb-012b-e210-55bb-36809682634a@riseup.net>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
 <CALZpt+GxKDEDAGUH3Jb3rcZdh_jy_depLRE5KzGTpkZOLVH+QA@mail.gmail.com>
 <VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com>
 <0ac3fecb-012b-e210-55bb-36809682634a@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] Detailed protocol design for routed
	multi-transaction CoinSwap
Precedence: list

Good morning Chris,

> A big downside is that it really ruins the property of allowing coins to
> remain unspent indefinitely. That has privacy implications: if a coin
> remains unspent for longer than 2 weeks (or another short locktime) then
> for sure the transaction was not a CoinSwap, and so the anonymity set of
> the CoinSwap system would be far smaller For this reason I'm pretty
> desperate to solve the vulnerability without losing the coins remaining
> unspent indefinitely feature.

Ah, right.... accept no small privacy leaks!

>
> We need to solve the vulnerability you found, which I'll call the
> riskless theft attempt problem. So what do you think of this solution:
>
> =3D=3D Building block 1: A, B and C having different contract txes =3D=3D
>
> In the original proposal each CoinSwap peer has the same contract
> transaction, and either side can broadcast it whenever they like. This
> actually isn't necessary. We can have a contract transaction
> fully-signed but only known to one peer, with a possibly-different
> transaction transaction fully-signed and only known to the other peer.
>
> Obviously for the CoinSwap to work both contract transactions must have
> the same hash-time-locked contract, but they can differ in other ways.
>
> =3D=3D Building block 2: collateral payments =3D=3D
>
> The riskless theft attempt problem happens because the previous owner of
> the coins knows the fully-signed contract transaction and can broadcast
> it at no cost to themselves. So to solve the problem we add a cost.
>
> There is a 2of2 multisig made up of Bob's and Charlie's keys. The
> associated contract transaction known to Bob must now also have one of
> Bob's single-sig inputs. The outputs are such that some of the money
> from Bob's input now ends up in the HTLC output. The result is that
> after the CoinSwap if Bob broadcasts his contract transaction but fails
> to take the money from the HTLC output, then Bob will have lost money.

Just to be clear:

* B is the one who originally funded the HTLC, and owns the timelock.
* C is the one who will accept the HTLC, and owns the hashlock.

> I'm calling this idea collateral payments, by analogy with collateral
> used for loans. A collateral is someone valuable a debtor puts on the
> table, and if they don't repay the loan then they lose the collateral
> (presumably the creditor sells it to repay the loan).
>
> Here is a diagram of the contract transaction known to Bob:
>
> multisig (B+C) [I btc]---> (B+timelock_B OR C+hash) [I+K-M~ btc]
>
>     collateral(B)  [J btc]     (Bob)                    [J-K btc]
>
>
> where:
> I =3D CoinSwap amount
> J =3D Value of Bob's collateral input
> K =3D Value that Bob loses if he broadcasts his contract tx but doesnt
> get the money
> M~ =3D miner fee (random variable)
>
> The value K is something that can be set by the protocol, and made high
> enough so that doing a riskless theft attempt is not worth it. Probably
> the value of K will be quite small because the odds of a riskless
> payment attempt succeeding is very small (assuming the makers all use
> multiple redundant watchtowers). Mostly likely K will be smaller than
> M~, so if the collateral is lost to Bob then the miners will the ones to
> gain, rather than Charlie.

This seems a great solution!

Since B is the one offering HTLCs, the taker of a CoinSwap sequence can be =
B as well.
This means, the taker has to have *some* collateral input, of at least valu=
e K, that it cannot swap (because if it tried to swap that amount, it would=
 be unable to provide a collateral as well).

How much does C need to know about the B collateralized contract transactio=
n?
At the minimum, it has to know the output pays out to the correct contract,=
 so it seems to me it has to know the entire B collateralized contract tran=
saction, meaning it learns another input of B ("collateral(B)") that is not=
 otherwise involved in the CoinSwap.
This is important, again, if B is a taker, as it means an unrelated input o=
f B is now learned by C as having the same ownership as B.

A fresh maker that is given its starting funds in a single UTXO needs to sp=
lit up its funds to make at least one collateral input it can use.

Of note is that the B output also serves as a point for CPFPing this transa=
ction, thus only one version of the B collateralized contract transaction n=
eeds to be made, and the B collateralized contract transaction can be at or=
 close to the minimum relay feerate and later CPFPed.

In terms of onchain analysis heuristics, it looks like the B output is chan=
ge, while the B+C contract output is the send-out, I think, for most cases.
In case of a protocol abort, this heuristic is misled, since both outputs b=
ecome owned by B due to the protocol abort.
In case of a protocol completion, this heuristic is accurate, since the B+C=
 contract output will be claimed by C, but we do not expect this transactio=
n to be confirmed onchain after protocol completion anyway (it effectively =
donates K to C or miners), so this is fine.

> The other contract transaction, known only to Charlie, does not contain
> a collateral input or collateral value (K), because Charlie can't do a
> riskless theft attempt to Bob.

Because it has a single output only, the C contract transaction needs to ha=
ve RBFed versions.

> If Bob ever spends his collateral input in another transaction, then his
> contract transaction will become invalid. However Bob will only be
> harming himself, so he'll never do this.

At least until B gets its own incoming funds in the swap, at which point th=
e collateral input can be used for other purposes (and effectively "release=
s" the lease of B on that output).

Since C knows the collateral input (it has to, in order to verify the B col=
lateralized contract transaction is correct), it can monitor the collateral=
 input for spendedness, and stop watching for the B collateralized contract=
 transaction in its watchtower(s) if the collateral input is deeply spent.
The B collateralized contract transaction is invalidated if the collateral =
input is spent, and then only C can spend the funding outpoint at that poin=
t, so it can remove that from the watchtower.
This can be significant if C is using a for-pay watchtower that supports de=
letion of watches, which I believe is planned for watchtowers as well, and =
reduces the operating cost of C.


Regards,
ZmnSCPxj