summaryrefslogtreecommitdiff
path: root/28/a26a5aaed7f9875e2449ef6c6a7906c22b74af
blob: d0db1206d81898616b9ac0cb740205b2a51fc2d6 (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
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
Return-Path: <willtech@live.com.au>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 16CCC892
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  7 Dec 2017 08:13:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from APC01-HK2-obe.outbound.protection.outlook.com
	(mail-oln040092255084.outbound.protection.outlook.com [40.92.255.84])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 71E5D79
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  7 Dec 2017 08:13:17 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; 
	h=From:Date:Subject:Message-ID:Content-Type:MIME-Version;
	bh=K6rIiGbs5/TrXLgl7ObHk1akcQHGbAN0vNsDF5I0Uq0=;
	b=L4LG4vIYhjWrJJZlVls9biFz837SALl+Tzc9m/67pDWDsHSa/bAxe34OIszD2KLkW8OFA4Ad1H3O2RfpKap/p1qslS8Z1hEpX7XnP/z1d19X/sGvJ0EqLrblT8oOgvEcXmtjtRCduMjPv7twuixOdG4lMfvSeNJ18TMjlr9uVf0Qo2pV8y97QuwXGAa0WK7ATIEHyf2e7CYFazKkQvFQEfwdi9Q1vpaRkcX7HI1qkEMlqnC8XqPjJVAtLfvnNYDVhU65Ukn7nXH95KT/be+TKpY2oSFWtWMZqus1c5VCWSfzXM/aGfbKRSmB6qv+XCIL/krsmcnV3IhRjO6W/mZYbQ==
Received: from PU1APC01FT015.eop-APC01.prod.protection.outlook.com
	(10.152.252.54) by PU1APC01HT177.eop-APC01.prod.protection.outlook.com
	(10.152.253.162) with Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4;
	Thu, 7 Dec 2017 08:13:15 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM (10.152.252.57) by
	PU1APC01FT015.mail.protection.outlook.com (10.152.252.227) with
	Microsoft SMTP Server (version=TLS1_2,
	cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.282.5 via
	Frontend Transport; Thu, 7 Dec 2017 08:13:15 +0000
Received: from PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) by
	PS2P216MB0179.KORP216.PROD.OUTLOOK.COM ([10.171.225.19]) with mapi id
	15.20.0282.007; Thu, 7 Dec 2017 08:13:15 +0000
From: Damian Williamson <willtech@live.com.au>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Thread-Topic: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight
	For Ordering Transactions In Blocks
Thread-Index: AQHTa+TfjIfbrac6DkW4WL8VVZ5YaaM102mAgAA9mEaAAWVUAIAAFHP0
Date: Thu, 7 Dec 2017 08:13:14 +0000
Message-ID: <PS2P216MB0179DD143E0558194295ADCC9D330@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
References: <PS2P216MB01791F54380CD03B3936399E9D3F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
	<TUV8ZuUkjBRWx-C9y-MOdLBBzWKRLd9TalfSPE1qN6oEvup6uAeGVUUlabCDDHKvWh1GZXTPgj6eOjPngN4ACLX2vIoXcjICy2s8tZfh7JQ=@protonmail.com>
	<PS2P216MB0179BC1CDE30F00D73DAA10F9D320@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>,
	<oVWjxK8fBoFl02giOtDPEQ7kAnp9TIRlAJKT14xJ6-VRRVJhT6-UsYLXqBARKUZi-fgRuKgymoTpHuQB5pluZRauX9dPOniJLAC5F6d0jo4=@protonmail.com>
In-Reply-To: <oVWjxK8fBoFl02giOtDPEQ7kAnp9TIRlAJKT14xJ6-VRRVJhT6-UsYLXqBARKUZi-fgRuKgymoTpHuQB5pluZRauX9dPOniJLAC5F6d0jo4=@protonmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-incomingtopheadermarker: OriginalChecksum:EE340025652C1522AFED52182E871BB62A9733517887786402E9C604D17B4BB0;
	UpperCasedChecksum:02F276195DCFFB54FD7FA9F413FBE7D42B8851ADC374FEF2D04773B061201E9E;
	SizeAsReceived:7612; Count:47
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [ZcUw2IgsezeYkad86EUpz5spG1mO5mAf]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; PU1APC01HT177;
	6:pgl9pXaqbWgLDX/07hdyWVocz+FVdVUnsE1P7HWAg4H7FzNFlT2XwFV855+h77YGgeLn4OVdijsHHlVLx9ZF6TbVNUYAsgf42vJ5Qc3egZsgMSKWvaCkbuTv9KV6j4wuMEjdvQg5C5b6WUxIt5Bf28jtQrsMyjJME4DQa2fpaz9Dor/nl+uE9Es7NiLPtKfBXyJZQfYpIu1v5TiBdeaIr1Nl40dLR2Ab+0yWI7ehiSXEeZa13mjpcCsTqRDdZfuNnpVvyu6ppPCP3pKYJm9iXuguP4oFmjQWKC7oaoI8g+5jYt4jERTW0AmGiIT4QvUozLF6Mvi3aJa8rsLwmCEPP4rgGRWDkEqX1LhuYoypA1U=;
	5:dMjewmddtAyOR+cx+U46gVpxlZITyThGSW+bgApan5/jjrMMbw2jB+zRDRZysanPCKyXdupL0GGTsho88LQgkUECAzxjiV3uiaqpKwdq5wkNywtAcm05F5FEZcOyJxuQ6K4ZBlX/ET5U89WYdq/3MGhiInFQOeHqweuFEJr4Tmc=;
	24:1tv2xxmWicZ6r7DdsYva2tZjahKJaPE7WZz1Axj1bMToCrnIaKDFmmFTisC8ycMqeyz4LJBctWE1IpI7p0aUqQ4VB6amZpyHbnU262t0EQY=;
	7:pwNeRUUdkPSWVQ5Zo/IysWh2TNbtwL6ouKTMI3qgMeQXiNNgxuatSPV3z0LVBg1o3ehW9uOWKHmEBdPCl6Sma7HI+okBifUOIAUocyNI37UyQxSXYRu/R7WAAciA9mTyL2DU9tl0uJn5A+tL8BtzS46THHm/kSwZSSTsti7iJqN0qd1jvHUbXwyd+E2J2C+6i9k2ABIMmgG8eJknSG4nCS0HGVla3lvv+PruOo6kSH/nrcECk89rWpGxVff7+JSG
x-incomingheadercount: 47
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125374)(1603101448)(1701031045);
	SRVR:PU1APC01HT177; 
x-ms-traffictypediagnostic: PU1APC01HT177:
x-ms-office365-filtering-correlation-id: 39b3b5c7-65f9-4ba6-63a6-08d53d4a5d9b
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444000031);
	SRVR:PU1APC01HT177; BCL:0; PCL:0;
	RULEID:(100000803101)(100110400095); SRVR:PU1APC01HT177; 
x-forefront-prvs: 05143A8241
x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT;
	SFP:1901; SCL:1; SRVR:PU1APC01HT177;
	H:PS2P216MB0179.KORP216.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_PS2P216MB0179DD143E0558194295ADCC9D330PS2P216MB0179KORP_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 39b3b5c7-65f9-4ba6-63a6-08d53d4a5d9b
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Dec 2017 08:13:14.9507 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PU1APC01HT177
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, 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: Thu, 07 Dec 2017 13:49:33 +0000
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight
 For Ordering Transactions In Blocks
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: Thu, 07 Dec 2017 08:13:19 -0000

--_000_PS2P216MB0179DD143E0558194295ADCC9D330PS2P216MB0179KORP_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Good morning ZmnSCPxj, it must be where you are,


I suppose that we are each missing each other's point some.


I understand that nodes would not be expected to agree on the transaction p=
ool and do not propose validating that the correct transactions are include=
d in a block. I speak of probability and likelihood of a transaction being =
included in a block, implying a random element. I do not propose rejecting =
blocks on the basis that the next block size is stated too large or too sma=
ll for the transaction pool, only that the block received conforms to the n=
ext block size given on the previous block. Yes, it could be cheated. Also,=
 various nodes may have at times wildly different amounts of transactions w=
aiting in the transaction pool compared to each other and there could be a =
great disparity between them. It would not be possible in any case I can th=
ink of to validate the next block size is correct for the current transacti=
on pool. Even as it is now, nodes may include transactions in a block that =
no other nodes have even heard of, nodes have no way to validate that eithe=
r. If the block is built on sufficiently, it is the blockchain.


I will post back the revised proposal to the list. I have fleshed parts of =
it out more, given more explanation and, tried this time not to recycle ter=
minology.


Regards,

Damian Williamson

________________________________
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Sent: Thursday, 7 December 2017 5:46:08 PM
To: Damian Williamson
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight =
For Ordering Transactions In Blocks

Good morning Damian,

>As I understand it, each node would be aware independently of x transactio=
ns waiting for confirmation, the transaction pool.

Each long-running node would have a view that is roughly the same as the vi=
ew of every other long-running node.

However, suppose a node, Sleeping Beauty, was temporarily stopped for a day=
 (for various reasons) then is started again.  That node cannot verify what=
 the "consensus" transaction pool was during the time it was stopped -- it =
has no view of that.  It can only trust that the longest chain is valid -- =
but that means it is SPV for this particular rule.

>If next blocksize is broadcast with the completed block it would be a simp=
le matter to back confirm that.

It would not. Suppose Sleeping Beauty slept at block height 500,000.  On aw=
akening, some node provides some purported block at height 500,001.  This b=
lock indicates some "next blocksize" for the block at height 500,002.  How =
does Sleeping Beauty know that the transaction pool at block 500,001 was of=
 the correct size to provide the given "next blocksize"?  The only way, wou=
ld be to look if there is some other chain with greater height that include=
s or does not include that block: that is, SPV confirmation.

How does Sleeping Beauty know it has caught up, and that its transaction po=
ol is similar to that of its neighbors (who might be lying to it, for that =
matter), and that it should therefore stop using SPV confirmation and switc=
h to strict fullnode rejection of blocks that indicate a "next blocksize" t=
hat is too large or too small according to your equation?  OR will it simpl=
y follow the longest chain always, in which case, it trusts miners to be ho=
nest about how loaded (or unloaded) the transaction pool is?

-------

As a general rule, consensus rules should restrict themselves to:

1.  The characteristics of the block.
2.  The characteristics of the transactions within the block.

The transaction pool is specifically those transaction that are NOT in any =
block, and thus, are not safe to depend on for any consensus rules.

Regards,
ZmnSCPxj


--_000_PS2P216MB0179DD143E0558194295ADCC9D330PS2P216MB0179KORP_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0"></p>
<p style=3D"margin-top:0;margin-bottom:0">Good morning ZmnSCPxj, it must be=
 where you are,</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">I suppose that we are each missin=
g each other's point some.</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">I understand that nodes would not=
 be expected to agree on the transaction pool and do not propose validating=
 that the correct transactions are included in a block. I speak of probabil=
ity and likelihood of a transaction
 being included in a block, implying a random element. I do not propose rej=
ecting blocks on the basis that the next block size is stated too large or =
too small for the transaction pool, only that the block received conforms t=
o the next block size given on the
 previous block. Yes, it could be cheated. Also, various nodes may have at =
times wildly different amounts of transactions waiting in the transaction p=
ool compared to each other and there could be a great disparity between the=
m. It would not be possible in any
 case I can think of to validate the next block size is correct for the cur=
rent transaction pool. Even as it is now, nodes may include transactions in=
 a block that no other nodes have even heard of, nodes have no way to valid=
ate that either. If the block is
 built on sufficiently, it is the blockchain.<br>
</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p style=3D"margin-top:0;margin-bottom:0">I will post back the revised prop=
osal to the list. I have fleshed parts of it out more, given more explanati=
on and, tried this time not to recycle terminology.</p>
<p style=3D"margin-top:0;margin-bottom:0"><br>
</p>
<p></p>
<p style=3D"margin-top:0;margin-bottom:0">Regards,</p>
<p style=3D"margin-top:0;margin-bottom:0">Damian Williamson<br>
</p>
</div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> ZmnSCPxj &lt;ZmnSCPxj=
@protonmail.com&gt;<br>
<b>Sent:</b> Thursday, 7 December 2017 5:46:08 PM<br>
<b>To:</b> Damian Williamson<br>
<b>Cc:</b> bitcoin-dev@lists.linuxfoundation.org<br>
<b>Subject:</b> Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction =
Weight For Ordering Transactions In Blocks</font>
<div>&nbsp;</div>
</div>
<div>
<div>Good morning Damian,<br>
</div>
<div><br>
</div>
<div>&gt;As I understand it, each node would be aware independently of x tr=
ansactions waiting for confirmation, the transaction pool.<br>
</div>
<div><br>
</div>
<div>Each long-running node would have a view that is roughly the same as t=
he view of every other long-running node.<br>
</div>
<div><br>
</div>
<div>However, suppose a node, Sleeping Beauty, was temporarily stopped for =
a day (for various reasons) then is started again.&nbsp; That node cannot v=
erify what the &quot;consensus&quot; transaction pool was during the time i=
t was stopped -- it has no view of that.&nbsp; It can
 only trust that the longest chain is valid -- but that means it is SPV for=
 this particular rule.<br>
</div>
<div><br>
</div>
<div>&gt;If next blocksize is broadcast with the completed block it would b=
e a simple matter to back confirm that.<br>
</div>
<div><br>
</div>
<div>It would not. Suppose Sleeping Beauty slept at block height 500,000.&n=
bsp; On awakening, some node provides some purported block at height 500,00=
1.&nbsp; This block indicates some &quot;next blocksize&quot; for the block=
 at height 500,002.&nbsp; How does Sleeping Beauty know that
 the transaction pool at block 500,001 was of the correct size to provide t=
he given &quot;next blocksize&quot;?&nbsp; The only way, would be to look i=
f there is some other chain with greater height that includes or does not i=
nclude that block: that is, SPV confirmation.<br>
</div>
<div><br>
</div>
<div>How does Sleeping Beauty know it has caught up, and that its transacti=
on pool is similar to that of its neighbors (who might be lying to it, for =
that matter), and that it should therefore stop using SPV confirmation and =
switch to strict fullnode rejection
 of blocks that indicate a &quot;next blocksize&quot; that is too large or =
too small according to your equation?&nbsp; OR will it simply follow the lo=
ngest chain always, in which case, it trusts miners to be honest about how =
loaded (or unloaded) the transaction pool is?<br>
</div>
<div><br>
</div>
<div>-------<br>
</div>
<div><br>
</div>
<div>As a general rule, consensus rules should restrict themselves to:<br>
</div>
<div><br>
</div>
<div>1.&nbsp; The characteristics of the block.<br>
</div>
<div>2.&nbsp; The characteristics of the transactions within the block.<br>
</div>
<div><br>
</div>
<div>The transaction pool is specifically those transaction that are NOT in=
 any block, and thus, are not safe to depend on for any consensus rules.<br=
>
</div>
<div><br>
</div>
<div>Regards,<br>
</div>
<div>ZmnSCPxj<br>
</div>
<div><br>
</div>
</div>
</body>
</html>

--_000_PS2P216MB0179DD143E0558194295ADCC9D330PS2P216MB0179KORP_--