From: Chris Belcher <belcher@riseup•net>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>,
Antoine Riard <antoine.riard@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
Date: Thu, 3 Sep 2020 10:00:00 +0100 [thread overview]
Message-ID: <0ac3fecb-012b-e210-55bb-36809682634a@riseup.net> (raw)
In-Reply-To: <VpsctPiYOV704v9wZiSROdRggid7uRv2mZVnCIILEPL4_VmwKhMVdNMPBj9XaF73-39jFLl3cq1o2tSk8h45tMuWM9W_i4_MQHKoJdYh9ew=@protonmail.com>
Hello ZmnSCPxj,
On 25/08/2020 04:16, ZmnSCPxj wrote:
>
> Good morning Antoine,
>
>
>> Note, I think this is independent of picking up either relative or absolute timelocks as what matters is the block delta between two links.
>
> I believe it is quite dependent on relative locktimes.
> Relative locktimes *require* a contract transaction to kick off the relative locktime period.
> On the other hand, with Scriptless Script (which we know how to do with 2p-ECDSA only, i.e. doable pre-Taproot), absolute locktimes do not need a contract transaction.
>
> With absolute locktimes + Scriptless SCript, in a single onchain PTLC, one participant holds a completely-signed timelock transaction while the other participant holds a completely-signed pointlock transaction.
> This can be arranged by having one side offer partial signatures for the transaction of the other, and once completing the signature, not sharing it with the other until we are ready to actually broadcast the transaction of our own volition.
> There is no transaction that both participants hold in completely-signed form.
>
> This should remove most of the shenanigans possible, and makes the 30xRBF safe for any range of fees.
> I think.
>
> Since for each PTLC a participant holds only its "own" transaction, it is possible for a participant to define its range of fees for the RBF versions of the transaction it owns, without negotiation with the other participant.
> Since the fee involved is deducted from its own transaction, each participant can define this range of RBFed fees and impose it on the partial signatures it gets from the other participant.
>
> --
>
> Private key turnover is still useful even in an absolute-timelock world.
>
> If we need to bump up the block delta between links, it might be impractical to have the total delta of a multi-hop swap be too long at the taker.
>
> As a concrete example, suppose A is a taker who wants to route over makers B and C.
> However, B and C require a CLTV delta of 1 week.
>
> If A wants to route "directly" A->B->C->A, then if something bad happens, it could be looking at having its funds locked for two weeks.
>
> To reduce this risk, A can instead first swap A->B->A, then when that completes, A->C->A.
> This limits its funding lockup to 1 week.
>
> Private key turnover is useful since as soon as the A->B->A swap completes, it can directly fund the A->C->A swap from the B-side funding transaction of the A->B->A swap.
>
> | A->B->A | A->C->A |
> : : :
> A -:->funding A&B--> B : :
> : : :
> B -:->funding A&B -----:--> funding A&C --> C :
> : : :
> : :C-> funding A&C ------:-> to-cold A -->
> : : :
>
> This increases the number of transactions by 1 per swap beyond the first, compared to a direct routing A->B->C->A, but this may be worth it for A if the timelocks involved are too big for A.
>
> With 2p-ECDSA, a funding A&C looks exactly the same as a to-cold A, so B is unable to reliably determine if it is the last hop in the route.
>
> Without private key turnover, A would have:
>
> **NO** private key turnover!
>
> | A->B->A | A->C->A |
> : : :
> A -:->funding A&B--> B : :
> : : :
> B -:->funding A&B -----:--> claim A -> funding A&C --> C :
> : : :
> : : C-> funding A&C ------:-> to-cold A -->
> : : :
>
> So if timelock-deltas are possibly-high (to reduce the probability of the MAD-HTLC argument, and other attacks, succeeding), takers might prefer to route by completing one swap first before starting the next one, and private key turnover is useful by reducing blockspace required by each hop.
>
> For reference, this is how it looks like with a single A->B->C->A swap with private key turnover:
>
> | A->B->C->A |
> : :
> A -:->funding A&B--> B :
> : :
> B -:->funding B&C -> C :
> : :
> C -:->funding A&C -----:-> to-cold A -->
> : :
>
> This is still smaller than in the A->B->A, A->C->A with private key turnover, by one funding tx per hop.
> However, A risks a much higher timelock (twice the timelock).
> Thus, A might prefer a lower timelock in exchange for paying for an additional transaction.
>
> Regards,
> ZmnSCPxj
>
Separating the timelock and hashlock cases into two separate
transactions is a nice way to solve many of these problems.
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.
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.
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.
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.
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.
I think this might be a fruitful idea, and soon I'll modify my earlier
detailed design to include it, and see if it can be made to work with no
weird edge cases or attacks.
=== Appendix: Brief historical note about separate contract txes ===
Separating hash- and time-lock branches into different transactions as
in ZmnSCPxj's design is actually very similar to the way the original
2013 CoinSwap design worked:
https://bitcointalk.org/index.php?topic=321228.0
The timelock branch was a transaction locked with nLockTime. And the
hashlock branch is another transaction spending to an output requiring
Carol's public key + hash preimage.
However Adam Gibson in 2017 found a vulnerability to this:
https://github.com/AdamISZ/CoinSwapCS/blob/master/docs/coinswap_tweak.md
The vulnerability is that even though Carol doesn't know the hash
preimage, she can still broadcast the hashlock transaction, which sends
the coins _into_ the hashlock contract, and that invalidates Alice's
timelock transaction. Carol is the only one who can spend the coins but
she doesn't know the hash preimage. The protocol then degenerates to the
MAD (mutually assured destruction) case because the coins are locked
forever.
Adam Gibson's fix was to include the hashlock and timelock branches into
the same transaction known to both peers, which is exactly the design I
used and for which all these vulnerabilities were found.
I realize now there is another way to solve the vulnerability, which is
to include a (Alice pubkey + OP_CLTV timelock) in Carol's contract
transaction. This means that if Carol broadcasts her contract tx (called
TX_2 in the text) without knowing the preimage then Alice can still get
her money back after a timeout, breaking the MAD situation. The crucial
part making this work is that Alice won't know the fully-signed Carol
contract transaction, and so won't be able to unilaterally broadcast it.
I believe this fix makes the scheme equivalent to ZmnSCPxj's idea of
separated transactions, but without scriptless scripts (and so the
scheme is less useful)
Kind regards
CB
next prev parent reply other threads:[~2020-09-03 9:00 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 [this message]
2020-09-03 9:45 ` ZmnSCPxj
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=0ac3fecb-012b-e210-55bb-36809682634a@riseup.net \
--to=belcher@riseup$(echo .)net \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=antoine.riard@gmail$(echo .)com \
--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