From: Dmitry Petukhov <dp@simplexum•com>
To: Chris Belcher <belcher@riseup•net>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
Date: Wed, 7 Aug 2019 20:10:17 +0500 [thread overview]
Message-ID: <20190807201017.2a03b971@simplexum.com> (raw)
In-Reply-To: <483af6d0-ac5a-0e22-da29-af0be5196c15@riseup.net>
В Wed, 7 Aug 2019 11:05:41 +0100
Chris Belcher <belcher@riseup•net> wrote:
> These are very creative schemes. At the very least they would stop the
> easy mindless renting TXO method, where someone with coins on a
> hardware wallet simply creates a signature and copypastes it into a
> website to get free money.
The second scheme ("all locked TXO may be required to be spendable
by *any* key that controls any TXO in the 'bond TXO package'") is in
almost all regards the same as simple "require TXO to be consolidated",
and looks like it is not in any way better than simple consolidation.
The first scheme - 'allow revocation of the whole bond by the key
controlling even a single TXO in a bond' - might be more promising.
> I wonder if there's a cryptographic way to prove that muSig and
> 2P-ECDSA have not been used to create a certain pubkey/signature.
In the second scheme, to revoke/spoil the bond, the entity that
controls one TXO participating in this bond needs to simply prove that
it somehow controls/have the ability to spend that TXO.
In shared ownership rent scheme that ZmnSCPxj described in [1],
the 'TXO rentier' has a signed timelocked 'backout' transaction that
spends the locked TXO, and assigns the reward to rentier.
If we say that any transaction that spends any TXO in the bond
(ignoring the timelock), invalidates the bond when presented to
takers, then TXO rentier can revoke the bond by simply
publishing this transaction (not to the blockchain, but by some other
means so that takers can receive it).
The transaction validity can be verified, with the relaxed rules that
ignores the timelock. After it is verified, takers mark the whole
bond as revoked and will not consider it when chosing makers.
One inconvenience here is that takers need to store the
data about revoked bonds. But it seems to me that there's no need
for that information to be synchronized between the participants
instantly. It is enougth for takers to get the revoked-set eventually.
The rentier are still incentivized to not spoil the bond, to receive
the profit. Their funds are locked anyway.
But if the goal of the 'rentier' is to attack the attacker, the
opportunity cost of these locked funds is the cost of the attack.
If the renter rents TXOs from several entities to include in one bond,
revocation by one rentier spoils whole bond, and the total loss for all
participants is bigger than the oportunity cost of locked funds of a
single rentier that made the revocation.
The possibility of such revocation increases risk for the renter and
would-be co-rentiers, and is likely limit the possible scale of such
TXO-renting operation.
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017217.html
next prev parent reply other threads:[~2019-08-07 15:08 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
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 [this message]
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=20190807201017.2a03b971@simplexum.com \
--to=dp@simplexum$(echo .)com \
--cc=belcher@riseup$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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