diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2020-08-20 11:17:07 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-08-20 11:17:23 +0000 |
| commit | 90d8cb08968df37e81bb37eca5f79ecad6b0b94d (patch) | |
| tree | 43c0aa5c0fcc050d32dd91dc5f2dd789748bf899 | |
| parent | 52ffe655ce4f0438d130814fac5d235bbf1d5108 (diff) | |
| download | pi-bitcoindev-90d8cb08968df37e81bb37eca5f79ecad6b0b94d.tar.gz pi-bitcoindev-90d8cb08968df37e81bb37eca5f79ecad6b0b94d.zip | |
Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap
| -rw-r--r-- | 9a/793122ab782594fe1af16be43036377eebfad8 | 405 |
1 files changed, 405 insertions, 0 deletions
diff --git a/9a/793122ab782594fe1af16be43036377eebfad8 b/9a/793122ab782594fe1af16be43036377eebfad8 new file mode 100644 index 000000000..88efab949 --- /dev/null +++ b/9a/793122ab782594fe1af16be43036377eebfad8 @@ -0,0 +1,405 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 13E5EC0051 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 20 Aug 2020 11:17:23 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by silver.osuosl.org (Postfix) with ESMTP id DE88C220A9 + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 20 Aug 2020 11:17:22 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +Received: from silver.osuosl.org ([127.0.0.1]) + by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id A7Gabx4ruwch + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 20 Aug 2020 11:17:18 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail-40137.protonmail.ch (mail-40137.protonmail.ch + [185.70.40.137]) + by silver.osuosl.org (Postfix) with ESMTPS id 867DB2010F + for <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 20 Aug 2020 11:17:18 +0000 (UTC) +Date: Thu, 20 Aug 2020 11:17:07 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=protonmail; t=1597922235; + bh=NWB2CVwSCThRdTgP7FOahc+MKClKEVQc4pB+jZXlC4k=; + h=Date:To:From:Reply-To:Subject:In-Reply-To:References:From; + b=nLp3b+jo0gUiPLikL8MV4E8HFs6FpQxrLCt6DouSw/al9cef0fPZyK+5DQt8FqKsO + ZIJJP1utTfbtmFHGW3nVqlg0Jqc4YscTLwFx/wr4o0yfiAoGiZTbJJJJCerfx99O8p + CMliRQuNxIR2S7o4chPEbJtA7R3EDIE9Rvmtagkw= +To: Chris Belcher <belcher@riseup.net>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <xhRsCejqgUjoLy5hPMHgFcZdiqJsO7TfS0azWhis9-tvSgXodoKe7gN5IXyiVIVqUWSm7FoY-aBUaJCCDgixdWUN4n8EzhQlSNshsQeIFsw=@protonmail.com> +In-Reply-To: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net> +References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net> +MIME-Version: 1.0 +Content-Type: text/plain; charset=utf-8 +Content-Transfer-Encoding: quoted-printable +Subject: Re: [bitcoin-dev] Detailed protocol design for routed + multi-transaction CoinSwap +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Thu, 20 Aug 2020 11:17:23 -0000 + +Good morning Chris, + +Great to see this! + +Mostly minor comments. + + + +> +> =3D=3D Direct connections to Alice =3D=3D=3D +> +> Only Alice, the taker, knows the entire route, Bob and Charlie just know +> their previous and next transactions. Bob and Charlie do not have direct +> connections with each other, only with Alice. +> +> Diagram of Tor connections: +> +> Bob Charlie +> | / +> | / +> | / +> Alice +> +> When Bob and Charlie communicate, they are actually sending and +> receiving messages via Alice who relays them to Charlie or Bob. This +> helps hide whether the previous or next counterparty in a CoinSwap route +> is a maker or taker. +> +> This doesn't have security issues even in the final steps where private +> keys are handed over, because those private keys are always for 2-of-2 +> multisig and so on their own are never enough to steal money. + +This has a massive advantage over CoinJoin. + +In CoinJoin, since all participants sign a single transaction, every partic= +ipant knows the total number of participants. +Thus, in CoinJoin, it is fairly useless to have just one taker and one make= +r, the maker knows exactly which output belongs to the taker. +Even if all communications were done via the single paying taker, the maker= +(s) are shown the final transaction and thus can easily know how many parti= +cipants there are (by counting the number of equal-valued outputs). + +With CoinSwap, in principle no maker has to know how many other makers are = +in the swap. + +Thus it would still be useful to make a single-maker CoinSwap, as that woul= +d be difficult, for the maker, to diferentiate from a multi-maker CoinSwap. + +There are still a few potential leaks though: + +* If paying through a CoinSwap, the cheapest option for the taker would be = +to send out a single large UTXO (single-output txes) to the first maker, an= +d then demand the final payment and any change as two separate swaps from t= +he final maker. + * Intermediate makers are likely to not have exact amounts, thus is unlik= +ely to create a single-output tx when forwarding. + * Thus, the first maker could identify the taker. +* The makers can try timing the communications lag with the taker. + The general assumption would be that more makers =3D=3D more delay in tak= +er responses. + + + +> +> =3D=3D=3D Miner fees =3D=3D=3D +> +> Makers have no incentive to pay any miner fees. They only do +> transactions which earn them an income and are willing to wait a very +> long time for that to happen. By contrast takers want to create +> transactions far more urgently. In JoinMarket we coded a protocol where +> the maker could contribute to miner fees, but the market price offered +> of that trended towards zero. So the reality is that takers will pay all +> the miner fees. Also because makers don't know the taker's time +> preference they don't know how much they should pay in miner fees. +> +> The taker will have to set limits on how large the maker's transactions +> are, otherwise makers could abuse this by having the taker consolidate +> maker's UTXOs for free. + +Why not have the taker pay for the *first* maker-spent UTXO and have additi= +onal maker-spent UTXOs paid for by the maker? +i.e. the taker indicates "swap me 1 BTC in 3 bags of 0.3, 0.3, and 0.4 BTC"= +, and pays for one UTXO spent for each "bag" (thus pays for 3 UTXOs). + +Disagreements on feerate can be resolved by having the taker set the feerat= +e, i.e. "the customer is always right". +Thus if the maker *has to* spend two UTXOs to make up the 0.4 BTC bag, it p= +ays for the mining fees for that extra UTXO. +The maker can always reject the swap attempt if it *has to* spend multiple = +UTXOs and would lose money doing so if the taker demands a too-high feerate= +. + + +> =3D=3D Contract transaction definitions =3D=3D +> +> Contract transactions are those which may spend from the 2-of-2 multisig +> outputs, they transfer the coins into a contract where the coins can be +> spent either by waiting for a timeout or providing a hash preimage +> value. Ideally contract transactions will never be broadcast but their +> existence keeps all parties honest. +> +> M~ is miner fees, which we treat as a random variable, and ultimately +> set by whichever pre-signed RBF tx get mined. When we talk about the +> contract tx, we actually mean perhaps 20-30 transactions which only +> differ by the miner fee and have RBF enabled, so they can be broadcasted +> in sequence to get the contract transaction mined regardless of the +> demand for block space. + +The highest-fee version could have, in addition, CPFP-anchor outputs, like = +those being proposed in Lightning, so even if onchain fees rise above the l= +argest fee reservation, it is possible to add even more fees. + +Or not. +Hmm. + + +Another thought: later you describe that miner fees are paid by Alice by fo= +rwarding those fees as well, how does that work when there are multiple ver= +sions of the contract transaction? + +> +> (Alice+timelock_A OR Bob+hash) =3D Is an output which can be spent +> either with Alice's private key +> after waiting for a relative +> timelock_A, or by Bob's private key by +> revealing a hash preimage value + +The rationale for relative timelocks is that it makes private key turnover = +slightly more useable by ensuring that, after private key turnover, it is p= +ossible to wait indefinitely to spend the UTXO it received. +This is in contrast with absolute timelocks, where after private key turnov= +er, it is required to spend received UTXO before the absolute timeout. + +The dangers are: + +* Until it receives the private key, if either of the incoming or outgoing = +contract transactions are confirmed, every swap participant (taker or maker= +) should also broadcast the other contract transaction, and resolve by onch= +ain transactions (with loss of privacy). +* After receiving the private key, if the incoming contract transaction is = +confirmed, it should spend the resulting contract output. +* It is possible to steal from a participant if that participant goes offli= +ne longer than the timeout. + This may imply that there may have to be some minimum timeout that makers= + indicate in their advertisements. + * The taker can detect if the first maker is offline, then if it is offli= +ne, try a contract transaction broadcast, if it confirms, the taker can wai= +t for the timeout; if it times out, the taker can clawback the transaction. + * This appears to be riskless for the taker. + * Against a similar attack, Lightning requires channel reserves, which = +means the first hop never gains control of the entire value, which is a bas= +ic requirement for private key turnover. + * On the other hand, the taker has the largest timeout before it can claw= +back the funds, so it would wait for a long time, and at any time in betwee= +n the first maker can come online and spend using the hashlock branch. + * But the taker can just try on the hope it works; it has nothing to lo= +se. + * This attack seems to be possible only for the taker to mount. + Other makers on the route cannot know who the other makers are, without= + cooperation of the taker, who is the only one who knows all the makers. + * On the other hand, the last maker in the route has an outgoing HTLC w= +ith the smallest timelock, so it is the least-risk and therefore a maker wh= +o notices its outgoing HTLC has a low timeout might want to just do this an= +yway even if it is unsure if the taker is offline. + * Participants might want to spend from the UTXO to a new address after p= +rivate key turnover anyway. + Makers could spend using a low-fee RBF-enabled tx, and when another req= +uest comes in for another swap, try to build a new funding tx with a higher= +-fee bump. + + +> A possible attack by a malicious Alice is that she chooses M1 to be very +> low (e.g. 1 sat/vbyte) and sets M2 and M3 to be very high (e.g. 1000 +> sat/vb) and then intentionally aborts, forcing the makers to lose much +> more money in miner fees than the attacker. The attack can be used to +> waste away Bob's and Charlie's coins on miner fees at little cost to the +> malicious taker Alice. So to defend against this attack Bob and Charlie +> must refuse to sign a contract transaction if the corresponding funding +> transaction pays miner fees greater than Alice's funding transaction. + +Sorry, I do not follow the logic for this...? + +> The timelocks are staggered so that if Alice uses the preimage to take +> coins then the right people will also learn the preimage and have enough +> time to be able to get their coins back too. Alice starts with knowledge +> of the hash preimage so she must have a longest timelock. + +More precisely: + +* The HTLC outgoing from Alice has the longest timelock. +* The HTLC incoming into Alice has the shortest timelock. + +For the makers, they only need to ensure that the incoming timelock is much= + larger than the outgoing timelock. + + +> +> =3D=3D EC tweak to reduce one round trip =3D=3D +> +> When two parties are agreeing on a 2-of-2 multisig address, they need to +> agree on their public keys. We can avoid one round trip by using the EC +> tweak trick. +> +> When Alice, the taker, downloads the entire offer book for the liquidity +> market, the offers will also contain a EC public key. Alice can tweak +> this to generate a brand new public key for which the maker knows the +> private key. This public key will be one of the keys in the 2-of-2 +> multisig. This feature removes one round trip from the protocol. +> +> q =3D EC privkey generated by maker +> Q =3D q.G =3D EC pubkey published by maker +> +> p =3D nonce generated by taker +> P =3D p.G =3D nonce point calculated by taker +> +> R =3D Q + P =3D pubkey used in bitcoin transaction +> =3D (q + p).G + +Whoa whoa whoa whoa. + +All this time I was thinking you were going to use 2p-ECDSA for all 2-of-2s= +. +In which case, the private key generated by the taker would be sufficient t= +weak to blind this. + +In 2p-ECDSA, for two participants M =3D m * G; T =3D t * G, the total key i= +s m * t * G =3D m * T =3D t * M. + +Are you going to use `2 <T> <Q+P> 2 OP_CHECKMULTISIG` instead of 2p-ECDSA? +Note that you cannot usefully hide among Lightning mutual closes, because o= +f the reserve; Lightning mutual closes are very very likely to be spent in = +a 1-input (that spends from a 2-of-2 P2WSH), 2-output (that pays to two P2W= +PKHs) tx. + +> +> =3D=3D Protocol =3D=3D + +> ---8<------ + +The protocol looks correct to me. + +LOL. + +Give me a little more time to check it in detail hahaha. + + + +> =3D=3D=3D=3D Retaliation as DOS-resistance =3D=3D=3D=3D +> +> In some situations (e.g. step 8.) if one maker in the coinswap route = +is +> the victim of a DOS they will retaliate by DOSing the previous maker = +in +> the route. This may seem unnecessary and unfair (after all why waste +> even more time and block space) but is actually the best way to resis= +t +> DOS because it produces a concrete cost every time a DOS happens. + +I agree. + +> +> =3D=3D Analysis of deviations =3D=3D +> +> This section discusses what happens if one party deviates from the +> protocol by doing something else, for example broadcasting a htlc +> contract tx when they shouldnt have. +> +> The party name refers to what that party does, followed by other part= +y's +> reactions to it. +> e.g. Party1: does a thing, Party2/Party3: does a thing in reaction +> +> If multiple deviations are possible in a step then they are numbered +> e.g. A1 A2 A2 etc +> +> 0-2. Alice/Bob/Charlie: nothing else is possible except following the +> protocol or aborting +> +> 8. Alice: broadcasts one or more of the A htlc txes. Bob/Charlie/Dennis: +> do nothing, they havent lost any time or money. +> 4-6. Bob/Charlie: nothing else is possible except following the proto= +col +> or aborting. +> +> 9. Bob: broadcasts one or more of the B htlc txes, Alice: broadcasts all +> her own A htlc txes and waits for the timeout to get her money back. +> Charlie: do nothing +> +> 10. Charlie: nothing else is possible except following the protocol or +> aborting. +> +> 11. Alice: broadcasts one or more of the A htlc txes. Bob: broadcasts al= +l +> his own A htlc txes and waits for the timeout. +> A. same as 8. +> B. Charlie: broadcasts one or more of the C htlc txes, Alice/Bob: +> broadcasts all their own htlc txes and waits for the timeout to get +> their money back. +> C-E1. Alice: broadcasts all of C htlc txes and uses her knowledge of = +the +> preimage hash to take the money immediately. Charlie: broadcasts +> all of B htlc txes and reading the hash value from the blockchain, +> uses it to take the money from B htlc immediately. Bob: broadcasts +> all of A htlc txes, and reading hash from the blockchain, uses it +> to take the money from A htlc immediately. +> C-E2. Alice: broadcast her own A htlc txes, and after a timeout take = +the +> money. Bob: broadcast his own B htlc txes and after the timeout +> take their money. Charlie: broadcast his own C htlc txes and after +> the timeout take their money. +> F1. Bob: broadcast one or more of A htcl txes and use the hash preima= +ge +> to get the money immediately. He already knows both privkeys of the +> multisig so this is pointless and just damages privacy and wastes +> miner fees. Alice: blacklist Bob's fidelity bond. +> F2. Bob: broadcast one or more of the C htlc txes. Charlie: use preim= +age +> to get his money immediately. Bob's actions were pointless. Alice: +> cant tell whether Bob or Charlie actually broadcasted, so blacklist +> both fidelity bonds. +> G1. Charlie: broadcast one or more of B htcl txes and use the hash +> preimage to get the money immediately. He already knows both +> privkeys of the multisig so this is pointless and just damages +> privacy and wastes miner fees. Alice: cant tell whether Bob or +> Charlie actually broadcasted, so blacklist both fidelity bonds. +> G2. Charlie: broadcast one or more of the A htlc txes. Alice: broadca= +st +> the remaining A htlc txes and use preimage to get her money +> immediately. Charlies's actions were pointless. Alice: blacklist +> Charlie's fidelity bond. +> +> The multisig outputs of the funding transactions can stay unspent +> indefinitely. However the parties must always be watching the network +> and ready to respond with their own sweep using a preimage. This is +> because the other party still possesses a fully-signed contract tx. T= +he +> parties respond in the same way as in steps C-E1, F2 and G2. Alice's +> reaction of blacklisting both fidelity bonds might not be the right w= +ay, +> because one maker could use it to get another one blacklisted (as wel= +l +> as themselves). + +Looks OK, though note that a participant might try to do so (as pointed out= + above) in the hope that the next participant is offline. + +Thank you very much for your writeup! + +Regards, +ZmnSCPxj + |