summaryrefslogtreecommitdiff
path: root/12/5354dba2612992d56e5319aefd7985d27c4999
blob: 6cf6dda415ae509bd891622db4ed95e21a2cfbe5 (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
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
Return-Path: <ethan.scruples@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 01FE194D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 27 Jul 2016 14:42:36 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f182.google.com (mail-io0-f182.google.com
	[209.85.223.182])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BD0D1235
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 27 Jul 2016 14:42:33 +0000 (UTC)
Received: by mail-io0-f182.google.com with SMTP id b62so72025115iod.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 27 Jul 2016 07:42:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 
	bh=alkHa8CcsuWjyhGpyBDMEln5app+wh+O0mqH/dibr5U=;
	b=QTm5NJi8XRa3d3axrBYNQNU5qma4sZCUSerh+49XNnDa4zK8i8ND9T/ucs2+gSACVV
	kl5CdqHOoIADrAlZFZgZH9NvgmfMGjkxiDzxjr1hS0LmWBkWWNHf5suKYrJqmLYz0tUM
	sW6xK6SrFNc58druDbDU0OU6qNd5Hm/6Okd2I2PRyNo9rNF1n2Glec93KB+ADqceoScm
	gkEqEFcit+cxDFM6pzJ8SF+35ZRlCVV4OQ3+AdCXaxIZg0GudNk/xJ3jwZMN5RE+Z07n
	o+JoryrFaOk8pDE+P9OHys/Jq6Jldu5oZeVFQkodu3B+pc+nQDz8MQsAmdjZkX/XV7xk
	jMFA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to;
	bh=alkHa8CcsuWjyhGpyBDMEln5app+wh+O0mqH/dibr5U=;
	b=gSmmw9leEkLiJjvXB5PsJ6257D+/xyLRGLJlEtFwHp7V18x2SjSOxTNp9rbZcJccE6
	dUFoLujdwK4l1fPusEtdO/CjkISiGOYwG5bgoso4f3tvpXOUVQ36U8RZr7of0AqXEg7t
	hJMwyneW8q7TlrYew/rg7dWSR+D+DTF+aJn86UK8+Yy7AoUzZLMvmWLdbqIHyfqpHBkF
	054X0QTom4Ai8/TfS6WkXXd1hDg7yddwtmmw0y0ytP9Dh9XjFe1pg5MSYjXdDDDiM3Ri
	COmaqSbaIZ3QIy/TkLBxwTe7xjlAFGThjhWdJUQn8E5c3bpvz0ZC1RnakGnz+z6GiDix
	T2Zg==
X-Gm-Message-State: AEkoouuWjxIIfhTH69fpC0DKSpxXjwWHNUGXA0Ud6EvRbeY4MQvJknQQspf/1QfRKdYLNNH3X3IXSOBajhKeKA==
X-Received: by 10.107.128.25 with SMTP id b25mr36157064iod.110.1469630552833; 
	Wed, 27 Jul 2016 07:42:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.80.15 with HTTP; Wed, 27 Jul 2016 07:42:32 -0700 (PDT)
In-Reply-To: <CANN4kmf32ozV=LGbOHrifRiSPX==Mb1uSnjqa2v2c43=HU3OBg@mail.gmail.com>
References: <CACiOHGxpTEOzUBovuJstNEVQOpD+Yv0JivuyeOFsba_jhdyydw@mail.gmail.com>
	<CANN4kmf32ozV=LGbOHrifRiSPX==Mb1uSnjqa2v2c43=HU3OBg@mail.gmail.com>
From: Moral Agent <ethan.scruples@gmail.com>
Date: Wed, 27 Jul 2016 10:42:32 -0400
Message-ID: <CACiOHGx_gzwy9O9Pz1mf8sRPL0vzfKVsi_dttSy-6tH_=fagHQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113fb5960d854105389f075f
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_LOW, URIBL_RED 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: Wed, 27 Jul 2016 15:03:28 +0000
Subject: Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin
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: Wed, 27 Jul 2016 14:42:36 -0000

--001a113fb5960d854105389f075f
Content-Type: text/plain; charset=UTF-8

I made a repo to be a home for sync_flags here:
https://github.com/moral-agent/sync_flags

If you see any personally identifying information, please be a good sport
and let me know. I'm a nobody, but I'd still prefer not to get doxxed.

Two changes to the proposal (see repo for explanations)

1. Sync flags now would have the same difficulty as blocks.
2. Blocks now donate to 5 sync flags instead of 1

I also added comments about selfish mining and invalid block spam.

Response to replies:

tomz@freedommail.ch: What is the advantage over optimistic mining?

1. Sync flags can be somewhat smaller than block headers.
2. Sync flags improve variance by doubling the number of chances to win
3. Sync flags can be distinguished from normal blocks, so SPV clients can
ignore them as confirmations.
4. Sync flags reward all miners equally. Optimistic blocks have to be empty
unless you mined the previous block, which damages decentralization.
5. Sync flags result in fewer empty blocks, smoothing out resource usage
6. Sync flags make transaction stuffing by miners either obvious or costly
7. Sync flags give miners something to do while they wait for attractive
transactions to appear.

erik@q32.com: Flags will be selfish mined.

I agree that flags would likely be selfish mined. I have modified the
proposal to say that flags have the same POW target as blocks, so the
selfish mining vulnerability should be equal to the current protocol.

martijn.meijering@mevs.nl: Why expect more selfish mining?

Because flags had small POW relative to blocks. After you find a block, why
not hide it while you take a crack at the flag?

tier.nolan@gmail.com: Effect is same as mandatory empty blocks.

Not quite the same:

1. Sync flags can be somewhat smaller than block headers.
2. Sync flags can be distinguished from normal blocks, so SPV clients can
ignore them as confirmations.
3. Sync flags make transaction stuffing by miners either obvious or costly
4. No one pays for empty blocks, except for the block subsidy. Some miners
may choose to only mine the non-empty blocks, resulting in
hashpower-for-rent to make mischief or hashpower that oscillates, creating
a situation where empty blocks take longer to mine than full blocks.

nickodell@gmail.com: Payout mechanism incompatible with certain mining pools

Hopefully some kind of smart contract structure could be implemented as you
suggested.


On Tue, Jul 26, 2016 at 6:03 PM, Nick ODell <nickodell@gmail.com> wrote:

> Moral,
>
> Mining the sync flag isn't compatible with the payout structure of non
> hot-wallet pools like Eligius or decentralized pools like p2pool.
> Those need the ability to split a reward among multiple parties.
> Instead of giving an address to send the funds to, you could include
> the hash of the transaction allowed to spend the sync flag output.
> You'd have to zero the previous outpoint of the transaction before
> hashing, since you don't know what the hash of the coinbase ten blocks
> from now will be.
>
>
> On Tue, Jul 26, 2016 at 6:47 AM, Moral Agent via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > I posted this to /r/bitcoin yesterday but it got minimal comments. One
> uses
> > suggested I try the mailing list so here it is:
> >
> > The idea presented here could have the following benefits:
> >
> > 1. Improve mining decentralization
> > 2. Reduce variance in mining profitability
> > 3. Reduce or eliminate SPV mined blocks
> > 4. Reduce or eliminate empty blocks, smoothing out resource usage
> > 5. Reduce or eliminate the latency bottleneck on throughput
> > 6. Make transaction stuffing by miners be either obvious or costly
> > 7. Gives miners something to do while they wait for attractive
> transactions
> > to appear
> > 8. Can be easily done with a soft fork
> >
> > #Basic idea:
> >
> > Ideally, all miners would begin hashing the next block at exactly the
> same
> > time. Miners with a head start are more profitable, and the techniques
> that
> > help miners receive and validate blocks quickly create centralization
> > pressure.
> >
> > What if there was something that acted like the starting flag at a race,
> > which could suddenly wave and cause all of the miners to simultaneously
> > begin hashing the next block?
> >
> > #Implementation:
> >
> > Let a sync flag be a message consisting of:
> >
> > 1. Hash of the previous block.
> > 2. Bitcoin address
> > 3. Nonce
> >
> > This tiny message could propagate through the network at maximum speed.
> If
> > miners had to include the hash of this flag in the next block, then all
> > miners wait for this flag, and when it suddenly spread through the
> network,
> > all miners could simultaneously begin hashing the next block.
> >
> > The sync flag should not be produced too quickly. You want to give
> everyone
> > enough time to be ready to hash the next block. Let's say that the hash
> of
> > the sync flag is a proof of work that is targeted for 2 minutes.
> >
> > To fund this proof of work, the protocol is modified to demand that the
> > block produced 10 blocks after the sync flag must allocate 25% of the
> block
> > reward to the address published by the sync flag. In this way, sync flags
> > are produced in 2 minutes, and blocks are produced in 8 minutes, with 10
> > minutes total.
> >
> >
> > Illustration 1: https://s32.postimg.org/wzg0hs8lx/sync_flag.png)
> >
> > Illustration 2: https://s32.postimg.org/vc5y9yz4l/sync_flag2.png
> >
> >
> > #Explanation of reasons:
> >
> > **Improve mining decentralization**
> >
> > One factor driving centralization is the imperative miners have to
> achieve
> > low latency in receiving and validating blocks. To achieve low latency,
> it
> > helps a lot if you have expensive low-latency internet connections,
> curated
> > network topologies, and large pools that have a plausible chance of
> finding
> > consecutive blocks. If miners are expected (or forced) to validate a
> block
> > prior to mining on top of it, the rational end game would be to outsource
> > the validation step to a trusted third party specialist who can choose
> > optimal locations on the globe to serve their (multiple?) mining pool
> > clients. These are all less decentralized than the mining situation
> Satoshi
> > and others imagined.
> >
> > **Reduce variance in mining revenue**
> >
> > Currently, there are about 144 opportunities per day for a pool or solo
> > miner to see any revenue at all. With sync flags, that number doubles to
> > 288. Sync flags are only worth 25% of what a block is worth, but this
> still
> > represents a significant reduction in variance. This variance is one
> factor
> > causing solo miners to group into pools, and large pools to be more
> > attractive than small pools.
> >
> > **Reduce or eliminate SPV mined blocks**
> >
> > One way miners have sought to make
> > full-block-transmission-and-validation-latency irrelevant has been
> through
> > "SPV" mining or "Head-first" mining. There is some evidence that these
> > techniques may be widely used, and that badgering the miners about it is
> an
> > ineffective strategy to stop them.
> >
> > In SPV mining, a miner would simply accept any block header that shows
> the
> > correct proof of work. All other validation is entrusted to other miners.
> > This practice is quite dangerous as the SPV miners can wander off on some
> > invalid chain, taking SPV nodes with them. If this occurs during a soft
> > fork, these blind miners can also fool unupgraded fully validating nodes
> > into following them.
> >
> > "Head-first" mining means that miners start hashing as soon as they
> receive
> > the block header with the correct POW, but they simultaneously validate
> the
> > block, and abandon it if is not valid. I consider this to be pretty
> safe, as
> > it strictly limits the length of an invalid chain that can result from
> > mining without validating. However, "Head-first" mining can plausibly
> > generate 2 or 3 confirmations of an invalid block. It would be nice if
> such
> > confirmations did not happen.
> >
> > The sync flag technique is similar to head-first mining, but rather than
> > hashing the next block while they wait for transmission and validation of
> > the prior block, they hash the sync flag. Nodes can differentiate between
> > sync flags and blocks, and can ignore sync flags when counting
> > confirmations.
> >
> > **Reduce or eliminate empty blocks, smoothing out resource usage**
> >
> > Empty blocks are another consequence of SPV or Headfirst mining, because
> the
> > miner cannot safely include any transactions in the block they are
> hashing
> > until they have validated the prior block. By delaying the start of
> hashing
> > the next block until after validation, miners would not have this reason
> to
> > mine empty blocks.
> >
> > **Reduce or eliminate the latency bottleneck on throughput**
> >
> > Centralization pressure due to latency issues has been a major
> preoccupation
> > over the last year. If latency mattered much less, it could represent a
> > scalability improvement that could enable higher throughput.
> >
> > **Make transaction stuffing by miners be either obvious or costly**
> >
> > Currently, the entire block reward goes to the miner who mines it. One
> > unfortunate consequence of this is that it does not cost the miner
> anything
> > to covertly stuff the block with transactions. These transactions would
> pay
> > fees and be indistinguishable from ordinary transactions, but the fees
> are
> > paid by the miner and then immediately returned to the miner.
> >
> > With sync flags, the miner must share these transaction fees with the
> > address contained in the sync flag 10 blocks prior. This means that if
> the
> > miner gives the transactions a normal looking fee, they will incur a cost
> > that will be paid to the sync flag. If the miner wants to avoid this,
> they
> > must give their stuffing transactions a zero fee, which provides evidence
> > that they are stuffing.
> >
> > Also, when miners stuff with transactions using a zero fee, they cannot
> > manipulate the perception of how much fee it takes to get into a block.
> >
> > Note that miners could still try to covertly stuff blocks that will pay a
> > sync flag that they themselves created. if this is a big concern, it can
> be
> > addressed by forcing blocks to pay multiple sync flags.
> >
> > **Gives miners something to do while they wait for attractive
> transactions
> > to appear**
> >
> > From the Montreal scaling workshop last year, we have [this
> > talk](
> https://scalingbitcoin.org/montreal2015/presentations/Day1/13-miles-carlsten-Mind-the-Gap.pdf
> )
> > which worried that as the block subsidy reduced and transactions became a
> > more important fraction of miner revenue, it would be rational for
> miners to
> > turn off their mining equipment for a "gap" phase after a block is
> found, to
> > allow time to pass as more lucrative transactions entered the mempool.
> >
> > I don't know whether this will actually happen. The presence of a
> suitable
> > backlog of transactions would help prevent this dynamic from emerging.
> But
> > if such idling behavior was the optima mining strategy, it could create a
> > serious vulnerability. Idle hands are the devil's workshop as the saying
> > goes, and idle miners represent a pool of inert hashpower that is
> available
> > to rent for all kinds of destabilizing purposes. It would be better to
> put
> > those miners to profitable work mining a sync flag while they wait.
> >
> > Also, this creates a more efficient price discovery mechanism for
> > transactions, because you allow transactions paying high fees time to
> arrive
> > to the marketplace, rather than take whatever anyone is offering because
> all
> > the "good" transactions got gobbled up in the prior block.
> >
> > **Can be easily done with a soft fork**
> >
> > Although a hard fork would be more efficient, sync flags could be easily
> > implemented using a soft fork by introducing the following rule:
> >
> > Every block must include a transaction which pays 25% of the block
> reward to
> > the address given by the 10th previous sync flag, and commits to the
> hash of
> > the 1st previous sync flag.
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

--001a113fb5960d854105389f075f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I made a repo to be a home for sync_flags here:=C2=A0=
<a href=3D"https://github.com/moral-agent/sync_flags">https://github.com/mo=
ral-agent/sync_flags</a></div><div><br></div><div>If you see any personally=
 identifying information, please be a good sport and let me know. I&#39;m a=
 nobody, but I&#39;d still prefer not to get doxxed.</div><div><br></div><d=
iv>Two changes to the proposal (see repo for explanations)</div><div><br></=
div><div>1. Sync flags now would have the same difficulty as blocks.</div><=
div>2. Blocks now donate to 5 sync flags instead of 1</div><div><br></div><=
div>I also added comments about selfish mining and invalid block spam.</div=
><div><br></div><div>Response to replies:</div><div><br></div><div><a href=
=3D"mailto:tomz@freedommail.ch">tomz@freedommail.ch</a>: What is the advant=
age over optimistic mining?<br></div><div><br></div><div>1. Sync flags=C2=
=A0can be somewhat smaller than block headers.</div><div>2. Sync flags=C2=
=A0improve variance by doubling the number of chances to win</div><div>3. S=
ync flags=C2=A0can be distinguished from normal blocks, so SPV clients can =
ignore them as confirmations.</div><div>4. Sync flags reward all miners equ=
ally. Optimistic blocks have to be empty unless you mined the previous bloc=
k, which damages decentralization.</div><div>5. Sync flags result in fewer =
empty blocks, smoothing out resource usage</div><div>6. Sync flags make tra=
nsaction stuffing by miners either obvious or costly</div><div>7. Sync flag=
s give miners something to do while they wait for attractive transactions t=
o appear.</div><div><br></div><div><a href=3D"mailto:erik@q32.com">erik@q32=
.com</a>: Flags will be selfish mined.</div><div><br></div><div>I agree tha=
t flags would likely be selfish mined. I have modified the proposal to say =
that flags have the same POW target as blocks, so the selfish mining vulner=
ability should be equal to the current protocol.</div><div><br></div><div><=
a href=3D"mailto:martijn.meijering@mevs.nl">martijn.meijering@mevs.nl</a>: =
Why expect more selfish mining?</div><div><br></div><div>Because flags had =
small POW relative to blocks. After you find a block, why not hide it while=
 you take a crack at the flag?</div><div><br></div><div><a href=3D"mailto:t=
ier.nolan@gmail.com">tier.nolan@gmail.com</a>: Effect is same as mandatory =
empty blocks.</div><div><br></div><div>Not quite the same:</div><div><br></=
div><div><div>1. Sync flags=C2=A0can be somewhat smaller than block headers=
.</div><div>2. Sync flags=C2=A0can be distinguished from normal blocks, so =
SPV clients can ignore them as confirmations.</div><div>3. Sync flags make =
transaction stuffing by miners either obvious or costly</div></div><div>4. =
No one pays for empty blocks, except for the block subsidy. Some miners may=
 choose to only mine the non-empty blocks, resulting in hashpower-for-rent =
to make mischief or hashpower that oscillates, creating a situation where e=
mpty blocks take longer to mine than full blocks.</div><div><br></div><div>=
<a href=3D"mailto:nickodell@gmail.com">nickodell@gmail.com</a>: Payout mech=
anism incompatible with certain mining pools</div><div><br></div><div>Hopef=
ully some kind of smart contract structure could be implemented as you sugg=
ested.</div><div><br></div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Tue, Jul 26, 2016 at 6:03 PM, Nick ODell <span dir=3D"l=
tr">&lt;<a href=3D"mailto:nickodell@gmail.com" target=3D"_blank">nickodell@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Moral,<b=
r>
<br>
Mining the sync flag isn&#39;t compatible with the payout structure of non<=
br>
hot-wallet pools like Eligius or decentralized pools like p2pool.<br>
Those need the ability to split a reward among multiple parties.<br>
Instead of giving an address to send the funds to, you could include<br>
the hash of the transaction allowed to spend the sync flag output.<br>
You&#39;d have to zero the previous outpoint of the transaction before<br>
hashing, since you don&#39;t know what the hash of the coinbase ten blocks<=
br>
from now will be.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
On Tue, Jul 26, 2016 at 6:47 AM, Moral Agent via bitcoin-dev<br>
&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>&gt; wrote:<br>
&gt; I posted this to /r/bitcoin yesterday but it got minimal comments. One=
 uses<br>
&gt; suggested I try the mailing list so here it is:<br>
&gt;<br>
&gt; The idea presented here could have the following benefits:<br>
&gt;<br>
&gt; 1. Improve mining decentralization<br>
&gt; 2. Reduce variance in mining profitability<br>
&gt; 3. Reduce or eliminate SPV mined blocks<br>
&gt; 4. Reduce or eliminate empty blocks, smoothing out resource usage<br>
&gt; 5. Reduce or eliminate the latency bottleneck on throughput<br>
&gt; 6. Make transaction stuffing by miners be either obvious or costly<br>
&gt; 7. Gives miners something to do while they wait for attractive transac=
tions<br>
&gt; to appear<br>
&gt; 8. Can be easily done with a soft fork<br>
&gt;<br>
&gt; #Basic idea:<br>
&gt;<br>
&gt; Ideally, all miners would begin hashing the next block at exactly the =
same<br>
&gt; time. Miners with a head start are more profitable, and the techniques=
 that<br>
&gt; help miners receive and validate blocks quickly create centralization<=
br>
&gt; pressure.<br>
&gt;<br>
&gt; What if there was something that acted like the starting flag at a rac=
e,<br>
&gt; which could suddenly wave and cause all of the miners to simultaneousl=
y<br>
&gt; begin hashing the next block?<br>
&gt;<br>
&gt; #Implementation:<br>
&gt;<br>
&gt; Let a sync flag be a message consisting of:<br>
&gt;<br>
&gt; 1. Hash of the previous block.<br>
&gt; 2. Bitcoin address<br>
&gt; 3. Nonce<br>
&gt;<br>
&gt; This tiny message could propagate through the network at maximum speed=
. If<br>
&gt; miners had to include the hash of this flag in the next block, then al=
l<br>
&gt; miners wait for this flag, and when it suddenly spread through the net=
work,<br>
&gt; all miners could simultaneously begin hashing the next block.<br>
&gt;<br>
&gt; The sync flag should not be produced too quickly. You want to give eve=
ryone<br>
&gt; enough time to be ready to hash the next block. Let&#39;s say that the=
 hash of<br>
&gt; the sync flag is a proof of work that is targeted for 2 minutes.<br>
&gt;<br>
&gt; To fund this proof of work, the protocol is modified to demand that th=
e<br>
&gt; block produced 10 blocks after the sync flag must allocate 25% of the =
block<br>
&gt; reward to the address published by the sync flag. In this way, sync fl=
ags<br>
&gt; are produced in 2 minutes, and blocks are produced in 8 minutes, with =
10<br>
&gt; minutes total.<br>
&gt;<br>
&gt;<br>
&gt; Illustration 1: <a href=3D"https://s32.postimg.org/wzg0hs8lx/sync_flag=
.png" rel=3D"noreferrer" target=3D"_blank">https://s32.postimg.org/wzg0hs8l=
x/sync_flag.png</a>)<br>
&gt;<br>
&gt; Illustration 2: <a href=3D"https://s32.postimg.org/vc5y9yz4l/sync_flag=
2.png" rel=3D"noreferrer" target=3D"_blank">https://s32.postimg.org/vc5y9yz=
4l/sync_flag2.png</a><br>
&gt;<br>
&gt;<br>
&gt; #Explanation of reasons:<br>
&gt;<br>
&gt; **Improve mining decentralization**<br>
&gt;<br>
&gt; One factor driving centralization is the imperative miners have to ach=
ieve<br>
&gt; low latency in receiving and validating blocks. To achieve low latency=
, it<br>
&gt; helps a lot if you have expensive low-latency internet connections, cu=
rated<br>
&gt; network topologies, and large pools that have a plausible chance of fi=
nding<br>
&gt; consecutive blocks. If miners are expected (or forced) to validate a b=
lock<br>
&gt; prior to mining on top of it, the rational end game would be to outsou=
rce<br>
&gt; the validation step to a trusted third party specialist who can choose=
<br>
&gt; optimal locations on the globe to serve their (multiple?) mining pool<=
br>
&gt; clients. These are all less decentralized than the mining situation Sa=
toshi<br>
&gt; and others imagined.<br>
&gt;<br>
&gt; **Reduce variance in mining revenue**<br>
&gt;<br>
&gt; Currently, there are about 144 opportunities per day for a pool or sol=
o<br>
&gt; miner to see any revenue at all. With sync flags, that number doubles =
to<br>
&gt; 288. Sync flags are only worth 25% of what a block is worth, but this =
still<br>
&gt; represents a significant reduction in variance. This variance is one f=
actor<br>
&gt; causing solo miners to group into pools, and large pools to be more<br=
>
&gt; attractive than small pools.<br>
&gt;<br>
&gt; **Reduce or eliminate SPV mined blocks**<br>
&gt;<br>
&gt; One way miners have sought to make<br>
&gt; full-block-transmission-and-validation-latency irrelevant has been thr=
ough<br>
&gt; &quot;SPV&quot; mining or &quot;Head-first&quot; mining. There is some=
 evidence that these<br>
&gt; techniques may be widely used, and that badgering the miners about it =
is an<br>
&gt; ineffective strategy to stop them.<br>
&gt;<br>
&gt; In SPV mining, a miner would simply accept any block header that shows=
 the<br>
&gt; correct proof of work. All other validation is entrusted to other mine=
rs.<br>
&gt; This practice is quite dangerous as the SPV miners can wander off on s=
ome<br>
&gt; invalid chain, taking SPV nodes with them. If this occurs during a sof=
t<br>
&gt; fork, these blind miners can also fool unupgraded fully validating nod=
es<br>
&gt; into following them.<br>
&gt;<br>
&gt; &quot;Head-first&quot; mining means that miners start hashing as soon =
as they receive<br>
&gt; the block header with the correct POW, but they simultaneously validat=
e the<br>
&gt; block, and abandon it if is not valid. I consider this to be pretty sa=
fe, as<br>
&gt; it strictly limits the length of an invalid chain that can result from=
<br>
&gt; mining without validating. However, &quot;Head-first&quot; mining can =
plausibly<br>
&gt; generate 2 or 3 confirmations of an invalid block. It would be nice if=
 such<br>
&gt; confirmations did not happen.<br>
&gt;<br>
&gt; The sync flag technique is similar to head-first mining, but rather th=
an<br>
&gt; hashing the next block while they wait for transmission and validation=
 of<br>
&gt; the prior block, they hash the sync flag. Nodes can differentiate betw=
een<br>
&gt; sync flags and blocks, and can ignore sync flags when counting<br>
&gt; confirmations.<br>
&gt;<br>
&gt; **Reduce or eliminate empty blocks, smoothing out resource usage**<br>
&gt;<br>
&gt; Empty blocks are another consequence of SPV or Headfirst mining, becau=
se the<br>
&gt; miner cannot safely include any transactions in the block they are has=
hing<br>
&gt; until they have validated the prior block. By delaying the start of ha=
shing<br>
&gt; the next block until after validation, miners would not have this reas=
on to<br>
&gt; mine empty blocks.<br>
&gt;<br>
&gt; **Reduce or eliminate the latency bottleneck on throughput**<br>
&gt;<br>
&gt; Centralization pressure due to latency issues has been a major preoccu=
pation<br>
&gt; over the last year. If latency mattered much less, it could represent =
a<br>
&gt; scalability improvement that could enable higher throughput.<br>
&gt;<br>
&gt; **Make transaction stuffing by miners be either obvious or costly**<br=
>
&gt;<br>
&gt; Currently, the entire block reward goes to the miner who mines it. One=
<br>
&gt; unfortunate consequence of this is that it does not cost the miner any=
thing<br>
&gt; to covertly stuff the block with transactions. These transactions woul=
d pay<br>
&gt; fees and be indistinguishable from ordinary transactions, but the fees=
 are<br>
&gt; paid by the miner and then immediately returned to the miner.<br>
&gt;<br>
&gt; With sync flags, the miner must share these transaction fees with the<=
br>
&gt; address contained in the sync flag 10 blocks prior. This means that if=
 the<br>
&gt; miner gives the transactions a normal looking fee, they will incur a c=
ost<br>
&gt; that will be paid to the sync flag. If the miner wants to avoid this, =
they<br>
&gt; must give their stuffing transactions a zero fee, which provides evide=
nce<br>
&gt; that they are stuffing.<br>
&gt;<br>
&gt; Also, when miners stuff with transactions using a zero fee, they canno=
t<br>
&gt; manipulate the perception of how much fee it takes to get into a block=
.<br>
&gt;<br>
&gt; Note that miners could still try to covertly stuff blocks that will pa=
y a<br>
&gt; sync flag that they themselves created. if this is a big concern, it c=
an be<br>
&gt; addressed by forcing blocks to pay multiple sync flags.<br>
&gt;<br>
&gt; **Gives miners something to do while they wait for attractive transact=
ions<br>
&gt; to appear**<br>
&gt;<br>
&gt; From the Montreal scaling workshop last year, we have [this<br>
&gt; talk](<a href=3D"https://scalingbitcoin.org/montreal2015/presentations=
/Day1/13-miles-carlsten-Mind-the-Gap.pdf" rel=3D"noreferrer" target=3D"_bla=
nk">https://scalingbitcoin.org/montreal2015/presentations/Day1/13-miles-car=
lsten-Mind-the-Gap.pdf</a>)<br>
&gt; which worried that as the block subsidy reduced and transactions becam=
e a<br>
&gt; more important fraction of miner revenue, it would be rational for min=
ers to<br>
&gt; turn off their mining equipment for a &quot;gap&quot; phase after a bl=
ock is found, to<br>
&gt; allow time to pass as more lucrative transactions entered the mempool.=
<br>
&gt;<br>
&gt; I don&#39;t know whether this will actually happen. The presence of a =
suitable<br>
&gt; backlog of transactions would help prevent this dynamic from emerging.=
 But<br>
&gt; if such idling behavior was the optima mining strategy, it could creat=
e a<br>
&gt; serious vulnerability. Idle hands are the devil&#39;s workshop as the =
saying<br>
&gt; goes, and idle miners represent a pool of inert hashpower that is avai=
lable<br>
&gt; to rent for all kinds of destabilizing purposes. It would be better to=
 put<br>
&gt; those miners to profitable work mining a sync flag while they wait.<br=
>
&gt;<br>
&gt; Also, this creates a more efficient price discovery mechanism for<br>
&gt; transactions, because you allow transactions paying high fees time to =
arrive<br>
&gt; to the marketplace, rather than take whatever anyone is offering becau=
se all<br>
&gt; the &quot;good&quot; transactions got gobbled up in the prior block.<b=
r>
&gt;<br>
&gt; **Can be easily done with a soft fork**<br>
&gt;<br>
&gt; Although a hard fork would be more efficient, sync flags could be easi=
ly<br>
&gt; implemented using a soft fork by introducing the following rule:<br>
&gt;<br>
&gt; Every block must include a transaction which pays 25% of the block rew=
ard to<br>
&gt; the address given by the 10th previous sync flag, and commits to the h=
ash of<br>
&gt; the 1st previous sync flag.<br>
&gt;<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">&gt; __________________=
_____________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org=
/mailman/listinfo/bitcoin-dev</a><br>
&gt;<br>
</div></div></blockquote></div><br></div>

--001a113fb5960d854105389f075f--