From: Chris Belcher <belcher@riseup•net>
To: "David A. Harding" <dave@dtrt•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
Date: Tue, 30 Jul 2019 22:27:17 +0100 [thread overview]
Message-ID: <96722b03-9aa0-5e3d-25ed-c644c26d5a27@riseup.net> (raw)
In-Reply-To: <20190727193417.cxf544dbempencql@ganymede>
On 27/07/2019 20:34, David A. Harding wrote:
>
> Timelocking bitcoins, especially for long periods, carries some special
> risks in Bitcoin:
>
> 1. Inability to sell fork coins, also creating an inability to influence
> the price signals that help determine the outcome of chainsplits.
>
> 2. Possible inability to transition to new security mechanisms if
> a major weakness is discovered in ECC or a hash function.
>
Far future locks are problematic. In my proposal I've only considered
locked coins for only 6 months because of exactly these reasons. The
market competition between airdrops should still exist after 6 months so
lockers will still get a chance to sell their airdrops. And any
ECC-alternative or hash-function-alternative fork will probably take a
couple of months to be designed, implemented and deployed as well,
giving a chance for lockers to move coins.
> An alternative to timelocks might be coin age---the value of a UTXO
> multiplied by the time since that UTXO was confirmed. Coin age may be
> even harder for an attacker to acquire given that it is a measure of
> past patience rather than future sacrifice. It also doesn't require
> using any particular script and so is flexible no matter what policy the
> coin owner wants to use (especially if proof-of-funds signatures are
> generated using something like BIP322).
I'm becoming more and more convinced that coin age is also a valid
method of proving a sacrifice. Using coin age also has a benefit that
less block space is used, because using timelocks requires a new
on-chain transaction to be made every 6 months or whatever the locking
period is.
Perhaps JoinMarket should accept all three methods of proving a
sacrifice: burning, timelocking and aging. I could imagine that makers
would first lock coins for 6 months to create a fidelity bond they could
immediately use, and after the timelock expires leave that coin unspent
and use its age as the fidelity bond.
For what its worth, I mostly considered burning coins because the maths
for it is easy (the value of such a bond is just V^2), and because it
provides a boundary condition (locking up coins for infinity time is the
same as burning them). I doubt anybody will actually do it in practice.
> - BIP158 users who have saved their past filters to disk can use them to
> determine which blocks subsequent to the one including the UTXO may
> contain a spend from it. However, since a UTXO can be spent in the
> same block, they'd always need to download the block containing the
> UTXO (alternatively, the script could contain a 1-block CSV delay
> ensuring any spend occurred in a later block). If BIP158 filters
> become committed at some point, this mechanism is upgraded to SPV-level
> security.
This scheme could be attacked using address reuse. An attacker could
create an aged coin on a heavily-reused address, which would force an
SPV client using this scheme to download all the blocks which contain
this reused address which could result in many gigabytes of extra
download requirement.
So to fix this: a condition for aged coins is that their address has not
been reused, if the coin is on a reused address then the value of the
fidelity bond becomes zero.
next prev parent reply other threads:[~2019-07-30 21:27 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
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 [this message]
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=96722b03-9aa0-5e3d-25ed-c644c26d5a27@riseup.net \
--to=belcher@riseup$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)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