1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
|
Return-Path: <tamas.blummer@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2B43DC2A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jul 2019 18:29:37 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com
[209.85.221.66])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6C4155E4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jul 2019 18:29:36 +0000 (UTC)
Received: by mail-wr1-f66.google.com with SMTP id p13so59380488wru.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 28 Jul 2019 11:29:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:message-id:mime-version:subject:date:in-reply-to:cc:to
:references; bh=MUImeC5Tcw+yBl3pP0UsrE8JFTojGU3E/GO2uKtWTus=;
b=ELifoFg1harWaRA+MuA+TvPbzzQ84nsde+IxWVGStyry8Crlr/2rqAjDf2ClBasq1g
7St8FBFjMLdjXuMA4V+UPnownsSJGt4yoSVs2GpRl5SO2wKA1m30pdNJmmYc6GVO2MMN
VvEzshXH+Op4DICpXSNgL4QIlvTv64gmgo/TNopHi3ldtI1AozwZwkmLhQYPevzt190f
LqMUlgZkbbr6Zndcye3ELKTkC2ZHuAqkkMrpuOlmLhDCTow0bKiMd3LXJgCTpNaGnWbZ
fQtnsVDeSxPJsiGCm7kRfgvQij20G9dNkxGNW7o4mV5/C7f1cMj5T+FTLE050Yk8OTrz
Tvvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:message-id:mime-version:subject:date
:in-reply-to:cc:to:references;
bh=MUImeC5Tcw+yBl3pP0UsrE8JFTojGU3E/GO2uKtWTus=;
b=ZJ+BT/dpJ+gEuYw1+sSmQQ97W1CzHB7d2GkUDCKF6Bj89hKSoXF2qDA4OvsBWPDuB0
lhN27GMskbdNpeIOYJkdjZK8UTiogH3896s9fAIC2LnKEHOLMaUHsK/ljfgCi6d3sJxG
i4z+CtejoxCXZF9hOP2gbz/H/GBbIMcthfwrr+fDPvh5AZ9J3EIB6TQFlWHp6Bq1VWCi
aq6G4nXIeCx7PdT3CkfnAqUxs+uBA7mQzNsBOsCWh3sg5AvtC/DXQpHDav9HqGa6rBB2
XTGxfeYoxlr+2h0ma6mdnUTKoJUFBlvuJ3tov/Lqw55hiH+S5J4R88kCWIU0ie74BbCN
0tdw==
X-Gm-Message-State: APjAAAV4Ch+TcT/AiDo0xqICzMZ+yew2oYVSsjSlPBVXwmhYqTWdxJCb
aR7Ogk79u5s2LmGQseq87zU=
X-Google-Smtp-Source: APXvYqzxdgx2PyqP0uoz08nDav9ohVyQ89hbhCxYHWoLhlq0p/mkaLuoFY0FERTI1/fBsfJd9vjT+g==
X-Received: by 2002:a5d:5012:: with SMTP id e18mr13046963wrt.166.1564338574954;
Sun, 28 Jul 2019 11:29:34 -0700 (PDT)
Received: from p200300dd67126429397d7db45608eb5e.dip0.t-ipconnect.de
(p200300DD67126429397D7DB45608EB5E.dip0.t-ipconnect.de.
[2003:dd:6712:6429:397d:7db4:5608:eb5e])
by smtp.gmail.com with ESMTPSA id
z25sm62527334wmf.38.2019.07.28.11.29.33
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sun, 28 Jul 2019 11:29:34 -0700 (PDT)
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>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Mon, 29 Jul 2019 02:53:15 +0000
Subject: Re: [bitcoin-dev] Improving JoinMarket's resistance to sybil
attacks using fidelity bonds
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 28 Jul 2019 18:29:37 -0000
--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--
|
