Re: [bitcoin-dev] Detailed protocol design for routed multi-transaction CoinSwap

[seid Mohammed <seidmda@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 33572 bytes --]

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 <belcher@riseup.net> 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
>> >>
>> >
>>
>

[-- Attachment #2: Type: text/html, Size: 38858 bytes --]