From: Tamas Blummer <tamas.blummer@gmail.com>
Message-Id: <78653C43-3766-4118-8C6A-8B073E7B8ECB@gmail.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_C25F4EE1-C208-444E-9370-E009C4CC78EE";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Sun, 28 Jul 2019 20:29:34 +0200
In-Reply-To: <20190727193417.cxf544dbempencql@ganymede>
To: "David A. Harding" <dave@dtrt.org>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <985792b1-e7aa-677b-a7a1-6a5f672da884@riseup.net>
	<20190727193417.cxf544dbempencql@ganymede>
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil
 attacks using fidelity bonds
Precedence: list


--Apple-Mail=_C25F4EE1-C208-444E-9370-E009C4CC78EE
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

In summary I see three mechansims of making use costly:

1. burn
2. time locked funds, locker will incure opportunity cost
3. proven coin age, holder did incure opportunity cost

I dislike burn as usage of a service is infinite while coin supply is =
finite.

I prefer time locked funds over coin age as locked funds do not need =
proof of
unspentness, they can not be spent. Therefore time locked funds can be =
sufficiently
proven with SPV. The user of the service could post SPV proof with the =
request.

Regards,

Tamas Blummer

> On Jul 27, 2019, at 21:34, David A. Harding via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>=20
> 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.
>=20
> Timelocking bitcoins, especially for long periods, carries some =
special
> risks in Bitcoin:
>=20
> 1. Inability to sell fork coins, also creating an inability to =
influence
> the price signals that help determine the outcome of chainsplits.
>=20
> 2. Possible inability to transition to new security mechanisms if
> a major weakness is discovered in ECC or a hash function.
>=20
> 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).
>=20
> 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:
>=20
> - Electrum-style clients can poll their server to see if a particular
>  UTXO is unspent.
>=20
> - 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.
>=20
>> 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.
>=20
> 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.
>=20
> -Dave
>=20
> [1] See, bitcoin-cli help gettxout
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_C25F4EE1-C208-444E-9370-E009C4CC78EE
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl096Y4ACgkQ9nKRxRdx
ORyM4Qf+KZXFzsqK5XPB083VUB7uKfyAqxRQXLfwNiHaBriI5nw7szmDd0pgdPW4
3+doN5/QYW0GHJALZUcDwnsWbaQhdlCwFmZnW3OZPXRhBywdyIctMhnkBrgRsEKP
gfAIuoMM+YAJXdSZScdQp//APYU7C/tGf3V+vK6i9ProSZS1JSv2xwQtv/Ojiidf
X0eF3kLPHKhH847Wi729qIRu6/qJNDIm2pFMutBS8HWJtAnCDkJfv9WxA/1eE5ZN
gsBpYah6yG20OuLuSXHVK5nuJJ/huT4Ky+uo3b+ao43XMlxrc6lzMc3znORiGq0h
+TUa0OoOA2ttxKii9y0iRQVKUye64Q==
=Fyo9
-----END PGP SIGNATURE-----

--Apple-Mail=_C25F4EE1-C208-444E-9370-E009C4CC78EE--