subscribe pls https://www.youtube.com/channel/UCcRPSO-n2HgolBFKzW3re4Q On Saturday, September 5, 2020, Antoine Riard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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ût 2020 à 18:03, Chris Belcher a écrit : > >> 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 >> the >> > 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 >> 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 >> counterparty >> > claim it after timelock expiration, in face of mempool congestion. Where >> > the issue dwells is that this fee is pre-committed and not cancelled >> when >> > the balance change of ownership by the outgoing hop learning the >> preimage >> > 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 >> previous >> > 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 >> course >> > you can increase this delta to be week-lengthy and thus decrease the >> need >> > 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 >> behind >> > 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 >> better >> > 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 >> and >> > not going to confirm, assuming a bit of congestion. As preimage is >> known, >> > 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 >> previous >> > 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 >> feerate >> > or waiting for mempool expiration after 2 weeks), taker gets it >> confirmed >> > this time and claims output through hashlock. Given the relative >> timelock >> > blocking the victim, there is not even a race. >> > >> > I guess restraining the contract transaction to one and only one version >> > would overcome this attack. A honest intermediate hop, as soon as >> seeing 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 >> CoinSwap >> > 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ût 2020 à 13:06, Chris Belcher via bitcoin-dev < >> > bitcoin-dev@lists.linuxfoundation.org> a écrit : >> > >> >> 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 >> 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 version. It >> >> makes use of the building blocks of multi-transaction CoinSwaps, routed >> >> CoinSwaps, liquidity market, private key handover, and fidelity bonds. >> >> It does not include PayJoin-with-CoinSwap, but that's in the plan to be >> >> added later. >> >> >> >> == Routed CoinSwap == >> >> >> >> Diagram of CoinSwaps in the route: >> >> >> >> Alice ====> Bob ====> Charlie ====> Alice >> >> >> >> Where (====>) means one CoinSwap. Alice gives coins to Bob, who 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, >> but >> >> it can easily be extended to any number of makers. >> >> >> >> == Multiple transactions == >> >> >> >> Each single CoinSwap is made up of multiple transactions to avoid >> amount >> >> 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 to >> >> 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 >> route. >> >> >> >> 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. >> >> >> >> == Direct connections to Alice === >> >> >> >> 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. >> >> >> >> >> >> === Miner fees === >> >> >> >> 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. >> >> >> >> == Funding transaction definitions == >> >> >> >> Funding transactions are those which pay into the 2-of-2 multisig >> >> addresses. >> >> >> >> Definitions: >> >> I = initial coinswap amount sent by Alice = a0 + a1 + a2 >> >> (WA, WB, WC) = Total value of UTXOs being spent by Alice, Bob, Charlie >> >> respectively. Could be called "wallet Alice", "wallet >> >> Bob", etc >> >> (B, C) = Coinswap fees paid by Alice and earned by Bob and Charlie. >> >> (M1, M2, M3) = 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) = 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 >> >> [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 >> are >> >> actually multiple transactions where the outputs add up some value >> (e.g. >> >> add up to I in Alice's transactions.) >> >> >> >> === Table of balances before and after a successful CoinSwap === >> >> >> >> If a CoinSwap is successful then all the multisig outputs in the >> funding >> >> 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 = WA-M1-M2-M3-B-C >> >> Bob | WB | WB-I+B + I = WB+B >> >> Charlie | WC | WC-(I-M2-B)+C + I-M2-B = 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. >> >> >> >> == Contract transaction definitions == >> >> >> >> 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. >> >> >> >> (Alice+timelock_A OR Bob+hash) = 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 >> >> >> >> 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] >> >> >> >> >> >> === Table of balances before/after CoinSwap using contracts >> transactions >> >> === >> >> >> >> In this case the parties had to get their money back by broadcasting >> and >> >> mining the contract transactions and waiting for timeouts. >> >> >> >> Party | Before | After >> >> --------|--------|-------------------------------------------- >> >> Alice | WA | WA-M1-I + I-M~ = WA-M1-M~ >> >> Bob | WB | WB-I+B + I-M2-B-M~ = WB-M2-M~ >> >> Charlie | WC | WC-(I-M2-B)+C + (I-M2-B)-M3-C-M~ = 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, although 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 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. >> >> >> >> >> >> 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 >> >> additional miner fee M~. >> >> >> >> Party | Before | After >> >> --------|--------|------------------------------------------ >> ------------ >> >> Alice | WA | WA-M1-I + (I-M2-B)-M3-C-M~ - M~ = >> WA-M1-M2-M3-B-C-2M~ >> >> Bob | WB | WB-I+B + I-M~ - M~ = WB+B-2M~ >> >> Charlie | WC | WC-(I-M2-B)+C + I-M2-B-M~ - M~ = 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. >> >> >> >> === Staggered timelocks === >> >> >> >> 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. >> >> >> >> == EC tweak to reduce one round trip == >> >> >> >> 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 = EC privkey generated by maker >> >> Q = q.G = EC pubkey published by maker >> >> >> >> p = nonce generated by taker >> >> P = p.G = nonce point calculated by taker >> >> >> >> R = Q + P = pubkey used in bitcoin transaction >> >> = (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 because >> >> 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 >> the >> >> 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. >> >> >> >> >> >> == Protocol == >> >> >> >> This section is the most important part of this document. >> >> >> >> Definitions: >> >> fund = all funding txes (remember in this multi-tx protocol there can >> be >> >> multiple txes which together make up the funding) >> >> A htlc = all htlc contract txes (fully signed) belonging to party A >> >> A unsign htcl = all unsigned htlc contract txes belonging to party A >> >> including the nonce point p used to calculate the >> >> maker's pubkey. >> >> p = nonce point p used in the tweak EC protocol for calculating the >> >> maker's pubkey >> >> A htlc B/2 = Bob's signature for the 2of2 multisig of the Alice htlc >> >> contract tx >> >> privA(A+B) = private key generated by Alice in the output >> >> multisig (Alice+Bob) >> >> >> >> >> >> | Alice | Bob | Charlie | >> >> |=================|=================|=================| >> >> 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) | >> >> >> >> == Protocol notes == >> >> 0-2 are the steps which setup Alice's funding tx and her contract tx >> for >> >> 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 >> back >> >> with a preimage. >> >> C-G is revealing the hash preimage to all, and handing over the private >> >> keys >> >> >> >> >> >> == Analysis of aborts == >> >> >> >> 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 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 >> happening >> >> 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 or >> >> 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 >> also >> >> lose time and money. >> >> 8. Charlie: aborts. Bob: broadcast his contract transaction and wait >> for >> >> the timeout to get his money back, also broadcast Alice's contract >> >> transaction in retaliation. Alice: waits for the timeout on her htlc >> >> 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 >> can >> >> read from the blockchain and also use. >> >> F. Bob: aborts. Alice: broadcast Charlie htlc tx and use preimage to >> get >> >> 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. >> Bob: >> >> does nothing, already has his privkey. >> >> >> >> ==== Retaliation as DOS-resistance ==== >> >> >> >> 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 resist >> >> DOS because it produces a concrete cost every time a DOS happens. >> >> >> >> >> >> == Analysis of deviations == >> >> >> >> 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/Dennis: >> >> do nothing, they havent lost any time or money. >> >> 4-6. Bob/Charlie: nothing else is possible except following the >> protocol >> >> or aborting. >> >> 7. 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 >> >> 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 >> all >> >> 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 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: blacklist Bob's fidelity bond. >> >> F2. Bob: broadcast one or more of the C htlc txes. Charlie: use >> preimage >> >> 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: broadcast >> >> 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. 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 right >> way, >> >> because one maker could use it to get another one blacklisted (as well >> >> as themselves). >> >> >> >> >> >> == Conclusion == >> >> >> >> 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 >> and >> >> 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 >> >> >> > >> >