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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 34BB8C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 May 2022 17:17:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 1594060D55
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 May 2022 17:17:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=jtimon-cc.20210112.gappssmtp.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Z-buZVJAzZsW
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 May 2022 17:17:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-yw1-x1132.google.com (mail-yw1-x1132.google.com
[IPv6:2607:f8b0:4864:20::1132])
by smtp3.osuosl.org (Postfix) with ESMTPS id BB1A0605D5
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 May 2022 17:17:41 +0000 (UTC)
Received: by mail-yw1-x1132.google.com with SMTP id
00721157ae682-2f7bb893309so88376757b3.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 06 May 2022 10:17:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20210112.gappssmtp.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=jJ9TGk5hnnJYvNuAKalGHpnSSUkb15R2lLvya7fMg0g=;
b=MX0D4SQdaR0R95Aa+gXhGvZvBcV3YvE0OBneGjvc3kYhAH3JTFZOCFF9wuEA75xIah
kZt4yHNAGoxH093WqY7PBY8EoyX/Xx+WLT4hiio6E2OCFa5DuD5UkCZoYoZPQ4T+KaAN
HPs3+lbzn4EgnQs8hhx5G/F5SRPtb/bADRmdjOPaHmp5iLs58Sn2Q3ERDghgINdq4tox
hLiiyzZmzLUib6wFouUevmHuWda18ztWqMM0F5l0JZsEHE/Lk3OQs5wo3NEp/lenL/ox
c3bt3eOJeeChtGtmD/NZW/pa72P+IWqb3ou3gSKIm5UsgwM402foIzzVbwVzGoS/QwsS
DUyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=jJ9TGk5hnnJYvNuAKalGHpnSSUkb15R2lLvya7fMg0g=;
b=nAHui4W+4uipeQHbg7pl3tBeb0p+VLs4PnWlMfJ2B1sPDSW51erv+VloTPd9s5urqp
k8/0P2/5wqgdMUOKB2sjvI82X2STDcWj12TxlgWJmPx9pe2PBLAa5wYK7sPgZsQWhHrp
N/c5jZwJZq8mhmp0ZRij8a0eDQ0HBXKEM0qIQjhu3LVPo2aGKPO+EmEv0PN4Q0GxlDye
aAljP123olhTlfEV1hMb1RJvwTmKgmcjfr9UPSB0RzSc9BX0IY3xN3kjjEhAR0k+vFqT
EhlJXBn0bQ8WfaIRFgNZWyj87zWGvZx+f+/e2jthXkJY/0vYrEpPr+Nc3GBU8iLY2+5o
9KkA==
X-Gm-Message-State: AOAM530kKIBE+DgcGzwa/LlJzXH0SvHPRRUj+5Ttq4CQMn3bcPoAEbRe
CPUAb7Lh0PiRKKlt09htqra+W1hQbf3JzbzCRjgSUw==
X-Google-Smtp-Source: ABdhPJwsflKIYtjsuJZKfFYbrKbLRA08s5T2nqZADvO/wuQibw0y1pcSRVLkGzXpEZfRWDzsmcsRhYU+2SD42HbzCR4=
X-Received: by 2002:a81:6145:0:b0:2f1:7a81:83f with SMTP id
v66-20020a816145000000b002f17a81083fmr3451634ywb.366.1651857460336; Fri, 06
May 2022 10:17:40 -0700 (PDT)
MIME-Version: 1.0
References: <EpwH6R7Ol7S4DZ4r_UcSSMU9RysZiRHFKZ2WkWZatUIeU9YE9avRZ-YIiafnf6I6U4tBbEu5xHa4JwcGh0fxMuyY-fGMwpaesfo5XK6SzLc=@protonmail.com>
<WtHCNGNhHAWBer9QnaWajdbJ341jMHQJa23WAPgNaRldKhopPIN7ry8wNAnmfnlAK6j0m7p3NEgckA6kIjWV5_rFla63Bh6HCfAlLHFODsE=@protonmail.com>
<CABm2gDrQXbS=i8j+Ja5PTgYekyH2X06eTOs8SXP8X-dhTy-hiQ@mail.gmail.com>
<CAMnpzfoLTecKQPmdDv7B=_JKgh1LZr_K5aahZ6JA5CsGbvomkA@mail.gmail.com>
In-Reply-To: <CAMnpzfoLTecKQPmdDv7B=_JKgh1LZr_K5aahZ6JA5CsGbvomkA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Fri, 6 May 2022 19:17:28 +0200
Message-ID: <CABm2gDp6YvV0ZLgW2Mzp8LivMM-KWjAA4ZmV1XO-6R+WuD9zEg@mail.gmail.com>
To: Ryan Grant <bitcoin-dev@rgrant.org>
Content-Type: multipart/alternative; boundary="00000000000024ad9105de5b0978"
X-Mailman-Approved-At: Fri, 06 May 2022 18:01:11 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] What to do when contentious soft fork activations
are attempted
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: Fri, 06 May 2022 17:17:44 -0000
--00000000000024ad9105de5b0978
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Tue, May 3, 2022 at 4:36 PM Ryan Grant <bitcoin-dev@rgrant.org> wrote:
> On Sun, May 1, 2022 at 8:49 PM Jorge Tim=C3=B3n via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> >> [...] Andreas is clueless about BIP 119 and other covenant
> >> proposals. He is spreading misinformation and [...]
>
> > Clueless and spreading disinformation, you say? What
> > misinformation, could you explain?
>
> First, OP_CTV covenants cannot restrict any address that the sender
> does not control. OP_CTV just delivers auditable presigned
> transactions. That's it! OP_CTV's primary design constraint is to
> NOT empower new ways to do blacklists (which are already possible
> using unwanted-multisig). That's not a statement about what Bitcoin
> should ultimately become, but rather what Bitcoin is likely ready for.
> Much like Bitcoin's design, the simplest possible covenant solution
> was chosen, so that it would be "dirt simple" to audit that the code
> does only what it should, and no more.
>
> Andreas used a few words of indecision to make excuses for not
> code-reviewing BIP119 or the pull request, while using a lot of words
> talking about: how dangerous any change is; conservative consensus
> process; and GovCoin blacklists. This gave the strong impression that
> the change was dangerous and could easily lead to the creation of
> blacklists enforced by L1 consensus itself (rather than enforced by
> other signers in a sidechain or unwanted-multisig).
>
> Andreas also didn't look into the reason that the proposed client was
> safe and would not cause a chain split. Speedy Trials by themselves
> don't risk chain splits, they poll. There was no UASF in the planned
> executable. Some devs hate ST because it puts the initiative in
> miner's hands to gauge **user support and readiness** - which those
> devs feel the miners have no reason to be good at - but that expires
> speedily. If everyone loved the change and the trial was about to
> pass, except ornery users - who we love when UASF is needed, of
> course - were going to cause a chain split of their own to block it,
> then ST offers miners the capability to - very quickly, faster than a
> release can be pushed out - change their signaling to again prevent a
> chain split.
>
I don't think that's enough of a reason to justify you calling andreas
"clueless". I'm sure whatever andreas said, he said it with the best
intentions.
Remember:
- Avoid personal attacks
Accusing andreas of being clueless is spreading misinformation.
Russell O'Connor wrote the definitive explanation for how ST arose in
> the consensus process and how it was designed to make everyone
> unhappy. It's a great explanation of what we went through last year.
>
> https://r6.ca/blog/20210615T191422Z.html
>
> "On Building Consensus and Speedy Trial"
>
> on | 2021-06-15T19:14:22Z
> by | Russell O'Connor
>
That's a lot of text, are you sure he said in there he designed speedy
trial to make everyone unhappy?
Well, if we're still talking about it, that proves that it failed at its
own design criterion of failing fast.
But if you think my judgement about speedy trial (sorry, we discussed it
for so long that I forgot the BIP number, it wasn't eight, I remember that)
and I locked my mind in about speedy trial too soon and without giving
anyone a chance to coordinate about my personal signaling of the
proposal...I guess I can give you a grace period of 6 months to upgrade
your own mind about it and accept my judgment about it, so that concern
about my criticism on the proposal is addressed.
There may be a couple of people trying to create dissent about this opinion
of mine. But once all concerns are addressed...
Andreas also didn't look for a non-attack reason for a separate binary
> release. (Here I feel like I should be naming a lot of devs as well,
> hmm.) Let's go back to O'Connor, who reminds us of a faction from the
> last consensus change:
>
> > The "devs-do-not-decide" faction's concern is regarding the
> > appearance of Bitcoin developers deciding the rules of Bitcoin.
> > [...] This faction would be fine with users building their own
> > alternative client for forced activation, or a configuration flag
> > for enabling some kind of forced activation that is not enabled by
> > default.
>
Yeah, I know, both speedy trial and CTV could be perceived as developers
trying to dictate rules.
I guess that criticism against bip8 can be applied from now on to any
proposal forever. what a great precedent.
It's not always that software designers should focus on making everyone
unhappy (like any other kind of designer, I guess), but some times it's
potential perceptions from vaguely defined groups that should be at the
heart of your design decisions.
> Maintainers of the repository and "Big Name" devs have very personal
> reasons to take this stance. Meanwhile, devs who want to form an
> opinion on some given matter but who do not want to do their own code
> reviews typically look to Big Name code reviewers for guidance, in a
> "Consensus Beauty Contest" [note_kbc]. Contrast this with everyone
> who restricts their opinion-formation to their own review of the code;
> they are "Doing Consensus Right", rather than being stuck in the
> Beauty Contest. Now, if a "devs-do-not-decide" dev wrote some code,
> they implicitly reviewed their own code, right? But! If they did not
> write that code, then they **must avoid it** ...in proportion to how
> much it affects consensus. According to this theory of Bitcoin's
> consensus, we would **expect** Big Names to be partly missing from the
> OP_CTV code reviews. This confuses people who are used to playing the
> Consensus Beauty Contest.
>
> [note_kbc:] for another game about what everybody else thinks,
> see Keynesian beauty contest:
> https://en.wikipedia.org/wiki/Keynesian_beauty_contest
>
> (The connection is funny to me because we all have to individually
> play this game when deciding what money is, and in so doing pay a
> last homage to Keynes, during our multi-generational exit from his
> eponymous economics of manipulated interest rates.)
>
> Jimmy Song, in a video best fitting the advocacy referred to by
> Michael (who did not give any specific link), claims that the OP_CTV
> review process is "routing around" some Big Names. Jimmy is seemingly
> unaware that some Big Names are explicitly not participating in
> guiding what Bitcoin's consensus should be, and that some are even
> using strategic ambiguity to do so. With the context above, we have a
> much less nefarious interpretation of motive for releasing a
> binary - one that is part of the consensus process.
>
> https://www.youtube.com/watch?v=3Di5VNiiCYnIg
> "Bitcoin Brief - BIP119, Mexico CBDC & Bitcoin's Role in Russia vs
> Ukraine!"
> on | Apr 25, 2022
>
> (mark 1:13:52.0) Jimmy Song
> (mark 1:18:00.0) "routing around"
>
> An alternative client must, by necessity, offer both its consensus
> feature and its activation. Releasing an alternative client is not a
> decision made from impatience and disrespect. It=E2=80=99s the result of
> asking everyone, getting literal non-responses, and intuiting that the
> landscape has changed, so something on this path must be different
> from last time. While the alternative client route surprised me when
> I heard about it, I cannot say that I personally knew of any other way
> to advance what has clearly been a blocked discussion, and so I did
> not disassociate myself from the effort. People do not understand how
> blocked up consensus is, and no dev has verbalized a better solution
> for maintainers than strategic ambiguity, which is most confusing when
> it is delivering only silence.
>
I don't know about beauty contest or big names.
But if you want to speak in those terms...
If there was a beauty contest for activation proposals and I was part of
the jury, BIP8 would win.
I was once in love with bip9, but, no offense, she is getting old.
And regarding speedy trial, whatever its bip was...sorry, I was trying to
follow your analogy, but some times my instinct tells me not to make
certain jokes about the lord of the rings in certain contexts.
As it turns out, not everyone likes the lord of the rings, or beauty
contests.
> The typical alternative offered by other devs is, "Wait." Well, this
> "Wait" has almost always meant "Never." Take a look at CSFS and APO.
> They've been waiting, but for what? What's the bug that BIP authors
> can't fix? Where's the concrete pull request? Who is going to anoint
> them as done? OP_CTV has made its rite of passage and transcended
> these questions. Its only competition is whether something better can
> be imagined, but those arguments need to explain why learning from a
> good opcode in the meantime is worth waiting years to work through new
> safety concerns. If any of this matters, then timing matters, too.
> OP_CTV is sitting at the front of the bus
>
Speedy covenants (I will write an email explaining the proposal and asking
for a bip number) is I think a superior covenant prooposal in terms of not
waiting. Minor activation details aside, it has been implemented for longer
than OP_CTV, and discussed for longer too.
I know what you're thinking: but that would be a hardfork and necromancy.
No, it wouldn't, well, at least not the hardfork part. Can we undo a
softfork with another softfork?
Well, I don't know if always, but some times, in practice, yes we can.
I will explain how in the coming "speedy covenants".
> Personally, I suspect that the "something better" crowd wants
> recursive covenants, yet recognizes the argument is difficult and
> would have put it off in a sense of misplaced priorities, but we'll
> find out soon. If there were some kind of assurance that could be
> offered, something that would result in a less contentious soft fork,
> instead of stonewalling resistance that makes all soft forks more
> contentious, then a later "epsilon" upgrade to covenants would be
> easier instead of harder. This is because everyone who believes that
> recursive covenants are not a new threat to Bitcoin could argue
> towards a common purpose and resolve that in a binding consensus
> agreement. One such binding mechanism could be parties committing
> matched coins locked under a future opcode, although this would be an
> extreme departure from typical development and incur massive risk to
> the parties if for other reasons phase two of the initiative fails.
> It's too bad the game theory isn't simpler.
>
Let's not allow perfection to be the enemy of the good sutff, or something
like that.
Hopefully speedy covenants will solve all the latest tensions around.
And OP_CTV can always be implemented afterwards if it is more optimal under
some criteria.
Finally, Andreas summarized the conservatism in his position as
> basically, "If you want scripting and contracts, go buy ETH." Which
> is offensive to everyone trying to make bitcoins more protective of
> individual freedom and thus more valuable; whether you're working on
> scaling and privacy, the Lightning Network, Discreet Log Contracts,
> CoinPool covenants, self-custody vault covenants, building out Taproot
> capabilities, or working on other infrastructure. What a clueless
> shitcoiner!
>
> https://www.youtube.com/watch?v=3DvAE5fOZ2Luw
>
> "BIP119, EU regulatory attack, El Salvador, and much more in Q&A
> with aantonop (April 2022)"
>
> on | Apr 24, 2022
> by | aantonop
>
> (mark 30:34.0) "if you want to do smart contracts..."
>
> The path to redemption in the Bitcoin community is to unequivocally
> help Bitcoin.
>
The path to redemption for whom?
> Jeremy wasn't always Bitcoin-only, but his efforts have been sincere
> and he works in the concrete realm where anyone can judge how pure his
> contributions are. Even if OP_CTV is never activated, or if no
> covenant opcode is ever activated, Bitcoin is much more secure due to
> the critical bug fixes that Jeremy has already seen merged just
> planning ahead for a mempool that could handle dependent transactions.
> Bitcoin was never under attack or at risk of harm from Jeremy's
> actions to advance the covenants discussion.
>
> Andreas is welcome to research technical merits better before
> communicating, and to discover how a vision of powerful contract
> covenants - in the most decentralized money that exists - can affect
> people's freedom. In so doing, join us.
>
yeah, jeremy is welcomed to understand bip8 and the analysis behind it.
He just needs to be open minded and not worry about "perceptions" for a few
minutes, so I don't think he will be able to, sadly.
But let's not personally attack andreas for his opinions.
The only reason you don't like bip8 is because you're ignorant about it and
you haven't reviewed it enough.
join bip8, join us. do it for freedom.
Speaking less specifically of ctv, SC or other covenants proposals, but
more generally about covenants...
What are your thoughts on "visacoin" (described on the technical bitcoin
forums) in the context of covenants?
Anyway, I should be working on a covenants proposal older than ctv myself.
Instead of just talking and criticizing what others have done.
You have a point there.
Jappy Janukka
--00000000000024ad9105de5b0978
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 3, 2022 at 4:36 PM Ryan G=
rant <<a href=3D"mailto:bitcoin-dev@rgrant.org">bitcoin-dev@rgrant.org</=
a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On=
Sun, May 1, 2022 at 8:49 PM Jorge Tim=C3=B3n via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br>
> On Sun, May 1, 2022, 09:22 alicexbt via bitcoin-dev <<a href=3D"mai=
lto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@li=
sts.linuxfoundation.org</a>> wrote:<br>
<br>
>> [...] Andreas is clueless about BIP 119 and other covenant<br>
>> proposals.=C2=A0 He is spreading misinformation and [...]<br>
<br>
> Clueless and spreading disinformation, you say?=C2=A0 What<br>
> misinformation, could you explain?<br>
<br>
First, OP_CTV covenants cannot restrict any address that the sender<br>
does not control.=C2=A0 OP_CTV just delivers auditable presigned<br>
transactions.=C2=A0 That's it!=C2=A0 OP_CTV's primary design constr=
aint is to<br>
NOT empower new ways to do blacklists (which are already possible<br>
using unwanted-multisig).=C2=A0 That's not a statement about what Bitco=
in<br>
should ultimately become, but rather what Bitcoin is likely ready for.<br>
Much like Bitcoin's design, the simplest possible covenant solution<br>
was chosen, so that it would be "dirt simple" to audit that the c=
ode<br>
does only what it should, and no more.<br>
<br>
Andreas used a few words of indecision to make excuses for not<br>
code-reviewing BIP119 or the pull request, while using a lot of words<br>
talking about: how dangerous any change is; conservative consensus<br>
process; and GovCoin blacklists.=C2=A0 This gave the strong impression that=
<br>
the change was dangerous and could easily lead to the creation of<br>
blacklists enforced by L1 consensus itself (rather than enforced by<br>
other signers in a sidechain or unwanted-multisig).<br>
<br>
Andreas also didn't look into the reason that the proposed client was<b=
r>
safe and would not cause a chain split.=C2=A0 Speedy Trials by themselves<b=
r>
don't risk chain splits, they poll.=C2=A0 There was no UASF in the plan=
ned<br>
executable.=C2=A0 Some devs hate ST because it puts the initiative in<br>
miner's hands to gauge **user support and readiness** - which those<br>
devs feel the miners have no reason to be good at - but that expires<br>
speedily.=C2=A0 If everyone loved the change and the trial was about to<br>
pass, except ornery users - who we love when UASF is needed, of<br>
course - were going to cause a chain split of their own to block it,<br>
then ST offers miners the capability to - very quickly, faster than a<br>
release can be pushed out - change their signaling to again prevent a<br>
chain split.<br></blockquote><div><br></div><div>I don't think that'=
;s enough of a reason to justify you calling andreas "clueless". =
I'm sure whatever andreas said, he said it with the best intentions.<br=
></div><div>Remember:<br></div><div><br>- Avoid personal attacks</div><div>=
=C2=A0</div><div>Accusing andreas of being clueless is spreading misinforma=
tion.<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex">
Russell O'Connor wrote the definitive explanation for how ST arose in<b=
r>
the consensus process and how it was designed to make everyone<br>
unhappy.=C2=A0 It's a great explanation of what we went through last ye=
ar.<br>
<br>
=C2=A0 <a href=3D"https://r6.ca/blog/20210615T191422Z.html" rel=3D"noreferr=
er" target=3D"_blank">https://r6.ca/blog/20210615T191422Z.html</a><br>
<br>
=C2=A0 =C2=A0 "On Building Consensus and Speedy Trial"<br>
<br>
=C2=A0 =C2=A0 on | 2021-06-15T19:14:22Z<br>
=C2=A0 =C2=A0 by | Russell O'Connor<br></blockquote><div><br></div><div=
>That's a lot of text, are you sure he said in there he designed speedy=
trial to make everyone unhappy?</div><div>Well, if we're still talking=
about it, that proves that it failed at its own design criterion of failin=
g fast.</div><div>But if you think my judgement about speedy trial (sorry, =
we discussed it for so long that I forgot the BIP number, it wasn't eig=
ht, I remember that) and I locked my mind in about speedy trial too soon an=
d without giving anyone a chance to coordinate about my personal signaling =
of the proposal...I guess I can give you a grace period of 6 months to upgr=
ade your own mind about it and accept my judgment about it, so that concern=
about my criticism on the proposal is addressed. <br></div><div>There may =
be a couple of people trying to create dissent about this opinion of mine. =
But once all concerns are addressed...<br></div><div><br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">
Andreas also didn't look for a non-attack reason for a separate binary<=
br>
release.=C2=A0 (Here I feel like I should be naming a lot of devs as well,<=
br>
hmm.)=C2=A0 Let's go back to O'Connor, who reminds us of a faction =
from the<br>
last consensus change:<br>
<br>
=C2=A0 > The "devs-do-not-decide" faction's concern is reg=
arding the<br>
=C2=A0 > appearance of Bitcoin developers deciding the rules of Bitcoin.=
<br>
=C2=A0 > [...]=C2=A0 This faction would be fine with users building thei=
r own<br>
=C2=A0 > alternative client for forced activation, or a configuration fl=
ag<br>
=C2=A0 > for enabling some kind of forced activation that is not enabled=
by<br>
=C2=A0 > default.<br></blockquote><div><br></div><div>Yeah, I know, both=
speedy trial and CTV could be perceived as developers trying to dictate ru=
les. <br></div><div>I guess that criticism against bip8 can be applied from=
now on to any proposal forever. what a great precedent.</div><div>It's=
not always that software designers should focus on making everyone unhappy=
(like any other kind of designer, I guess), but some times it's potent=
ial perceptions from vaguely defined groups that should be at the heart of =
your design decisions.</div><div>=C2=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">
Maintainers of the repository and "Big Name" devs have very perso=
nal<br>
reasons to take this stance.=C2=A0 Meanwhile, devs who want to form an<br>
opinion on some given matter but who do not want to do their own code<br>
reviews typically look to Big Name code reviewers for guidance, in a<br>
"Consensus Beauty Contest" [note_kbc].=C2=A0 Contrast this with e=
veryone<br>
who restricts their opinion-formation to their own review of the code;<br>
they are "Doing Consensus Right", rather than being stuck in the<=
br>
Beauty Contest.=C2=A0 Now, if a "devs-do-not-decide" dev wrote so=
me code,<br>
they implicitly reviewed their own code, right?=C2=A0 But!=C2=A0 If they di=
d not<br>
write that code, then they **must avoid it** ...in proportion to how<br>
much it affects consensus.=C2=A0 According to this theory of Bitcoin's<=
br>
consensus, we would **expect** Big Names to be partly missing from the<br>
OP_CTV code reviews.=C2=A0 This confuses people who are used to playing the=
<br>
Consensus Beauty Contest.<br>
<br>
=C2=A0 [note_kbc:] for another game about what everybody else thinks,<br>
=C2=A0 =C2=A0 see Keynesian beauty contest:<br>
=C2=A0 =C2=A0 =C2=A0 <a href=3D"https://en.wikipedia.org/wiki/Keynesian_bea=
uty_contest" rel=3D"noreferrer" target=3D"_blank">https://en.wikipedia.org/=
wiki/Keynesian_beauty_contest</a><br>
<br>
=C2=A0 =C2=A0 (The connection is funny to me because we all have to individ=
ually<br>
=C2=A0 =C2=A0 play this game when deciding what money is, and in so doing p=
ay a<br>
=C2=A0 =C2=A0 last homage to Keynes, during our multi-generational exit fro=
m his<br>
=C2=A0 =C2=A0 eponymous economics of manipulated interest rates.)<br>
<br>
Jimmy Song, in a video best fitting the advocacy referred to by<br>
Michael (who did not give any specific link), claims that the OP_CTV<br>
review process is "routing around" some Big Names.=C2=A0 Jimmy is=
seemingly<br>
unaware that some Big Names are explicitly not participating in<br>
guiding what Bitcoin's consensus should be, and that some are even<br>
using strategic ambiguity to do so.=C2=A0 With the context above, we have a=
<br>
much less nefarious interpretation of motive for releasing a<br>
binary - one that is part of the consensus process.<br>
<br>
=C2=A0 <a href=3D"https://www.youtube.com/watch?v=3Di5VNiiCYnIg" rel=3D"nor=
eferrer" target=3D"_blank">https://www.youtube.com/watch?v=3Di5VNiiCYnIg</a=
><br>
=C2=A0 =C2=A0 "Bitcoin Brief - BIP119, Mexico CBDC & Bitcoin's=
Role in Russia vs<br>
=C2=A0 =C2=A0 Ukraine!"<br>
=C2=A0 =C2=A0 on | Apr 25, 2022<br>
<br>
=C2=A0 =C2=A0 (mark 1:13:52.0) Jimmy Song<br>
=C2=A0 =C2=A0 (mark 1:18:00.0) "routing around"<br>
<br>
An alternative client must, by necessity, offer both its consensus<br>
feature and its activation.=C2=A0 Releasing an alternative client is not a<=
br>
decision made from impatience and disrespect.=C2=A0 It=E2=80=99s the result=
of<br>
asking everyone, getting literal non-responses, and intuiting that the<br>
landscape has changed, so something on this path must be different<br>
from last time.=C2=A0 While the alternative client route surprised me when<=
br>
I heard about it, I cannot say that I personally knew of any other way<br>
to advance what has clearly been a blocked discussion, and so I did<br>
not disassociate myself from the effort.=C2=A0 People do not understand how=
<br>
blocked up consensus is, and no dev has verbalized a better solution<br>
for maintainers than strategic ambiguity, which is most confusing when<br>
it is delivering only silence.<br></blockquote><div><br></div><div>I don=
9;t know about beauty contest or big names.</div><div>But if you want to sp=
eak in those terms...<br></div><div>If there was a beauty contest for activ=
ation proposals and I was part of the jury, BIP8 would win.</div><div>I was=
once in love with bip9, but, no offense, she is getting old.</div><div>And=
regarding speedy trial, whatever its bip was...sorry, I was trying to foll=
ow your analogy, but some times my instinct tells me not to make certain jo=
kes about the lord of the rings in certain contexts.</div><div>As it turns =
out, not everyone likes the lord of the rings, or beauty contests.</div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The typical alternative offered by other devs is, "Wait."=C2=A0 W=
ell, this<br>
"Wait" has almost always meant "Never."=C2=A0 Take a lo=
ok at CSFS and APO.<br>
They've been waiting, but for what?=C2=A0 What's the bug that BIP a=
uthors<br>
can't fix?=C2=A0 Where's the concrete pull request?=C2=A0 Who is go=
ing to anoint<br>
them as done?=C2=A0 OP_CTV has made its rite of passage and transcended<br>
these questions.=C2=A0 Its only competition is whether something better can=
<br>
be imagined, but those arguments need to explain why learning from a<br>
good opcode in the meantime is worth waiting years to work through new<br>
safety concerns.=C2=A0 If any of this matters, then timing matters, too.<br=
>
OP_CTV is sitting at the front of the bus<br></blockquote><div><br></div><d=
iv>Speedy covenants (I will write an email explaining the proposal and aski=
ng for a bip number) is I think a superior covenant prooposal in terms of n=
ot waiting. Minor activation details aside, it has been implemented for lon=
ger than OP_CTV, and discussed for longer too.</div><div>I know what you=
9;re thinking: but that would be a hardfork and necromancy.</div><div>No, i=
t wouldn't, well, at least not the hardfork part. Can we undo a softfor=
k with another softfork?</div><div>Well, I don't know if always, but so=
me times, in practice, yes we can.</div><div>I will explain how in the comi=
ng "speedy covenants".</div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
Personally, I suspect that the "something better" crowd wants<br>
recursive covenants, yet recognizes the argument is difficult and<br>
would have put it off in a sense of misplaced priorities, but we'll<br>
find out soon.=C2=A0 If there were some kind of assurance that could be<br>
offered, something that would result in a less contentious soft fork,<br>
instead of stonewalling resistance that makes all soft forks more<br>
contentious, then a later "epsilon" upgrade to covenants would be=
<br>
easier instead of harder.=C2=A0 This is because everyone who believes that<=
br>
recursive covenants are not a new threat to Bitcoin could argue<br>
towards a common purpose and resolve that in a binding consensus<br>
agreement.=C2=A0 One such binding mechanism could be parties committing<br>
matched coins locked under a future opcode, although this would be an<br>
extreme departure from typical development and incur massive risk to<br>
the parties if for other reasons phase two of the initiative fails.<br>
It's too bad the game theory isn't simpler.<br></blockquote><div><b=
r></div><div>Let's not allow perfection to be the enemy of the good sut=
ff, or something like that.</div><div>Hopefully speedy covenants will solve=
all the latest tensions around.</div><div>And OP_CTV can always be impleme=
nted afterwards if it is more optimal under some criteria.</div><div><br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
Finally, Andreas summarized the conservatism in his position as<br>
basically, "If you want scripting and contracts, go buy ETH."=C2=
=A0 Which<br>
is offensive to everyone trying to make bitcoins more protective of<br>
individual freedom and thus more valuable; whether you're working on<br=
>
scaling and privacy, the Lightning Network, Discreet Log Contracts,<br>
CoinPool covenants, self-custody vault covenants, building out Taproot<br>
capabilities, or working on other infrastructure.=C2=A0 What a clueless<br>
shitcoiner!<br>
<br>
=C2=A0 <a href=3D"https://www.youtube.com/watch?v=3DvAE5fOZ2Luw" rel=3D"nor=
eferrer" target=3D"_blank">https://www.youtube.com/watch?v=3DvAE5fOZ2Luw</a=
><br>
<br>
=C2=A0 =C2=A0 "BIP119, EU regulatory attack, El Salvador, and much mor=
e in Q&A<br>
=C2=A0 =C2=A0 with aantonop (April 2022)"<br>
<br>
=C2=A0 =C2=A0 on | Apr 24, 2022<br>
=C2=A0 =C2=A0 by | aantonop<br>
<br>
=C2=A0 =C2=A0 (mark 30:34.0) "if you want to do smart contracts...&quo=
t;<br>
<br>
The path to redemption in the Bitcoin community is to unequivocally<br>
help Bitcoin.<br></blockquote></div><div class=3D"gmail_quote"><br></div><d=
iv class=3D"gmail_quote">The path to redemption for whom?</div><div class=
=3D"gmail_quote"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">
Jeremy wasn't always Bitcoin-only, but his efforts have been sincere<br=
>
and he works in the concrete realm where anyone can judge how pure his<br>
contributions are.=C2=A0 Even if OP_CTV is never activated, or if no<br>
covenant opcode is ever activated, Bitcoin is much more secure due to<br>
the critical bug fixes that Jeremy has already seen merged just<br>
planning ahead for a mempool that could handle dependent transactions.<br>
Bitcoin was never under attack or at risk of harm from Jeremy's<br>
actions to advance the covenants discussion.<br>
<br>
Andreas is welcome to research technical merits better before<br>
communicating, and to discover how a vision of powerful contract<br>
covenants - in the most decentralized money that exists - can affect<br>
people's freedom.=C2=A0 In so doing, join us.<br></blockquote><div><br>=
</div><div>yeah, jeremy is welcomed to understand bip8 and the analysis beh=
ind it.</div><div>He just needs to be open minded and not worry about "=
;perceptions" for a few minutes, so I don't think he will be able =
to, sadly.</div><div>But let's not personally attack andreas for his op=
inions.</div><div>The only reason you don't like bip8 is because you=
9;re ignorant about it and you haven't reviewed it enough.<br></div><di=
v>join bip8, join us. do it for freedom.</div><div><br></div><div>Speaking =
less specifically of ctv, SC or other covenants proposals, but more general=
ly about covenants...</div><div>What are your thoughts on "visacoin&qu=
ot; (described on the technical bitcoin forums) in the context of covenants=
?</div><div><br></div><div>Anyway, I should be working on a covenants propo=
sal older than ctv=20
myself. Instead of just talking and criticizing what others have done.</div=
><div>You have a point there.</div><div><br></div><div>Jappy Janukka</div><=
div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><=
div>=C2=A0</div></div></div>
--00000000000024ad9105de5b0978--
|