From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4EAB8C0052 for ; Sat, 5 Sep 2020 01:07:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 314D6869CA for ; Sat, 5 Sep 2020 01:07:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXrGq+R-K7X7 for ; Sat, 5 Sep 2020 01:07:30 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f45.google.com (mail-wr1-f45.google.com [209.85.221.45]) by whitealder.osuosl.org (Postfix) with ESMTPS id 053A386356 for ; Sat, 5 Sep 2020 01:07:30 +0000 (UTC) Received: by mail-wr1-f45.google.com with SMTP id m6so9192841wrn.0 for ; Fri, 04 Sep 2020 18:07:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rczALG0ffb5fhw3sdl1N0yy0viuS4P4B4xiwa3iTiWE=; b=UKSnIy/vD/71DLUeORY2K8wSi0L5s7Ax8x9Bo92/LwvzjkIEqPlg1CNY7oerNKtz1O E/kjX3oopYAzCwsz/87udLZ5xIVzyyEJnVejaOLmSQdZq2pNHaxyOp/ucC5Ytrsj5mtL yDGHJ8dRnG2wpB9SDvh37eIaB9BVrKklsOq5ycP+k3OBQbUZdZ3pG3O5on1FHDwjgLkf rWvy+6Qu0ep1bKCGCAxvdyIu8UD18cLWZRvmBzfLN1iRf/xbNhV8PABlXp8bzj18Btz3 FOAuxuVPKXPXymznQl2Af2L3vgg2WAlAZ3NIIOUgZ7JtM4/lZJYoTaMWfDk9duJM+Mh9 1+eg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rczALG0ffb5fhw3sdl1N0yy0viuS4P4B4xiwa3iTiWE=; b=EnC5oqC3F8M7IUJ1XZmYCDfrtaIdC9WmWFThkQs+irC0hG+zFEgCreSirznEuOWsBt eOPSI/76efLr7VqG/f+IMFdXM45IxEydpef3S6hX0AqvSlod7cl/jzwyL+6SpGF/dpEu zsuDkBcyoDAb/OPGlgEs18SG+2iJ+cpEkMxnA5Cs/6F1baUn7e3o4VyUWQZZYnh0TPgs 6ykVzCuKHTY89e5uJHmQ+oMI4Q5qqUfwPPh+2uxZFNaYn0iI3KRYKQFEBXiyE4yT/UCB PydRW5D1CApTKf+flpdlQcA+AatBuIiZN8AVmw5b0WaF9/e7EWjgmSXmubio8eZnJWM6 0Odg== X-Gm-Message-State: AOAM531WaheP3cafmNbuv4tA5WOHU91biJXTlPfS2FGAAIlq9T+ntVnO pU9HpN7nipsLMa1MNG4bDBXtNTvjU9EmJ63imBA= X-Google-Smtp-Source: ABdhPJxfPeQcoI3sXu3ECgxKQXFdA57BhnwM0mKxBVfsLOJd357Bw9We76ZJj/OzVIOSvgtg3JSEjRpRakxagcQBVnk= X-Received: by 2002:adf:f44d:: with SMTP id f13mr4442841wrp.224.1599268047910; Fri, 04 Sep 2020 18:07:27 -0700 (PDT) MIME-Version: 1.0 References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net> In-Reply-To: From: Antoine Riard Date: Fri, 4 Sep 2020 21:07:15 -0400 Message-ID: To: Chris Belcher Content-Type: multipart/alternative; boundary="000000000000e5791005ae869b27" X-Mailman-Approved-At: Sat, 05 Sep 2020 06:58:07 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2020 01:07:35 -0000 --000000000000e5791005ae869b27 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Chris, I forgot to underscore that contract transaction output must be grieved by at least a CSV of 1. Otherwise, a malicious counterparty can occupy with garbage both the timelock-or-preimage output and its own anchor output thus blocking you to use the bumping capability of your own anchor ouput. A part of this, I think it works. > Another possible fix for both vulnerabilities is to separate the > timelock and hashlock cases into two separate transactions as described > by ZmnSCPxj in a recent email to this list. This comes at the cost of > breaking private key handover allowing coins to remain unspent indefinitely. This works too assuming these second-stage transactions aren't malleable at all (e.g SIGASH_SINGLE). Other ways you can increase their feerate/absolute fee and you're back to the initial situation. Beyond note also that anchors-on-second-stage are more risky here, as otherwise your counterparty can again attach a low-feerate child. In case of concurrent broadcast (assuming you haven't achieved to claim the output before timelock expiration due to network outage/mempool-congestion) you might not see your counterparty version. I.e, your local mempool has the timelock tx and the rest of the network the hashlock and your CPFP bump won't propagate as being an orphan. So you're left with a RBF-range, which is mostly okay minus a theoretical concern : a party guessing the odds to lose the balance are high can broadcast/send out-of-band the highest-fee bound to miners thus incentivizing them to censor a honest, low-fee preimage tx. A "nothing-at-stake-for-genuinely-evil-counterparty" issue. > Another possible fix for the second attack, is to encumber the output > with a `1 OP_CSV` which stops that output being spent while unconfirmed. > This seems to be the simplest way if your aim is to only fix the second > attack. Yes you don't package fee malleability so an honest party can always unilaterally bump the feerate and override concurrent bids. That said, I would lean towards anchors and thus unileratel fee bumping. Feerate interactivity among a multi-party protocol should be seen as an oracle to leak the full-node of a participant. By sending a range of conflicting transactions with different feerates to a set of network mempools I could theoretically observe variations in the protocol feerate announced. I would recommend you to have a look on this paper, if it's not done yet : https://arxiv.org/pdf/2007.00764.pdf, the first one analyzing privacy holistically across Bitcoin layers. Cheers, Antoine Le sam. 29 ao=C3=BBt 2020 =C3=A0 18:03, Chris Belcher = a =C3=A9crit : > Hello Antoine, > > Thanks for the very useful insights. > > It seems having just one contract transaction which includes anchor > outputs in the style already used by Lightning is one way to fix both > these vulnerabilities. > > For the first attack, the other side cannot burn the entire balance > because they only have access to the small amount of satoshi of the > anchor output, and to add miner fees they must add their own inputs. So > they'd burn their own coins to miner fees, not the coins in the contract. > > For the second attack, the other side cannot do transaction pinning > because there is only one contract transaction, and all the protections > already developed for use with Lightning apply here as well, such as > CPFP carve out. > > > Another possible fix for both vulnerabilities is to separate the > timelock and hashlock cases into two separate transactions as described > by ZmnSCPxj in a recent email to this list. This comes at the cost of > breaking private key handover allowing coins to remain unspent > indefinitely. > > Another possible fix for the second attack, is to encumber the output > with a `1 OP_CSV` which stops that output being spent while unconfirmed. > This seems to be the simplest way if your aim is to only fix the second > attack. > > > These are all the possible fixes I can think of. > > Regards > Chris > > On 24/08/2020 20:30, Antoine Riard wrote: > > Hello Chris, > > > > I think you might have vulnerability issues with the current design. > > > > With regards to the fee model for contract transactions, AFAICT timely > > confirmation is a fund safety matter for an intermediate hop. Between t= he > > offchain preimage reveal phase and the offchain private key handover > phase, > > the next hop can broadcast your outgoing contract transactions, thus > > forcing you to claim quickly backward as you can't assume previous hop > will > > honestly cooperate to achieve the private key handover. This means that > > your range of pre-signed RBF-transactions must theoretically have for f= ee > > upper bound the maximum of the contested balance, as game-theory side, > it's > > rational to you to burn your balance instead of letting your counterpar= ty > > claim it after timelock expiration, in face of mempool congestion. Wher= e > > the issue dwells is that this fee is pre-committed and not cancelled wh= en > > the balance change of ownership by the outgoing hop learning the preima= ge > > of the haslock output. Thus the previous hop is free to broadcast the > > highest-fee RBF-transactions and burn your balance, as for him, his > balance > > is now encoded in the output of the contract transactions on the previo= us > > link, for which he knows the preimage. > > > > Note, I think this is independent of picking up either relative or > absolute > > timelocks as what matters is the block delta between two links. Of cour= se > > you can increase this delta to be week-lengthy and thus decrease the ne= ed > > for a compelling fee but a) you may force quickly close with contract > > transactions if the private key handover doesn't happen soon, you don't > > want to be caught by surprise by congestion so you would close far behi= nd > > delta period expiration like half of it, and b) you increase the > time-value > > of makers funds in case of faulty hop, thus logically increasing the > maker > > fee and making the cost of the system higher in average. I guess a bett= er > > solution would be to use dual-anchor outputs has spec'ed out by > Lightning, > > it lets the party who has a balance at stake unilaterally increase > feerate > > with a CPFP. The CPFP is obviously a higher blockchain cost but a) it's= a > > safety mechanism for a worst-case scenario, 99% of the time they won't = be > > committed, b) you might use this CPFP to aggregate change outputs or > other > > opportunistically side-usage. > > > > With regards to the preimage release phase, I think you might have a > > pinning scenario. The victim would be an intermediate hop, targeted by = a > > malicious taker. The preimage isn't revealed offchain to this victim > hop. A > > low-feerate version of the outgoing contract transaction is broadcast a= nd > > not going to confirm, assuming a bit of congestion. As preimage is know= n, > > the malicious taker can directly attach a high-fee, low-feerate child > > transaction and thus prevent any replacement of the pinned parent by a > > honest broadcast of a high-fee RBF-transaction under BIP 125 rules. At > the > > same time, the malicious taker broadcasts the contract tx on the previo= us > > link and gets it confirmed. At relative timelock expiration, malicious > > taker claims back the funds. When the pinned transaction spending the > > outgoing link gets evicted (either by replacing child by a higher feera= te > > or waiting for mempool expiration after 2 weeks), taker gets it confirm= ed > > this time and claims output through hashlock. Given the relative timelo= ck > > blocking the victim, there is not even a race. > > > > I guess restraining the contract transaction to one and only one versio= n > > would overcome this attack. A honest intermediate hop, as soon as seein= g > a > > relative timelock triggered backward would immediately broadcast the > > outgoing link contract tx or if it's already in network mempools > broadcast > > a higher-feerate child. As you don't have valid multiple contract > > transactions, an attacker can't obstruct you to propagate the correct > > child, as you are not blind about the parent txid. > > > > Lastly, one downside of using relative timelocks, in case of one > downstream > > link failure, it forces every other upstream hops to go onchain to > protect > > against this kind of pinning scenario. And this would be a privacy > > breakdown, as a maker would be able to provoke one, thus constraining > every > > upstream hops to go onchain with the same hash and revealing the CoinSw= ap > > route. > > > > Let me know if I reviewed the correct transactions circuit model or > > misunderstood associated semantic. I might be completely wrong, coming > from > > a LN perspective. > > > > Cheers, > > Antoine > > > > Le mar. 11 ao=C3=BBt 2020 =C3=A0 13:06, Chris Belcher via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > > > >> I'm currently working on implementing CoinSwap (see my other email > >> "Design for a CoinSwap implementation for massively improving Bitcoin > >> privacy and fungibility"). > >> > >> CoinSwaps are special because they look just like regular bitcoin > >> transactions, so they improve the privacy even for people who do not u= se > >> them. Once CoinSwap is deployed, anyone attempting surveillance of > >> bitcoin transactions will be forced to ask themselves the question: ho= w > >> do we know this transaction wasn't a CoinSwap? > >> > >> This email contains a detailed design of the first protocol version. I= t > >> makes use of the building blocks of multi-transaction CoinSwaps, route= d > >> CoinSwaps, liquidity market, private key handover, and fidelity bonds. > >> It does not include PayJoin-with-CoinSwap, but that's in the plan to b= e > >> added later. > >> > >> =3D=3D Routed CoinSwap =3D=3D > >> > >> Diagram of CoinSwaps in the route: > >> > >> Alice =3D=3D=3D=3D> Bob =3D=3D=3D=3D> Charlie =3D=3D=3D=3D> Alice > >> > >> Where (=3D=3D=3D=3D>) means one CoinSwap. Alice gives coins to Bob, wh= o gives > >> coins to Charlie, who gives coins to Alice. Alice is the market taker > >> and she starts with the hash preimage. She chooses the CoinSwap amount > >> and chooses who the makers will be. > >> > >> This design has one market taker and two market makers in its route, b= ut > >> it can easily be extended to any number of makers. > >> > >> =3D=3D Multiple transactions =3D=3D > >> > >> Each single CoinSwap is made up of multiple transactions to avoid amou= nt > >> correlation > >> > >> (a0 BTC) ---> (b0 BTC) ---> (c0 BTC) ---> > >> Alice (a1 BTC) ---> Bob (b1 BTC) ---> Charlie (c1 BTC) ---> Alice > >> (a2 BTC) ---> (b2 BTC) ---> (c2 BTC) ---> > >> > >> The arrow (--->) represent funding transactions. The money gets paid t= o > >> a 2-of-2 multisig but after the CoinSwap protocol and private key > >> handover is done they will be controlled by the next party in the rout= e. > >> > >> This example has 6 regular-sized transactions which use approximately > >> the same amount of block space as a single JoinMarket coinjoin with 6 > >> parties (1 taker, 5 makers). Yet the privacy provided by this one > >> CoinSwap would be far far greater. It would not have to be repeated in > >> the way that Equal-Output CoinJoins must be. > >> > >> =3D=3D Direct connections to Alice =3D=3D=3D > >> > >> Only Alice, the taker, knows the entire route, Bob and Charlie just kn= ow > >> their previous and next transactions. Bob and Charlie do not have dire= ct > >> 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 rou= te > >> is a maker or taker. > >> > >> This doesn't have security issues even in the final steps where privat= e > >> 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. > >> > >> > >> =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 wher= e > >> 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 a= ll > >> 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 transaction= s > >> are, otherwise makers could abuse this by having the taker consolidate > >> maker's UTXOs for free. > >> > >> =3D=3D Funding transaction definitions =3D=3D > >> > >> Funding transactions are those which pay into the 2-of-2 multisig > >> addresses. > >> > >> Definitions: > >> I =3D initial coinswap amount sent by Alice =3D a0 + a1 + a2 > >> (WA, WB, WC) =3D Total value of UTXOs being spent by Alice, Bob, Charl= ie > >> respectively. Could be called "wallet Alice", "wallet > >> Bob", etc > >> (B, C) =3D Coinswap fees paid by Alice and earned by Bob and Charlie. > >> (M1, M2, M3) =3D Miner fees of the first, second, third, etc sets of > >> funding transactions. Alice will choose what these are > >> since she's paying. > >> multisig(A+B) =3D A 2of2 multisig output with private keys held by A a= nd B > >> > >> The value in square parentheses refers to the bitcoin amount. > >> > >> Alice funding txes > >> [WA btc] ---> multisig (Alice+Bob) [I btc] > >> change [WA-M1-I btc] > >> Bob funding txes > >> [WB btc] ---> multisig (Bob+Charlie) [I-M2-B btc] > >> change [WB-I+B btc] > >> Charlie funding txes > >> [WC btc] ---> multisig (Charlie+Alice) [(I-M2-B)-M3-C btc] > >> change [WC-(I-M2-B)+C btc] > >> > >> Here we've drawn these transactions as single transactions, but they a= re > >> actually multiple transactions where the outputs add up some value (e.= g. > >> add up to I in Alice's transactions.) > >> > >> =3D=3D=3D Table of balances before and after a successful CoinSwap =3D= =3D=3D > >> > >> If a CoinSwap is successful then all the multisig outputs in the fundi= ng > >> transactions will become controlled unilaterally by one party. We can > >> calculate how the balances of each party change. > >> > >> Party | Before | After > >> --------|--------|------------------------------------------- > >> Alice | WA | WA-M1-I + (I-M2-B)-M3-C =3D WA-M1-M2-M3-B-C > >> Bob | WB | WB-I+B + I =3D WB+B > >> Charlie | WC | WC-(I-M2-B)+C + I-M2-B =3D WC+C > >> > >> After a successful coinswap, we see Alice's balance goes down by the > >> miner fees and the coinswap fees. Bob's and Charlie's balance goes up = by > >> their coinswap fees. > >> > >> =3D=3D Contract transaction definitions =3D=3D > >> > >> Contract transactions are those which may spend from the 2-of-2 multis= ig > >> outputs, they transfer the coins into a contract where the coins can b= e > >> 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 broadcast= ed > >> in sequence to get the contract transaction mined regardless of the > >> demand for block space. > >> > >> (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 b= y > >> revealing a hash preimage value > >> > >> Alice contract tx: > >> multisig (Alice+Bob) ---> (Alice+timelock_A OR Bob+hash) > >> [I btc] [I-M~ btc] > >> Bob contract tx: > >> multisig (Bob+Charlie) ---> (Bob+timelock_B OR Charlie+hash) > >> [I-M2-B btc] [I-M2-B-M~ btc] > >> Charlie contract tx: > >> multisig (Charlie+Alice) ---> (Charlie+timelock_C OR Alice+hash) > >> [(I-M2-B)-M3-C btc] [(I-M2-B)-M3-C-M~ btc] > >> > >> > >> =3D=3D=3D Table of balances before/after CoinSwap using contracts tran= sactions > >> =3D=3D=3D > >> > >> In this case the parties had to get their money back by broadcasting a= nd > >> mining the contract transactions and waiting for timeouts. > >> > >> Party | Before | After > >> --------|--------|-------------------------------------------- > >> Alice | WA | WA-M1-I + I-M~ =3D WA-M1-M~ > >> Bob | WB | WB-I+B + I-M2-B-M~ =3D WB-M2-M~ > >> Charlie | WC | WC-(I-M2-B)+C + (I-M2-B)-M3-C-M~ =3D WC-M3-M~ > >> > >> In the timeout failure case, every party pays for their own miner fees= . > >> And nobody earns or spends any coinswap fees. So even for a market mak= er > >> its possible for their wallet balance to go down sometimes, although a= s > >> we shall see there are anti-DOS features which make this unlikely to > >> happen often. > >> > >> A possible attack by a malicious Alice is that she chooses M1 to be ve= ry > >> 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 t= he > >> malicious taker Alice. So to defend against this attack Bob and Charli= e > >> must refuse to sign a contract transaction if the corresponding fundin= g > >> transaction pays miner fees greater than Alice's funding transaction. > >> > >> > >> There can also be a failure case where each party gets their money usi= ng > >> hash preimage values instead of timeouts. Note that each party has to > >> sweep the output before the timeout expires, so that will cost an > >> additional miner fee M~. > >> > >> Party | Before | After > >> --------|--------|----------------------------------------------------= -- > >> Alice | WA | WA-M1-I + (I-M2-B)-M3-C-M~ - M~ =3D WA-M1-M2-M3-B-C= -2M~ > >> Bob | WB | WB-I+B + I-M~ - M~ =3D WB+B-2M~ > >> Charlie | WC | WC-(I-M2-B)+C + I-M2-B-M~ - M~ =3D WC+C-2M~ > >> > >> In this situation the makers Bob and Charlie earn their CoinSwap fees, > >> but they pay an additional miner fee twice. Alice pays for all the > >> funding transaction miner fees, and the CoinSwap fees, and two > >> additional miner fees. And she had her privacy damaged because the > >> entire world saw on the blockchain the contract script. > >> > >> Using the timelock path is like a refund, everyone's coin just comes > >> back to them. Using the preimage is like the CoinSwap transaction > >> happened, with the coins being sent ahead one hop. Again note that if > >> the preimage is used then coinswap fees are paid. > >> > >> =3D=3D=3D Staggered timelocks =3D=3D=3D > >> > >> 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 enou= gh > >> time to be able to get their coins back too. Alice starts with knowled= ge > >> of the hash preimage so she must have a longest 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 E= C > >> tweak trick. > >> > >> When Alice, the taker, downloads the entire offer book for the liquidi= ty > >> 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 > >> > >> Taker sends unsigned transaction which pays to multisig using pubkey Q= , > >> and also sends nonce p. The maker can use nonce p to calculate (q + p) > >> which is the private key of pubkey R. > >> > >> Taker doesnt know the privkey because they are unable to find q becaus= e > >> of the ECDLP. > >> > >> Any eavesdropper can see the nonce p and easily calculate the point R > >> too but Tor communication is encrypted so this isnt a concern. > >> > >> None of the makers in the route know each other's Q values, so Alice t= he > >> taker will generate a nonce p on their behalf and send it over. I > >> believe this cant be used for any kind of attack, because the signing > >> maker will always check that the nonce results in the public key > >> included in the transaction they're signing, and they'll never sign a > >> transaction not in their interests. > >> > >> > >> =3D=3D Protocol =3D=3D > >> > >> This section is the most important part of this document. > >> > >> Definitions: > >> fund =3D all funding txes (remember in this multi-tx protocol there ca= n be > >> multiple txes which together make up the funding) > >> A htlc =3D all htlc contract txes (fully signed) belonging to party A > >> A unsign htcl =3D all unsigned htlc contract txes belonging to party A > >> including the nonce point p used to calculate the > >> maker's pubkey. > >> p =3D nonce point p used in the tweak EC protocol for calculating the > >> maker's pubkey > >> A htlc B/2 =3D Bob's signature for the 2of2 multisig of the Alice htlc > >> contract tx > >> privA(A+B) =3D private key generated by Alice in the output > >> multisig (Alice+Bob) > >> > >> > >> | Alice | Bob | Charlie | > >> |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D| > >> 0. A unsign htlc ----> | | > >> 1. <---- A htlc B/2 | | > >> 2. ***** BROADCAST AND MINE ALICE FUNDING TXES ****** | > >> 3. A fund+htlc+p ----> | | > >> 4. | B unsign htlc ----> | > >> 5. | <---- B htlc C/2 | > >> 6. ******* BROADCAST AND MINE BOB FUNDING TXES ******* | > >> 7. | B fund+htlc+p ----> | > >> 8. <---------------------- C unsign htlc | > >> 9. C htlc A/2 ----------------------> | > >> A. ***** BROADCAST AND MINE CHARLIE FUNDING TXES ***** | > >> B. <---------------------- C fund+htlc+p | > >> C. hash preimage ----------------------> | > >> D. hash preimage ----> | | > >> E. privA(A+B) ----> | | > >> F. | privB(B+C) ----> | > >> G. <---------------------- privC(C+A) | > >> > >> =3D=3D Protocol notes =3D=3D > >> 0-2 are the steps which setup Alice's funding tx and her contract tx f= or > >> possible refund > >> 4-5 same as 0-2 but for Bob > >> 8-9 same as 0-2 but for Charlie > >> 3,7 is proof to the next party that the previous party has already > >> committed miner fees to getting a transaction mined, and therefore > >> this isnt a DOS attack. The step also reveals the fully-signed > >> contract transaction which the party can use to get their money ba= ck > >> with a preimage. > >> C-G is revealing the hash preimage to all, and handing over the privat= e > >> keys > >> > >> > >> =3D=3D Analysis of aborts =3D=3D > >> > >> We will now discuss aborts, which happen when one party halts the > >> protocol and doesnt continue. Perhaps they had a power cut, their > >> internet broke, or they're a malicious attacker wanting to waste time > >> and money. The other party may try to reestablish a connection for som= e > >> time, but eventually must give up. > >> > >> Number refers to the step number where the abort happened > >> e.g. step 1 means that the party aborted instead of the action happeni= ng > >> on protocol step 1. > >> > >> The party name refers to what that party does > >> e.g. Party1: aborts, Party2/Party3: does a thing in reaction > >> > >> 0. Alice: aborts. Bob/Charlie: do nothing, they havent lost any time o= r > >> money > >> 1. Bob: aborts. Alice: lost no time or money, try with another Bob. > >> Charlie: do nothing > >> 2-3. same as 0. > >> 4. Bob: aborts. Charlie: do nothing. Alice: broadcasts her contract tx > >> and waits for the timeout, loses time and money on miner fees, she'= ll > >> never coinswap with Bob's fidelity bond again. > >> 5. Charlie: aborts. Alice/Bob: lose nothing, find another Charlie to > >> coinswap with. > >> 6. same as 4. > >> 7. similar to 4 but Alice MIGHT not blacklist Bob's fidelity bond, > >> because Bob will also have to broadcast his contract tx and will al= so > >> lose time and money. > >> 8. Charlie: aborts. Bob: broadcast his contract transaction and wait f= or > >> the timeout to get his money back, also broadcast Alice's contract > >> transaction in retaliation. Alice: waits for the timeout on her htl= c > >> tx that Bob broadcasted, will never do a coinswap with Charlie's > >> fidelity bond again. > >> 9. Alice: aborts. Charlie: do nothing, no money or time lost. Bob: > >> broadcast bob contract tx and wait for timeout to get money back, > >> comforted by the knowledge that when Alice comes back online she'll > >> have to do the same thing and waste the same amount of time and > >> money. > >> A-B. same as 8. > >> C-E. Alice: aborts. Bob/Charlie: all broadcast their contract txes and > >> wait for the timeout to get their money back, or if Charlie knows > >> the preimage he uses it to get the money immediately, which Bob c= an > >> read from the blockchain and also use. > >> F. Bob: aborts. Alice: broadcast Charlie htlc tx and use preimage to g= et > >> money immediately, Alice blacklists Bob's fidelity bond. Charlie: > >> broadcast Bob htlc and use preimage to get money immediately. > >> G. Charlie: aborts. Alice: broadcast Charlie htlc and use preimage to > >> get money immediately, Alice blacklists Charlie's fidelity bond. Bo= b: > >> does nothing, already has his privkey. > >> > >> =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 i= s > >> the victim of a DOS they will retaliate by DOSing the previous maker i= n > >> 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 resist > >> DOS because it produces a concrete cost every time a DOS happens. > >> > >> > >> =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 party= '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 > >> 3. Alice: broadcasts one or more of the A htlc txes. Bob/Charlie/Denni= s: > >> do nothing, they havent lost any time or money. > >> 4-6. Bob/Charlie: nothing else is possible except following the protoc= ol > >> or aborting. > >> 7. Bob: broadcasts one or more of the B htlc txes, Alice: broadcasts a= ll > >> her own A htlc txes and waits for the timeout to get her money back= . > >> Charlie: do nothing > >> 8. Charlie: nothing else is possible except following the protocol or > >> aborting. > >> 9. Alice: broadcasts one or more of the A htlc txes. Bob: broadcasts a= ll > >> 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 t= he > >> preimage hash to take the money immediately. Charlie: broadcasts > >> all of B htlc txes and reading the hash value from the blockchai= n, > >> uses it to take the money from B htlc immediately. Bob: broadcas= ts > >> all of A htlc txes, and reading hash from the blockchain, uses i= t > >> to take the money from A htlc immediately. > >> C-E2. Alice: broadcast her own A htlc txes, and after a timeout take t= he > >> money. Bob: broadcast his own B htlc txes and after the timeout > >> take their money. Charlie: broadcast his own C htlc txes and aft= er > >> the timeout take their money. > >> F1. Bob: broadcast one or more of A htcl txes and use the hash preimag= e > >> to get the money immediately. He already knows both privkeys of th= e > >> 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 preima= ge > >> to get his money immediately. Bob's actions were pointless. Alice: > >> cant tell whether Bob or Charlie actually broadcasted, so blacklis= t > >> 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: broadcas= t > >> 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. Th= e > >> 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 wa= y, > >> because one maker could use it to get another one blacklisted (as well > >> as themselves). > >> > >> > >> =3D=3D Conclusion =3D=3D > >> > >> This document describes the first version of the protocol which > >> implements multi-transaction Coinswap, routed Coinswap, fidelity bonds= , > >> a liquidity market and private key handover. I describe the protocol a= nd > >> also analyze aborts of the protocols and deviations from the protocol. > >> > >> _______________________________________________ > >> bitcoin-dev mailing list > >> bitcoin-dev@lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >> > > > --000000000000e5791005ae869b27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Chris,

I forgot to underscore that contract tran= saction output must be grieved by at least a CSV of 1. Otherwise, a malicio= us counterparty can occupy with garbage both the timelock-or-preimage outpu= t and its own anchor output thus blocking you to use the bumping capability= of your own anchor ouput.

A part of this, I think it works.

= > Another possible fix for both vulnerabilities is to separate the
&g= t; timelock and hashlock cases into two separate transactions as described<= br>> by ZmnSCPxj in a recent email to this list. This comes at the cost = of
> breaking private key handover allowing coins to remain unspent i= ndefinitely.

This works too assuming these second-stage transactions= aren't malleable at all (e.g SIGASH_SINGLE). Other ways you can increa= se their feerate/absolute fee and you're back to the initial situation.=

Beyond note also that anchors-on-second-stage are more risky here, = as otherwise your counterparty can again attach a low-feerate child. In cas= e of concurrent broadcast (assuming you haven't achieved to claim the o= utput before timelock expiration due to network outage/mempool-congestion) = you might not see your counterparty version. I.e, your local mempool has th= e timelock tx and the rest of the network the hashlock and your CPFP bump w= on't propagate as being an orphan.

So you're left with a RBF= -range, which is mostly okay minus a theoretical concern : a party guessing= the odds to lose the balance are high can broadcast/send out-of-band the h= ighest-fee bound to miners thus incentivizing them to censor a honest, low-= fee=C2=A0 preimage tx. A "nothing-at-stake-for-genuinely-evil-counterp= arty" issue.

> Another possible fix for the second attack, i= s to encumber the output
> with a `1 OP_CSV` which stops that output = being spent while unconfirmed.
> This seems to be the simplest way if= your aim is to only fix the second
> attack.

Yes you don'= t package fee malleability so an honest party can always unilaterally bump = the feerate and override concurrent bids.


That said, I would lea= n towards anchors and thus unileratel fee bumping. Feerate interactivity am= ong a multi-party protocol should be seen as an oracle to leak the full-nod= e of a participant. By sending a range of conflicting transactions with dif= ferent feerates to a set of network mempools I could theoretically observe = variations in the protocol feerate announced.

I would recommend you = to have a look on this paper, if it's not done yet : https://arxiv.org/pdf/2007.00764.pdf, th= e first one analyzing privacy holistically across Bitcoin layers.

Ch= eers,

Antoine

Le=C2=A0sam. 29 ao=C3=BBt 2020 =C3=A0=C2=A018:03, C= hris Belcher <belcher@riseup.net> a =C3=A9crit=C2=A0:
Hello Antoine,

Thanks for the very useful insights.

It seems having just one contract transaction which includes anchor
outputs in the style already used by Lightning is one way to fix both
these vulnerabilities.

For the first attack, the other side cannot burn the entire balance
because they only have access to the small amount of satoshi of the
anchor output, and to add miner fees they must add their own inputs. So
they'd burn their own coins to miner fees, not the coins in the contrac= t.

For the second attack, the other side cannot do transaction pinning
because there is only one contract transaction, and all the protections
already developed for use with Lightning apply here as well, such as
CPFP carve out.


Another possible fix for both vulnerabilities is to separate the
timelock and hashlock cases into two separate transactions as described
by ZmnSCPxj in a recent email to this list. This comes at the cost of
breaking private key handover allowing coins to remain unspent indefinitely= .

Another possible fix for the second attack, is to encumber the output
with a `1 OP_CSV` which stops that output being spent while unconfirmed. This seems to be the simplest way if your aim is to only fix the second
attack.


These are all the possible fixes I can think of.

Regards
Chris

On 24/08/2020 20:30, Antoine Riard wrote:
> Hello Chris,
>
> I think you might have vulnerability issues with the current design. >
> With regards to the fee model for contract transactions, AFAICT timely=
> confirmation is a fund safety matter for an intermediate hop. Between = the
> offchain preimage reveal phase and the offchain private key handover p= hase,
> the next hop can broadcast your outgoing contract transactions, thus > forcing you to claim quickly backward as you can't assume previous= hop will
> honestly cooperate to achieve the private key handover. This means tha= t
> your range of pre-signed RBF-transactions must theoretically have for = fee
> upper bound the maximum of the contested balance, as game-theory side,= it's
> rational to you to burn your balance instead of letting your counterpa= rty
> claim it after timelock expiration, in face of mempool congestion. Whe= re
> the issue dwells is that this fee is pre-committed and not cancelled w= hen
> the balance change of ownership by the outgoing hop learning the preim= age
> of the haslock output. Thus the previous hop is free to broadcast the<= br> > highest-fee RBF-transactions and burn your balance, as for him, his ba= lance
> is now encoded in the output of the contract transactions on the previ= ous
> link, for which he knows the preimage.
>
> Note, I think this is independent of picking up either relative or abs= olute
> timelocks as what matters is the block delta between two links. Of cou= rse
> you can increase this delta to be week-lengthy and thus decrease the n= eed
> for a compelling fee but a) you may force quickly close with contract<= br> > transactions if the private key handover doesn't happen soon, you = don't
> want to be caught by surprise by congestion so you would close far beh= ind
> delta period expiration like half of it, and b) you increase the time-= value
> of makers funds in case of faulty hop, thus logically increasing the m= aker
> fee and making the cost of the system higher in average. I guess a bet= ter
> solution would be to use dual-anchor outputs has spec'ed out by Li= ghtning,
> it lets the party who has a balance at stake unilaterally increase fee= rate
> with a CPFP. The CPFP is obviously a higher blockchain cost but a) it&= #39;s a
> safety mechanism for a worst-case scenario, 99% of the time they won&#= 39;t be
> committed, b) you might use this CPFP to aggregate change outputs or o= ther
> opportunistically side-usage.
>
> With regards to the preimage release phase, I think you might have a > pinning scenario. The victim would be an intermediate hop, targeted by= a
> malicious taker. The preimage isn't revealed offchain to this vict= im hop. A
> low-feerate version of the outgoing contract transaction is broadcast = and
> not going to confirm, assuming a bit of congestion. As preimage is kno= wn,
> the malicious taker can directly attach a high-fee, low-feerate child<= br> > transaction and thus prevent any replacement of the pinned parent by a=
> honest broadcast of a high-fee RBF-transaction under BIP 125 rules. At= the
> same time, the malicious taker broadcasts the contract tx on the previ= ous
> link and gets it confirmed. At relative timelock expiration, malicious=
> taker claims back the funds. When the pinned transaction spending the<= br> > outgoing link gets evicted (either by replacing child by a higher feer= ate
> or waiting for mempool expiration after 2 weeks), taker gets it confir= med
> this time and claims output through hashlock. Given the relative timel= ock
> blocking the victim, there is not even a race.
>
> I guess restraining the contract transaction to one and only one versi= on
> would overcome this attack. A honest intermediate hop, as soon as seei= ng a
> relative timelock triggered backward would immediately broadcast the > outgoing link contract tx or if it's already in network mempools b= roadcast
> a higher-feerate child. As you don't have valid multiple contract<= br> > transactions, an attacker can't obstruct you to propagate the corr= ect
> child, as you are not blind about the parent txid.
>
> Lastly, one downside of using relative timelocks, in case of one downs= tream
> link failure, it forces every other upstream hops to go onchain to pro= tect
> against this kind of pinning scenario. And this would be a privacy
> breakdown, as a maker would be able to provoke one, thus constraining = every
> upstream hops to go onchain with the same hash and revealing the CoinS= wap
> route.
>
> Let me know if I reviewed the correct transactions circuit model or > misunderstood associated semantic. I might be completely wrong, coming= from
> a LN perspective.
>
> Cheers,
> Antoine
>
> Le mar. 11 ao=C3=BBt 2020 =C3=A0 13:06, Chris Belcher via bitcoin-dev = <
> bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit :
>
>> I'm currently working on implementing CoinSwap (see my other e= mail
>> "Design for a CoinSwap implementation for massively improving= Bitcoin
>> privacy and fungibility").
>>
>> CoinSwaps are special because they look just like regular bitcoin<= br> >> transactions, so they improve the privacy even for people who do n= ot use
>> them. Once CoinSwap is deployed, anyone attempting surveillance of=
>> bitcoin transactions will be forced to ask themselves the question= : how
>> do we know this transaction wasn't a CoinSwap?
>>
>> This email contains a detailed design of the first protocol versio= n. It
>> makes use of the building blocks of multi-transaction CoinSwaps, r= outed
>> CoinSwaps, liquidity market, private key handover, and fidelity bo= nds.
>> It does not include PayJoin-with-CoinSwap, but that's in the p= lan to be
>> added later.
>>
>> =3D=3D Routed CoinSwap =3D=3D
>>
>> Diagram of CoinSwaps in the route:
>>
>>=C2=A0 =C2=A0 =C2=A0Alice =3D=3D=3D=3D> Bob =3D=3D=3D=3D> Cha= rlie =3D=3D=3D=3D> Alice
>>
>> Where (=3D=3D=3D=3D>) means one CoinSwap. Alice gives coins to = Bob, who gives
>> coins to Charlie, who gives coins to Alice. Alice is the market ta= ker
>> and she starts with the hash preimage. She chooses the CoinSwap am= ount
>> and chooses who the makers will be.
>>
>> This design has one market taker and two market makers in its rout= e, but
>> it can easily be extended to any number of makers.
>>
>> =3D=3D Multiple transactions =3D=3D
>>
>> Each single CoinSwap is made up of multiple transactions to avoid = amount
>> correlation
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(a0 BTC) --->=C2=A0 =C2= =A0 =C2=A0(b0 BTC) --->=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(c0 BTC) --->= ;
>>=C2=A0 =C2=A0 =C2=A0Alice (a1 BTC) ---> Bob (b1 BTC) ---> Cha= rlie (c1 BTC) ---> Alice
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(a2 BTC) --->=C2=A0 =C2= =A0 =C2=A0(b2 BTC) --->=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(c2 BTC) --->= ;
>>
>> The arrow (--->) represent funding transactions. The money gets= paid to
>> a 2-of-2 multisig but after the CoinSwap protocol and private key<= br> >> handover is done they will be controlled by the next party in the = route.
>>
>> This example has 6 regular-sized transactions which use approximat= ely
>> the same amount of block space as a single JoinMarket coinjoin wit= h 6
>> parties (1 taker, 5 makers). Yet the privacy provided by this one<= br> >> CoinSwap would be far far greater. It would not have to be repeate= d in
>> the way that Equal-Output CoinJoins must be.
>>
>> =3D=3D Direct connections to Alice =3D=3D=3D
>>
>> Only Alice, the taker, knows the entire route, Bob and Charlie jus= t know
>> their previous and next transactions. Bob and Charlie do not have = direct
>> connections with each other, only with Alice.
>>
>> Diagram of Tor connections:
>>
>>=C2=A0 =C2=A0 =C2=A0Bob=C2=A0 =C2=A0 =C2=A0 Charlie
>>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0/
>>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 /
>>=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0/
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0Alice
>>
>> When Bob and Charlie communicate, they are actually sending and >> receiving messages via Alice who relays them to Charlie or Bob. Th= is
>> 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 wher= e 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.
>>
>>
>> =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 v= ery
>> 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 off= ered
>> of that trended towards zero. So the reality is that takers will p= ay 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 f= ees.
>>
>> The taker will have to set limits on how large the maker's tra= nsactions
>> are, otherwise makers could abuse this by having the taker consoli= date
>> maker's UTXOs for free.
>>
>> =3D=3D Funding transaction definitions =3D=3D
>>
>> Funding transactions are those which pay into the 2-of-2 multisig<= br> >> addresses.
>>
>> Definitions:
>> I =3D initial coinswap amount sent by Alice =3D a0 + a1 + a2
>> (WA, WB, WC) =3D Total value of UTXOs being spent by Alice, Bob, C= harlie
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 respectivel= y. Could be called "wallet Alice", "wallet
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bob", = etc
>> (B, C) =3D Coinswap fees paid by Alice and earned by Bob and Charl= ie.
>> (M1, M2, M3) =3D Miner fees of the first, second, third, etc sets = of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 funding tra= nsactions. Alice will choose what these are
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 since she&#= 39;s paying.
>> multisig(A+B) =3D A 2of2 multisig output with private keys held by= A and B
>>
>> The value in square parentheses refers to the bitcoin amount.
>>
>> Alice funding txes
>>=C2=A0 =C2=A0[WA btc] ---> multisig (Alice+Bob) [I btc]
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chang= e [WA-M1-I btc]
>> Bob funding txes
>>=C2=A0 =C2=A0[WB btc] ---> multisig (Bob+Charlie) [I-M2-B btc] >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chang= e [WB-I+B btc]
>> Charlie funding txes
>>=C2=A0 =C2=A0[WC btc] ---> multisig (Charlie+Alice) [(I-M2-B)-M3= -C btc]
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0chang= e [WC-(I-M2-B)+C btc]
>>
>> Here we've drawn these transactions as single transactions, bu= t they are
>> actually multiple transactions where the outputs add up some value= (e.g.
>> add up to I in Alice's transactions.)
>>
>> =3D=3D=3D Table of balances before and after a successful CoinSwap= =3D=3D=3D
>>
>> If a CoinSwap is successful then all the multisig outputs in the f= unding
>> transactions will become controlled unilaterally by one party. We = can
>> calculate how the balances of each party change.
>>
>> Party=C2=A0 =C2=A0| Before | After
>> --------|--------|-------------------------------------------
>> Alice=C2=A0 =C2=A0| WA=C2=A0 =C2=A0 =C2=A0| WA-M1-I + (I-M2-B)-M3-= C=C2=A0 =3D WA-M1-M2-M3-B-C
>> Bob=C2=A0 =C2=A0 =C2=A0| WB=C2=A0 =C2=A0 =C2=A0| WB-I+B + I=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D WB+B
>> Charlie | WC=C2=A0 =C2=A0 =C2=A0| WC-(I-M2-B)+C + I-M2-B=C2=A0 =C2= =A0=3D WC+C
>>
>> After a successful coinswap, we see Alice's balance goes down = by the
>> miner fees and the coinswap fees. Bob's and Charlie's bala= nce goes up by
>> their coinswap fees.
>>
>> =3D=3D Contract transaction definitions =3D=3D
>>
>> Contract transactions are those which may spend from the 2-of-2 mu= ltisig
>> outputs, they transfer the coins into a contract where the coins c= an be
>> spent either by waiting for a timeout or providing a hash preimage=
>> value. Ideally contract transactions will never be broadcast but t= heir
>> existence keeps all parties honest.
>>
>> M~ is miner fees, which we treat as a random variable, and ultimat= ely
>> set by whichever pre-signed RBF tx get mined. When we talk about _= the_
>> contract tx, we actually mean perhaps 20-30 transactions which onl= y
>> differ by the miner fee and have RBF enabled, so they can be broad= casted
>> in sequence to get the contract transaction mined regardless of th= e
>> demand for block space.
>>
>> (Alice+timelock_A OR Bob+hash) =3D Is an output which can be spent=
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 either with Alice'= s private key
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 after waiting for a re= lative
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 timelock_A, or by Bob&= #39;s private key by
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 revealing a hash preim= age value
>>
>> Alice contract tx:
>>=C2=A0 =C2=A0 =C2=A0multisig (Alice+Bob) ---> (Alice+timelock_A = OR Bob+hash)
>>=C2=A0 =C2=A0 =C2=A0[I btc]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[I-M~ btc]
>> Bob contract tx:
>>=C2=A0 =C2=A0 =C2=A0multisig (Bob+Charlie) ---> (Bob+timelock_B = OR Charlie+hash)
>>=C2=A0 =C2=A0 =C2=A0[I-M2-B btc]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 [I-M2-B-M~ btc]
>> Charlie contract tx:
>>=C2=A0 =C2=A0 =C2=A0multisig (Charlie+Alice)=C2=A0 ---> (Charlie= +timelock_C OR Alice+hash)
>>=C2=A0 =C2=A0 =C2=A0[(I-M2-B)-M3-C btc]=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 [(I-M2-B)-M3-C-M~ btc]
>>
>>
>> =3D=3D=3D Table of balances before/after CoinSwap using contracts = transactions
>> =3D=3D=3D
>>
>> In this case the parties had to get their money back by broadcasti= ng and
>> mining the contract transactions and waiting for timeouts.
>>
>> Party=C2=A0 =C2=A0| Before | After
>> --------|--------|--------------------------------------------
>> Alice=C2=A0 =C2=A0| WA=C2=A0 =C2=A0 =C2=A0| WA-M1-I + I-M~=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D WA-M1-M~<= br> >> Bob=C2=A0 =C2=A0 =C2=A0| WB=C2=A0 =C2=A0 =C2=A0| WB-I+B + I-M2-B-M= ~=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=3D WB-M2-M~
>> Charlie | WC=C2=A0 =C2=A0 =C2=A0| WC-(I-M2-B)+C + (I-M2-B)-M3-C-M~= =3D WC-M3-M~
>>
>> In the timeout failure case, every party pays for their own miner = fees.
>> And nobody earns or spends any coinswap fees. So even for a market= maker
>> its possible for their wallet balance to go down sometimes, althou= gh as
>> we shall see there are anti-DOS features which make this unlikely = to
>> happen often.
>>
>> A possible attack by a malicious Alice is that she chooses M1 to b= e very
>> low (e.g. 1 sat/vbyte) and sets M2 and M3 to be very high (e.g. 10= 00
>> 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 litt= le cost to the
>> malicious taker Alice. So to defend against this attack Bob and Ch= arlie
>> must refuse to sign a contract transaction if the corresponding fu= nding
>> transaction pays miner fees greater than Alice's funding trans= action.
>>
>>
>> There can also be a failure case where each party gets their money= using
>> hash preimage values instead of timeouts. Note that each party has= to
>> sweep the output before the timeout expires, so that will cost an<= br> >> additional miner fee M~.
>>
>> Party=C2=A0 =C2=A0| Before | After
>> --------|--------|------------------------------------------------= ------
>> Alice=C2=A0 =C2=A0| WA=C2=A0 =C2=A0 =C2=A0| WA-M1-I + (I-M2-B)-M3-= C-M~ - M~ =3D WA-M1-M2-M3-B-C-2M~
>> Bob=C2=A0 =C2=A0 =C2=A0| WB=C2=A0 =C2=A0 =C2=A0| WB-I+B + I-M~ - M= ~=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =3D WB+B-2M~
>> Charlie | WC=C2=A0 =C2=A0 =C2=A0| WC-(I-M2-B)+C + I-M2-B-M~ - M~= =C2=A0 =3D WC+C-2M~
>>
>> In this situation the makers Bob and Charlie earn their CoinSwap f= ees,
>> but they pay an additional miner fee twice. Alice pays for all the=
>> funding transaction miner fees, and the CoinSwap fees, and two
>> additional miner fees. And she had her privacy damaged because the=
>> entire world saw on the blockchain the contract script.
>>
>> Using the timelock path is like a refund, everyone's coin just= comes
>> back to them. Using the preimage is like the CoinSwap transaction<= br> >> happened, with the coins being sent ahead one hop. Again note that= if
>> the preimage is used then coinswap fees are paid.
>>
>> =3D=3D=3D Staggered timelocks =3D=3D=3D
>>
>> 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 kno= wledge
>> of the hash preimage so she must have a longest 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 n= eed to
>> agree on their public keys. We can avoid one round trip by using t= he EC
>> tweak trick.
>>
>> When Alice, the taker, downloads the entire offer book for the liq= uidity
>> market, the offers will also contain a EC public key. Alice can tw= eak
>> 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. >>
>>=C2=A0 =C2=A0 =C2=A0q =3D EC privkey generated by maker
>>=C2=A0 =C2=A0 =C2=A0Q =3D q.G =3D EC pubkey published by maker
>>
>>=C2=A0 =C2=A0 =C2=A0p =3D nonce generated by taker
>>=C2=A0 =C2=A0 =C2=A0P =3D p.G =3D nonce point calculated by taker >>
>>=C2=A0 =C2=A0 =C2=A0R =3D Q + P =3D pubkey used in bitcoin transact= ion
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0=3D (q + p).G
>>
>> Taker sends unsigned transaction which pays to multisig using pubk= ey Q,
>> and also sends nonce p. The maker can use nonce p to calculate (q = + p)
>> which is the private key of pubkey R.
>>
>> Taker doesnt know the privkey because they are unable to find q be= cause
>> of the ECDLP.
>>
>> Any eavesdropper can see the nonce p and easily calculate the poin= t R
>> too but Tor communication is encrypted so this isnt a concern.
>>
>> None of the makers in the route know each other's Q values, so= Alice the
>> taker will generate a nonce p on their behalf and send it over. I<= br> >> believe this cant be used for any kind of attack, because the sign= ing
>> maker will always check that the nonce results in the public key >> included in the transaction they're signing, and they'll n= ever sign a
>> transaction not in their interests.
>>
>>
>> =3D=3D Protocol =3D=3D
>>
>> This section is the most important part of this document.
>>
>> Definitions:
>> fund =3D all funding txes (remember in this multi-tx protocol ther= e can be
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 multiple txes which together make up th= e funding)
>> A htlc =3D all htlc contract txes (fully signed) belonging to part= y A
>> A unsign htcl =3D all unsigned htlc contract txes belonging to par= ty A
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0inclu= ding the nonce point p used to calculate the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0maker= 's pubkey.
>> p =3D nonce point p used in the tweak EC protocol for calculating = the
>>=C2=A0 =C2=A0 =C2=A0maker's pubkey
>> A htlc B/2 =3D Bob's signature for the 2of2 multisig of the Al= ice htlc
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 contract tx
>> privA(A+B) =3D private key generated by Alice in the output
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 multisig (Alice+Bo= b)
>>
>>
>>=C2=A0 | Alice=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Bob=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Charlie=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|
>>=C2=A0 |=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D|=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D|
>> 0. A unsign htlc ---->=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
>> 1.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<---- = A htlc B/2=C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
>> 2. ***** BROADCAST AND MINE ALICE FUNDING TXES ******=C2=A0 |
>> 3. A fund+htlc+p ---->=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
>> 4.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = B unsign htlc ---->=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
>> 5.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<---- B htlc C/2= =C2=A0 =C2=A0 |
>> 6. ******* BROADCAST AND MINE BOB FUNDING TXES ******* |
>> 7.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = B fund+htlc+p ---->=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
>> 8.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<-----= ----------------- C unsign htlc |
>> 9.=C2=A0 =C2=A0 C htlc A/2 ---------------------->=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>> A. ***** BROADCAST AND MINE CHARLIE FUNDING TXES ***** |
>> B.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<-----= ----------------- C fund+htlc+p |
>> C. hash preimage ---------------------->=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>> D. hash preimage ---->=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
>> E.=C2=A0 =C2=A0 privA(A+B) ---->=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
>> F.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= =C2=A0 =C2=A0 privB(B+C) ---->=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|
>> G.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<-----= ----------------- privC(C+A)=C2=A0 =C2=A0 |
>>
>> =3D=3D Protocol notes =3D=3D
>> 0-2 are the steps which setup Alice's funding tx and her contr= act tx for
>>=C2=A0 =C2=A0 =C2=A0possible refund
>> 4-5 same as 0-2 but for Bob
>> 8-9 same as 0-2 but for Charlie
>> 3,7 is proof to the next party that the previous party has already=
>>=C2=A0 =C2=A0 =C2=A0committed miner fees to getting a transaction m= ined, and therefore
>>=C2=A0 =C2=A0 =C2=A0this isnt a DOS attack. The step also reveals t= he fully-signed
>>=C2=A0 =C2=A0 =C2=A0contract transaction which the party can use to= get their money back
>>=C2=A0 =C2=A0 =C2=A0with a preimage.
>> C-G is revealing the hash preimage to all, and handing over the pr= ivate
>>=C2=A0 =C2=A0 =C2=A0keys
>>
>>
>> =3D=3D Analysis of aborts =3D=3D
>>
>> We will now discuss aborts, which happen when one party halts the<= br> >> protocol and doesnt continue. Perhaps they had a power cut, their<= br> >> internet broke, or they're a malicious attacker wanting to was= te time
>> and money. The other party may try to reestablish a connection for= some
>> time, but eventually must give up.
>>
>> Number refers to the step number where the abort happened
>> e.g. step 1 means that the party aborted instead of the action hap= pening
>> on protocol step 1.
>>
>> The party name refers to what that party does
>> e.g. Party1: aborts, Party2/Party3: does a thing in reaction
>>
>> 0. Alice: aborts. Bob/Charlie: do nothing, they havent lost any ti= me or
>>=C2=A0 =C2=A0 money
>> 1. Bob: aborts. Alice: lost no time or money, try with another Bob= .
>>=C2=A0 =C2=A0 Charlie: do nothing
>> 2-3. same as 0.
>> 4. Bob: aborts. Charlie: do nothing. Alice: broadcasts her contrac= t tx
>>=C2=A0 =C2=A0 and waits for the timeout, loses time and money on mi= ner fees, she'll
>>=C2=A0 =C2=A0 never coinswap with Bob's fidelity bond again. >> 5. Charlie: aborts. Alice/Bob: lose nothing, find another Charlie = to
>>=C2=A0 =C2=A0 coinswap with.
>> 6. same as 4.
>> 7. similar to 4 but Alice MIGHT not blacklist Bob's fidelity b= ond,
>>=C2=A0 =C2=A0 because Bob will also have to broadcast his contract = tx and will also
>>=C2=A0 =C2=A0 lose time and money.
>> 8. Charlie: aborts. Bob: broadcast his contract transaction and wa= it for
>>=C2=A0 =C2=A0 the timeout to get his money back, also broadcast Ali= ce's contract
>>=C2=A0 =C2=A0 transaction in retaliation. Alice: waits for the time= out on her htlc
>>=C2=A0 =C2=A0 tx that Bob broadcasted, will never do a coinswap wit= h Charlie's
>>=C2=A0 =C2=A0 fidelity bond again.
>> 9. Alice: aborts. Charlie: do nothing, no money or time lost. Bob:=
>>=C2=A0 =C2=A0 broadcast bob contract tx and wait for timeout to get= money back,
>>=C2=A0 =C2=A0 comforted by the knowledge that when Alice comes back= online she'll
>>=C2=A0 =C2=A0 have to do the same thing and waste the same amount o= f time and
>>=C2=A0 =C2=A0 money.
>> A-B. same as 8.
>> C-E. Alice: aborts. Bob/Charlie: all broadcast their contract txes= and
>>=C2=A0 =C2=A0 =C2=A0 wait for the timeout to get their money back, = or if Charlie knows
>>=C2=A0 =C2=A0 =C2=A0 the preimage he uses it to get the money immed= iately, which Bob can
>>=C2=A0 =C2=A0 =C2=A0 read from the blockchain and also use.
>> F. Bob: aborts. Alice: broadcast Charlie htlc tx and use preimage = to get
>>=C2=A0 =C2=A0 money immediately, Alice blacklists Bob's fidelit= y bond. Charlie:
>>=C2=A0 =C2=A0 broadcast Bob htlc and use preimage to get money imme= diately.
>> G. Charlie: aborts. Alice: broadcast Charlie htlc and use preimage= to
>>=C2=A0 =C2=A0 get money immediately, Alice blacklists Charlie's= fidelity bond. Bob:
>>=C2=A0 =C2=A0 does nothing, already has his privkey.
>>
>> =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 rou= te is
>> the victim of a DOS they will retaliate by DOSing the previous mak= er in
>> the route. This may seem unnecessary and unfair (after all why was= te
>> even more time and block space) but is actually the best way to re= sist
>> DOS because it produces a concrete cost every time a DOS happens.<= br> >>
>>
>> =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<= br> >> contract tx when they shouldnt have.
>>
>> The party name refers to what that party does, followed by other p= arty'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 number= ed
>> e.g. A1 A2 A2 etc
>>
>>
>> 0-2. Alice/Bob/Charlie: nothing else is possible except following = the
>>=C2=A0 =C2=A0 =C2=A0 protocol or aborting
>> 3. Alice: broadcasts one or more of the A htlc txes. Bob/Charlie/D= ennis:
>>=C2=A0 =C2=A0 do nothing, they havent lost any time or money.
>> 4-6. Bob/Charlie: nothing else is possible except following the pr= otocol
>>=C2=A0 =C2=A0 =C2=A0 or aborting.
>> 7. Bob: broadcasts one or more of the B htlc txes, Alice: broadcas= ts all
>>=C2=A0 =C2=A0 her own A htlc txes and waits for the timeout to get = her money back.
>>=C2=A0 =C2=A0 Charlie: do nothing
>> 8. Charlie: nothing else is possible except following the protocol= or
>>=C2=A0 =C2=A0 aborting.
>> 9. Alice: broadcasts one or more of the A htlc txes. Bob: broadcas= ts all
>>=C2=A0 =C2=A0 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:<= br> >>=C2=A0 =C2=A0 broadcasts all their own htlc txes and waits for the = timeout to get
>>=C2=A0 =C2=A0 their money back.
>> C-E1. Alice: broadcasts all of C htlc txes and uses her knowledge = of the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0preimage hash to take the money immediat= ely. Charlie: broadcasts
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0all of B htlc txes and reading the hash = value from the blockchain,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0uses it to take the money from B htlc im= mediately. Bob: broadcasts
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0all of A htlc txes, and reading hash fro= m the blockchain, uses it
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0to take the money from A htlc immediatel= y.
>> C-E2. Alice: broadcast her own A htlc txes, and after a timeout ta= ke the
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0money. Bob: broadcast his own B htlc txe= s and after the timeout
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0take their money. Charlie: broadcast his= own C htlc txes and after
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0the timeout take their money.
>> F1. Bob: broadcast one or more of A htcl txes and use the hash pre= image
>>=C2=A0 =C2=A0 =C2=A0to get the money immediately. He already knows = both privkeys of the
>>=C2=A0 =C2=A0 =C2=A0multisig so this is pointless and just damages = privacy and wastes
>>=C2=A0 =C2=A0 =C2=A0miner fees. Alice: blacklist Bob's fidelity= bond.
>> F2. Bob: broadcast one or more of the C htlc txes. Charlie: use pr= eimage
>>=C2=A0 =C2=A0 =C2=A0to get his money immediately. Bob's actions= were pointless. Alice:
>>=C2=A0 =C2=A0 =C2=A0cant tell whether Bob or Charlie actually broad= casted, so blacklist
>>=C2=A0 =C2=A0 =C2=A0both fidelity bonds.
>> G1. Charlie: broadcast one or more of B htcl txes and use the hash=
>>=C2=A0 =C2=A0 =C2=A0preimage to get the money immediately. He alrea= dy knows both
>>=C2=A0 =C2=A0 =C2=A0privkeys of the multisig so this is pointless a= nd just damages
>>=C2=A0 =C2=A0 =C2=A0privacy and wastes miner fees. Alice: cant tell= whether Bob or
>>=C2=A0 =C2=A0 =C2=A0Charlie actually broadcasted, so blacklist both= fidelity bonds.
>> G2. Charlie: broadcast one or more of the A htlc txes. Alice: broa= dcast
>>=C2=A0 =C2=A0 =C2=A0the remaining A htlc txes and use preimage to g= et her money
>>=C2=A0 =C2=A0 =C2=A0immediately. Charlies's actions were pointl= ess. Alice: blacklist
>>=C2=A0 =C2=A0 =C2=A0Charlie's fidelity bond.
>>
>> The multisig outputs of the funding transactions can stay unspent<= br> >> indefinitely. However the parties must always be watching the netw= ork
>> and ready to respond with their own sweep using a preimage. This i= s
>> because the other party still possesses a fully-signed contract tx= . The
>> 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 righ= t way,
>> because one maker could use it to get another one blacklisted (as = well
>> as themselves).
>>
>>
>> =3D=3D Conclusion =3D=3D
>>
>> This document describes the first version of the protocol which >> implements multi-transaction Coinswap, routed Coinswap, fidelity b= onds,
>> a liquidity market and private key handover. I describe the protoc= ol and
>> also analyze aborts of the protocols and deviations from the proto= col.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
>>
>
--000000000000e5791005ae869b27--