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
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
|
Return-Path: <earonesty@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id C4CB5C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Nov 2022 15:49:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 921F840253
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Nov 2022 15:49:25 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 921F840253
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=q32-com.20210112.gappssmtp.com
header.i=@q32-com.20210112.gappssmtp.com header.a=rsa-sha256
header.s=20210112 header.b=iv8+Os9L
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.399
X-Spam-Level:
X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001,
HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=no autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id h2nUxG9rerQg
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Nov 2022 15:49:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org EA042401A1
Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com
[IPv6:2607:f8b0:4864:20::e2c])
by smtp2.osuosl.org (Postfix) with ESMTPS id EA042401A1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Nov 2022 15:49:23 +0000 (UTC)
Received: by mail-vs1-xe2c.google.com with SMTP id k67so14052352vsk.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 08 Nov 2022 07:49:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=q32-com.20210112.gappssmtp.com; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=QVxOpD/lrk9lkskQ2VqxS/JN5uFfsJQZZ4frczhLCy8=;
b=iv8+Os9Lk5Gk0+3ABUB1a7UBrIgQz6IxJ6XAFUM87ExqJDyaQmcYjNreucqFaB9n6N
53K0K2SWbzsY8/j1kB7jieJGCeHulLgUgzyow/aHNKOHhDtl+0aKMM1z5yYOS2+ZL4KS
rL68CPFXMBHcvcOOiymMcmwAPdY3ABwt0Z9c2RYtmcWnEeGhm0oYN4XMllRIsIH9/UAz
TNVIamHI2P+qPhoJW3fIMWpEKOhpcZ/adMd8C0ytvHTTEAuQ03ujtlIYcAjapdKOfHNp
RfRa4hXpyK5r01VpR0IHThkFBpywvbAmiPByKAv8nwAkExmXYTxTkI5zd5exJ5kfQYcg
Fifg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=QVxOpD/lrk9lkskQ2VqxS/JN5uFfsJQZZ4frczhLCy8=;
b=oq/sIES2srrw3CVVJkUvPUzAiUV5ggGwyZB7uwCBUR1CbFEPjsafc1cu1RKSwRsPqn
CtdTv1XhZz5z+yPvIvev1Faw4FI554mqSyECcISgJZtugWNaDoRospnSpCD3dm2TE0gx
e/wlpuXY93Z8GNJ4I2MKx4GjTHVOjRJpox7eLSXDUukIk/fxL/gCv3cmDIUoC5ePJXWh
3y3q2aC7YDN69wwbeJwKyFMhbtLKWuHG9vihpKVo7gfqRvAfCt6EAQPOyKvN8PpV6hoM
8CzvMOiYHi9akH+dv5FCnlsDOPmhbdBQc0eNzAciBF2i1mIYO+MW1JXLHVqHiK4ZHoIp
ScqA==
X-Gm-Message-State: ANoB5pm9bdstaqA155XsNaqGzHP4z2bR9aqxejL1QKolTT4RHJ4FAAEZ
EcWoVjwN0+A/binLqHf0rPtHSvHdfuSy150mHkVq6DlYSIrxUbA=
X-Google-Smtp-Source: AA0mqf5vG/PRiK0nE2koM0RYd43K9K0JvDwQrKxFtbvuAFHiQR5V2Eq39Y1XYmKwhXFM7SKV+YXgXha6ryicu+0BXyE=
X-Received: by 2002:a05:6102:6c8:b0:3ad:d646:d9d1 with SMTP id
m8-20020a05610206c800b003add646d9d1mr7658627vsg.32.1667922562392; Tue, 08 Nov
2022 07:49:22 -0800 (PST)
MIME-Version: 1.0
References: <mOBAWIbHTgkSrCJ9IEBJgArqUNYcNSDQawhUzaiYyliaPDQT_YDfI5CLoDPZgEt43mePJof-CJfxzFxgXMUe6ONDJ4j5Bzk1QGjd50S9gb8=@mm-studios.com>
<CAJowKgKvtRXoLuA0kS5QhAVbhDi0k+3KZqfo+rBr+dbCCS2R5A@mail.gmail.com>
<lS-eB0uZHRjuHUG6HAyn4_Ponw4ysOCkY_J4cfqBjJ1eOK3PqC0hQ6Ov3XOIofmMC9D_Za3k9Px0OZPa2ayT4dd7wXKEMR910EfrSjlAfQw=@mm-studios.com>
<CAJowKgK5d15hf=paL_OO5xC3GBSXmwS3xdRYS+P1-NG6Y6dO-Q@mail.gmail.com>
<ox3E7bDtY6c4XIvQ5likp9j8Dk8CQlIEoGoSiCTRr3SE4B6udch2adfEnglM0mpCsVRF1hQAZERmzo-bq5fkafcvMvLqmK2O1E4IOiqwjog=@mm-studios.com>
In-Reply-To: <ox3E7bDtY6c4XIvQ5likp9j8Dk8CQlIEoGoSiCTRr3SE4B6udch2adfEnglM0mpCsVRF1hQAZERmzo-bq5fkafcvMvLqmK2O1E4IOiqwjog=@mm-studios.com>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 8 Nov 2022 10:49:10 -0500
Message-ID: <CAJowKg+2GaD+kMGMttcU8AXs+uJbg5bPMv7wuXQx91hLCDyYgw@mail.gmail.com>
To: mm-studios <mm@mm-studios.com>
Content-Type: multipart/alternative; boundary="000000000000d82a6b05ecf77bf7"
X-Mailman-Approved-At: Tue, 08 Nov 2022 21:49:46 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] brickchain
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Tue, 08 Nov 2022 15:49:25 -0000
--000000000000d82a6b05ecf77bf7
Content-Type: text/plain; charset="UTF-8"
> I think it's pretty clear that the "competitive nature of PoW" is not
referring to verification nodes
cool, so we can agree there is no accepted centralization pressure for
validating nodes then
> layers also add fees to users
source? i feel like it's obvious that the tree-like efficiencies should
reduce fees, but i'd appreciate your research on that topic
On Tue, Nov 8, 2022 at 9:25 AM mm-studios <mm@mm-studios.com> wrote:
>
> ------- Original Message -------
> On Tuesday, November 8th, 2022 at 2:16 PM, Erik Aronesty <erik@q32.com>
> wrote:
>
> > A) to not increase the workload of full-nodes
>
> yes, this is critical
>
> > given the competitive nature of PoW itself
>
> validating nodes do not compete with PoW, i think maybe you are not sure
> of the difference between a miner and a node
>
> nodes do validation of transactions, they do this for free, and many of
> them provide essential services, like SPV validation for mobile
>
>
>
> I think it's pretty clear that the "competitive nature of PoW" is not
> referring to verification nodes (satoshi preferred this other word).
>
> B) to not undermine L2 systems like LN.
>
> yes, as a general rule, layered financial systems are vastly superior. so
> that risks incurred by edge layers are not propagated fully to the inner
> layers. For example L3 projects like TARO and RGB are building on lightning
> with less risk
>
>
> layers also add fees to users
>
>
> On Wed, Oct 19, 2022 at 12:04 PM mm-studios <mm@mm-studios.com> wrote:
>
>> Thanks all for your responses.
>> so is it a no-go is because "reduced settlement speed is a desirable
>> feature"?
>>
>> I don';t know what weights more in this consideration:
>> A) to not increase the workload of full-nodes, being "less difficult to
>> operate" and hence reduce the chance of some of them giving up which would
>> lead to a negative centralization effect. (a bit cumbersome reasoning in my
>> opinion, given the competitive nature of PoW itself, which introduce an
>> accepted centralization, forcing some miners to give up). In this case the
>> fact is accepted because is decentralized enough.
>> B) to not undermine L2 systems like LN.
>>
>> in any case it is a major no-go reason, if there is not intention to
>> speed up L1.
>> Thanks
>> M
>> ------- Original Message -------
>> On Wednesday, October 19th, 2022 at 3:24 PM, Erik Aronesty <erik@q32.com>
>> wrote:
>>
>> > currently, a miner produce blocks with a limited capacity of
>> transactions that ultimately limits the global settlement throughput to a
>> reduced number of tx/s.
>>
>> reduced settlement speed is a desirable feature and isn't something we
>> need to fix
>>
>> the focus should be on layer 2 protocols that allow the ability to hold &
>> transfer, uncommitted transactions as pools / joins, so that layer 1's
>> decentralization and incentives can remain undisturbed
>>
>> protocols like mweb, for example
>>
>>
>>
>>
>> On Wed, Oct 19, 2022 at 7:34 AM mm-studios via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi Bitcoin devs,
>>> I'd like to share an idea of a method to increase throughput in the
>>> bitcoin network.
>>>
>>> Currently, a miner produce blocks with a limited capacity of
>>> transactions that ultimately limits the global settlement throughput to a
>>> reduced number of tx/s.
>>>
>>> Big-blockers proposed the removal of limits but this didn't come with
>>> undesirable effects that have been widely discussed and rejected.
>>>
>>> The main feature we wanted to preserve is 'small blocks', providing
>>> 'better network effects' I won't focus on them.
>>>
>>> The problem with small blocks is that, once a block is filled
>>> transactions, they are kept back in the mempool, waiting for their turn in
>>> future blocks.
>>>
>>> The following changes in the protocol aim to let all transactions go in
>>> the current block, while keeping the block size small. It requires changes
>>> in the PoW algorithm.
>>>
>>> Currently, the PoW algorithm consists on finding a valid hash for the
>>> block. Its validity is determined by comparing the numeric value of the
>>> block hash with a protocol-defined value difficulty.
>>>
>>> Once a miner finds a nonce for the block that satisfies the condition
>>> the new block becomes valid and can be propagated. All nodes would update
>>> their blockchains with it. (assuming no conflict resolution (orphan blocks,
>>> ...) for clarity).
>>>
>>> This process is meant to happen every 10 minutes in average.
>>>
>>> With this background information (we all already know) I go on to
>>> describe the idea:
>>>
>>> Let's allow a miner to include transactions until the block is filled,
>>> let's call this structure (coining a new term 'Brick'), B0. [brick=block
>>> that doesn't meet the difficulty rule and is filled of tx to its full
>>> capacity]
>>> Since PoW hashing is continuously active, Brick B0 would have a nonce
>>> corresponding to a minimum numeric value of its hash found until it got
>>> filled.
>>>
>>> Fully filled brick B0, with a hash that doesn't meet the difficulty
>>> rule, would be broadcasted and nodes would have it on in a separate fork as
>>> usual.
>>>
>>> At this point, instead of discarding transactions, our miner would start
>>> working on a new brick B1, linked with B0 as usual.
>>>
>>> Nodes would allow incoming regular blocks and bricks with hashes that
>>> don't satisfy the difficulty rule, provided the brick is fully filled of
>>> transactions. Bricks not fully filled would be rejected as invalid to
>>> prevent spam (except if constitutes the last brick of a brickchain,
>>> explained below).
>>>
>>> Let's assume that 10 minutes have elapsed and our miner is in a state
>>> where N bricks have been produced and the accumulated PoW calculated using
>>> mathematics (every brick contains a 'minimum hash found', when a series of
>>> 'minimum hashes' is computationally equivalent to the network difficulty is
>>> then the full 'brickchain' is valid as a Block.
>>>
>>> This calculus shall be better defined, but I hope that this idea can
>>> serve as a seed to a BIP, or otherwise deemed absurd, which might be
>>> possible and I'd be delighted to discover why a scheme like this wouldn't
>>> work.
>>>
>>> If it finally worked, it could completely flush mempools, keep
>>> transactions fees low and increase throughput without an increase in the
>>> block size that would raise other concerns related to propagation.
>>>
>>> Thank you.
>>> I look forward to your responses.
>>>
>>> --
>>> Marcos Mayorga
>>> https://twitter.com/KatlasC
>>>
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>
--000000000000d82a6b05ecf77bf7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style=3D"font-family:Arial;font-size:14px;color:rgb(0=
,0,0)">> I think it's pretty clear that the "competitive nature=
of PoW" is not referring to verification nodes<br></div><div style=3D=
"font-family:Arial;font-size:14px;color:rgb(0,0,0)"><br></div><div style=3D=
"font-family:Arial;font-size:14px;color:rgb(0,0,0)">cool, so we can agree t=
here is no accepted centralization pressure for validating nodes then</div>=
<span class=3D"gmail-im" style=3D"color:rgb(80,0,80)"><div style=3D"font-fa=
mily:Arial;font-size:14px;color:rgb(0,0,0)"><br></div><div style=3D"font-fa=
mily:Arial;font-size:14px;color:rgb(0,0,0)">> layers also add fees to us=
ers</div><div style=3D"font-family:Arial;font-size:14px;color:rgb(0,0,0)"><=
br></div><div style=3D"font-family:Arial;font-size:14px;color:rgb(0,0,0)">s=
ource?=C2=A0 i feel like it's obvious that the tree-like efficiencies s=
hould reduce fees, but i'd appreciate your research on that topic</div>=
<div style=3D"font-family:Arial;font-size:14px;color:rgb(0,0,0)"><br></div>=
</span></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail=
_attr">On Tue, Nov 8, 2022 at 9:25 AM mm-studios <<a href=3D"mailto:mm@m=
m-studios.com">mm@mm-studios.com</a>> wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><br><div>
------- Original Message -------<br>
On Tuesday, November 8th, 2022 at 2:16 PM, Erik Aronesty <<a hre=
f=3D"mailto:erik@q32.com" target=3D"_blank">erik@q32.com</a>> wrote:<br>=
<br>
<blockquote type=3D"cite">
<div dir=3D"ltr"><span style=3D"font-family:Arial;font-size:14p=
x">> A) to not increase the workload of full-nodes</span><div><span styl=
e=3D"font-family:Arial;font-size:14px"><br></span></div><div><span style=3D=
"font-family:Arial;font-size:14px">yes, this is critical</span></div><div><=
span style=3D"font-family:Arial;font-size:14px"><br></span></div><div><span=
style=3D"font-family:Arial;font-size:14px">> given the competitive nat=
ure of PoW itself<br><br></span></div><div><span style=3D"font-family:Arial=
;font-size:14px">validating nodes do not compete with PoW, i think maybe yo=
u are not sure of the difference between a miner and a node</span></div><di=
v><span style=3D"font-family:Arial;font-size:14px"><br></span></div><div><s=
pan style=3D"font-family:Arial;font-size:14px">nodes do validation of trans=
actions, they do this for free, and many of them provide essential services=
, like SPV validation for mobile</span></div></div></blockquote><div style=
=3D"font-family:Arial;font-size:14px;color:rgb(0,0,0)"><br></div><div style=
=3D"font-family:Arial;font-size:14px;color:rgb(0,0,0)"><br></div><div style=
=3D"font-family:Arial;font-size:14px;color:rgb(0,0,0)">I think it's pre=
tty clear that the "competitive nature of PoW" is not referring t=
o verification nodes (satoshi preferred this other word).<br></div><div sty=
le=3D"font-family:Arial;font-size:14px;color:rgb(0,0,0)"><br></div><blockqu=
ote type=3D"cite"><div dir=3D"ltr"><div><span style=3D"font-family:Arial;fo=
nt-size:14px"> </span></div><div><span style=3D"font-family:Arial;font-size=
:14px">B) to not undermine L2 systems like LN.</span><br style=3D"font-fami=
ly:Arial;font-size:14px"></div><div><span style=3D"font-family:Arial;font-s=
ize:14px"><br></span></div><div><span style=3D"font-family:Arial;font-size:=
14px">yes, as a general rule, layered financial systems are vastly superior=
. so that risks incurred by edge layers are not propagated fully to the in=
ner layers. For example L3 projects like TARO and RGB are building on ligh=
tning with less risk</span></div></div></blockquote><div style=3D"font-fami=
ly:Arial;font-size:14px;color:rgb(0,0,0)"><br></div><div style=3D"font-fami=
ly:Arial;font-size:14px;color:rgb(0,0,0)">layers also add fees to users<br>=
</div><div style=3D"font-family:Arial;font-size:14px;color:rgb(0,0,0)"><br>=
</div><div style=3D"font-family:Arial;font-size:14px;color:rgb(0,0,0)"><br>=
</div><blockquote type=3D"cite"><div class=3D"gmail_quote"><div class=3D"gm=
ail_attr" dir=3D"ltr">On Wed, Oct 19, 2022 at 12:04 PM mm-studios <<a hr=
ef=3D"mailto:mm@mm-studios.com" rel=3D"noreferrer nofollow noopener" target=
=3D"_blank">mm@mm-studios.com</a>> wrote:<br></div><blockquote style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex" class=3D"gmail_quote"><div style=3D"font-family:Arial;font-size:14px=
">Thanks all for your responses.<br>so is it a no-go is because "r<spa=
n>educed settlement speed is a desirable feature</span>"?<br><br>I don=
';t know what weights more in this consideration:<br>A) to not increase=
the workload of full-nodes, being "less difficult to operate" an=
d hence reduce the chance of some of them giving up which would lead to a n=
egative centralization effect. (a bit cumbersome reasoning in my opinion, g=
iven the competitive nature of PoW itself, which introduce an accepted cent=
ralization, forcing some miners to give up). In this case the fact is accep=
ted because is decentralized enough.<br>B) to not undermine L2 systems like=
LN.<br><br>in any case it is a major no-go reason, if there is not intenti=
on to speed up L1.</div><div style=3D"font-family:Arial;font-size:14px">Tha=
nks<br>M<br></div><div style=3D"font-family:Arial;font-size:14px">
<div>
</div>
<div>
</div>
</div>
<div>
------- Original Message -------<br>
On Wednesday, October 19th, 2022 at 3:24 PM, Erik Aronesty <<a h=
ref=3D"mailto:erik@q32.com" rel=3D"noreferrer nofollow noopener" target=3D"=
_blank">erik@q32.com</a>> wrote:<br><br>
<blockquote type=3D"cite">
<div dir=3D"ltr"><span style=3D"font-family:Arial;font-size:14p=
x">> currently, a miner produce blocks with a limited capacity of transa=
ctions that ultimately limits the global settlement throughput to a reduced=
number of tx/s.</span><br style=3D"font-family:Arial;font-size:14px"><div>=
<span style=3D"font-family:Arial;font-size:14px"><br></span></div><div><spa=
n style=3D"font-family:Arial;font-size:14px">reduced settlement speed is a =
desirable feature and isn't something we need to fix</span></div><div><=
span style=3D"font-family:Arial;font-size:14px"><br></span></div><div><span=
style=3D"font-family:Arial;font-size:14px">the focus should be on layer 2 =
protocols that allow the ability to hold & transfer, uncommitted transa=
ctions as pools / joins, so that layer 1's decentralization and incenti=
ves can remain undisturbed</span></div><div><span style=3D"font-family:Aria=
l;font-size:14px"><br></span></div><div><span style=3D"font-family:Arial;fo=
nt-size:14px">protocols like mweb, for example</span></div><div><span style=
=3D"font-family:Arial;font-size:14px"><br></span></div><div><span style=3D"=
font-family:Arial;font-size:14px"><br></span></div><div><span style=3D"font=
-family:Arial;font-size:14px"><br></span></div></div><br><div class=3D"gmai=
l_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 19, 2022 at 7:34=
AM mm-studios via bitcoin-dev <<a rel=3D"noreferrer nofollow noopener" =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bit=
coin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex"><div style=3D"font-family:Arial;font-size=
:14px"><span>Hi Bitcoin devs,</span><div>I'd like to share an idea of a=
method to increase throughput in the bitcoin network.</div><div><br></div>=
<div>Currently,
a miner produce blocks with a limited capacity of transactions that
ultimately limits the global settlement throughput to a reduced number
of tx/s.<br><br>Big-blockers proposed the removal of limits but this
didn't come with undesirable effects that have been widely discussed an=
d
rejected.<br><br>The main feature we wanted to preserve is 'small bloc=
ks', providing 'better network effects' I won't focus on th=
em.</div><div><br></div><div>The
problem with small blocks is that, once a block is filled transactions, th=
ey
are kept back in the mempool, waiting for their turn in future blocks.<br><=
br>The
following changes in the protocol aim to let all transactions go in the
current block, while keeping the block size small. It requires changes
in the PoW algorithm.</div><div><br></div><div>Currently,
the PoW algorithm consists on finding a valid hash for the block. Its
validity is determined by comparing the numeric value of the block hash
with a protocol-defined value difficulty.<br></div><div><br>Once
a miner finds a nonce for the block that satisfies the condition the new
block becomes valid and can be propagated. All nodes would update
their blockchains with it. (assuming no conflict resolution (orphan
blocks, ...) for clarity).<br><br>This process is meant to happen every 10 =
minutes in average.<br><br>With this background information (we all already=
know) I go on to describe the idea:<br><br>Let's allow a miner to incl=
ude transactions until the block is filled, let's call this structure (=
coining a new term 'Brick'), B0. [brick=3Dblock that doesn't me=
et the difficulty rule and is filled of tx to its full capacity]<br>Since P=
oW hashing is continuously active, Brick B0 would have a nonce correspondin=
g to a minimum numeric value of its hash found until it got filled.<br><br>=
Fully
filled brick B0, with a hash that doesn't meet the difficulty rule,
would be broadcasted and nodes would have it on in a separate fork as
usual.<br><br> At this point, instead of discarding transactions, our miner=
would start working on a new brick B1, linked with B0 as usual.<br><br>Nod=
es
would allow incoming regular blocks and bricks with hashes that don't
satisfy the difficulty rule, provided the brick is fully filled of
transactions. Bricks not fully filled would be rejected as invalid to
prevent spam (except if constitutes the last brick of a brickchain, explain=
ed below).<br><br>Let's assume that 10 minutes have elapsed and our
miner is in a state where N bricks have been produced and the
accumulated PoW calculated using mathematics (every brick contains a
'minimum hash found', when a series of 'minimum hashes' is
computationally equivalent to the network difficulty is then the full
'brickchain' is valid as a Block.<br><br>This calculus shall be bet=
ter
defined, but I hope that this idea can serve as a seed to a BIP, or
otherwise deemed absurd, which might be possible and I'd be delighted t=
o
discover why a scheme like this wouldn't work.<br><br>If it finally
worked, it could completely flush mempools, keep transactions fees low
and increase throughput without an increase in the block size that would
raise other concerns related to propagation.<br><br>Thank you.<br>I look f=
orward to your responses.<br><br>--<br>Marcos Mayorga<br></div><span><a rel=
=3D"noreferrer nofollow noopener" href=3D"https://twitter.com/KatlasC" targ=
et=3D"_blank">https://twitter.com/KatlasC</a></span><br><br></div>
<div style=3D"font-family:Arial;font-size:14px">
<div>
</div>
<div>
</div>
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a rel=3D"noreferrer nofollow noopener" href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<=
/a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer nofollow noopener" target=3D"_blank">https://lists.linuxf=
oundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote><br>
</div></blockquote></div>
</blockquote><br>
</div></blockquote></div>
--000000000000d82a6b05ecf77bf7--
|