From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Chris Belcher <belcher@riseup•net>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Date: Thu, 03 Sep 2020 09:45:53 +0000 [thread overview]
Message-ID: <bqFuDDJpKgkg1DaEQ9p14lxD__yLcJmklNqSK3jhmHxjxmhRYgHGJnUDDWMKfkZTJu-VqhFkVX4P2w6ipYuHpJ6umPmwe44PQs3HoNELEg4=@protonmail.com> (raw)
In-Reply-To: <0ac3fecb-012b-e210-55bb-36809682634a@riseup.net>
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:
>
> == Building block 1: A, B and C having different contract txes ==
>
> 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.
>
> == Building block 2: collateral payments ==
>
> 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 = CoinSwap amount
> J = Value of Bob's collateral input
> K = Value that Bob loses if he broadcasts his contract tx but doesnt
> get the money
> M~ = 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 value 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 transaction?
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 transaction, 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 of 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 split 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 transaction, thus only one version of the B collateralized contract transaction needs 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 change, 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 become 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 transaction 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 have 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 the collateral input can be used for other purposes (and effectively "releases" the lease of B on that output).
Since C knows the collateral input (it has to, in order to verify the B collateralized 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 point, so it can remove that from the watchtower.
This can be significant if C is using a for-pay watchtower that supports deletion of watches, which I believe is planned for watchtowers as well, and reduces the operating cost of C.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2020-09-03 9:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-11 12:05 Chris Belcher
2020-08-20 11:17 ` ZmnSCPxj
2020-08-20 15:28 ` Nadav Kohen
2020-08-20 21:38 ` ZmnSCPxj
2020-08-20 22:37 ` Chris Belcher
2020-08-20 22:15 ` Chris Belcher
2020-08-21 4:20 ` ZmnSCPxj
2020-08-21 9:47 ` Chris Belcher
2020-08-22 1:09 ` ZmnSCPxj
2020-08-24 19:30 ` Antoine Riard
2020-08-25 3:16 ` ZmnSCPxj
2020-09-03 9:00 ` Chris Belcher
2020-09-03 9:45 ` ZmnSCPxj [this message]
2020-09-03 10:50 ` Chris Belcher
2020-09-03 23:39 ` ZmnSCPxj
2020-09-05 2:45 ` ZmnSCPxj
2020-09-05 1:10 ` Antoine Riard
2020-09-05 2:29 ` ZmnSCPxj
2020-08-29 22:03 ` Chris Belcher
2020-08-30 13:38 ` ZmnSCPxj
2020-09-05 1:07 ` Antoine Riard
2020-09-06 3:06 ` seid Mohammed
2020-10-03 10:36 ` [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap appendium Chris Belcher
2020-10-03 13:31 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='bqFuDDJpKgkg1DaEQ9p14lxD__yLcJmklNqSK3jhmHxjxmhRYgHGJnUDDWMKfkZTJu-VqhFkVX4P2w6ipYuHpJ6umPmwe44PQs3HoNELEg4=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=belcher@riseup$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox