summaryrefslogtreecommitdiff
path: root/84/a6e55e22d7f367e197c0f136161049b66cc552
blob: e22150558eb2611ca1fee8074cd1bd7a53ef088e (plain)
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
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4D48997
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 22 Aug 2015 01:03:11 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148101.authsmtp.com (outmail148101.authsmtp.com
	[62.13.148.101])
	by smtp1.linuxfoundation.org (Postfix) with ESMTP id B2B1EAB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 22 Aug 2015 01:03:09 +0000 (UTC)
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7M135Hx089847;
	Sat, 22 Aug 2015 02:03:05 +0100 (BST)
Received: from muck (S0106e03f49079160.ok.shawcable.net [174.4.1.120])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t7M0vpq7045505
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Sat, 22 Aug 2015 01:58:45 +0100 (BST)
Date: Fri, 21 Aug 2015 17:57:49 -0700
From: Peter Todd <pete@petertodd.org>
To: Thomas Kerin <thomas.kerin@gmail.com>
Message-ID: <20150822005749.GA22371@muck>
References: <55D288C2.9020207@gmail.com> <20150819010404.GB2835@muck>
	<CAOG=w-tENY3aFbg88Gvhi26jgJ6m-bMqkEi1CaLP+wct7dErnA@mail.gmail.com>
	<55D707C5.50803@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="VbJkn9YxBvnuCH5J"
Content-Disposition: inline
In-Reply-To: <55D707C5.50803@gmail.com>
X-Server-Quench: 8b499740-4869-11e5-9f75-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdAAUGUATAgsB AmMbW1ZeUF57WWY7 ag1VcwFDY1RPXQV1
	VUBOXVMcUAIVAVpB RxkeVhx3dwAIfH90 ZUAsViJfVU19cUZg
	RkZSHHAHZDJldWlJ V0VFdwNWdQpKLx5G bwR8GhFYa3VsNCMk
	FAgyOXU9MCtqYA50 elNFEEkTR0lDOzMw RhkEVSkuGEBAXywo
	M1QvMRYRGkoJNUQ0 LRMvXkh6exsVAQ5C HkRASCRQI1IcQyM3 DARcRiYA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.4.1.120/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP: Using Median time-past as endpoint for
 locktime calculations
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sat, 22 Aug 2015 01:03:11 -0000


--VbJkn9YxBvnuCH5J
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 21, 2015 at 12:13:09PM +0100, Thomas Kerin wrote:
>=20
> I submitted the pull-request for the median-past timelock BIP just now
>=20
> https://github.com/bitcoin/bips/pull/182
>=20
> Any luck finding the link to this discussion? It would be nice to
> include this for posterity.

Found it! From #bitcoin-wizards, 2013-07-16:

23:57 < petertodd> See, it'd be possible for nLockTime w/ time-based locks =
to create some really ugly incentives for miners to mine blocks at thelimit=
 of the 2hr window - a timestamping chain could provide a way for nodes to =
at least detect that their clocks are off, especially given how peers can m=
ess with them.
23:58 < petertodd> It's still dodgy though... I was thinking if nLockTime-b=
y-time inclusion was based on the previous block timestamp it'd be ok, but =
that still leaves large miners with incentives to screw with the 2hr window=
, never mind how it can reduce competition if there exists clock skew in th=
e mining nodes.
--- Log closed Wed Jul 17 00:00:57 2013
--- Log opened Wed Jul 17 00:00:57 2013
00:01 < petertodd> (remember that if this is a timestamping facility any no=
de wanting to know the current time simply gets a nonce timestamped, and th=
en they know what time it is!)
00:11 < Luke-Jr> I don't see how nLockTime can discourage forward-dating bl=
ocks
00:11 < Luke-Jr> and there is no 2hr window backward..
00:12 < Luke-Jr> well, I guess if miners are behaving there is <.<
00:19 < petertodd> The problem is a block being created with nTime > actual=
 time, and the incentive is to get a head start on other miners to put, say=
, a high-fee nLockTime in the block you are creating.
00:21 < Luke-Jr> petertodd: but nLockTime only sets a minimum time, it cann=
ot set a maximum
00:22 < petertodd> but that's it, if I have a 1BTC fee tx, with nLockTime e=
xpiring in two hours, why not take the increased orphan chance and set nTim=
e on my block to two hours ahead/
00:22 < petertodd> ?
00:22 < petertodd> yet if we allow that incentive, it's very bad for consen=
sus
00:23 < gmaxwell> ha. We can fix.
00:23 < gmaxwell> it's a soft forking fix.
00:23 < gmaxwell> use the last blocks ntime, not this one.
00:23 < Luke-Jr> is sipa's secp256k1 branch reasonably stable?
00:23 < petertodd> gmaxwell: that's what I said...
00:24 < gmaxwell> petertodd: sorry I just read the last couple lines.
00:24 < Luke-Jr> petertodd: AFAIK we already don't relay transactions with =
time in the future?
00:24 < gmaxwell> petertodd: well I agree. (or not even the last block=E2=
=80=94 it could use the minimum time)
00:24 < petertodd> gmaxwell: The problem is, that's only a fix if mining po=
wer is well distributed, it actually makes things worse because if there is=
 a lot of profit to be gained the miners with a lot of hashing power still =
have the incentive, and it's to a much greater degree. (their orphan rate i=
s less)
00:24 < Luke-Jr> gmaxwell: the minimum time will be earlier than the last b=
lock's :p
00:25 < gmaxwell> Luke-Jr: sure, but that doesn't change it really. Presuma=
bly if people start locking in the future miners will run nodes that take w=
hat they get and selfishly horde them, creating incentives for all miners t=
o run good collection networks.
00:25 < petertodd> Luke-Jr: sure, but there are lots of ways to learn that =
a tx exists
00:26 < gmaxwell> petertodd: one of the reasons that the min is important t=
here is because (1) it's hard to advance, and (2) when you advance it you r=
aise the difficulty.
00:26 < petertodd> gmaxwell: I was working on figuring out the expected ret=
urn - the math is really ugly
00:27 < gmaxwell> petertodd: a worst case expected return may be easier.
00:27 < petertodd> gmaxwell: Worst case is easy - your block is orphaned.
00:28 < petertodd> gmaxwell: See the issue is that once I find a block, the=
 other side needs to find two blocks to beat me. As time goes on more of th=
e other sides hashing power will accept my from the future block as valid, =
so then you get the next level where the remainder needs three blocks and s=
o on.
00:28 < petertodd> gmaxwell: Pretty sure it can't be done as a closed-form =
equation.
00:30 < petertodd> gmaxwell: I don't think minimum time works either, becau=
se you still get to manipulate it by creating blocks in the future, althoug=
h the ability too is definitely less. If I could show you'd need >50% hashi=
ng power to do anything interesting I'd be set.
00:31 < Luke-Jr> petertodd: hmm, is block-uneconomic-utxo-creation basicall=
y just an older revision of what Gavin did in 0.8.2?
00:31 < gmaxwell> petertodd: moving the minimum time forward needs the cope=
ration of >50% of the hashpower over the small median window.
00:32 < petertodd> Luke-Jr: It's what Gavin did but non-hardcoded. I'd emph=
asize the better, not the older. :P
00:32 < Luke-Jr> petertodd: will you be rebasing it despite its closed stat=
us?
00:32 < Luke-Jr> actually, what about Gavin's is hardcoded? <.<
00:33 < petertodd> gmaxwell: Yeah, but you have to assume a steady stream o=
f these incentives.
00:33 < gmaxwell> petertodd: right, so you have some force that turns all m=
iners into a conspiracy.
00:34 < petertodd> gmaxwell: exactly
00:34 < petertodd> gmaxwell: nLockTime by time should have never been added=
 in the first place, but it's such a nice idea on the face of it
00:35 -!- realazthat is now known as rudeasthat
00:35 -!- rudeasthat is now known as rudest
00:35 < Luke-Jr> softfork so nLockTime requires data on what block a transa=
ction was created at, and enforces the 10 min per block <.<
00:36 -!- rudest is now known as heh
00:36 < petertodd> Luke-Jr: ?
00:36 -!- heh is now known as realz
00:36 < Luke-Jr> petertodd: for example, if you nLockTime for 1 day from no=
w, it also enforces 144 blocks passing too
00:37 < Luke-Jr> so block count must be >now+144 AND time must be >now+24h
00:37 < Luke-Jr> not perfect, but might help
00:37 < petertodd> Still doesn't help in the usual case where mean interval=
 is < 10 minutes, because you're back to only caring about time.
00:38 < Luke-Jr> usual now, but not eventually
00:38 < petertodd> Right, you've solved half the problem, when measured ove=
r the entire lifespan of Bitcoin, and only approximately half. :P
00:39 < Luke-Jr> theory is so much nicer than practice <.<
00:39 < gmaxwell> I'm forgetting why this is a problem again?  If miners mi=
ne blocks early, people will just artifically inflate their times or switch=
 to height locking.
00:39 < petertodd> The problem is you're incentivising miners to make the 2=
hr window for block acceptance effectively shorter.
00:39 < petertodd> Thus requiring accurate clocks for consensus.
00:39 < gmaxwell> if miners do this consistently they'll drive difficulty u=
p too which wouldn't be in their interest.
00:39 < Luke-Jr> ^
00:40 < petertodd> gmaxwell: It's only a fixed 2hr offset, that just drives=
 difficulty up by 0.5%
00:40 < Luke-Jr> and on top of that, you'd just end up treating nTime with =
a minus-2-hours :p
00:41 < Luke-Jr> if everyone does it, it's predictable.
00:41 < petertodd> More to the point for any individual miner the marginal =
difference if they do it is effectively zero.
00:41 < gmaxwell> consider, why why cant the 2 hour window be 24 hours?
00:41 < petertodd> Luke-Jr: But that's the problem, if everyone does it, an=
d people respond, then you can extend the interval even further!
00:41 < Luke-Jr> petertodd: how?
00:41 < petertodd> gmaxwell: It should have been more like 24 hours in the =
first place...
00:42 < Luke-Jr> you don't change the 2h rule
00:42 < Luke-Jr> you just assume miner times will always be up against it
00:42 < gmaxwell> Luke-Jr: move your clock/window forward so you dont rejec=
t stupid blocks.
00:42 < petertodd> Luke-Jr: Again, the issue is the effect on *consusus*. I=
 don't care when the tx gets mined, I care that miners are incentivised to =
break consunsus for anyone without NTP.
00:43 < petertodd> The problem is no matter *what* the window is, there is =
an incentive to mine as close to the window as possible to accept a tx soon=
er than your competitors.
00:43 < petertodd> It could be a week and people would still have an incent=
ive to set nTime + 1 week - 1 second
00:44 < Luke-Jr> if nTime is future, wait until that time before relaying i=
t? <.<
00:44 -!- realz is now known as pleasedont
00:44 < gmaxwell> and once people did that, you'd want to start accepting b=
locks that where nTime + 1 week because god knows you don't want to reject =
a block if your clock was 2 seconds slow and most hashpower accepted it.
00:44 < petertodd> About the only thing that might change that is if the ru=
le was nLockTime > nTime of last block, and then after that being allowed t=
o include a tx was based on H(txhash, last hash) or similar
00:45 < petertodd> gmaxwell: exactly, the fundemental issue is there is no =
good incentive to set nTime accurately other than miners rejecting your blo=
cks, and nLockTime sabotages that
00:45 -!- pleasedont is now known as realzies
00:45 < petertodd> gmaxwell: (timestamping could do, but the cause->effect =
is less obvious)
00:45 < Luke-Jr> I guess I just incentivized always setting nTime to the mi=
nimum then
00:45 < Luke-Jr> [04:32:26] <Luke-Jr> petertodd: will you be rebasing it de=
spite its closed status? (block-uneconomic-utxo-creation)
00:46 < petertodd> Luke-Jr: again, relaying does nothing - consider the cas=
e of nLockTime'd fidelity bonds where it's guaranteed 100% of the hashing p=
ower know (why I wrote the spec as by-block-height in the first place)
00:46 < petertodd> Luke-Jr: sure
00:46 < Luke-Jr> petertodd: I mean delaying relaying the BLOCK
00:46 < Luke-Jr> ie, increasing the risk of it being stale
00:47 < petertodd> Luke-Jr: then you have your mining pool connect directly=
 to other mining pools playing the same game
00:47 < petertodd> you have to assume perfect information knowledge in this=
 stuff, at least if you're writing worst-case academic papers
00:48 < gmaxwell> petertodd: so ... prior block vs minimum time.
00:48 < petertodd> see, that's why I was talking about timestamping, becaus=
e it provides a way for all users to set their clocks to what the majority =
of hashing power thinks nTime is, sidestepping the problem
00:48 < gmaxwell> petertodd: what are your arguments there?
00:48 < petertodd> gmaxwell: minimum time is definitely stronger because it=
 involves more hashing power
00:49 < petertodd> gmaxwell: users would prefer minimum time - easier to un=
derstand why the tx isn't getting mined
00:49 < gmaxwell> sidestepping the problem < that doesn't sidestep the prob=
lem, it would allow the majority of hashpower to mine difficulty down to 1;=
 also moots nlocktime as _time_ being more reliable than a height.
00:49 < gmaxwell> petertodd: plus, you can just add a constant offset to yo=
ur nlocktime to adjust for the expected minimum lag.
00:51 < petertodd> gmaxwell: yes, it creates a new problem, but it did side=
step the existing one :P
00:51 < gmaxwell> petertodd: yea, lol, creates an inflation attack. Keep it=
 up and you'll be qualified to create an altcoin. :P
00:52 < gmaxwell> (sorry, hah, I'm not poking fun at you, I'm poking fun at=
 all the altcoins that "solved the Foo problem" where foo is something no o=
ne else thinks is a problem and they totally broke security as a side effec=
t)
00:52 < petertodd> gmaxwell: yup, now you see how it only sidesteps the pro=
blem truly when there is enough hashing power setting their clocks back, IE=
 50% honest, which is better
00:53 < petertodd> gmaxwell: without the timestamping, nodes have the conse=
nsus failures, which can be attacked, likely it trades off one risk for a m=
ore existential risk
00:53 < petertodd> gmaxwell: and it's a good excuse for timestamping, lol
00:54 < gmaxwell> I thin the min solves the consensus failure so long as ha=
shpower is well distributed.
00:54 < petertodd> yeah, I'm thinking min is probably the best we can do

https://download.wpsoftware.net/bitcoin/wizards/2013/07/13-07-16.log

--=20
'peter'[:-1]@petertodd.org
00000000000000000402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d

--VbJkn9YxBvnuCH5J
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

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

iQGrBAEBCACVBQJV18kKXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwNDAyZmU2ZmI5YWQ2MTNjOTNlMTJiZGRmYzZlYzAyYTJi
ZDkyZjAwMjA1MDU5NGQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzYCQf/erkIoXBscykeg3NuOZl6Gk1k
UbnMgYm9V1VHZ/A6mUjMH6fk0FMFfq3gN/+Rqec9NyDvXbmWOFzgTaJX6Bl4rF3v
mIBCsZ23Gs95JkvT5evlkUfdHXBVrhcaY54H2w+XuU9L6IKF2U8HOsTGn+uTLqf+
T90ojRxq7E0P0SujnYig/97KCVUTW2rRfNyoxHtciy17XXalc4qISer6YThuiJuy
LrVHqTB3JKm2d5zdRtfNxJW8zEZUZZoEd0kMy6mui8pPn8BNDaw/ZS03+RBz3cEm
mlIGwVeTAOXuK5XAhIAU8a6enS9KZo56dNMqP7fN7QMlIoTEmVzJrx3KTatKeA==
=EVnu
-----END PGP SIGNATURE-----

--VbJkn9YxBvnuCH5J--