summaryrefslogtreecommitdiff
path: root/a4/4db63aa6433a5d77aa628d761ddd9b2ba387c4
blob: 3d2caccf0ec1d783e4ce912090dd8f2951e268db (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
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
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B60378E3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 29 Jun 2017 01:09:50 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f51.google.com (mail-vk0-f51.google.com
	[209.85.213.51])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8067F1B4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 29 Jun 2017 01:09:48 +0000 (UTC)
Received: by mail-vk0-f51.google.com with SMTP id y70so41996871vky.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 28 Jun 2017 18:09:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=blockstream-io.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=1P0T0Kfy5zQi8RWo8U+JjKYTfO9Wp1x1n2MrgvCfJMY=;
	b=korpMaWUsrqkhq2H+TbB/dbDCw9y0PIz+q0TQPRCRQ8LvalRICyCHQ8IELPncEyx0K
	PMYmxcXLMgWB8eVSlvAOGuVwCBYRy0NkH3UAxbeHdL44st9LLDJO63iYBRZfOlWHrE7e
	uqjeOV28DGjIMi/ZWe8MA5IfkCX8r6QMQvU24pyoskoAIfvLsGRn5rB2Cfu1H+TCbTJm
	HUfF0dSF7i+CzLBfXEeIL7+t8CkloeNiYCkFLgFzSyxaGyHm3ZKAK2aTlRLHEYO4SQCY
	8Hz5WEbBj4YZOjYpR7gu2S0KFiktT80le/7MQ9nOywWF1bLruHIH3LosVcgzwBU4iG5E
	J04w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=1P0T0Kfy5zQi8RWo8U+JjKYTfO9Wp1x1n2MrgvCfJMY=;
	b=hi1jqe1ZCaCv4bXcZqD/FkCdkkVZjG5umIpquCKnhKYWQyf+LIt2NJ0xovk0pC0iC3
	slaCIT+QM78rGmsl9ZIBBYnBWAKAh7f6qY4v3DP3jqC7kL4ymMabiSDIlYx51JU77x2U
	Gd9mhA2n2szzPe3dHBPHsTgpR2rSh6kPWWHtDlPwhPR6o4gmuMfD8NnyRZ/hugrLwrC7
	zFVnSWK6Y6PiAhQWSygCuC5pqP+1lx4i0rh/cKLgtFJs6/LsDZaLZjjfAQOgHJxA6sCo
	oF6wEjVy9iSKWM0Hb1RgMhh5ByI/YbBPt2czrOmGa0yfm1qEiaOhg6E4vCA/lJhgFxCG
	qb/w==
X-Gm-Message-State: AKS2vOyCJwK4vPCGRO6SQuCgz3ld1c2T34KD2tPQM3Zv95d2tNzDRROB
	3v1SKlIewfqyjOI9NgqOHAoKNc9SIwBx
X-Received: by 10.31.166.133 with SMTP id p127mr7308612vke.134.1498698587539; 
	Wed, 28 Jun 2017 18:09:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.74.89 with HTTP; Wed, 28 Jun 2017 18:09:27 -0700 (PDT)
In-Reply-To: <CAGL6+mECcS=rNz3guM+95RoOB4cVYvXTgTj9JWhf52uZRZimCg@mail.gmail.com>
References: <CAGL6+mHQ_vMc2JYVqwfP89WOZdUF2WDtWfh7ccL1PQve=nC+zQ@mail.gmail.com>
	<OozQK1_gWeExd5578AYH_dHnSKSvx63FJc2rIBBcaJF4f07qzsR8rr-ka5epwMFCjqDuidAWZiZqqlvn4xvSuUpDY0KkV014VQs6_E3Rp_A=@protonmail.com>
	<2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
	<CAMZUoKmKxJvVECh8ofdn=6N1tZ2M_4EAAFcWvpOeUYVp5DDyDw@mail.gmail.com>
	<CAGL6+mECcS=rNz3guM+95RoOB4cVYvXTgTj9JWhf52uZRZimCg@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Wed, 28 Jun 2017 21:09:27 -0400
Message-ID: <CAMZUoK=s0LtsJS-Wspg83Pz-HH=8TdhbitJtXb-nzNRCO0hJ5w@mail.gmail.com>
To: Chris Stewart <chris@suredbits.com>
Content-Type: multipart/alternative; boundary="001a114265c8efa17b05530ef48b"
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind
 Merge Mined drivechains
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Jun 2017 01:09:50 -0000

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

HI Chris,

My proposal isn't intended to assume that the bitcoin miner is also
following the sidechain.  In line with my understanding of your proposal,
I'm only proposing to bribe miners to put particular data into the coinbase
output regardless of any semantics that doing so may entail. By my proposed
soft-fork rules, only one of these Bribe TXOs can be included per coinbase
slot (except unless there are identical Bribe TXOs), so there is a
competition of which one of a set of conflicting Bribe TXOs will be
included in the next block.  (That said, the losing set Bribe TXOs can be
included in the later blocks; I don't know what this means semantically for
sidechains; however, the same thing occurs with your proposal as well.)

On Wed, Jun 28, 2017 at 7:47 PM, Chris Stewart <chris@suredbits.com> wrote:

> Hi Russell,
>
> >I haven't really been following the drivechain discussion; I have found
> the documentation about how drivechains are supposed to work scattered and
> difficult to follow. So, without advocating for or against this proposal,
> I'd also suggest that adding an opcode is not the best way to implement
> this bribe.
>
> Despite the flaws in this draft BIP, the goal is to start consolidating
> this information into a more compact format. This BIP is *only*
> meant to address the Blind Merging Mining Process of drivechains. It does
> *not* address the withdrawal process from drivechain -> bitcoin.
>
> >The problem I see is that to send a bribe one must first post a
> transaction to a script that uses the OP_BRIBE code that fixes the critical
> hash (and the sidechain id), and then a second transaction is needed to pay
> the bribe to the miner.
>
> That is intentional, this allows for a competitive process (like bitcoin
> mining) for a block to be 'found' on the sidechain. The OP_BV output that
> rewards
> the bitcoin miner the most amount of money should be the one that is
> included in the bitcoin blockchain. If I understand your scheme correctly,
> you are
> assuming the the bitcoin miner is *also* following the sidechain --
> Sztorc's scheme does not make this assumption. The *number one goal* of BMM
> is to *minimize* the resource burden on bitcoin miners for mining on a
> drivechain.
>
> To gmaxwell/luke-jr,
>
> I agree my commitment scheme is flawed. Thanks for pointing it out. Is
> there any way we could manipulate a coinbase transaction
> into spending these OP_BV outputs? According to instagibbs, and AFIACT he
> is right, we cannot have coinbase transactions
> spend any outputs in previous blocks without a hard fork. This is
> unfortunate because it might make more sense for the coinbase transaction
> to spend these OP_BV outputs. We could design the coinbase transaction's
> scriptSig to push the critical hash onto the stack and
> place an OP_EQUAL on the OP_BV output to verify they were equal.
> If I understand gmaxwell's concern about 'monotone' (or stateless) blocks
> correctly, I *think*
> this solution might fix that as well.
>
> Another way we could fix this is by *fixing* the drivechain indices.
> Therefore the mining rewards and witness commitments must
> *not* occupy one of those indices -- but can occupy any other indice in
> the coinbase output.
> This would give us future flexibility for committing to new soft forks.
> For instance, we would say
> the mining reward must *not* be index 0 of the coinbase transaction, but
> can occupy index 1 - 256. The same would apply for witness commitments.
>
> -Chris
>
> On Wed, Jun 28, 2017 at 5:49 PM, Russell O'Connor <roconnor@blockstream.io
> > wrote:
>
>> I haven't really been following the drivechain discussion; I have found
>> the documentation about how drivechains are supposed to work scattered and
>> difficult to follow. So, without advocating for or against this proposal,
>> I'd also suggest that adding an opcode is not the best way to implement
>> this bribe.
>>
>> The problem I see is that to send a bribe one must first post a
>> transaction to a script that uses the OP_BRIBE code that fixes the critical
>> hash (and the sidechain id), and then a second transaction is needed to pay
>> the bribe to the miner.
>>
>> I suggest instead to use a 0 output value with some currently
>> non-standard OP_RETURN output script that specifies the critical hash (and
>> the sidechain id), similar to ZmnSCPxj's idea.  The difference is that I we
>> would soft-fork a rule that says that such an output is only legal when a
>> miner places the same critical hash suitably in their coinbase output.
>>
>> OP_RETURN outputs are prunable from the UTXO set.  The special bribe
>> output can be fixed to 0 value because the bribe will be paid using the
>> transaction's fees.  To perform a bribe, a user creates and signs a
>> transaction containing one (or more) of these special bribe outputs.  The
>> fee of this transaction constitutes the bribe, and any change the user has
>> can be sent back to themselves.  This way only a single transaction is
>> required to make a bribe.  I didn't really understand the bribe refund
>> mechanism, but I think the fact that the bribe can be done in a single
>> transaction this way alleviates any need for bribe refunds.
>>
>> Hopefully I have understood the goal of this proposal.
>>
>>
>> On Wed, Jun 28, 2017 at 6:20 PM, Paul Sztorc via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hi ZmnSCPxj,
>>>
>>> It seems that, in your version, the "bribers" would react to the scheme
>>> in inefficient ways, particularly when the mainchain's tx-fee-rate (ie
>>> fee per Kb) is low.
>>>
>>> In short, there would be many bribe-attempts (each of which would take
>>> up space in mainchain blocks), almost all of which would be unsuccessful.
>>>
>>> In turn, miners would likely react to this, and try to improve the state
>>> of affairs by offering users the privilege of occupying transaction slot
>>> #2 (ie, the one right after the coinbase). Users would need to trust
>>> miners for this, which introduces a cost friction which is pure
>>> deadweight loss. And, it might be easier for larger/older miners to be
>>> trustworthy than smaller/newer ones.
>>>
>>> Your way is actually very similar to mine. Mine _forces_ the bribe to be
>>> in the earliest txn (the coinbase) and to only occur once. Yours doesn't
>>> do anything to refund the briber, if the sidechain (but not the
>>> mainchain) reorganizes (as it can easily do, if an older sidechain
>>> parent is extended while the mainchain proceeds normally). This creates
>>> additional risk.
>>>
>>> I think mine is also much more space-efficient. Even if ours each had
>>> exactly one h* per sidechain per block, it seems that I only require one
>>> hash to be communicated (plus an indicator byte, and a ~2 byte counter
>>> for the ratchet), whereas you require two. Since its overhead per
>>> sidechain per block, it actually might really add up.
>>>
>>> Thanks,
>>> Paul
>>>
>>>
>>>
>>> On 6/28/2017 4:26 AM, ZmnSCPxj via bitcoin-dev wrote:
>>> > Good morning.
>>> >
>>> > I still do not see what this does that cannot be done by:
>>> >
>>> > OP_RETURN <sidechain-id> <sidechain-block-id>
>>> >
>>> > A transaction with such an output would allow sidechain-miners to bribe
>>> > mainchain-miners by paying a transaction fee if the transaction
>>> > containing this OP_RETURN is included in a block and committed to by a
>>> > mainchain-miner in the Merkle tree root.
>>> >
>>> > It would not require a softfork.
>>> >
>>> > --
>>> >
>>> > I have an alternate proposal that sidechains and altcoins that want to
>>> > do "blinded" merge mining can use without a softfork:
>>> >
>>> > 1.  Encode a block header as a simple cons-pair, with the head as the
>>> > block and the tail as the parent cons-pair.
>>> > 1.1.  This can be encoded as a 32-byte hash of the block including its
>>> > header, and the 32-byte hash of the parent cons-pair.
>>> > 1.2.  This is now the actual "chain" in the sidecoin/altcoin
>>> blockchain.
>>> > 2.  When a sidechain-node wants to know the consensus, it downloads
>>> > mainchain-blocks and looks for OP_RETURN's.
>>> > 2.1.  Starting with its genesis cons-pair hash (equivalent to the empty
>>> > list) as the current cons-pair, it scans each OP_RETURN transaction.
>>> > 2.1.1.  If an OP_RETURN is 64-byte and has the parent cons-pair equal
>>> to
>>> > the current cons-pair, look for the side block indicated and confirm
>>> its
>>> > correctness.  If correct, update the current cons-pair for the hash of
>>> > the OP_RETURN data.
>>> > 2.2.  When reaching the latest mainchain block, the current cons-pair
>>> is
>>> > now the sidecoin/altcoin latest block.
>>> > 2.3.  Note that if multiple OP_RETURN in a block match the current
>>> > cons-pair, the first one is considered the correct chain.  This
>>> property
>>> > means that the sidechain/altchain can only have a chainsplit if the
>>> > mainchain has a chainsplit.
>>> > 3.  When a sidechain-miner wants to create a side-block, it generates a
>>> > new cons-pair and creates an OP_RETURN transaction for it, paying a
>>> > mainchain-miner to include it in the next mainchain-block.
>>> > 3.1.  The sidechain-miner risks that its competitors will outbid it and
>>> > get its OP_RETURN earlier in a mainchain-block (or earlier in the order
>>> > of transactions).  It can mitigate this risk by updating itself to
>>> > become a mainchain-miner, it can then keep its OP_RETURN transaction
>>> > private and put it earlier in the block, ensuring it will "win" the
>>> > sidechain-consensus if it wins the mainchain-consensus.
>>> >
>>> > Regards,
>>> > ZmnSCPxj
>>> >
>>> > -------- Original Message --------
>>> > Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for
>>> Blind
>>> > Merge Mined drivechains
>>> > Local Time: June 28, 2017 8:37 AM
>>> > UTC Time: June 28, 2017 12:37 AM
>>> > From: bitcoin-dev@lists.linuxfoundation.org
>>> > To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org
>>> >
>>> >
>>> > <pre>
>>> >   BIP: <BIP number>
>>> >   Layer: Consensus (Soft fork)
>>> >   Title: OP_BRIBEVERIFY
>>> >   Author: Chris Stewart <chris@suredbits.com>
>>> >   Status: Draft
>>> >   Type: Standards Track
>>> >   Created: 2017-06-27
>>> > </pre>
>>> >
>>> >
>>> > ==Abstract==
>>> >
>>> > This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin
>>> > scripting system that allows for a user to bribe a miner to include a
>>> hash
>>> > in the coinbase transaction's output.
>>> >
>>> >
>>> > ==Summary==
>>> >
>>> > BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the
>>> given
>>> > critical hash is included at the given vout index in the coinbase
>>> > transaction
>>> > the script evaluates to true. Otherwise, the script will fail.
>>> >
>>> > This allows sidechains to be merged mined against
>>> > bitcoin without burdening bitcoin miners with extra resource
>>> requirements.
>>> >
>>> > ==Motivation==
>>> >
>>> > The current political climate of bitcoin is extremely contentious. Many
>>> > community members
>>> > have different visions of what bitcoin is. This op code is meant to
>>> > enable [http://www.truthcoin.info/blog/blind-merged-mining/ Blind
>>> Merge
>>> > Mining].
>>> > This enables sidechains in Bitcoin. With OP_BRIBEVERIFY, sidechains
>>> > miners can
>>> > bribe bitcoin miners to to include their block hash in the bitcoin
>>> > blockchain. If their block
>>> > is included in the coinbase transaction's vout, it is assumed that
>>> block
>>> > is a mined block on the sidechain.
>>> >
>>> > This will allow various factions of the community to realize their
>>> > vision on their own separate
>>> > blockchain that is interoperable with the bitcoin blockchain. This
>>> > allows those factions to use
>>> > bitcoin as a 'reserve currency' for their own network.
>>> >
>>> >
>>> > ===Commitment Structure===
>>> >
>>> > A new block rule is added which requires that the miner's coinbase
>>> > reward be at index 0 in the coinbase transaction's output vector.
>>> >
>>> > It also fixes the witness commitment output to be at index 1 of the
>>> > coinbase transaction's output vector.
>>> >
>>> > This is needed so we can reliably tell what vout corresponds to what
>>> > drivechain. For instance, the mimblewimble sidechain
>>> > could correspond to index 2 of the vector outputs on the coinbase
>>> > transaction.
>>> >
>>> > The commitment is recorded in a <code>scriptPubKey</code> of the
>>> > coinbase transaction. It must be at least 34 bytes in size
>>> >    1-byte - OP_RETURN (0x6a)
>>> >    1-byte - Push the following 32 bytes (0x20)
>>> >   32-byte - block hash
>>> >
>>> > the 35th byte and onward have no consensus meaning.
>>> >
>>> > ===OP_BRIBEVERIFY op code===
>>> >
>>> > This op code reads two arguments from the stack. The stack top is
>>> > expected to be a sidechain id for which this user attempting to blind
>>> > merge mine for.
>>> > The next element on the stack is expected to be a block hash. This op
>>> > code looks into the coinbase transaction's output vector at the given
>>> > index (which is derived from the sidechain id) and checks
>>> > to see if the hash in the block matches the hash inside of the
>>> > BRIBEVERIFY program. If the hashes match, the OP_BRIBEVERIFY acts as an
>>> > OP_NOP. If the
>>> > comparison between the two hashes fail, the script fails.
>>> >
>>> > ===BRIBEVERIFY program===
>>> >
>>> > A standard BRIBEVERIFY program has the format:
>>> >   1-byte - Push the following 32 bytes (0x20)
>>> >  32-byte - block hash
>>> >   1 byte - Push operation? (needed if number can't be encoded as OP_0 -
>>> > OP_16)
>>> >   1 byte - sidechain id
>>> >   1 byte - OP_BRIBEVERIFY op code
>>> >
>>> > ==Detailed Specification==
>>> >
>>> > Refer to the reference implementation, reproduced below, for the
>>> precise
>>> > semantics and detailed rationale for those semantics.
>>> >
>>> >
>>> >  case OP_NOP4:
>>> >  {
>>> >     //format: block_hash sidechain_id OP_BRIBEVERIFY
>>> >     if (!(flags & SCRIPT_VERIFY_BRIBEVERIFY)) {
>>> >         // not enabled; treat as a NOP4
>>> >         if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
>>> >             return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADAB
>>> LE_NOPS);
>>> >         }
>>> >         break;
>>> >     }
>>> >
>>> >     if (stack.size() < 2)
>>> >         return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
>>> >
>>> >     const CScriptNum scriptNumSidechainId(stacktop(
>>> -1),fRequireMinimal);
>>> >     uint8_t nSidechainId;
>>> >     if (!checker.CheckSidechainId(scriptNumSidechainId,nSidechainId))
>>> {
>>> >         return set_error(serror, SCRIPT_ERR_UNKNOWN_SIDECHAIN);
>>> >     }
>>> >
>>> >     // Check block hash
>>> >     bool fHashCritical =
>>> > checker.CheckCriticalHash(stacktop(-2),nSidechainId);
>>> >     if (!fHashCritical) {
>>> >         return set_error(serror, SCRIPT_ERR_UNSATISFIED_BRIBE);
>>> >     }
>>> >     break;
>>> >  }
>>> >
>>> >
>>> >
>>> > https://github.com/Christewart/bitcoin/blob/94b6f33f2278c42d
>>> 4d8758a3c8ffe2078e4ec933/src/script/interpreter.cpp#L427
>>> >
>>> > https://github.com/drivechain-project/bitcoin/pull/13
>>> >
>>> > ==Deployment==
>>> >
>>> > TODO
>>> >
>>> > ==Credits==
>>> >
>>> > Credit to Paul Sztorc for the original idea of Blind Merge Mined
>>> sidechains.
>>> >
>>> > Credit to CryptAxe for writing the foundational layer of software for
>>> > drivechains so I could implement OP_BRIBEVERIFY.
>>> >
>>> >
>>> > ==References==
>>> >
>>> > Blind Merge Mined Sidechains -
>>> > http://www.truthcoin.info/blog/blind-merged-mining/
>>> > Mailing list discussion -
>>> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017
>>> -May/014408.html
>>> >
>>> > ==Copyright==
>>> >
>>> > This document is placed in the public domain.
>>> >
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev@lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>

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

<div dir=3D"ltr"><div>HI Chris,<br><br></div>My proposal isn&#39;t intended=
 to assume that the bitcoin miner is also following the sidechain.=C2=A0 In=
 line with my understanding of your proposal, I&#39;m only proposing to bri=
be miners to put particular data into the coinbase output regardless of any=
 semantics that doing so may entail. By my proposed soft-fork rules, only o=
ne of these Bribe TXOs can be included per coinbase slot (except unless the=
re are identical Bribe TXOs), so there is a competition of which one of a s=
et of conflicting Bribe TXOs will be included in the next block.=C2=A0 (Tha=
t said, the losing set Bribe TXOs can be included in the later blocks; I do=
n&#39;t know what this means semantically for sidechains; however, the same=
 thing occurs with your proposal as well.)<br><div><div><div class=3D"gmail=
_extra"><br><div class=3D"gmail_quote">On Wed, Jun 28, 2017 at 7:47 PM, Chr=
is Stewart <span dir=3D"ltr">&lt;<a href=3D"mailto:chris@suredbits.com" tar=
get=3D"_blank">chris@suredbits.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">Hi Russell, <br><span class=3D""><br>&gt;I=
 haven&#39;t really been following the drivechain discussion; I have found =
the documentation about how drivechains are supposed to work scattered and =
difficult to follow. So, without advocating for or against this proposal, I=
&#39;d also suggest that adding an opcode is not the best way to implement =
this bribe.<br><br></span>Despite the flaws in this draft BIP, the goal is =
to start consolidating this information into a more compact format. This BI=
P is *only* <br>meant to address the Blind Merging Mining Process of drivec=
hains. It does *not* address the withdrawal process from drivechain -&gt; b=
itcoin.<span class=3D""><br><br>&gt;The problem I see is that to send a bri=
be one must first post a transaction to a script that uses the OP_BRIBE cod=
e that fixes the critical hash (and the sidechain id), and then a second tr=
ansaction is needed to pay the bribe to the miner.<br><br></span>That is in=
tentional, this allows for a competitive process (like bitcoin mining) for =
a block to be &#39;found&#39; on the sidechain. The OP_BV output that rewar=
ds <br>the bitcoin miner the most amount of money should be the one that is=
 included in the bitcoin blockchain. If I understand your scheme correctly,=
 you are <br>assuming the the bitcoin miner is *also* following the sidecha=
in -- Sztorc&#39;s scheme does not make this assumption. The *number one go=
al* of BMM<br>is to *minimize* the resource burden on bitcoin miners for mi=
ning on a drivechain.<br><br>To gmaxwell/luke-jr,<br><br>I agree my commitm=
ent scheme is flawed. Thanks for pointing it out. Is there any way we could=
 manipulate a coinbase transaction <br>into spending these OP_BV outputs? A=
ccording to instagibbs, and AFIACT he is right, we cannot have coinbase tra=
nsactions<br>spend any outputs in previous blocks without a hard fork. This=
 is unfortunate because it might make more sense for the coinbase transacti=
on <br>to spend these OP_BV outputs. We could design the coinbase transacti=
on&#39;s scriptSig to push the critical hash onto the stack and <br>place a=
n OP_EQUAL on the OP_BV output to verify they were equal. <br>If I understa=
nd gmaxwell&#39;s concern about &#39;monotone&#39; (or stateless) blocks co=
rrectly, I *think*<br>this solution might fix that as well. <br><br>Another=
 way we could fix this is by *fixing* the drivechain indices. Therefore the=
 mining rewards and witness commitments must <br>*not* occupy one of those =
indices -- but can occupy any other indice in the coinbase output. <br>This=
 would give us future flexibility for committing to new soft forks. For ins=
tance, we would say<br>the mining reward must *not* be index 0 of the coinb=
ase transaction, but can occupy index 1 - 256. The same would apply for wit=
ness commitments.<span class=3D"HOEnZb"><font color=3D"#888888"><br><br>-Ch=
ris<br></font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div cla=
ss=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jun 28, 2017 at 5=
:49 PM, Russell O&#39;Connor <span dir=3D"ltr">&lt;<a href=3D"mailto:roconn=
or@blockstream.io" target=3D"_blank">roconnor@blockstream.io</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>I have=
n&#39;t really been following the drivechain discussion; I have found the d=
ocumentation about how drivechains are supposed to work scattered and diffi=
cult to follow. So, without advocating for or against this proposal, I&#39;=
d also suggest that adding an opcode is not the best way to implement this =
bribe.<br></div></div><div><br>The problem I see is that to send a bribe on=
e must first post a transaction to a script that uses the OP_BRIBE code tha=
t fixes the critical hash (and the sidechain id), and then a second transac=
tion is needed to pay the bribe to the miner.<br><br>I suggest instead to u=
se a 0 output value with some currently non-standard OP_RETURN output scrip=
t that specifies the critical hash (and the sidechain id), similar to ZmnSC=
Pxj&#39;s idea.=C2=A0 The difference is that I we would soft-fork a rule th=
at says that such an output is only legal when a miner places the same crit=
ical hash suitably in their coinbase output.<br><br>OP_RETURN outputs are p=
runable from the UTXO set.=C2=A0 The special bribe output can be fixed to 0=
 value because the bribe will be paid using the transaction&#39;s fees.=C2=
=A0 To perform a bribe, a user creates and signs a transaction containing o=
ne (or more) of these special bribe outputs.=C2=A0 The fee of this transact=
ion constitutes the bribe, and any change the user has can be sent back to =
themselves.=C2=A0 This way only a single transaction is required to make a =
bribe.=C2=A0 I didn&#39;t really understand the bribe refund mechanism, but=
 I think the fact that the bribe can be done in a single transaction this w=
ay alleviates any need for bribe refunds.<br><br></div><div>Hopefully I hav=
e understood the goal of this proposal.<br></div><div><br></div></div><div =
class=3D"m_-4664675009402884476HOEnZb"><div class=3D"m_-4664675009402884476=
h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Jun 2=
8, 2017 at 6:20 PM, Paul Sztorc via bitcoin-dev <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev@lists.linuxfounda<wbr>tion.org</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">Hi ZmnSCPxj,<br>
<br>
It seems that, in your version, the &quot;bribers&quot; would react to the =
scheme<br>
in inefficient ways, particularly when the mainchain&#39;s tx-fee-rate (ie<=
br>
fee per Kb) is low.<br>
<br>
In short, there would be many bribe-attempts (each of which would take<br>
up space in mainchain blocks), almost all of which would be unsuccessful.<b=
r>
<br>
In turn, miners would likely react to this, and try to improve the state<br=
>
of affairs by offering users the privilege of occupying transaction slot<br=
>
#2 (ie, the one right after the coinbase). Users would need to trust<br>
miners for this, which introduces a cost friction which is pure<br>
deadweight loss. And, it might be easier for larger/older miners to be<br>
trustworthy than smaller/newer ones.<br>
<br>
Your way is actually very similar to mine. Mine _forces_ the bribe to be<br=
>
in the earliest txn (the coinbase) and to only occur once. Yours doesn&#39;=
t<br>
do anything to refund the briber, if the sidechain (but not the<br>
mainchain) reorganizes (as it can easily do, if an older sidechain<br>
parent is extended while the mainchain proceeds normally). This creates<br>
additional risk.<br>
<br>
I think mine is also much more space-efficient. Even if ours each had<br>
exactly one h* per sidechain per block, it seems that I only require one<br=
>
hash to be communicated (plus an indicator byte, and a ~2 byte counter<br>
for the ratchet), whereas you require two. Since its overhead per<br>
sidechain per block, it actually might really add up.<br>
<br>
Thanks,<br>
Paul<br>
<div class=3D"m_-4664675009402884476m_-4708731832964720959HOEnZb"><div clas=
s=3D"m_-4664675009402884476m_-4708731832964720959h5"><br>
<br>
<br>
On 6/28/2017 4:26 AM, ZmnSCPxj via bitcoin-dev wrote:<br>
&gt; Good morning.<br>
&gt;<br>
&gt; I still do not see what this does that cannot be done by:<br>
&gt;<br>
&gt; OP_RETURN &lt;sidechain-id&gt; &lt;sidechain-block-id&gt;<br>
&gt;<br>
&gt; A transaction with such an output would allow sidechain-miners to brib=
e<br>
&gt; mainchain-miners by paying a transaction fee if the transaction<br>
&gt; containing this OP_RETURN is included in a block and committed to by a=
<br>
&gt; mainchain-miner in the Merkle tree root.<br>
&gt;<br>
&gt; It would not require a softfork.<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; I have an alternate proposal that sidechains and altcoins that want to=
<br>
&gt; do &quot;blinded&quot; merge mining can use without a softfork:<br>
&gt;<br>
&gt; 1.=C2=A0 Encode a block header as a simple cons-pair, with the head as=
 the<br>
&gt; block and the tail as the parent cons-pair.<br>
&gt; 1.1.=C2=A0 This can be encoded as a 32-byte hash of the block includin=
g its<br>
&gt; header, and the 32-byte hash of the parent cons-pair.<br>
&gt; 1.2.=C2=A0 This is now the actual &quot;chain&quot; in the sidecoin/al=
tcoin blockchain.<br>
&gt; 2.=C2=A0 When a sidechain-node wants to know the consensus, it downloa=
ds<br>
&gt; mainchain-blocks and looks for OP_RETURN&#39;s.<br>
&gt; 2.1.=C2=A0 Starting with its genesis cons-pair hash (equivalent to the=
 empty<br>
&gt; list) as the current cons-pair, it scans each OP_RETURN transaction.<b=
r>
&gt; 2.1.1.=C2=A0 If an OP_RETURN is 64-byte and has the parent cons-pair e=
qual to<br>
&gt; the current cons-pair, look for the side block indicated and confirm i=
ts<br>
&gt; correctness.=C2=A0 If correct, update the current cons-pair for the ha=
sh of<br>
&gt; the OP_RETURN data.<br>
&gt; 2.2.=C2=A0 When reaching the latest mainchain block, the current cons-=
pair is<br>
&gt; now the sidecoin/altcoin latest block.<br>
&gt; 2.3.=C2=A0 Note that if multiple OP_RETURN in a block match the curren=
t<br>
&gt; cons-pair, the first one is considered the correct chain.=C2=A0 This p=
roperty<br>
&gt; means that the sidechain/altchain can only have a chainsplit if the<br=
>
&gt; mainchain has a chainsplit.<br>
&gt; 3.=C2=A0 When a sidechain-miner wants to create a side-block, it gener=
ates a<br>
&gt; new cons-pair and creates an OP_RETURN transaction for it, paying a<br=
>
&gt; mainchain-miner to include it in the next mainchain-block.<br>
&gt; 3.1.=C2=A0 The sidechain-miner risks that its competitors will outbid =
it and<br>
&gt; get its OP_RETURN earlier in a mainchain-block (or earlier in the orde=
r<br>
&gt; of transactions).=C2=A0 It can mitigate this risk by updating itself t=
o<br>
&gt; become a mainchain-miner, it can then keep its OP_RETURN transaction<b=
r>
&gt; private and put it earlier in the block, ensuring it will &quot;win&qu=
ot; the<br>
&gt; sidechain-consensus if it wins the mainchain-consensus.<br>
&gt;<br>
&gt; Regards,<br>
&gt; ZmnSCPxj<br>
&gt;<br>
&gt; -------- Original Message --------<br>
&gt; Subject: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Bli=
nd<br>
&gt; Merge Mined drivechains<br>
&gt; Local Time: June 28, 2017 8:37 AM<br>
&gt; UTC Time: June 28, 2017 12:37 AM<br>
&gt; From: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt; To: Bitcoin Protocol Discussion &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfounda<wbr>=
tion.org</a>&gt;<br>
&gt;<br>
&gt; &lt;pre&gt;<br>
&gt;=C2=A0 =C2=A0BIP: &lt;BIP number&gt;<br>
&gt;=C2=A0 =C2=A0Layer: Consensus (Soft fork)<br>
&gt;=C2=A0 =C2=A0Title: OP_BRIBEVERIFY<br>
&gt;=C2=A0 =C2=A0Author: Chris Stewart &lt;<a href=3D"mailto:chris@suredbit=
s.com" target=3D"_blank">chris@suredbits.com</a>&gt;<br>
&gt;=C2=A0 =C2=A0Status: Draft<br>
&gt;=C2=A0 =C2=A0Type: Standards Track<br>
&gt;=C2=A0 =C2=A0Created: 2017-06-27<br>
&gt; &lt;/pre&gt;<br>
&gt;<br>
&gt;<br>
&gt; =3D=3DAbstract=3D=3D<br>
&gt;<br>
&gt; This BIP describes a new opcode, OP_BRIBEVERIFY, for the Bitcoin<br>
&gt; scripting system that allows for a user to bribe a miner to include a =
hash<br>
&gt; in the coinbase transaction&#39;s output.<br>
&gt;<br>
&gt;<br>
&gt; =3D=3DSummary=3D=3D<br>
&gt;<br>
&gt; BRIBEVERIFY redefines the existing NOP4 opcode. When executed, if the =
given<br>
&gt; critical hash is included at the given vout index in the coinbase<br>
&gt; transaction<br>
&gt; the script evaluates to true. Otherwise, the script will fail.<br>
&gt;<br>
&gt; This allows sidechains to be merged mined against<br>
&gt; bitcoin without burdening bitcoin miners with extra resource requireme=
nts.<br>
&gt;<br>
&gt; =3D=3DMotivation=3D=3D<br>
&gt;<br>
&gt; The current political climate of bitcoin is extremely contentious. Man=
y<br>
&gt; community members<br>
&gt; have different visions of what bitcoin is. This op code is meant to<br=
>
&gt; enable [<a href=3D"http://www.truthcoin.info/blog/blind-merged-mining/=
" rel=3D"noreferrer" target=3D"_blank">http://www.truthcoin.info/blo<wbr>g/=
blind-merged-mining/</a> Blind Merge<br>
&gt; Mining].<br>
&gt; This enables sidechains in Bitcoin. With OP_BRIBEVERIFY, sidechains<br=
>
&gt; miners can<br>
&gt; bribe bitcoin miners to to include their block hash in the bitcoin<br>
&gt; blockchain. If their block<br>
&gt; is included in the coinbase transaction&#39;s vout, it is assumed that=
 block<br>
&gt; is a mined block on the sidechain.<br>
&gt;<br>
&gt; This will allow various factions of the community to realize their<br>
&gt; vision on their own separate<br>
&gt; blockchain that is interoperable with the bitcoin blockchain. This<br>
&gt; allows those factions to use<br>
&gt; bitcoin as a &#39;reserve currency&#39; for their own network.<br>
&gt;<br>
&gt;<br>
&gt; =3D=3D=3DCommitment Structure=3D=3D=3D<br>
&gt;<br>
&gt; A new block rule is added which requires that the miner&#39;s coinbase=
<br>
&gt; reward be at index 0 in the coinbase transaction&#39;s output vector.<=
br>
&gt;<br>
&gt; It also fixes the witness commitment output to be at index 1 of the<br=
>
&gt; coinbase transaction&#39;s output vector.<br>
&gt;<br>
&gt; This is needed so we can reliably tell what vout corresponds to what<b=
r>
&gt; drivechain. For instance, the mimblewimble sidechain<br>
&gt; could correspond to index 2 of the vector outputs on the coinbase<br>
&gt; transaction.<br>
&gt;<br>
&gt; The commitment is recorded in a &lt;code&gt;scriptPubKey&lt;/code&gt; =
of the<br>
&gt; coinbase transaction. It must be at least 34 bytes in size<br>
&gt;=C2=A0 =C2=A0 1-byte - OP_RETURN (0x6a)<br>
&gt;=C2=A0 =C2=A0 1-byte - Push the following 32 bytes (0x20)<br>
&gt;=C2=A0 =C2=A032-byte - block hash<br>
&gt;<br>
&gt; the 35th byte and onward have no consensus meaning.<br>
&gt;<br>
&gt; =3D=3D=3DOP_BRIBEVERIFY op code=3D=3D=3D<br>
&gt;<br>
&gt; This op code reads two arguments from the stack. The stack top is<br>
&gt; expected to be a sidechain id for which this user attempting to blind<=
br>
&gt; merge mine for.<br>
&gt; The next element on the stack is expected to be a block hash. This op<=
br>
&gt; code looks into the coinbase transaction&#39;s output vector at the gi=
ven<br>
&gt; index (which is derived from the sidechain id) and checks<br>
&gt; to see if the hash in the block matches the hash inside of the<br>
&gt; BRIBEVERIFY program. If the hashes match, the OP_BRIBEVERIFY acts as a=
n<br>
&gt; OP_NOP. If the<br>
&gt; comparison between the two hashes fail, the script fails.<br>
&gt;<br>
&gt; =3D=3D=3DBRIBEVERIFY program=3D=3D=3D<br>
&gt;<br>
&gt; A standard BRIBEVERIFY program has the format:<br>
&gt;=C2=A0 =C2=A01-byte - Push the following 32 bytes (0x20)<br>
&gt;=C2=A0 32-byte - block hash<br>
&gt;=C2=A0 =C2=A01 byte - Push operation? (needed if number can&#39;t be en=
coded as OP_0 -<br>
&gt; OP_16)<br>
&gt;=C2=A0 =C2=A01 byte - sidechain id<br>
&gt;=C2=A0 =C2=A01 byte - OP_BRIBEVERIFY op code<br>
&gt;<br>
&gt; =3D=3DDetailed Specification=3D=3D<br>
&gt;<br>
&gt; Refer to the reference implementation, reproduced below, for the preci=
se<br>
&gt; semantics and detailed rationale for those semantics.<br>
&gt;<br>
&gt;<br>
&gt;=C2=A0 case OP_NOP4:<br>
&gt;=C2=A0 {<br>
&gt;=C2=A0 =C2=A0 =C2=A0//format: block_hash sidechain_id OP_BRIBEVERIFY<br=
>
&gt;=C2=A0 =C2=A0 =C2=A0if (!(flags &amp; SCRIPT_VERIFY_BRIBEVERIFY)) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// not enabled; treat as a NOP4<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (flags &amp; SCRIPT_VERIFY_DISCOUR=
AGE_UPGRA<wbr>DABLE_NOPS) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return set_error(serror=
, SCRIPT_ERR_DISCOURAGE_UPGRADAB<wbr>LE_NOPS);<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0break;<br>
&gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0if (stack.size() &lt; 2)<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return set_error(serror, SCRIPT_ERR_I=
NVALID_STACK_OPERA<wbr>TION);<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0const CScriptNum scriptNumSidechainId(stacktop(<wbr=
>-1),fRequireMinimal);<br>
&gt;=C2=A0 =C2=A0 =C2=A0uint8_t nSidechainId;<br>
&gt;=C2=A0 =C2=A0 =C2=A0if (!checker.CheckSidechainId(scr<wbr>iptNumSidecha=
inId,nSidechainId<wbr>)) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return set_error(serror, SCRIPT_ERR_U=
NKNOWN_SIDECHAIN);<br>
&gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt;<br>
&gt;=C2=A0 =C2=A0 =C2=A0// Check block hash<br>
&gt;=C2=A0 =C2=A0 =C2=A0bool fHashCritical =3D<br>
&gt; checker.CheckCriticalHash(stac<wbr>ktop(-2),nSidechainId);<br>
&gt;=C2=A0 =C2=A0 =C2=A0if (!fHashCritical) {<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0return set_error(serror, SCRIPT_ERR_U=
NSATISFIED_BRIBE);<br>
&gt;=C2=A0 =C2=A0 =C2=A0}<br>
&gt;=C2=A0 =C2=A0 =C2=A0break;<br>
&gt;=C2=A0 }<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; <a href=3D"https://github.com/Christewart/bitcoin/blob/94b6f33f2278c42=
d4d8758a3c8ffe2078e4ec933/src/script/interpreter.cpp#L427" rel=3D"noreferre=
r" target=3D"_blank">https://github.com/Christewart<wbr>/bitcoin/blob/94b6f=
33f2278c42d<wbr>4d8758a3c8ffe2078e4ec933/src/s<wbr>cript/interpreter.cpp#L4=
27</a><br>
&gt;<br>
&gt; <a href=3D"https://github.com/drivechain-project/bitcoin/pull/13" rel=
=3D"noreferrer" target=3D"_blank">https://github.com/drivechain-<wbr>projec=
t/bitcoin/pull/13</a><br>
&gt;<br>
&gt; =3D=3DDeployment=3D=3D<br>
&gt;<br>
&gt; TODO<br>
&gt;<br>
&gt; =3D=3DCredits=3D=3D<br>
&gt;<br>
&gt; Credit to Paul Sztorc for the original idea of Blind Merge Mined sidec=
hains.<br>
&gt;<br>
&gt; Credit to CryptAxe for writing the foundational layer of software for<=
br>
&gt; drivechains so I could implement OP_BRIBEVERIFY.<br>
&gt;<br>
&gt;<br>
&gt; =3D=3DReferences=3D=3D<br>
&gt;<br>
&gt; Blind Merge Mined Sidechains -<br>
&gt; <a href=3D"http://www.truthcoin.info/blog/blind-merged-mining/" rel=3D=
"noreferrer" target=3D"_blank">http://www.truthcoin.info/blog<wbr>/blind-me=
rged-mining/</a><br>
&gt; Mailing list discussion -<br>
&gt; <a href=3D"https://lists.linuxfoundation.org/pipermail/bitcoin-dev/201=
7-May/014408.html" rel=3D"noreferrer" target=3D"_blank">https://lists.linux=
foundation.<wbr>org/pipermail/bitcoin-dev/2017<wbr>-May/014408.html</a><br>
&gt;<br>
&gt; =3D=3DCopyright=3D=3D<br>
&gt;<br>
&gt; This document is placed in the public domain.<br>
&gt;<br>
&gt;<br>
</div></div><div class=3D"m_-4664675009402884476m_-4708731832964720959HOEnZ=
b"><div class=3D"m_-4664675009402884476m_-4708731832964720959h5">&gt; _____=
_________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
&gt;<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-d<wbr>ev</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div></div></div>

--001a114265c8efa17b05530ef48b--