path: root/73/68a068dd5a297978ad88125bbc1f5973538eca

Return-Path: <seidmda@gmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DBD82C0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Sep 2020 03:07:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id B2F2C86D28
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Sep 2020 03:07:00 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id l7OoCsTm2yRS
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Sep 2020 03:06:56 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-ed1-f50.google.com (mail-ed1-f50.google.com
 [209.85.208.50])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id BB12785F89
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  6 Sep 2020 03:06:55 +0000 (UTC)
Received: by mail-ed1-f50.google.com with SMTP id ay8so9473986edb.8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 05 Sep 2020 20:06:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
 bh=QAUd4mK/nsSua85W0hLRvQitVsxreTNfsFdxT9Gjq8o=;
 b=BWCLkPgH2Ptij3PLWETPN+ug4uehQDU7J8bH5H4DjtATSw18gOG6yA/PGRoDZ1RqM3
 M9uk0zc3Kc3TiHX4RNxe5Nc86TCU1Os4he8svakDot99cOsQOGaaZ/BxUwj6ddTlAyWZ
 Py6EZx6jQfPv/8A1TydPqsSDYWbTDMHRLrPuNDVNB7+3aOL+0pV7nS1uTU0BHzd7yDA/
 L6Y0xNtj1gC1acBEdHCt2YVed6EBR6ynysEvTbg8w5xI6SamkcTioYvInEgYrD5NRfky
 V2cRUmyw6HCWl3mTJqQadY9Mq53meNZNUTyFMgyjzN/acnx+TcWmC5zaBWu0JlOaiPL4
 92fw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to;
 bh=QAUd4mK/nsSua85W0hLRvQitVsxreTNfsFdxT9Gjq8o=;
 b=ANuaCduc2T/u7NdFEZj5jZ6HSZLnBITP0PV6vn7h0KZypS64PG2XSv2qW9UMT+m/OY
 2HUdbU6xxUgIJh3VIZa1uFSA0Ukrqyhn0SskwCnG7AZQaj0hlMwaS+p4oLRSQuEtXLXf
 TpYzsL/LUDviZSKKHBvntTAjFxH84pWKcaDi1S/u+3eTkOdliLoSxNMTb4gLyt++cLTF
 gnrk+FmWhQeb/7dIXBNbcuBO3kBfBpHlB9vaXDE0PybCymunCqLX4YEEsLPAGjR3Pv0A
 cib8UuMf2L5cOvPqsSCWhhcK/9Oa1rPUvj/pH5cAChEfTDyQI7Q1c1u463dzU1POqbSM
 I3BA==
X-Gm-Message-State: AOAM530gZiy+S87upXNyZdnDEnxhdg4l6k4VDi3buMPnIIH0zaEr1KF2
 eK5cFD/qJjk5NEWxUUwTCQYl3pG9KDdjyKwtTkhcX+d1iEc=
X-Google-Smtp-Source: ABdhPJyUr70ZLU4I/WmgykBSfmJCE8nl/xS6PCYIAn9t7dRFVFf0j5pIkAJx27N0Mj4qJ04owCKVYx/pmO057odClgo=
X-Received: by 2002:a50:8d4b:: with SMTP id t11mr16237193edt.5.1599361613957; 
 Sat, 05 Sep 2020 20:06:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a50:208a:0:0:0:0:0 with HTTP;
 Sat, 5 Sep 2020 20:06:52 -0700 (PDT)
In-Reply-To: <CALZpt+GCwksRTxtyOka75caTGFmP0t6+yjWHthWcaMb9L52M5g@mail.gmail.com>
References: <813e51a1-4252-08c0-d42d-5cef32f684bc@riseup.net>
 <CALZpt+GxKDEDAGUH3Jb3rcZdh_jy_depLRE5KzGTpkZOLVH+QA@mail.gmail.com>
 <d08ddff2-f62a-661b-d9cf-2f84f7d3ea9e@riseup.net>
 <CALZpt+GCwksRTxtyOka75caTGFmP0t6+yjWHthWcaMb9L52M5g@mail.gmail.com>
From: seid Mohammed <seidmda@gmail.com>
Date: Sun, 6 Sep 2020 06:06:52 +0300
Message-ID: <CAL00YY2qAWiUf28GZnweHpgtCE8pao5p83CtrsrA5Kgx_6ZKEw@mail.gmail.com>
To: Antoine Riard <antoine.riard@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000de0d3705ae9c64e5"
X-Mailman-Approved-At: Sun, 06 Sep 2020 06:16:43 +0000
Subject: Re: [bitcoin-dev] Detailed protocol design for routed
 multi-transaction CoinSwap
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Sep 2020 03:07:01 -0000

--000000000000de0d3705ae9c64e5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 b=
y
> 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 th=
us
> 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 outpu=
t
> 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 <belcher@riseup.net=
> 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
>> 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 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
>> counterparty
>> > 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
>> 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 versi=
on
>> > 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=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
>> use
>> >> them. Once CoinSwap is deployed, anyone attempting surveillance of
>> >> bitcoin transactions will be forced to ask themselves the question: h=
ow
>> >> 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, rout=
ed
>> >> 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.
>> >>
>> >> =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, w=
ho 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 amoun=
t
>> >> 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.
>> >>
>> >> =3D=3D Multiple transactions =3D=3D
>> >>
>> >> 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 i=
n
>> >> 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
>> 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 priva=
te
>> >> 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 whe=
re
>> >> the maker could contribute to miner fees, but the market price offere=
d
>> >> 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 transactio=
ns
>> >> are, otherwise makers could abuse this by having the taker consolidat=
e
>> >> 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, Char=
lie
>> >>                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 =
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.)
>> >>
>> >> =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
>> 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  =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
>> 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 thei=
r
>> >> 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) =3D Is an output which can be spent
>> >>                                  either with Alice's private key
>> >>                                  after waiting for a relative
>> >>                                  timelock_A, or by Bob's private key =
by
>> >>                                  revealing a hash preimage value
>> >>
>> >> 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
>> transactions
>> >> =3D=3D=3D
>> >>
>> >> 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~                   =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 fee=
s.
>> >> 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 muc=
h
>> >> 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 Charl=
ie
>> >> must refuse to sign a contract transaction if the corresponding fundi=
ng
>> >> 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~ =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 tak=
e
>> >> 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.
>> >>
>> >> =3D=3D EC tweak to reduce one round trip =3D=3D
>> >>
>> >> When two parties are agreeing on a 2-of-2 multisig address, they need
>> to
>> >> agree on their public keys. We can avoid one round trip by using the =
EC
>> >> tweak trick.
>> >>
>> >> When Alice, the taker, downloads the entire offer book for the
>> liquidity
>> >> market, the offers will also contain a EC public key. Alice can tweak
>> >> this to generate a brand new public key for which the maker knows the
>> >> private key. This public key will be one of the keys in the 2-of-2
>> >> multisig. This feature removes one round trip from the protocol.
>> >>
>> >>     q =3D EC privkey generated by maker
>> >>     Q =3D q.G =3D EC pubkey published by maker
>> >>
>> >>     p =3D nonce generated by taker
>> >>     P =3D p.G =3D nonce point calculated by taker
>> >>
>> >>     R =3D Q + P =3D pubkey used in bitcoin transaction
>> >>       =3D (q + p).G
>> >>
>> >> 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 becau=
se
>> >> 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.
>> >>
>> >>
>> >> =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 c=
an
>> 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 htl=
c
>> >>              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
>> 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 therefor=
e
>> >>     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 priva=
te
>> >>     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 so=
me
>> >> 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 t=
x
>> >>    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 ht=
lc
>> >>    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'l=
l
>> >>    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 an=
d
>> >>      wait for the timeout to get their money back, or if Charlie know=
s
>> >>      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.
>> >>
>> >> =3D=3D=3D=3D Retaliation as DOS-resistance =3D=3D=3D=3D
>> >>
>> >> In some situations (e.g. step 8.) if one maker in the coinswap route =
is
>> >> the victim of a DOS they will retaliate by DOSing the previous maker =
in
>> >> the route. This may seem unnecessary and unfair (after all why waste
>> >> even more time and block space) but is actually the best way to resis=
t
>> >> DOS because it produces a concrete cost every time a DOS happens.
>> >>
>> >>
>> >> =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/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 bac=
k.
>> >>    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 ge=
t
>> >>    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: broadcast=
s
>> >>       all of B htlc txes and reading the hash value from the
>> blockchain,
>> >>       uses it to take the money from B htlc immediately. Bob:
>> broadcasts
>> >>       all of A htlc txes, and reading hash from the blockchain, uses =
it
>> >>       to take the money from A htlc immediately.
>> >> C-E2. Alice: broadcast her own A htlc txes, and after a timeout take
>> the
>> >>       money. Bob: broadcast his own B htlc txes and after the timeout
>> >>       take their money. Charlie: broadcast his own C htlc txes and
>> after
>> >>       the timeout take their money.
>> >> F1. Bob: broadcast one or more of A htcl txes and use the hash preima=
ge
>> >>     to get the money immediately. He already knows both privkeys of t=
he
>> >>     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 blackli=
st
>> >>     both fidelity bonds.
>> >> G1. Charlie: broadcast one or more of B htcl txes and use the hash
>> >>     preimage to get the money immediately. He already knows both
>> >>     privkeys of the multisig so this is pointless and just damages
>> >>     privacy and wastes miner fees. Alice: cant tell whether Bob or
>> >>     Charlie actually broadcasted, so blacklist both fidelity bonds.
>> >> G2. Charlie: broadcast one or more of the A htlc txes. Alice: broadca=
st
>> >>     the remaining A htlc txes and use preimage to get her money
>> >>     immediately. Charlies's actions were pointless. Alice: blacklist
>> >>     Charlie's fidelity bond.
>> >>
>> >> The multisig outputs of the funding transactions can stay unspent
>> >> indefinitely. However the parties must always be watching the network
>> >> and ready to respond with their own sweep using a preimage. This is
>> >> because the other party still possesses a fully-signed contract tx. T=
he
>> >> parties respond in the same way as in steps C-E1, F2 and G2. Alice's
>> >> reaction of blacklisting both fidelity bonds might not be the right
>> way,
>> >> because one maker could use it to get another one blacklisted (as wel=
l
>> >> as themselves).
>> >>
>> >>
>> >> =3D=3D Conclusion =3D=3D
>> >>
>> >> This document describes the first version of the protocol which
>> >> implements multi-transaction Coinswap, routed Coinswap, fidelity bond=
s,
>> >> 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
>> >>
>> >
>>
>

--000000000000de0d3705ae9c64e5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

--000000000000de0d3705ae9c64e5--