public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "David A. Harding" <dave@dtrt.org>
To: Chris Belcher <belcher@riseup.net>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds
Date: Sat, 27 Jul 2019 09:34:17 -1000	[thread overview]
Message-ID: <20190727193417.cxf544dbempencql@ganymede> (raw)
In-Reply-To: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net>

On Thu, Jul 25, 2019 at 12:47:54PM +0100, Chris Belcher via bitcoin-dev wrote:
> 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.

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.

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).

Any full node (archival or pruned) can verify coin age using the UTXO
set.[1]  Unlike script-based timelock (CLTV or CSV), there is no current
SPV-level secure way to prove to lite clients that an output is still
unspent, however such verification may be possible within each lite
client's own security model related to transaction withholding attacks:

- Electrum-style clients can poll their server to see if a particular
  UTXO is unspent.

- 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.

> 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.

This is the thing I most like about the proposal.  I suspect most
honest makers are likely to have only a small portion of their funds
under JoinMarket control, with the rest sitting idle in a cold wallet.
Giving makers a way to communicate that they fit that user template
would indeed seem to provide significant sybil resistance.

-Dave

[1] See, bitcoin-cli help gettxout


  parent reply	other threads:[~2019-07-27 19:35 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-25 11:47 [bitcoin-dev] Improving JoinMarket's resistance to sybil attacks using fidelity bonds 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 [this message]
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=20190727193417.cxf544dbempencql@ganymede \
    --to=dave@dtrt.org \
    --cc=belcher@riseup.net \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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