path: root/35/7f39ea70d80504df92fc9ec01253265ef75198

Return-Path: <ekaggata@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 0691F1488
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  2 Aug 2019 14:24:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com
	[209.85.167.66])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1838A7ED
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  2 Aug 2019 14:24:25 +0000 (UTC)
Received: by mail-lf1-f66.google.com with SMTP id s19so53087260lfb.9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 02 Aug 2019 07:24:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=P6vEo5QQcq9/VSk/k/oVDoM7ptjsslYJG5rFViuOLC8=;
	b=kRXJ+ODMWQDDzqWV/ecmqFOjmaFtYKkjBdN9pswLDg5vHW5FA6mK32M3Dun/ft+3Fi
	jHelsPdhgl7WJdOHM4nFN9UYgD/qnU1LpV12vlXMpUdT0tLTCsGGgV1f7QkYJjtJWppN
	wDzWIjX9Fhxd+nB/yl4zzQN6eP4DEqCraBod9lEBKXe4iQHqnyQsoXt9nTrJ/YVFQLS7
	+Rv+K2M0KadjJUouzvC4tZ4SK9MnMmIRh82cSwQlQ8rxjU2JQjAIlLGUV+jI90/LfaND
	taUY8F+b6fP6CjMaHr4DTsc1CEYH+kVxpS47GGZS+mDEXd2abVx7MxNWnqsLAD7OXp67
	T3SA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=P6vEo5QQcq9/VSk/k/oVDoM7ptjsslYJG5rFViuOLC8=;
	b=HwlSCofQpu/zuszJMyZ46rLGLLWwPjkibdLgHpLmBM5hr2W6w8+5zNAdiRSBdjkNTo
	3Y5VDxSNX/39r+RUlDpzlioe4Fbbr/BDeTTseGbwoym3l7Wm4Raxj+NyPYe3xzSpPegg
	C923+G1Prao9zpsIscNW/KmhN+1jR0C1+Du/lgf91jAm0EjWdA+pZcXXOHSjmfMn8nkQ
	x5PR93BmxZgo0xOIf/RHeJoaApYHZBa/xjm76HkBqCCza15+lPbR5fSNjrtKsqX1kuje
	uVLZbCSjNYrpVpH5TR+VmroIbSI7sJPkWSDmVUFsggLtqNIeGJBcCUsN/XCi6fRl+5Qx
	uoSg==
X-Gm-Message-State: APjAAAUiM7O/PGmsNAaNstP2TUzHO48JjoyDvRKcJ/x46sa4yZN+4bhg
	DQ2KiQsr+QIg8/m96f66SNw0VyZnKMqLA9/YW1Y=
X-Google-Smtp-Source: APXvYqwXgpG+RyFOHAxanJRHfMVE0vcmlmmlZ29ZQHFAmpyfmvfXo1HhLylb02wQ8Kz5yX2MKdp/43+OENhO/rPKLv8=
X-Received: by 2002:a19:6e41:: with SMTP id q1mr54923706lfk.20.1564755863404; 
	Fri, 02 Aug 2019 07:24:23 -0700 (PDT)
MIME-Version: 1.0
References: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net>
In-Reply-To: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net>
From: Adam Gibson <ekaggata@gmail.com>
Date: Fri, 2 Aug 2019 15:24:11 +0100
Message-ID: <CAN2_kKQGOoFz6tfrO7s9ULS61R5Hs+KVwFcShXXvSikFuSrirA@mail.gmail.com>
To: Chris Belcher <belcher@riseup.net>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000660577058f231d44"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil
 attacks using fidelity bonds
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Fri, 02 Aug 2019 14:24:28 -0000

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

reposted due to wrong email address:

I'd just like to repeat something I said years ago but is undoubtedly lost
now:

>
> ### Today's low cost for sybil attacks
>
> A paper on JoinMarket [M=C3=B6ser, Malte and Rainer B=C3=B6hme. =E2=80=9C=
Join Me on a
> Market for Anonymity.=E2=80=9D (2016).] calculates the requirement of suc=
h a
> sybil attack in 2016 to be just 32,000 USD. According to the paper such
> an attack would succeed 90% of the time and the investment is
> recoverable afterwards so that figure for the requirement isn't even a
> true cost.
>
> JoinMarket has been improved since 2016 and more makers have joined, so
> the true requirement is perhaps 2x or 3x higher today, but it is still
> relatively low.
>
> Even with future improvements like fixing issue #693 [2] the requirement
> of a sybil attack would probably only rise another 2x.
>

I criticised this point from the Moser paper at the time, in particular
because it was the headline grabbing result and in my opinion was only half
the truth, at best:

The $32K figure came from the assumption that swamping the bottom of the
order book (in other words, making lots of bots offering prices lower than
all the other bots) would lead to taking most of the join volume.

At the time, this was true and false to some extent: it was true that the
default order choosing algorithm was exponentially weighted to lower fees.
But it was also true even then that Takers could simply manually choose any
counterparty bots they liked (-P).

Also at the time I complained that it was trivial to implement other order
choosing algorithms, in particular I advocated (for its simplicity) "choose
randomly under a user specified maximum fee", and indeed since the paper we
have implemented that algorithm and it's now the default.

Note that this algorithm is the crudest variant of what was loosely called
"quantization" in this discussion between belcher and gmaxwell on the topic
some years ago:

https://github.com/JoinMarket-Org/joinmarket/issues/14#issuecomment-1435097=
88

To me the crucial point is that the Taker's price sensitivity should not be
too large, although of course it cannot be zero!

So independent of changes in the makeup of the users of Joinmarket, that
analysis from 2016 was in my opinion a bit skewed at the time, and
completely wrong today.

None of this is a critique of the fidelity bonds idea, since the Sybil
threat is real in any case (see issue 693 as mentioned), but price-based
Sybilling is less effective than it seems based on that.

I'll continue my thoughts on fidelity bonds, for what they're worth, in the
active thread:
https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/371

(for those not in the know, Joinmarket-Org/joinmarket-clientserver is the
active repo, not Joinmarket-Org/joinmarket).

Adam Gibson / waxwing / AdamISZ

On Thu, Jul 25, 2019 at 3:18 PM Chris Belcher via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> JoinMarket[1] can be sybil attacked today at relatively low cost which
> can destroy its privacy. Bitcoins can be sacrificed with burner outputs
> and time-locked addresses (also called fidelity bonds), and this can be
> used to greatly improve JoinMarket's resistance to sybil attacks.
>
> With real-world data and realistic assumptions we calculate that under
> such a fidelity bond system an adversary would need to lock up
> 30,000-80,000 bitcoins for months, or send 45-120 bitcoins to burner
> addresses to have a good chance of sybil attacking the system if it were
> added to JoinMarket.
>
> This increased resistance to sybil attacks would most likely cause
> coinjoin fees to rise. I think the added cost is worth it for the
> greatly improved privacy, because today miner fees are the biggest cost
> to JoinMarket takers not coinjoin fees which are very low. Users should
> definitely share their opinion on fees after reading the document.
>
> ## Introduction
>
> JoinMarket creates a market for coinjoins, allowing anyone to create
> equal-amount coinjoins for any amount they want at any time they want.
> In return they pay a fee for the liquidity made available to them. The
> project has existed since 2015 and has probably created hundreds of
> thousands of coinjoins since then. Today there is available liquidity
> for creating coinjoins with amounts up to about 400 btc per coinjoin
> output.
>
> ### Sybil attacks
>
> JoinMarket, like many other schemes where participants are free to
> anonymously enter, can be targetted by sybil attacks. In JoinMarket this
> would work by an attacker running lots of maker bots which attempt to be
> all the makers in every coinjoin. If successful the attacker would have
> enough information unmix every coinjoin.
>
> One way to solve the problem of sybil attacks is centralization. For
> example coinjoins could be constructed on a centralized server. Then
> random anonymous participants cant sybil attack because they can't
> control the coinjoin construction, but this comes at the cost that the
> server can sybil attack very easily. So this solution is probably a bad
> tradeoff.
>
> In general, sybil attacks are solved by making them expensive. For
> example, bitcoin mining resists sybil attacks because it requires a
> provable sacrifice of electricity to mine. A bitcoin user can calculate
> the actual monetary value that an attacker must spend in order to
> reverse their transaction.
>
> Likewise in JoinMarket such a sybil attack is not free either as the
> attacker needs to own enough bitcoins to run enough maker bots for all
> the coinjoins.
>
> ### Today's low cost for sybil attacks
>
> A paper on JoinMarket [M=C3=B6ser, Malte and Rainer B=C3=B6hme. =E2=80=9C=
Join Me on a
> Market for Anonymity.=E2=80=9D (2016).] calculates the requirement of suc=
h a
> sybil attack in 2016 to be just 32,000 USD. According to the paper such
> an attack would succeed 90% of the time and the investment is
> recoverable afterwards so that figure for the requirement isn't even a
> true cost.
>
> JoinMarket has been improved since 2016 and more makers have joined, so
> the true requirement is perhaps 2x or 3x higher today, but it is still
> relatively low.
>
> Even with future improvements like fixing issue #693 [2] the requirement
> of a sybil attack would probably only rise another 2x.
>
> Apart from the cost to sybil attack being low, there is also the odd
> situation that smaller coinjoin amounts receive less sybil protection
> than large ones. It costs 100x less to sybil attack a transaction of 0.1
> btc than one of 10 btc. Why should smaller amounts receive less
> sybil-resistance and therefore less privacy?
>
> ### Liquidity
>
> When creating this project, it was expected that many more people would
> enter the market as makers and so the cost of a sybil attack would be
> very high. That has not happened. One reason is that everyone who wants
> to create a coinjoin is able to even for large amounts. The fundamental
> problem is that takers are paying-for and getting liquidity, but not
> necessarily sybil-resistance.
>
> Another smaller reason for the low cost of sybil attacks is that many
> people don't want to store too many bitcoins on an computer connected to
> the internet.
>
> What is needed is a way to increase the cost of running in a maker in a
> way that retains the anonymity and is attractive to long-term holders of
> bitcoin. This can be done using time-locked addresses.
>
> ## Fidelity bonds
>
> In bitcoin, a fidelity bond [3] is a mechanism where bitcoin value is
> deliberately sacrificed to make a cryptographic identity expensive to
> obtain. The sacrifice is done in a way that can be proven to a third part=
y.
>
> A way to create a fidelity bond is to burn an amount of bitcoins by
> sending to a OP_RETURN output. Another kind is time-locked addresses
> created using OP_CHECKLOCKTIMEVERIFY where the valuable thing being
> sacrificed is time rather than money, but the two are related because of
> the time-value-of-money.
>
> Under this system, makers would sacrifice an amount of bitcoins and
> publish a proof along with their coinjoin offers. Takers would choose
> maker offers based on the sacrificed amount (as well as other factors),
> knowing that a sybil attacker would also have to sacrifice a certain
> amount of coins in order to unmix the taker's coinjoins. The sacrifice
> would be an objective measurement that can't be faked and which can be
> verified by anybody (just like, for example PoW mining)
>
> Note that a long-term holder (or hodler) of bitcoins can buy time-locked
> fidelity bonds essentially for free, assuming they never intended to
> transact with their coins much anyway. A long-term holder probably won't
> want to attack a system like JoinMarket which makes his own investment
> coins more private and more fungible.
>
> ### Fidelity bonds in cold storage
>
> The private keys of fidelity bonds can be kept offline. Signatures
> potentially only need to be made when the timelock expires (every 6
> months for example), or only once in the case of OP_RETURN burned coins.
> This allows JoinMarket's sybil resistance to increase without the hot
> wallet risk.
>
> Burned coin signatures should still have a lifetime, in case the private
> key associated with the IRC nick (which is online) is stolen, so that
> the thief of that privkey can't impersonate the maker indefinitely. The
> signature linking the burned coins and IRC nick could expire after
> perhaps 6 months.
>
> ### Anonymity
>
> Under this scheme makers would need to publish the transactions of their
> fidelity bonds to the entire world. Those transactions could be subject
> to blockchain analysis. So before makers do this they should make sure
> their coins are anonymous (possibly by mixing with JoinMarket). Also if
> they ever want to use their coins for something else apart from fidelity
> bonds they should mix them.
>
> ### Value of a fidelity bond
>
> See the other document (Financial mathematics of joinmarket fidelity
> bonds)[4] for a formula expressing the value of a fidelity bond.
>
> The value of a fidelity bond made by sending V bitcoins to a burner
> address is:
>
>     V^2
>
> The amount of bitcoins is squared to get the fidelity bond value. This
> has the effect that economic-rational makers have a strong incentive to
> lump up all their coin sacrifices together into one maker bot, not to
> split it up over several bots.
>
> The value of a fidelity bond made by locking up V bitcoins in a
> time-locked address for time period T is:
>
>     V^2 (exp(rT) - 1)^2
>
> To get an idea of the numbers, if we burn 2 btc then the value of the
> fidelity bond is 4 BTC^2. If we lock up 100 BTC for one year, and have a
> bitcoin interest rate r =3D 0.001 (0.1%) per year, then the value of that
> fidelity bond is 0.01 BTC^2 which is the same as burning 0.1 BTC. That
> is a relatively small valued bond. It can be increased by locking up
> more bitcoins for longer (up to and including permanant locking via a
> burner transaction).
>
> ## Taker algorithm for choosing makers
>
> I suggest the following taker peer choosing algorithm: obtain the list
> of offers and discard offers which the taker's user deems are too
> expensive. One of the remaining offers is randomly chosen with weighting
> determined by the fidelity bond value. Once an offer is chosen it is
> removed from the list, and another offer is again randomly chosen, this
> is repeated until the taker has chosen the desired number of
> fidelity-bonded maker's offers.
>
> Some people run makers not for profit but for their own privacy.
> Therefore not all makers should be required to have bonds, because such
> privacy-makers are useful to include in coinjoins too. We could have
> taker allow say, an eighth (12.5%), of their coinjoin peers to be makers
> without bonds. They can be chosen randomly from the orderbook without
> any weighting based on fidelity bond values. Of course these are easy to
> fake by an adversary so they dont contribute much to sybil resistance.
>
> ### Cost of sybil attacks
>
> See the other document (Cost of sybil attacks) for discussion and
> calculations on the sybil resistance given by the above maker-choosing
> algorithm.
>
> It can be calculated that the fidelity bond system dramatically
> increases the cost of a sybil attack. With real-world data and realistic
> assumptions we can calculate that a sybil attacker would need to lock up
> 30,000-80,000 bitcoins for 6 months, or send 45-120 bitcoins to burner
> addresses to have a good chance of attacking the system by being all the
> counterparties in everyone's coinjoin.
>
> ## Effect of fidelity bonds on CoinJoin fees
>
> Someone might ask "why would anyone lock up coins for months or more,
> let alone burn coins forever, just to run a maker bot". The only way
> this would even happen is if makers can generate a higher income that
> justifies the fidelity bond sacrifice. That higher income can only come
> from taker's coinjoin fees (or possibly coinswap fees one day). We can
> expect that makers with higher valued fidelity bonds will demand higher
> coinjoin fees. So a big question is whether takers will accept paying
> higher coinjoin fees. I think they will, because right now coinjoin fees
> are only 10-1000 satoshi, and a far biggest cost of coinjoins is the
> miner fee not the coinjoin fee. I'm pretty sure takers will recognize
> that they get what they pay for, and that additional privacy is well
> worth the cost. Any other takers reading this should definitely let me
> know what they think.
>
> ## Technical ideas
>
> JoinMarket's wallet could also create time-locked addresses. Locktimes
> should be fixed to be midnight on the first day of each month, then each
> public key corresponds to 12 addresses per year (1200 addresses per
> century) which is very practical to all be monitored as watch-only
> addresses. These wallets can be created offline and could safely hold
> time-locked bitcoins.
>
> The timelocked addresses public key can be used to sign an IRC nickname
> proving that the nickname is the real owner of the TXO. OP_RETURN
> outputs used for burning coins can include a pubkey hash used for the
> same thing.
>
> We don't want the cold storage keypairs to be held online. We can design
> the system that the time-locked address keypair is held offline but it
> signs another key pair which is held online. Every time the IRC bot
> connects it can use this intermediate keypair to sign the IRC nickname
> proving ownership. The signature from the time-locked address to the
> intermediate keypair can be made to have an expiry date (for example 6
> months). This all means that the time-locked bitcoins can be held
> offline but still be used to prove ownership of an IRC nickname.
>
> The existance of the UTXO of a time-locked coin can be proved by
> revealing the TXID and vout, which full nodes can use to query the UTXO
> set to check that the coin exists. SPV clients would need a merkle proof
> as well. Burned coins and spent time-locked coins could have their
> existence proved by sharing the transaction which created them along
> with a block height and transaction position for an unpruned node, or a
> merkle proof for a pruned node or SPV client. Note that from the point
> of view of a pruned node, a merkle proof is a fully-verified proof of
> existance of a transaction. It is not a proof with just SPV-security.
>
> ## Links / References
> [1] https://github.com/JoinMarket-Org/joinmarket-clientserver
> [2] https://github.com/JoinMarket-Org/joinmarket/issues/693
> [3] https://en.bitcoin.it/wiki/Fidelity_bonds
> [4] https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25=
b
> [5]
>
> https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b#co=
st-of-sybil-attacks
> [6] First ever mention of fidelity bonds I found. The idea is basically
> invented by Peter Todd: https://bitcointalk.org/index.php?topic=3D134827.=
0
> [7] Old idea for combining fidelity bonds with mixers:
> https://bitcointalk.org/index.php?topic=3D172047.0
> [8] Suggestion that is very close to the fidelity bonds idea. He talks
> about requiring a deposit from makers, but nobody is able to come up
> with a way to make such a deposit decentralized and trustless:
>
> https://www.reddit.com/r/Bitcoin/comments/2zc5tc/joinmarket_increase_the_=
privacy_of_bitcoin_and/ctk37hn/?context=3D1
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

<div dir=3D"ltr"><div>reposted due to wrong email address:</div><div><br></=
div><div>I&#39;d just like to repeat something I said years ago but is undo=
ubtedly lost now:<br><br>&gt;<br>&gt; ### Today&#39;s low cost for sybil at=
tacks<br>&gt;<br>&gt; A paper on JoinMarket [M=C3=B6ser, Malte and Rainer B=
=C3=B6hme. =E2=80=9CJoin Me on a<br>&gt; Market for Anonymity.=E2=80=9D (20=
16).] calculates the requirement of such a<br>&gt; sybil attack in 2016 to =
be just 32,000 USD. According to the paper such<br>&gt; an attack would suc=
ceed 90% of the time and the investment is<br>&gt; recoverable afterwards s=
o that figure for the requirement isn&#39;t even a<br>&gt; true cost.<br>&g=
t;<br>&gt; JoinMarket has been improved since 2016 and more makers have joi=
ned, so<br>&gt; the true requirement is perhaps 2x or 3x higher today, but =
it is still<br>&gt; relatively low.<br>&gt;<br>&gt; Even with future improv=
ements like fixing issue #693 [2] the requirement<br>&gt; of a sybil attack=
 would probably only rise another 2x.<br>&gt;<br><br>I criticised this poin=
t from the Moser paper at the time, in particular because it was the headli=
ne grabbing result and in my opinion was only half the truth, at best:<br><=
br>The $32K figure came from the assumption that swamping the bottom of the=
 order book (in other words, making lots of bots offering prices lower than=
 all the other bots) would lead to taking most of the join volume.<br><br>A=
t the time, this was true and false to some extent: it was true that the de=
fault order choosing algorithm was exponentially weighted to lower fees. Bu=
t it was also true even then that Takers could simply manually choose any c=
ounterparty bots they liked (-P).<br><br>Also at the time I complained that=
 it was trivial to implement other order choosing algorithms, in particular=
 I advocated (for its simplicity) &quot;choose randomly under a user specif=
ied maximum fee&quot;, and indeed since the paper we have implemented that =
algorithm and it&#39;s now the default.<br><br>Note that this algorithm is =
the crudest variant of what was loosely called &quot;quantization&quot; in =
this discussion between belcher and gmaxwell on the topic some years ago:<b=
r><br><a href=3D"https://github.com/JoinMarket-Org/joinmarket/issues/14#iss=
uecomment-143509788">https://github.com/JoinMarket-Org/joinmarket/issues/14=
#issuecomment-143509788</a><br><br>To me the crucial point is that the Take=
r&#39;s price sensitivity should not be too large, although of course it ca=
nnot be zero!<br><br>So independent of changes in the makeup of the users o=
f Joinmarket, that analysis from 2016 was in my opinion a bit skewed at the=
 time, and completely wrong today.<br><br>None of this is a critique of the=
 fidelity bonds idea, since the Sybil threat is real in any case (see issue=
 693 as mentioned), but price-based Sybilling is less effective than it see=
ms based on that.<br><br>I&#39;ll continue my thoughts on fidelity bonds, f=
or what they&#39;re worth, in the active thread: <a href=3D"https://github.=
com/JoinMarket-Org/joinmarket-clientserver/issues/371">https://github.com/J=
oinMarket-Org/joinmarket-clientserver/issues/371</a><br><br>(for those not =
in the know, Joinmarket-Org/joinmarket-clientserver is the active repo, not=
 Joinmarket-Org/joinmarket).<br><br>Adam Gibson / waxwing / AdamISZ</div></=
div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On=
 Thu, Jul 25, 2019 at 3:18 PM Chris Belcher via bitcoin-dev &lt;<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfounda=
tion.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex">JoinMarket[1] can be sybil attacked today at relatively low cost wh=
ich<br>
can destroy its privacy. Bitcoins can be sacrificed with burner outputs<br>
and time-locked addresses (also called fidelity bonds), and this can be<br>
used to greatly improve JoinMarket&#39;s resistance to sybil attacks.<br>
<br>
With real-world data and realistic assumptions we calculate that under<br>
such a fidelity bond system an adversary would need to lock up<br>
30,000-80,000 bitcoins for months, or send 45-120 bitcoins to burner<br>
addresses to have a good chance of sybil attacking the system if it were<br=
>
added to JoinMarket.<br>
<br>
This increased resistance to sybil attacks would most likely cause<br>
coinjoin fees to rise. I think the added cost is worth it for the<br>
greatly improved privacy, because today miner fees are the biggest cost<br>
to JoinMarket takers not coinjoin fees which are very low. Users should<br>
definitely share their opinion on fees after reading the document.<br>
<br>
## Introduction<br>
<br>
JoinMarket creates a market for coinjoins, allowing anyone to create<br>
equal-amount coinjoins for any amount they want at any time they want.<br>
In return they pay a fee for the liquidity made available to them. The<br>
project has existed since 2015 and has probably created hundreds of<br>
thousands of coinjoins since then. Today there is available liquidity<br>
for creating coinjoins with amounts up to about 400 btc per coinjoin output=
.<br>
<br>
### Sybil attacks<br>
<br>
JoinMarket, like many other schemes where participants are free to<br>
anonymously enter, can be targetted by sybil attacks. In JoinMarket this<br=
>
would work by an attacker running lots of maker bots which attempt to be<br=
>
all the makers in every coinjoin. If successful the attacker would have<br>
enough information unmix every coinjoin.<br>
<br>
One way to solve the problem of sybil attacks is centralization. For<br>
example coinjoins could be constructed on a centralized server. Then<br>
random anonymous participants cant sybil attack because they can&#39;t<br>
control the coinjoin construction, but this comes at the cost that the<br>
server can sybil attack very easily. So this solution is probably a bad<br>
tradeoff.<br>
<br>
In general, sybil attacks are solved by making them expensive. For<br>
example, bitcoin mining resists sybil attacks because it requires a<br>
provable sacrifice of electricity to mine. A bitcoin user can calculate<br>
the actual monetary value that an attacker must spend in order to<br>
reverse their transaction.<br>
<br>
Likewise in JoinMarket such a sybil attack is not free either as the<br>
attacker needs to own enough bitcoins to run enough maker bots for all<br>
the coinjoins.<br>
<br>
### Today&#39;s low cost for sybil attacks<br>
<br>
A paper on JoinMarket [M=C3=B6ser, Malte and Rainer B=C3=B6hme. =E2=80=9CJo=
in Me on a<br>
Market for Anonymity.=E2=80=9D (2016).] calculates the requirement of such =
a<br>
sybil attack in 2016 to be just 32,000 USD. According to the paper such<br>
an attack would succeed 90% of the time and the investment is<br>
recoverable afterwards so that figure for the requirement isn&#39;t even a<=
br>
true cost.<br>
<br>
JoinMarket has been improved since 2016 and more makers have joined, so<br>
the true requirement is perhaps 2x or 3x higher today, but it is still<br>
relatively low.<br>
<br>
Even with future improvements like fixing issue #693 [2] the requirement<br=
>
of a sybil attack would probably only rise another 2x.<br>
<br>
Apart from the cost to sybil attack being low, there is also the odd<br>
situation that smaller coinjoin amounts receive less sybil protection<br>
than large ones. It costs 100x less to sybil attack a transaction of 0.1<br=
>
btc than one of 10 btc. Why should smaller amounts receive less<br>
sybil-resistance and therefore less privacy?<br>
<br>
### Liquidity<br>
<br>
When creating this project, it was expected that many more people would<br>
enter the market as makers and so the cost of a sybil attack would be<br>
very high. That has not happened. One reason is that everyone who wants<br>
to create a coinjoin is able to even for large amounts. The fundamental<br>
problem is that takers are paying-for and getting liquidity, but not<br>
necessarily sybil-resistance.<br>
<br>
Another smaller reason for the low cost of sybil attacks is that many<br>
people don&#39;t want to store too many bitcoins on an computer connected t=
o<br>
the internet.<br>
<br>
What is needed is a way to increase the cost of running in a maker in a<br>
way that retains the anonymity and is attractive to long-term holders of<br=
>
bitcoin. This can be done using time-locked addresses.<br>
<br>
## Fidelity bonds<br>
<br>
In bitcoin, a fidelity bond [3] is a mechanism where bitcoin value is<br>
deliberately sacrificed to make a cryptographic identity expensive to<br>
obtain. The sacrifice is done in a way that can be proven to a third party.=
<br>
<br>
A way to create a fidelity bond is to burn an amount of bitcoins by<br>
sending to a OP_RETURN output. Another kind is time-locked addresses<br>
created using OP_CHECKLOCKTIMEVERIFY where the valuable thing being<br>
sacrificed is time rather than money, but the two are related because of<br=
>
the time-value-of-money.<br>
<br>
Under this system, makers would sacrifice an amount of bitcoins and<br>
publish a proof along with their coinjoin offers. Takers would choose<br>
maker offers based on the sacrificed amount (as well as other factors),<br>
knowing that a sybil attacker would also have to sacrifice a certain<br>
amount of coins in order to unmix the taker&#39;s coinjoins. The sacrifice<=
br>
would be an objective measurement that can&#39;t be faked and which can be<=
br>
verified by anybody (just like, for example PoW mining)<br>
<br>
Note that a long-term holder (or hodler) of bitcoins can buy time-locked<br=
>
fidelity bonds essentially for free, assuming they never intended to<br>
transact with their coins much anyway. A long-term holder probably won&#39;=
t<br>
want to attack a system like JoinMarket which makes his own investment<br>
coins more private and more fungible.<br>
<br>
### Fidelity bonds in cold storage<br>
<br>
The private keys of fidelity bonds can be kept offline. Signatures<br>
potentially only need to be made when the timelock expires (every 6<br>
months for example), or only once in the case of OP_RETURN burned coins.<br=
>
This allows JoinMarket&#39;s sybil resistance to increase without the hot<b=
r>
wallet risk.<br>
<br>
Burned coin signatures should still have a lifetime, in case the private<br=
>
key associated with the IRC nick (which is online) is stolen, so that<br>
the thief of that privkey can&#39;t impersonate the maker indefinitely. The=
<br>
signature linking the burned coins and IRC nick could expire after<br>
perhaps 6 months.<br>
<br>
### Anonymity<br>
<br>
Under this scheme makers would need to publish the transactions of their<br=
>
fidelity bonds to the entire world. Those transactions could be subject<br>
to blockchain analysis. So before makers do this they should make sure<br>
their coins are anonymous (possibly by mixing with JoinMarket). Also if<br>
they ever want to use their coins for something else apart from fidelity<br=
>
bonds they should mix them.<br>
<br>
### Value of a fidelity bond<br>
<br>
See the other document (Financial mathematics of joinmarket fidelity<br>
bonds)[4] for a formula expressing the value of a fidelity bond.<br>
<br>
The value of a fidelity bond made by sending V bitcoins to a burner<br>
address is:<br>
<br>
=C2=A0 =C2=A0 V^2<br>
<br>
The amount of bitcoins is squared to get the fidelity bond value. This<br>
has the effect that economic-rational makers have a strong incentive to<br>
lump up all their coin sacrifices together into one maker bot, not to<br>
split it up over several bots.<br>
<br>
The value of a fidelity bond made by locking up V bitcoins in a<br>
time-locked address for time period T is:<br>
<br>
=C2=A0 =C2=A0 V^2 (exp(rT) - 1)^2<br>
<br>
To get an idea of the numbers, if we burn 2 btc then the value of the<br>
fidelity bond is 4 BTC^2. If we lock up 100 BTC for one year, and have a<br=
>
bitcoin interest rate r =3D 0.001 (0.1%) per year, then the value of that<b=
r>
fidelity bond is 0.01 BTC^2 which is the same as burning 0.1 BTC. That<br>
is a relatively small valued bond. It can be increased by locking up<br>
more bitcoins for longer (up to and including permanant locking via a<br>
burner transaction).<br>
<br>
## Taker algorithm for choosing makers<br>
<br>
I suggest the following taker peer choosing algorithm: obtain the list<br>
of offers and discard offers which the taker&#39;s user deems are too<br>
expensive. One of the remaining offers is randomly chosen with weighting<br=
>
determined by the fidelity bond value. Once an offer is chosen it is<br>
removed from the list, and another offer is again randomly chosen, this<br>
is repeated until the taker has chosen the desired number of<br>
fidelity-bonded maker&#39;s offers.<br>
<br>
Some people run makers not for profit but for their own privacy.<br>
Therefore not all makers should be required to have bonds, because such<br>
privacy-makers are useful to include in coinjoins too. We could have<br>
taker allow say, an eighth (12.5%), of their coinjoin peers to be makers<br=
>
without bonds. They can be chosen randomly from the orderbook without<br>
any weighting based on fidelity bond values. Of course these are easy to<br=
>
fake by an adversary so they dont contribute much to sybil resistance.<br>
<br>
### Cost of sybil attacks<br>
<br>
See the other document (Cost of sybil attacks) for discussion and<br>
calculations on the sybil resistance given by the above maker-choosing<br>
algorithm.<br>
<br>
It can be calculated that the fidelity bond system dramatically<br>
increases the cost of a sybil attack. With real-world data and realistic<br=
>
assumptions we can calculate that a sybil attacker would need to lock up<br=
>
30,000-80,000 bitcoins for 6 months, or send 45-120 bitcoins to burner<br>
addresses to have a good chance of attacking the system by being all the<br=
>
counterparties in everyone&#39;s coinjoin.<br>
<br>
## Effect of fidelity bonds on CoinJoin fees<br>
<br>
Someone might ask &quot;why would anyone lock up coins for months or more,<=
br>
let alone burn coins forever, just to run a maker bot&quot;. The only way<b=
r>
this would even happen is if makers can generate a higher income that<br>
justifies the fidelity bond sacrifice. That higher income can only come<br>
from taker&#39;s coinjoin fees (or possibly coinswap fees one day). We can<=
br>
expect that makers with higher valued fidelity bonds will demand higher<br>
coinjoin fees. So a big question is whether takers will accept paying<br>
higher coinjoin fees. I think they will, because right now coinjoin fees<br=
>
are only 10-1000 satoshi, and a far biggest cost of coinjoins is the<br>
miner fee not the coinjoin fee. I&#39;m pretty sure takers will recognize<b=
r>
that they get what they pay for, and that additional privacy is well<br>
worth the cost. Any other takers reading this should definitely let me<br>
know what they think.<br>
<br>
## Technical ideas<br>
<br>
JoinMarket&#39;s wallet could also create time-locked addresses. Locktimes<=
br>
should be fixed to be midnight on the first day of each month, then each<br=
>
public key corresponds to 12 addresses per year (1200 addresses per<br>
century) which is very practical to all be monitored as watch-only<br>
addresses. These wallets can be created offline and could safely hold<br>
time-locked bitcoins.<br>
<br>
The timelocked addresses public key can be used to sign an IRC nickname<br>
proving that the nickname is the real owner of the TXO. OP_RETURN<br>
outputs used for burning coins can include a pubkey hash used for the<br>
same thing.<br>
<br>
We don&#39;t want the cold storage keypairs to be held online. We can desig=
n<br>
the system that the time-locked address keypair is held offline but it<br>
signs another key pair which is held online. Every time the IRC bot<br>
connects it can use this intermediate keypair to sign the IRC nickname<br>
proving ownership. The signature from the time-locked address to the<br>
intermediate keypair can be made to have an expiry date (for example 6<br>
months). This all means that the time-locked bitcoins can be held<br>
offline but still be used to prove ownership of an IRC nickname.<br>
<br>
The existance of the UTXO of a time-locked coin can be proved by<br>
revealing the TXID and vout, which full nodes can use to query the UTXO<br>
set to check that the coin exists. SPV clients would need a merkle proof<br=
>
as well. Burned coins and spent time-locked coins could have their<br>
existence proved by sharing the transaction which created them along<br>
with a block height and transaction position for an unpruned node, or a<br>
merkle proof for a pruned node or SPV client. Note that from the point<br>
of view of a pruned node, a merkle proof is a fully-verified proof of<br>
existance of a transaction. It is not a proof with just SPV-security.<br>
<br>
## Links / References<br>
[1] <a href=3D"https://github.com/JoinMarket-Org/joinmarket-clientserver" r=
el=3D"noreferrer" target=3D"_blank">https://github.com/JoinMarket-Org/joinm=
arket-clientserver</a><br>
[2] <a href=3D"https://github.com/JoinMarket-Org/joinmarket/issues/693" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/JoinMarket-Org/joinmar=
ket/issues/693</a><br>
[3] <a href=3D"https://en.bitcoin.it/wiki/Fidelity_bonds" rel=3D"noreferrer=
" target=3D"_blank">https://en.bitcoin.it/wiki/Fidelity_bonds</a><br>
[4] <a href=3D"https://gist.github.com/chris-belcher/87ebbcbb639686057a389a=
cb9ab3e25b" rel=3D"noreferrer" target=3D"_blank">https://gist.github.com/ch=
ris-belcher/87ebbcbb639686057a389acb9ab3e25b</a><br>
[5]<br>
<a href=3D"https://gist.github.com/chris-belcher/87ebbcbb639686057a389acb9a=
b3e25b#cost-of-sybil-attacks" rel=3D"noreferrer" target=3D"_blank">https://=
gist.github.com/chris-belcher/87ebbcbb639686057a389acb9ab3e25b#cost-of-sybi=
l-attacks</a><br>
[6] First ever mention of fidelity bonds I found. The idea is basically<br>
invented by Peter Todd: <a href=3D"https://bitcointalk.org/index.php?topic=
=3D134827.0" rel=3D"noreferrer" target=3D"_blank">https://bitcointalk.org/i=
ndex.php?topic=3D134827.0</a><br>
[7] Old idea for combining fidelity bonds with mixers:<br>
<a href=3D"https://bitcointalk.org/index.php?topic=3D172047.0" rel=3D"noref=
errer" target=3D"_blank">https://bitcointalk.org/index.php?topic=3D172047.0=
</a><br>
[8] Suggestion that is very close to the fidelity bonds idea. He talks<br>
about requiring a deposit from makers, but nobody is able to come up<br>
with a way to make such a deposit decentralized and trustless:<br>
<a href=3D"https://www.reddit.com/r/Bitcoin/comments/2zc5tc/joinmarket_incr=
ease_the_privacy_of_bitcoin_and/ctk37hn/?context=3D1" rel=3D"noreferrer" ta=
rget=3D"_blank">https://www.reddit.com/r/Bitcoin/comments/2zc5tc/joinmarket=
_increase_the_privacy_of_bitcoin_and/ctk37hn/?context=3D1</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000660577058f231d44--