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: Mon, 5 Aug 2019 20:04:26 +0100 [thread overview]
Message-ID: <ad501873-8912-765e-8df5-c9b0451fcd0a@riseup.net> (raw)
In-Reply-To: <20190802145057.7b81c597@simplexum.com>
On 02/08/2019 10:50, Dmitry Petukhov wrote:
> В Fri, 2 Aug 2019 10:21:57 +0100
> Chris Belcher <belcher@riseup•net> wrote:
>
>> 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
>
> But if the entity that rented the coins, makes a profit using this coins
> from the maker opertion, and it makes the same or higher amount than
> it paid in rent, is it a sacrifice ? Given that the aim was to not make
> a profit in the first place, just increase deanonymization
> capabilities ?
Yes you're right. I should correct myself: Running a maker under the
proposal doesn't require a sacrifice of value, in fact you actually make
money doing it.
However, there _is_ a cost to being a sybil attacker. If we define
honest makers as entities who run just one maker bot, and dishonest
makers as entities who run multiple maker bots, then we can say that
running a dishonest maker operation requires a sacrifice of fee income,
because someone doing that would earn more money if they ran an honest
maker instead. This happens because of the quadratic V^2 term in the
formula calculating the fidelity bond value, which provides this
incentive for lumping together fidelity bonds. This V^2 is probably the
most important part for privacy.
The V^2 term also creates a bad incentive where multiple people might
choose to pool together their bitcoin hoard into one maker bot so that
each can earn a higher fee income. This can be done by renting out TXOs
signatures as you've said.
So what's needed is a way to make renting out TXOs impossible or very
difficult. We can note that fidelity bonds made of rented TXOs will be
made up of a large number of relatively small valued TXOs, so one
amelioration is to cap the number of TXOs that can be used in one
fidelity bond. This could be worked around by honest makers because they
can consolidate TXOs on the blockchain, which rented TXO owners can't do
because the TXOs are owned by different people.
Another way is to require the bond signature proofs to involve the
one-time taker identifier, and so be different every time. This
basically requires fidelity bond privkeys to be online in hot wallets,
and so should massively increase the difficulty of renting TXOs because
the maker and the TXO owner need to be in constant real-time communication.
Thoughts?
CB
next prev parent reply other threads:[~2019-08-05 19:04 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
[not found] ` <20190802145057.7b81c597@simplexum.com>
2019-08-05 19:04 ` Chris Belcher [this message]
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=ad501873-8912-765e-8df5-c9b0451fcd0a@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