public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Chris Belcher <belcher@riseup•net>
To: Dmitry Petukhov <dp@simplexum•com>,
	bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
Date: Fri, 2 Aug 2019 10:21:57 +0100	[thread overview]
Message-ID: <ae32dcbb-c950-3b3f-22b9-d152d6b221cb@riseup.net> (raw)
In-Reply-To: <20190731205018.10ed4302@simplexum.com>

On 31/07/2019 16:50, Dmitry Petukhov wrote:
> В Tue, 30 Jul 2019 22:39:14 +0100
> Chris Belcher via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
> wrote:
> 
>> This is where a sacrifice of V bitcoins creates a
>> bond of value V^2. The formula provides a strong incentive for
>> profit-motivated makers to use all their fidelity bond coins with just
>> one maker, not spread them out over many makers.
> 
> The attacker derives additional value from the use of
> locked utxo - the deanonimyzation capabilities.
> 
> An entity M can use all of its locked coins to run a maker, and then
> earn value X. It will also incur some operational expenses in the course
> of running the maker, so the profit will be less than X.
> 
> If these locked coins are given to the attacker A as a package, an
> attacker can derive a value of X+D where D is a value of increased
> deanonymization capabilities for an attacker. Operational expenses
> for an attacker are the same as before (without timelocked bonds),
> because they need to operate a lot of makers either way.
> 
> If M is profit-driven and non-ideological, it can rent out all of its
> coins to A as a package, for the price X, and get the same value without
> running a maker and dedicating any resources and time to it, not
> incurring any operatinal expenses (thus having a bigger profit in the
> end).
> 
> Attacker A will run a maker with M's coins, get profit X, pay X to M,
> get increased deanonymization capabilities. 
> 
> If renting out of utxo is done in a way that the owner always gets X
> after the lock expires, the operation will be riskless for the owner.
> The attacker will need to lock amount X along with owner's coins, but
> hopefully makes X back by running a maker operation. 
> 
> The price for renting out the coins will be determined on the size of
> the 'coin package', so it will not be feasible for the owners of the
> coins to rent them out separately.
> 
> An attacker can even rent coins from several entities and combine them
> to create a more 'powerful' maker. If I understand correctly, such
> 'powerful' maker can have bigger profit than two less 'powerful'
> makers. It seems like a centralization risk to me.
> 

There's a few different issues here.

Yes TXO fidelity bonds can be rented out, but that doesn't make a sybil
attack cheaper. The aim of the fidelity bond scheme is to require makers
to sacrifice value, renting out their fidelity bond coins doesn't avoid
that sacrifice because the sacrifice is the paid rent. Because of the
maths and market forces the rent paid by the attacker should be about
the same as the cost of just buying the bitcoins and locking them.

Centralization and decentralization are not ends in themselves, the main
aim in JoinMarket is to improve privacy while keeping the other
properties of bitcoin (e.g. censorship resistance). A single maker can
never deanonoymize coinjoins no matter how valuable their bond is,
because takers always choose multiple makers, and all of them need to be
controlled by the sybil attacker for the attack to succeed. If a sybil
attacker splits up their fidelity bonds (rented or not) amongst multiple
maker bots then they reduce the value of their bonds because of the V^2
term.

Rented TXOs does destroy the effect of "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". However this is not
the main effect which would protect JoinMarket's privacy. The main
effect is the cost which for real-life numbers would be about 45-120
bitcoin sent to burner outputs.

Perhaps then rented TXOs is an argument against using coin age as a way
to create fidelity bonds. Hodlers would be far less likely to rent out
their coins if they have to specifically move them to a special
time-locked address. Another point is that for privacy reasons creators
of fidelity bonds should mix their coins before and after using them,
because those TXOs are revealed to the world. So it's likely that
fidelity bonds creators will need to install and run JoinMarket anyway.



  reply	other threads:[~2019-08-02  9:22 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-25 11:47 Chris Belcher
2019-07-26  8:10 ` Tamas Blummer
2019-07-26  9:38   ` Dmitry Petukhov
2019-07-30 21:39     ` Chris Belcher
2019-07-31 15:50       ` Dmitry Petukhov
2019-08-02  9:21         ` Chris Belcher [this message]
     [not found]           ` <20190802145057.7b81c597@simplexum.com>
2019-08-05 19:04             ` Chris Belcher
2019-08-06  1:51               ` Leo Wandersleb
2019-08-06 10:27                 ` Chris Belcher
2019-08-06 13:07                   ` Leo Wandersleb
2019-08-06  2:54               ` ZmnSCPxj
2019-08-06 20:55               ` Dmitry Petukhov
2019-08-06 21:37                 ` Dmitry Petukhov
2019-08-06 23:33                   ` ZmnSCPxj
2019-08-07  9:38                     ` Chris Belcher
2019-08-07 11:20                       ` ZmnSCPxj
2019-08-07 10:05                   ` Chris Belcher
2019-08-07 11:35                     ` ZmnSCPxj
2019-08-07 15:10                     ` Dmitry Petukhov
2019-08-08  0:09                       ` ZmnSCPxj
2019-08-08  9:35                         ` ZmnSCPxj
2019-08-08 11:37                           ` Dmitry Petukhov
2019-08-08 13:59                             ` ZmnSCPxj
2019-08-08 20:06                               ` Chris Belcher
2019-08-08 12:05                       ` Dmitry Petukhov
2019-07-27 19:34 ` David A. Harding
2019-07-28 14:17   ` Tamas Blummer
2019-07-28 18:29   ` Tamas Blummer
2019-07-30 21:27   ` Chris Belcher
2019-07-31 17:59     ` David A. Harding
2019-08-02 14:24 ` Adam Gibson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ae32dcbb-c950-3b3f-22b9-d152d6b221cb@riseup.net \
    --to=belcher@riseup$(echo .)net \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=dp@simplexum$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox