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
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 1AC77C0012
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Dec 2021 11:56:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id E3CCD40646
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Dec 2021 11:56:32 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.854
X-Spam-Level:
X-Spam-Status: No, score=-0.854 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_MSPIKE_H3=0.001,
RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (1024-bit key) header.d=gazeta.pl
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 DQhsoztfKxCt
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Dec 2021 11:56:29 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from smtpo76.poczta.onet.pl (smtpo76.poczta.onet.pl [141.105.16.26])
by smtp2.osuosl.org (Postfix) with ESMTPS id 2099340103
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Dec 2021 11:56:28 +0000 (UTC)
Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4JKTDh3jKyz1pKN;
Thu, 23 Dec 2021 12:56:20 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1640260580; bh=Hih79KUvz1cpl0B8cT10eYl0cy6aAeA6dnSl3MTQRho=;
h=From:Cc:To:In-Reply-To:Date:Subject:From;
b=bW/N9ZFEPchd/8Tydz15FuuXyllpESEJKXv9vKKMGjYy6QtJxdP80/Fw/2718/YLf
3R3WkCpij7jZvmWH24iIu7EnoOIm5KrwujUj7I5eo3EhAkyPQsNqqk+fVOhyiCI3q8
qlK2yEKfVgVMEzOez64uGnnpNcFHheeth1wGfCPc=
Content-Type: multipart/alternative;
boundary="===============0028088375559804441=="
MIME-Version: 1.0
Received: from [31.61.160.121] by pmq3v.m5r2.onet via HTTP id ;
Thu, 23 Dec 2021 12:56:20 +0100
From: vjudeu@gazeta.pl
X-Priority: 3
To: Billy Tetrud <billy.tetrud@gmail.com>
In-Reply-To: <CAGpPWDbGTET27Hq8kKrQQoOavtOUEGzYkohVurSqZJ5r+o4gpQ@mail.gmail.com>
Date: Thu, 23 Dec 2021 12:56:18 +0100
Message-Id: <151161119-8858833d76ec6beed19cf87cc542dc62@pmq3v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;31.61.160.121;PL;3
X-Mailman-Approved-At: Thu, 23 Dec 2021 17:38:21 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin Advent Calendar] Decentralized
Coordination Free Mining Pools
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: Thu, 23 Dec 2021 11:56:33 -0000
This is a multi-part message in MIME format.
--===============0028088375559804441==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
> Associating signing with proof of stake and thereby concluding that signi=
ng is something to avoid sounds like superstitious thinking.
If you introduce signing into mining, then you will have cases, where someo=
ne is powerful enough to produce blocks, but cannot, because signing is nee=
ded. Then, your consensus is no longer "the heaviest chain", but "the heavi=
est signed chain". That means, your computing power is no longer enough by =
itself (as today), because to make a block, you also need some kind of "per=
mission to mine", because first you sign things (like in signet) and then y=
ou mine them. That kind of being "reliably unreliable" may be ok for testin=
g, but not for the main network.
> A signing scheme with proof of work would clearly not be proof of stake.
It is not that far from Proof of Stake as you may think. In Proof of Stake,=
you sign your whale balance with thousands of BTC, and then you can mine a=
new block, just by putting your coins at stake. In Proof of Work with sign=
ing, you also make a signature, and even if there is no amount in satoshis =
for your signing key, it is still somehow checked, who can sign a block and=
how many signatures are needed. So, is your private key that allows you to=
extend the chain is really worth zero satoshis, because there is no balanc=
e connected with your address/public key? Not really, it is worth a lot of =
coins, because it can be used to control the chain.
> The benefit of that over merge mining would be no extra on chain foot pri=
nt.
Your signatures would be that "extra on chain foot print". In signet, by de=
fault you have 1-of-2 multisig, so you have one signature for every block. =
In the main chain, there is no need for any foot print, because you can rev=
eal taproot public key and hide other things in tapscript, so your foot pri=
nt is present only when people will not cooperate.
On 2021-12-20 18:18:58 user Billy Tetrud <billy.tetrud@gmail.com> wrote:
> you can assign some minimal difficulty,
=C2=A0
I was assuming that would be part of the plan.
=C2=A0
>=C2=A0Signing sounds more like Proof of Stake
=C2=A0
Associating signing with proof of stake and thereby concluding that signing=
is something to avoid sounds like superstitious thinking. A signing scheme=
with proof of work would clearly not be proof of stake. I would suggest no=
t dismissing a design out of hand like that. The benefit of that over merge=
mining would be no extra on chain foot print. What do you think the downsi=
des might be?
=C2=A0
> if you use just hashes, then they could be random.
=C2=A0
You're right. Nodes would of course need to validate the Bitcoin block head=
ers being included, so i concede hashing them doesn't gain you anything.
On Thu, Dec 16, 2021, 22:37 <vjudeu@gazeta.pl> wrote:
> I was thinking that this would be a separate blockchain with separate hea=
ders that progress linearly like a normal blockchain.
Exactly, that's what I called "superblocks", where you have a separate chai=
n, just to keep block headers instead of transactions.
> A block creator would collect together as many blocks that haven't been c=
ollected yet into the next superblock (and maybe receive a reward proportio=
nal to how many / how much weight they include).
You cannot "catch them all". If you do, you can end up with a lot of block =
headers, where each of them has difficulty equal to one. You need some limi=
t, you can limit amount of blocks, you can assign some minimal difficulty, =
it does not matter that much, but some limit is needed, also because mining=
on top of the latest superblock should be more profitable than replacing s=
omeone else's reward in the previous superblock by your own reward and gett=
ing a bigger share in the previous superblock.
> This could be done using merge mining, or it could be done using a signin=
g scheme (eg where the block creator signs to say "I created this superbloc=
k" and have mechanisms to punish those who sign multiple superblocks at the=
same height.
I would pick merge mining, because it is more compatible with existing mini=
ng scheme. Signing sounds more like Proof of Stake and I am trying to avoid=
that solution. Also, there is no need to sign anything, because you are so=
lo mining where you have your own coinbase transaction or you are mining in=
a pool, where you have some shared address, and then you cannot produce an=
y incompatible superblock, because the protocol can tell you, which address=
you should use (and if it is N-of-N taproot multisig and you have some clo=
sing transaction, then you can safely mine it).
> Really, you could even just use hashes of the block headers.
Replacing transactions with block headers will do the same trick. Each tran=
saction is first hashed with double SHA-256, in exactly the same way as blo=
ck headers are. If you replace transactions with block headers, you would g=
et a superblock header, then varint saying how many block headers are there=
, and then you can place all block headers. During superblock merkle tree c=
onstruction, you will hash all block headers (so you will get block hashes =
as leaves), and then you will combine block hashes in the same way as trans=
action hashes are combined.
From the Script point of view, you can always use "OP_SIZE 80 OP_EQUALVERIF=
Y OP_HASH256 <hash> OP_EQUAL". Then, you can just change the size, just to =
show which object is hashed. Value 80 will work for block headers, small va=
lues below 520 will work for small transactions, value 64 will work for any=
merkle tree proof, no matter if it is for superblock or normal block. Also=
, by using block headers instead of hashes, you can prove that at least a p=
roper amount of work was done to produce it, because if you use just hashes=
, then they could be random.
On 2021-12-16 17:57:23 user Billy Tetrud <billy.tetrud@gmail.com> wrote:
@Jeremy
>=C2=A0 =C2=A0for top-level pool participants there is never any central cu=
stody.
=C2=A0
I definitely see that. That was actually what I meant when I said the goals=
aren't the same as benefits. While your idea definitely satisfies all your=
goals in a modular way, the fact that it relies on pools means that unless=
the pools can also satisfy the goals, the total system also doesn't satisf=
y the goals (even tho the piece of that system you designed does).=C2=A0
=C2=A0
>=C2=A0Thus it doesn't "hurt" anyone except for the miners who are taking t=
he not fully locked in funds risk
=C2=A0
True, it only potentially hurts whoever the channel partner is accepting th=
e unspendable coins. And no one can really stop anyone from taking that ris=
k if they really want to. But in that case, its not exactly a fully functio=
nal channel, since recourse mechanisms couldn't be performed. Wouldn't that=
open such a channel up to a pretty bad theft possibility?
=C2=A0
@Bob
>=C2=A0Increased payout regularity does not lower the viable size of mining=
pools, because smaller mining pools using this mechanism still have higher=
variance.
=C2=A0
Yes, smaller mining pools will always have higher variance. However, lower =
variance has diminishing benefits. Below a certain amount of variance, less=
variance isn't very valuable. So increased payout regularity does indeed l=
ower the viable size of mining pools because a given low-enough level of va=
riance can be achieved with less pool hashpower.
=C2=A0
> The on-chain footprint is *higher* due to the increased payout regularity.
=C2=A0
That's a reasonable point. However, I think there is a difference here betw=
een the regularity of rewards vs payouts. Rewards for each miner can be mor=
e regular without necessarily increasing the number of on-chain payouts. In=
fact, theoretically, an individual miner could let their rewards accumulat=
e in a pool over many rewards and only redeem when they need the coins for =
something. The incentive is there for each miner to be judicious on how muc=
h onchain space they take up.
=C2=A0
@vjudeu
=C2=A0
> how many block headers should be stored per one "superblock"?
=C2=A0
I was thinking that this would be a separate blockchain with separate heade=
rs that progress linearly like a normal blockchain. A block creator would c=
ollect together as many blocks that haven't been collected yet into the nex=
t superblock (and maybe receive a reward proportional to how many / how muc=
h weight they include). This could be done using merge mining, or it could =
be done using a signing scheme (eg where the block creator signs to say "I =
created this superblock" and have mechanisms to punish those who sign multi=
ple superblocks at the same height. For merge mining, I could even imagine =
the data necessary to validate that it has been merge mined could be put in=
to a taproot script branch (creating an invalid script, but a valid hash of=
the superblock).=C2=A0
=C2=A0
> we can collect all headers with the same previous block hash, and distrib=
ute block reward between all coinbase transactions in those headers
=C2=A0
Exactly.
=C2=A0
> we would just have block headers instead of transactions
=C2=A0
Yeah, I think that would be the way to go. Really, you could even just use =
hashes of the block headers. But the size doesn't matter much because it wo=
uld be both a small blockchain and an ephemeral one (which can be fully dis=
carded after all parties have been paid out, or at least their payout has b=
een committed to on the bitcoin blockchain).=C2=A0
On Thu, Dec 16, 2021 at 1:35 AM <vjudeu@gazeta.pl> wrote:
> The missing piece here would be an ordering of weak blocks to make the wi=
ndow possible. Or at least a way to determine what blocks should definitely=
be part of a particular block's pay out. I could see this being done by a =
separate ephemeral blockchain (which starts fresh after each Bitcoin block)=
that keeps track of which weak blocks have been submitted, potentially usi=
ng the pow already in each block to secure it. Granted that piece is a bit =
half baked, but it seems quite solvable. Wdyt?
=C2=A0
I thought about something like that, but there is one problem: how many blo=
ck headers should be stored per one "superblock"? Currently, we have single=
block header, where the whole coinbase transaction is taken by some mining=
pool or solo miner. But instead, each miner could submit its own block hea=
der. Then, we can collect all headers with the same previous block hash, an=
d distribute block reward between all coinbase transactions in those header=
s. One "superblock" then would be created in a similar way as existing bloc=
ks, we would just have block headers instead of transactions. If most trans=
actions inside those blocks will be the same, then each block could be expr=
essed just as a set of transaction hashes, only coinbase transactions or cu=
stom, non-broadcasted transactions included by miners will be revealed, eve=
rything else will be known.
> One thing that jumped out at me as not safe is throwing block rewards int=
o a channel and being able to spend them immediately. There's a reason bloc=
k rewards aren't spendable for a while, and channels don't solve that probl=
em, do they? Why not simply reduce the on chain wait time for spending bloc=
k rewards at that point? Seems like the consequences would be the same.
All coinbase rewards are unspendable for 100 blocks, it is enforced by cons=
ensus. It does not matter if there are outputs owned directly by miners, or=
if there is one huge N-of-N taproot multisig for the whole pool, where eve=
ry miner signed the closing transaction. The only option to take coins fast=
er I can see is swapping the coins by some LN transaction. But then, the ot=
her party can check if some deposit to the LN channel is a part of the coin=
base transaction or not, and then decide if it is acceptable to do the swap.
On 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
Looks like an interesting proposal, but it doesn't seem to quite match the =
goals you mentioned. As you do mention, this mining pool coordination doesn=
't get rid of the need for mining pools in the first place. So it doesn't s=
atisfy item 1 on your goal list afaict.=C2=A0 =C2=A0
The primary benefits over what we have today that I can see are:
1. increased payout regularity, which lowers the viable size of mining pool=
s, and
2. Lower on chain footprint through combining pay outs from multiple pools.
=C2=A0
Am I missing some?
=C2=A0
These are interesting benefits, but it would be nice if your post was clear=
er on that, since the goals list is not the same as the list of potential b=
enefits of this kind of design.
=C2=A0
As far as enabling solo mining, what if this concept were used off chain? H=
ave a public network of solo miners who publish "weak blocks" to that netwo=
rk, and the next 100 (or 1000 etc) nice miners pay you out as long as you'r=
e also being nice by following the protocol? All the nice optimizations you=
mentioned about eg combined taproot payouts would apply i think. The only =
goals this wouldn't satisfy are 3 and 5 since an extra network is needed, b=
ut to be fair, your proposal requires pools which all need their own extra =
network anyways.=C2=A0
=C2=A0
The missing piece here would be an ordering of weak blocks to make the wind=
ow possible. Or at least a way to determine what blocks should definitely b=
e part of a particular block's pay out. I could see this being done by a se=
parate ephemeral blockchain (which starts fresh after each Bitcoin block) t=
hat keeps track of which weak blocks have been submitted, potentially using=
the pow already in each block to secure it. Granted that piece is a bit ha=
lf baked, but it seems quite solvable. Wdyt?
=C2=A0
One thing that jumped out at me as not safe is throwing block rewards into =
a channel and being able to spend them immediately. There's a reason block =
rewards aren't spendable for a while, and channels don't solve that problem=
, do they? Why not simply reduce the on chain wait time for spending block =
rewards at that point? Seems like the consequences would be the same.
On Tue, Dec 14, 2021, 16:12 Bob McElrath via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
You are hand waving. Attempting to redefine terms to justify your argument =
is
intellectually dishonest. Bitcoin pools have *always* been about variance
reduction. Your window function fundamentally CANNOT be used to hedge hashr=
ate.
Various suggestions below introduce dangerous new games that might be playe=
d by
miners.
The fact is that the half-baked design you posted is less than useless, and
doesn't do anything that anyone wants.
You are trying to justify CTV by making it be all things to all people. "Wh=
en
all you have is a hammer, every problem looks like a nail".=C2=A0 Instead I=
humbly
suggest that you pick ONE problem for which CTV is demonstrably the right a=
nd
best solution, instead of snowing us with a ton of half-baked things that
*could* be done, and often don't even require CTV, and some (like this one)
fundamentally don't work. I do like some of your ideas, but if you had to p=
ick
just one "use case", which would it be?
Jeremy [jlrubin@mit.edu] wrote:
> Bitcoin didn't invent the concept of pooling: https://en.wikipedia.org/wi=
ki/
> Pooling_(resource_management). This is a Bitcoin Mining Pool, although it=
may
> not be your favorite kind, which is fixated on specific properties of com=
puting
> contributions before finding a block. Pooling is just a general technique=
for
> aggregating resources to accomplish something. If you have another name l=
ike
> pooling that is in common use for this type of activity I would be more t=
han
> happy to adopt it.
>
> This sort of pool can hedge not only against fee rates but also against
> increases in hashrate since your historical rate 'carries' into the futur=
e as a
> function of the window. Further, windows and reward functions can be defi=
ned in
> a myriad of ways that could, e.g., pay less to blocks found in more rapid
> succession, contributing to the smoothing functionality.
>
> With respect to sub-block pooling, as described in the article, this sort=
of
> design also helps with micro-pools being able to split resources
> non-custodially in every block as a part of the higher order DCFMP. The p=
oint
> is not, as noted, to enable solo mining an S9, but to decrease the size o=
f the
> minimum viable pool. It's also possible to add, without much validation or
> data, some 'uncle block' type mechanism in an incentive compatible way (e=
.g.,
> add 10 pow-heavy headers on the last block for cost 48 bytes header + 32 =
bytes
> payout key) such that there's an incentive to include the heaviest ones y=
ou've
> seen, not just your own, that are worth further study and consideration
> (particularly because it's non-consensus, only for opt-in participation i=
n the
> pool).
>
> With respect to space usage, it seems you wholly reject the viability of a
> payment pool mechanism to cut-through chain space. Is this a critique that
> holds for all Payment Pools, or just in the context of mining? Is there a
> particular reason why you think it infeasible that "strongly online"
> counterparties would be able to coordinate more efficiently? Is it prefer=
able
> for miners, the nexus of decentralization for Bitcoin, to prefer to use
> custodial services for pooling (which may require KYC/AM) over bearing a =
cost
> of some extra potential chainload?
>
> Lastly, with respect to complexity, the proposal is actually incredibly s=
imple
> when you take it in a broader context. Non Interactive Channels and Payme=
nt
> Pools are useful=C2=A0by themselves, so are the operations to merge them =
and swap
> balance across them. Therefore most of the complexity in this proposal is
> relying on tools we'll likely see in everyday use in any case, DCFMP or n=
o.
>
> Jeremy
> !DSPAM:61b8f2f5321461582627336!
--
Cheers, Bob McElrath
"For every complex problem, there is a solution that is simple, neat, and w=
rong."
=C2=A0 =C2=A0 -- H. L. Mencken
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--===============0028088375559804441==
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
<div>> Associating signing with proof of stake and thereby concluding th=
at signing is something to avoid sounds like superstitious thinking.<br /><=
br />If you introduce signing into mining, then you will have cases, where =
someone is powerful enough to produce blocks, but cannot, because signing i=
s needed. Then, your consensus is no longer "the heaviest chain", but "the =
heaviest signed chain". That means, your computing power is no longer enoug=
h by itself (as today), because to make a block, you also need some kind of=
"permission to mine", because first you sign things (like in signet) and t=
hen you mine them. That kind of being "reliably unreliable" may be ok for t=
esting, but not for the main network.<br /><br />> A signing scheme with=
proof of work would clearly not be proof of stake.<br /><br />It is not th=
at far from Proof of Stake as you may think. In Proof of Stake, you sign yo=
ur whale balance with thousands of BTC, and then you can mine a new block, =
just by putting your coins at stake. In Proof of Work with signing, you als=
o make a signature, and even if there is no amount in satoshis for your sig=
ning key, it is still somehow checked, who can sign a block and how many si=
gnatures are needed. So, is your private key that allows you to extend the =
chain is really worth zero satoshis, because there is no balance connected =
with your address/public key? Not really, it is worth a lot of coins, becau=
se it can be used to control the chain.<br /><br />> The benefit of that=
over merge mining would be no extra on chain foot print.<br /><br />Your s=
ignatures would be that "extra on chain foot print". In signet, by default =
you have 1-of-2 multisig, so you have one signature for every block. In the=
main chain, there is no need for any foot print, because you can reveal ta=
proot public key and hide other things in tapscript, so your foot print is =
present only when people will not cooperate.<br /><br /></div>
<div>On 2021-12-20 18:18:58 user Billy Tetrud <billy.tetrud@gmail.com>=
; wrote:</div>
<blockquote style=3D"margin-left: 7px; border-left: 2px solid orange; paddi=
ng-left: 8px;">
<div dir=3D"auto">
<div dir=3D"auto">> you can assign some minimal difficulty,</div>
<div dir=3D"auto"> </div>
<div dir=3D"auto">I was assuming that would be part of the plan.</div>
<div dir=3D"auto"> </div>
<div>> Signing sounds more like Proof of Stake</div>
<div dir=3D"auto"> </div>
<div dir=3D"auto">Associating signing with proof of stake and thereby concl=
uding that signing is something to avoid sounds like superstitious thinking=
. A signing scheme with proof of work would clearly not be proof of stake. =
I would suggest not dismissing a design out of hand like that. The benefit =
of that over merge mining would be no extra on chain foot print. What do yo=
u think the downsides might be?</div>
<div dir=3D"auto"> </div>
<div dir=3D"auto">> if you use just hashes, then they could be random.</=
div>
<div dir=3D"auto"> </div>
<div dir=3D"auto">You're right. Nodes would of course need to validate the =
Bitcoin block headers being included, so i concede hashing them doesn't gai=
n you anything.</div>
<div dir=3D"auto"><span style=3D"font-size: 12.8px;"><br /></span><br />
<div class=3D"gmail_quote" dir=3D"auto">
<div class=3D"gmail_attr" dir=3D"ltr">On Thu, Dec 16, 2021, 22:37 <<a hr=
ef=3D"../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchEuGRE%2BJkYAEBM5Bgk=
BElIaQgpBQUFBVCVGX18dBRtTEQcBF1UyQUoDEQ0TRQYNQUdjI1hCU0cyajZIblhVZRQcVlEe" =
target=3D"_parent">vjudeu@gazeta.pl</a>> wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 .8ex; border-left:=
1px #ccc solid; padding-left: 1ex;">
<div>> I was thinking that this would be a separate blockchain with sepa=
rate headers that progress linearly like a normal blockchain.<br /><br />Ex=
actly, that's what I called "superblocks", where you have a separate chain,=
just to keep block headers instead of transactions.<br /><br />> A bloc=
k creator would collect together as many blocks that haven't been collected=
yet into the next superblock (and maybe receive a reward proportional to h=
ow many / how much weight they include).<br /><br />You cannot "catch them =
all". If you do, you can end up with a lot of block headers, where each of =
them has difficulty equal to one. You need some limit, you can limit amount=
of blocks, you can assign some minimal difficulty, it does not matter that=
much, but some limit is needed, also because mining on top of the latest s=
uperblock should be more profitable than replacing someone else's reward in=
the previous superblock by your own reward and getting a bigger share in t=
he previous superblock.<br /><br />> This could be done using merge mini=
ng, or it could be done using a signing scheme (eg where the block creator =
signs to say "I created this superblock" and have mechanisms to punish thos=
e who sign multiple superblocks at the same height.<br /><br />I would pick=
merge mining, because it is more compatible with existing mining scheme. S=
igning sounds more like Proof of Stake and I am trying to avoid that soluti=
on. Also, there is no need to sign anything, because you are solo mining wh=
ere you have your own coinbase transaction or you are mining in a pool, whe=
re you have some shared address, and then you cannot produce any incompatib=
le superblock, because the protocol can tell you, which address you should =
use (and if it is N-of-N taproot multisig and you have some closing transac=
tion, then you can safely mine it).<br /><br />> Really, you could even =
just use hashes of the block headers.<br /><br />Replacing transactions wit=
h block headers will do the same trick. Each transaction is first hashed wi=
th double SHA-256, in exactly the same way as block headers are. If you rep=
lace transactions with block headers, you would get a superblock header, th=
en varint saying how many block headers are there, and then you can place a=
ll block headers. During superblock merkle tree construction, you will hash=
all block headers (so you will get block hashes as leaves), and then you w=
ill combine block hashes in the same way as transaction hashes are combined=
.<br /><br />From the Script point of view, you can always use "OP_SIZE 80 =
OP_EQUALVERIFY OP_HASH256 <hash> OP_EQUAL". Then, you can just change=
the size, just to show which object is hashed. Value 80 will work for bloc=
k headers, small values below 520 will work for small transactions, value 6=
4 will work for any merkle tree proof, no matter if it is for superblock or=
normal block. Also, by using block headers instead of hashes, you can prov=
e that at least a proper amount of work was done to produce it, because if =
you use just hashes, then they could be random.<br /><br /></div>
<div>On 2021-12-16 17:57:23 user Billy Tetrud <<a href=3D"../NowaWiadomo=
sc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6Ggg2Oh1RQVcsEhdBUgNTXwcNH10HCQtGX19WV=
jUTBgddUwsWQUoDQlQnBFFKBho%2FKEAWQlYnNjNAbl5XJ045Ggh0IFxIARFsQkQgQwZw" targ=
et=3D"_parent" rel=3D"noreferrer">billy.tetrud@gmail.com</a>> wrote:</di=
v>
<blockquote style=3D"margin-left: 7px; border-left: 2px solid orange; paddi=
ng-left: 8px;">
<div dir=3D"ltr">
<div id=3D"m_7099304871181977130gmail-:1tx" style=3D"direction: ltr; min-he=
ight: 85px;">
<div>@Jeremy</div>
> <span style=3D"color: #000000; font-family: arial,helvetica,sans=
-serif;"> for top-level pool participants there is never any central c=
ustody.</span>
<div> </div>
<div>I definitely see that. That was actually what I meant when I said the =
goals aren't the same as benefits. While your idea definitely satisfies all=
your goals in a modular way, the fact that it relies on pools means that u=
nless the pools can also satisfy the goals, the total system also doesn't s=
atisfy the goals (even tho the piece of that system you designed does).&nbs=
p;</div>
<div> </div>
<div>> <span style=3D"color: #000000; font-family: arial,helvetica,=
sans-serif;">Thus it doesn't "hurt" anyone except for the miners who are ta=
king the not fully locked in funds risk</span></div>
<div><span style=3D"color: #000000; font-family: arial,helvetica,sans-serif=
;"> </span></div>
<div><span style=3D"color: #000000;">True, it only potentially hurts whoeve=
r the channel partner is accepting the unspendable coins. And no one can re=
ally stop anyone from taking that risk if they really want to. But in that =
case, its not exactly a fully functional channel, since recourse mechanisms=
couldn't be performed. Wouldn't that open such a channel up to a pretty ba=
d theft possibility?</span></div>
<div><span style=3D"color: #000000;"> </span></div>
<div><span style=3D"color: #000000;">@Bob<br /></span></div>
<div><span style=3D"color: #000000;">> </span>Increased payout regu=
larity does not lower the viable size of mining pools, because smaller mini=
ng pools using this mechanism still have higher variance.</div>
<div> </div>
<div>Yes, smaller mining pools will always have higher variance. However, l=
ower variance has diminishing benefits. Below a certain amount of variance,=
less variance isn't very valuable. So increased payout regularity does ind=
eed lower the viable size of mining pools because a given low-enough level =
of variance can be achieved with less pool hashpower.</div>
<div> </div>
<div>> The on-chain footprint is *higher* due to the increased payout re=
gularity.</div>
<div> </div>
<div>That's a reasonable point. However, I think there is a difference here=
between the regularity of rewards vs payouts. Rewards for each miner can b=
e more regular without necessarily increasing the number of on-chain payout=
s. In fact, theoretically, an individual miner could let their rewards accu=
mulate in a pool over many rewards and only redeem when they need the coins=
for something. The incentive is there for each miner to be judicious on ho=
w much onchain space they take up.</div>
<div> </div>
<div>@vjudeu</div>
<div> </div>
<div>> how many block headers should be stored per one "superblock"?</di=
v>
<div> </div>
<div>I was thinking that this would be a separate blockchain with separate =
headers that progress linearly like a normal blockchain. A block creator wo=
uld collect together as many blocks that haven't been collected yet into th=
e next superblock (and maybe receive a reward proportional to how many / ho=
w much weight they include). This could be done using merge mining, or it c=
ould be done using a signing scheme (eg where the block creator signs to sa=
y "I created this superblock" and have mechanisms to punish those who sign =
multiple superblocks at the same height. For merge mining, I could even ima=
gine the data necessary to validate that it has been merge mined could be p=
ut into a taproot script branch (creating an invalid script, but a valid ha=
sh of the superblock). </div>
<div> </div>
<div>> we can collect all headers with the same previous block hash, and=
distribute block reward between all coinbase transactions in those headers=
</div>
<div> </div>
<div>Exactly.</div>
<div> </div>
<div>> we would just have block headers instead of transactions</div>
<div> </div>
<div>Yeah, I think that would be the way to go. Really, you could even just=
use hashes of the block headers. But the size doesn't matter much because =
it would be both a small blockchain and an ephemeral one (which can be full=
y discarded after all parties have been paid out, or at least their payout =
has been committed to on the bitcoin blockchain). </div>
</div>
</div>
<br />
<div class=3D"gmail_quote">
<div class=3D"gmail_attr" dir=3D"ltr">On Thu, Dec 16, 2021 at 1:35 AM <<=
a href=3D"http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchEuGRE%2B=
JkYAEBM5BgkBElIaQgpBQUFBVCVGX18dBRtTEQcBF1UyQUoDEQ0TRQYNQUdjI1hCU0cyajZIblh=
VZRQcVlEe" target=3D"_blank" rel=3D"noopener noreferrer">vjudeu@gazeta.pl</=
a>> wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left: 1px solid #cccccc; padding-left: 1ex;">
<div>> The missing piece here would be an ordering of weak blocks to mak=
e the window possible. Or at least a way to determine what blocks should de=
finitely be part of a particular block's pay out. I could see this being do=
ne by a separate ephemeral blockchain (which starts fresh after each Bitcoi=
n block) that keeps track of which weak blocks have been submitted, potenti=
ally using the pow already in each block to secure it. Granted that piece i=
s a bit half baked, but it seems quite solvable. Wdyt?<br /> <br />I t=
hought about something like that, but there is one problem: how many block =
headers should be stored per one "superblock"? Currently, we have single bl=
ock header, where the whole coinbase transaction is taken by some mining po=
ol or solo miner. But instead, each miner could submit its own block header=
. Then, we can collect all headers with the same previous block hash, and d=
istribute block reward between all coinbase transactions in those headers. =
One "superblock" then would be created in a similar way as existing blocks,=
we would just have block headers instead of transactions. If most transact=
ions inside those blocks will be the same, then each block could be express=
ed just as a set of transaction hashes, only coinbase transactions or custo=
m, non-broadcasted transactions included by miners will be revealed, everyt=
hing else will be known.<br /><br />> One thing that jumped out at me as=
not safe is throwing block rewards into a channel and being able to spend =
them immediately. There's a reason block rewards aren't spendable for a whi=
le, and channels don't solve that problem, do they? Why not simply reduce t=
he on chain wait time for spending block rewards at that point? Seems like =
the consequences would be the same.<br /><br />All coinbase rewards are uns=
pendable for 100 blocks, it is enforced by consensus. It does not matter if=
there are outputs owned directly by miners, or if there is one huge N-of-N=
taproot multisig for the whole pool, where every miner signed the closing =
transaction. The only option to take coins faster I can see is swapping the=
coins by some LN transaction. But then, the other party can check if some =
deposit to the LN channel is a part of the coinbase transaction or not, and=
then decide if it is acceptable to do the swap.<br /><br /></div>
<div>On 2021-12-15 19:00:44 user Billy Tetrud via bitcoin-dev <<a href=
=3D"http://../NowaWiadomosc/Do/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7=
EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAs=
zLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQUQUoDQlAiBFY8" target=3D"_blank=
" rel=3D"noopener noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>>=
wrote:</div>
<blockquote style=3D"margin-left: 7px; border-left: 2px solid orange; paddi=
ng-left: 8px;">
<div dir=3D"auto">Looks like an interesting proposal, but it doesn't seem t=
o quite match the goals you mentioned. As you do mention, this mining pool =
coordination doesn't get rid of the need for mining pools in the first plac=
e. So it doesn't satisfy item 1 on your goal list afaict.
<div dir=3D"auto"> </div>
<div dir=3D"auto">The primary benefits over what we have today that I can s=
ee are:</div>
<div dir=3D"auto">1. increased payout regularity, which lowers the viable s=
ize of mining pools, and</div>
<div dir=3D"auto">2. Lower on chain footprint through combining pay outs fr=
om multiple pools.</div>
<div dir=3D"auto"> </div>
<div dir=3D"auto">Am I missing some?</div>
<div dir=3D"auto"> </div>
<div dir=3D"auto">These are interesting benefits, but it would be nice if y=
our post was clearer on that, since the goals list is not the same as the l=
ist of potential benefits of this kind of design.</div>
<div dir=3D"auto"> </div>
<div dir=3D"auto">As far as enabling solo mining, what if this concept were=
used off chain? Have a public network of solo miners who publish "weak blo=
cks" to that network, and the next 100 (or 1000 etc) nice miners pay you ou=
t as long as you're also being nice by following the protocol? All the nice=
optimizations you mentioned about eg combined taproot payouts would apply =
i think. The only goals this wouldn't satisfy are 3 and 5 since an extra ne=
twork is needed, but to be fair, your proposal requires pools which all nee=
d their own extra network anyways. </div>
<div dir=3D"auto"> </div>
<div dir=3D"auto">The missing piece here would be an ordering of weak block=
s to make the window possible. Or at least a way to determine what blocks s=
hould definitely be part of a particular block's pay out. I could see this =
being done by a separate ephemeral blockchain (which starts fresh after eac=
h Bitcoin block) that keeps track of which weak blocks have been submitted,=
potentially using the pow already in each block to secure it. Granted that=
piece is a bit half baked, but it seems quite solvable. Wdyt?</div>
<div dir=3D"auto"> </div>
<div dir=3D"auto">One thing that jumped out at me as not safe is throwing b=
lock rewards into a channel and being able to spend them immediately. There=
's a reason block rewards aren't spendable for a while, and channels don't =
solve that problem, do they? Why not simply reduce the on chain wait time f=
or spending block rewards at that point? Seems like the consequences would =
be the same.</div>
</div>
<br />
<div class=3D"gmail_quote">
<div class=3D"gmail_attr" dir=3D"ltr">On Tue, Dec 14, 2021, 16:12 Bob McElr=
ath via bitcoin-dev <<a href=3D"http://../NowaWiadomosc/Do/QlIkBFQ6QUFhI=
VRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQFxcXEgcFh8UVVVD=
EyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAMGAMXBQJfW1sdXRQ=
UQUoDQlAiBFY8" target=3D"_blank" rel=3D"noopener noreferrer noreferrer">bit=
coin-dev@lists.linuxfoundation.org</a>> wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; borde=
r-left: 1px solid #cccccc; padding-left: 1ex;">You are hand waving. Attempt=
ing to redefine terms to justify your argument is<br />intellectually disho=
nest. Bitcoin pools have *always* been about variance<br />reduction. Your =
window function fundamentally CANNOT be used to hedge hashrate.<br />Variou=
s suggestions below introduce dangerous new games that might be played by<b=
r />miners.<br /><br />The fact is that the half-baked design you posted is=
less than useless, and<br />doesn't do anything that anyone wants.<br /><b=
r />You are trying to justify CTV by making it be all things to all people.=
"When<br />all you have is a hammer, every problem looks like a nail".&nbs=
p; Instead I humbly<br />suggest that you pick ONE problem for which CTV is=
demonstrably the right and<br />best solution, instead of snowing us with =
a ton of half-baked things that<br />*could* be done, and often don't even =
require CTV, and some (like this one)<br />fundamentally don't work. I do l=
ike some of your ideas, but if you had to pick<br />just one "use case", wh=
ich would it be?<br /><br />Jeremy [<a href=3D"http://../NowaWiadomosc/Do/Q=
lIkBFQ6QUFhIVRZX192dnQBeCtCchEyHxYvIVpLARduChoQSFZQR0NWQVZWJUNRXwMSCRMTBgcW=
ASdWVkpbCxUTQwoWQUdjKVBMGFY3MWMWeU9QBAZtNw%3D%3D" target=3D"_blank" rel=3D"=
noopener noreferrer noreferrer noreferrer">jlrubin@mit.edu</a>] wrote:<br /=
>> Bitcoin didn't invent the concept of pooling: <a href=3D"https://en.w=
ikipedia.org/wiki/" target=3D"_blank" rel=3D"noopener noreferrer noreferrer=
noreferrer noreferrer">https://en.wikipedia.org/wiki/</a><br />> Poolin=
g_(resource_management). This is a Bitcoin Mining Pool, although it may<br =
/>> not be your favorite kind, which is fixated on specific properties o=
f computing<br />> contributions before finding a block. Pooling is just=
a general technique for<br />> aggregating resources to accomplish some=
thing. If you have another name like<br />> pooling that is in common us=
e for this type of activity I would be more than<br />> happy to adopt i=
t.<br />> <br />> This sort of pool can hedge not only against fee ra=
tes but also against<br />> increases in hashrate since your historical =
rate 'carries' into the future as a<br />> function of the window. Furth=
er, windows and reward functions can be defined in<br />> a myriad of wa=
ys that could, e.g., pay less to blocks found in more rapid<br />> succe=
ssion, contributing to the smoothing functionality.<br />> <br />> Wi=
th respect to sub-block pooling, as described in the article, this sort of<=
br />> design also helps with micro-pools being able to split resources<=
br />> non-custodially in every block as a part of the higher order DCFM=
P. The point<br />> is not, as noted, to enable solo mining an S9, but t=
o decrease the size of the<br />> minimum viable pool. It's also possibl=
e to add, without much validation or<br />> data, some 'uncle block' typ=
e mechanism in an incentive compatible way (e.g.,<br />> add 10 pow-heav=
y headers on the last block for cost 48 bytes header + 32 bytes<br />> p=
ayout key) such that there's an incentive to include the heaviest ones you'=
ve<br />> seen, not just your own, that are worth further study and cons=
ideration<br />> (particularly because it's non-consensus, only for opt-=
in participation in the<br />> pool).<br />> <br />> With respect =
to space usage, it seems you wholly reject the viability of a<br />> pay=
ment pool mechanism to cut-through chain space. Is this a critique that<br =
/>> holds for all Payment Pools, or just in the context of mining? Is th=
ere a<br />> particular reason why you think it infeasible that "strongl=
y online"<br />> counterparties would be able to coordinate more efficie=
ntly? Is it preferable<br />> for miners, the nexus of decentralization =
for Bitcoin, to prefer to use<br />> custodial services for pooling (whi=
ch may require KYC/AM) over bearing a cost<br />> of some extra potentia=
l chainload?<br />> <br />> Lastly, with respect to complexity, the p=
roposal is actually incredibly simple<br />> when you take it in a broad=
er context. Non Interactive Channels and Payment<br />> Pools are useful=
by themselves, so are the operations to merge them and swap<br />>=
balance across them. Therefore most of the complexity in this proposal is<=
br />> relying on tools we'll likely see in everyday use in any case, DC=
FMP or no.<br />> <br />> Jeremy<br />> !DSPAM:61b8f2f532146158262=
7336!<br />--<br />Cheers, Bob McElrath<br /><br />"For every complex probl=
em, there is a solution that is simple, neat, and wrong."<br />  =
; -- H. L. Mencken <br /><br />____________________________________________=
___<br />bitcoin-dev mailing list<br /><a href=3D"http://../NowaWiadomosc/D=
o/QlIkBFQ6QUFhIVRZX192dnQBeCtCchE6GhA5LFpLCUc7EVZQVl9dQRIXXR8NCBMbCwIGChJXQ=
FxcXEgcFh8UVVVDEyBdVkE9JVRdEwFhYXVlblhVIkosEAszLR5BQVV7U0MID0BAQUgIGh0RHgAM=
GAMXBQJfW1sdXRQUQUoDQlAiBFY8" target=3D"_blank" rel=3D"noopener noreferrer =
noreferrer noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br /><a hr=
ef=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" targe=
t=3D"_blank" rel=3D"noopener noreferrer noreferrer noreferrer noreferrer">h=
ttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a></blockquo=
te>
</div>
</blockquote>
</blockquote>
</div>
</blockquote>
</blockquote>
</div>
</div>
</div>
</blockquote>
--===============0028088375559804441==--
|