-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.xml
710 lines (681 loc) · 127 KB
/
index.xml
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
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>yanmaani's blog</title>
<link>https://yanmaani.github.io/</link>
<description>Recent content on yanmaani's blog</description>
<generator>Hugo -- gohugo.io</generator>
<language>en-US</language>
<lastBuildDate>Wed, 02 Mar 2022 12:00:00 +0000</lastBuildDate>
<atom:link href="https://yanmaani.github.io/index.xml" rel="self" type="application/rss+xml" />
<item>
<title>Does Council Regulation (EU) 2022/350 make it illegal to operate a Tor node in the EU?</title>
<link>https://yanmaani.github.io/does-council-regulation-eu-2022/350-make-it-illegal-to-operate-a-tor-node-in-the-eu/</link>
<pubDate>Wed, 02 Mar 2022 12:00:00 +0000</pubDate>
<guid>https://yanmaani.github.io/does-council-regulation-eu-2022/350-make-it-illegal-to-operate-a-tor-node-in-the-eu/</guid>
<description><p><em>Note: I am not a lawyer. I am writing this not because I have any special qualifications, but because I can’t find anything else about this on the Internet.</em></p>
<p>Recently, it was announced that the EU is to “ban RT”. I heard you can’t get it on the TV these days, which seems reasonable enough. But I was pointed to the actual text of law, and it seems like it does a bit more than that.</p>
<p>If you want to follow along, the regulation in question is <a href="https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32022R0350">“Council Regulation (EU) 2022/350 of 1 March 2022 amending Regulation (EU) No 833/2014 concerning restrictive measures in view of Russia’s actions destabilising the situation in Ukraine”</a>.</p>
<p>(This seems like it was hastily written to alter a sanctions law from a few years ago, to just add “broadcasting” as a prohibited activity and “RT” as a prohibited entity. But when you’re dealing with information control, hack jobs are not ideal.)</p>
<p>The purpose of the sanctions are pretty well explained in section 10 of the preamble: (emphasis added)</p>
<blockquote>
<p>In view of the gravity of the situation, and in response to Russia’s actions destabilising the situation in Ukraine, it is necessary, consistent with the fundamental rights and freedoms recognised in the Charter of Fundamental Rights, in particular with the right to freedom of expression and information as recognised in Article 11 thereof, to introduce further <strong>restrictive measures to urgently suspend the broadcasting activities of such media outlets in the Union, or directed at the Union</strong>. These measures should be maintained until the aggression against Ukraine is put to an end, <strong>and until</strong> the Russian Federation, and its associated media outlets, cease to conduct propaganda actions against the Union and its Member States.</p>
</blockquote>
<p>From my understanding, “and until” would mean the sanctions end once (1) the war is over, (2) Ukraine wins, and (3) <em>Russia ceases to conduct propaganda actions against the EU</em>. From what I can see, the law does not describe “propaganda actions” any further.</p>
<p>The actual text of the amendment is quite short, so I will paste it in its entirety below:</p>
<blockquote>
<h2 id="article-1">Article 1</h2>
<p>Regulation (EU) No 833/2014 is amended as follows:</p>
<ol type="1">
<li><p>the following Article is inserted after Article 2e:</p>
<p>‘Article 2f</p>
<ol type="1">
<li><p>It shall be prohibited for operators to broadcast or to enable, facilitate or otherwise contribute to broadcast, any content by the legal persons, entities or bodies listed in Annex XV, including through transmission or distribution by any means such as cable, satellite, IP-TV, internet service providers, internet video-sharing platforms or applications, whether new or pre-installed.</p></li>
<li><p>Any broadcasting licence or authorisation, transmission and distribution arrangement with the legal persons, entities or bodies listed in Annex XV shall be suspended.’;</p></li>
</ol></li>
<li><p>Article 11(1), point (a), is replaced by the following:</p>
<p>‘(a) legal persons, entities or bodies listed in Annex III, IV, V, VI, XII, XIII, XIV or XV, or referred to in point (b) or (c) of Article 5(1), in point (b) or (c) of Article 5(2), in point (c) or (d) of Article 5(3), in point (b) or (c) of Article 5(4), in point (a), (b) or (c) of Article 5a, or in Article 5h;’;</p></li>
<li><p>Article 12 is replaced by the following:</p>
<p>‘Article 12</p>
<p>It shall be prohibited to participate, knowingly and intentionally, in activities the object or effect of which is to circumvent prohibitions in this Regulation including by acting as a substitute for natural or legal persons, entities or bodies referred to in Article 2e(3) or Article 2f, 5, 5a, 5b, 5e, 5f or 5h, or by acting to their benefit by using the exceptions in Article 2e(4), 5(6), 5a(2), 5a(5), 5b(2), 5b(3), 5e(2) or 5f(2).’;</p></li>
<li><p>the text appearing in the Annex to this Regulation is added as Annex XV to Regulation (EU) No 833/2014.</p></li>
</ol>
<h2 id="article-2">Article 2</h2>
<p>This Regulation shall enter into force on the date of its publication in the Official Journal of the European Union.</p>
<p>This Regulation shall be binding in its entirety and directly applicable in all Member States.</p>
<p>Done at Brussels, 1 March 2022.</p>
</blockquote>
<p>In plain English:</p>
<ol type="1">
<li>Article 2f bans “operators” from “broadcasting” or “contributing to broadcast” content by “entities listed in Annex XV” - basically RT and Sputnik News.</li>
<li>Article 2f explicitly bans “internet service providers, internet video-sharing platforms or applications” from doing the same. (This is an order for ISPs to block RT.)</li>
<li>Article 12 makes it prohibited to “circumvent prohibitions in this Regulation”, e.g. get around the ban.</li>
<li>The phrase “knowingly and intentionally” applies to “participat[ion] in activities,” not to “circumvent[ing] prohibitions”.</li>
<li>The ban isn’t just for intentionally unblocking RT, but <em>participating</em> in any activity, <em>the effect of which</em> is to unblock RT.</li>
</ol>
<p>My problem here isn’t mainly with the cable news networks, but that the EU appears to have made it illegal to participate in the Tor project in any way. For example</p>
<ul>
<li>is it legal to run a node?</li>
<li>is it legal to contriibute code?</li>
<li>is it legal to sell hosting services/transit to people who host nodes?</li>
<li>is it legal to peer with ISPs that host nodes?</li>
</ul>
<p>This also appears to apply to VPNs - either apply EU censorship regulations on your end, or the EU will block you.</p>
<p>I sincerely pray that I am wrong, that I am proven as a clickbaiter and as a hoaxster, and that the EU has already provided for this outcome, and that the phrase “internet service provider” means something other than what I think, or that “broadcast” only applies to TV, or something along those lines.</p>
<p>If I am made to “take the L,” I shall update this post.</p>
<h2 id="update">Update</h2>
<p>The Body of European Regulators for Electronic Communications have <a href="https://berec.europa.eu/eng/news_and_publications/whats_new/9340-berec-supports-isps-in-implementing-the-eu-sanctions-to-block-rt-and-sputnik">confirmed</a> that the sanctions also cover ISPs:</p>
<blockquote>
<p>It is BEREC’s understanding that the obligations to block RT and Sputnik are to be read in a broad manner and that all websites belonging to the entities mentioned in the Annex XV of the Regulation are covered <strong>including the provision of access to them by ISPs.</strong></p>
</blockquote>
<p>I can’t see anything on whether this covers VPN providers.</p>
<p>I also had the following strange exchange with the ACM, the telecommunications regulator in the Netherlands:</p>
<p>ACM:</p>
<blockquote>
<p>Dear —,</p>
<p>As for now, the ACM is the competent regulator regarding the Open Internet Regulation, not on the Council Regulation that you refer to. The ACM is not tasked with the implementation of the implementation of the Council Regulation you refer to.</p>
<p>Kind regards,</p>
<p>—</p>
</blockquote>
<p>Me:</p>
<blockquote>
<p>Dear —,</p>
<p>I thank you for your prompt reply.</p>
<p>In that case, would you happen to know who is the competent regulator regarding the implementation of Council Regulation (EU) 2022/350 in the Netherlands? The ACM is the only Dutch member of the BEREC as far as I can see - is there another agency which takes the lead for this? Or is there simply no regulator tasked with the implementation of this Council Regulation in the Netherlands?</p>
<p>Thanks again,<br />
—</p>
</blockquote>
<p>ACM:</p>
<blockquote>
<blockquote>
<p>Or is there simply no regulator tasked with the implementation of this Council Regulation in the Netherlands?</p>
</blockquote>
<p>To my current knowledge, this is indeed the current situation.</p>
<p>Best regards,</p>
<p>—</p>
</blockquote>
<p>It appears that we have, then, a regulation without regulators. Is that how it usually works?</p>
<p>Strangely enough, Anco Scholte ter Horst, managing director of the Dutch ISP Freedom Internet, said in <a href="https://www.volkskrant.nl/nieuws-achtergrond/als-we-het-normaal-gaan-vinden-dat-de-eu-media-kunnen-blokkeren-kan-dat-grote-gevolgen-hebben~bf3a9c94/">an interview with de Volkskrant</a> (in Dutch):</p>
<blockquote>
<p>The Public Prosecution Service has also indicated that they are going to enforce the law, so we have to carry out the blockade. Otherwise they can impose penalty payments, prosecute members of the board or even close down the company.</p>
</blockquote>
<p>…</p>
<blockquote>
<p><strong>You are now considering legal action to have the blockage reversed. Why would this decision be unlawful?</strong></p>
</blockquote>
<blockquote>
<p>First of all, the regulation is unclear and open to multiple interpretations. In the Netherlands it is interpreted in such a way that we also have to block websites, but not in other member states. So this needs to be clarified.</p>
</blockquote>
<p>So it does seem like someone is tasked with doing something, just not the ACM.</p>
<p>Usually, I try not to talk about politics too much on this blog. However, I will say that I <em>fully endorse</em> anyone who goes out there and starts reporting VPN companies to the authorities. If you allow them to implement these laws as long as they decline to enforce them, you will eventually end up with a large corpus of draconian laws that can spring into existence at a moment’s notice.</p>
<p>Or as Alinsky put it:</p>
<blockquote>
<p><strong>Make the enemy live up to its own book of rules.</strong> If the rule is that every letter gets a reply, send 30,000 letters. You can kill them with this because no one can possibly obey all of their own rules. (This is a serious rule. The besieged entity’s very credibility and reputation is at stake, because if activists catch it lying or not living up to its commitments, they can continue to chip away at the damage.)</p>
</blockquote>
<p>For anyone else interested in this, you should probably also watch the <a href="https://berec.europa.eu/eng/events/berec_events_2022_/291-public-debriefing-on-the-outcomes-of-the-50th-berec-ordinary-meetings">Public debriefing on the outcomes of the 50th BEREC ordinary meetings</a> on March 16, 2022. It will be live-streamed and members of the peanut gallery will be allowed to ask questions.</p>
</description>
</item>
<item>
<title>No, Ethereum Name Service is still a clown show</title>
<link>https://yanmaani.github.io/no-ethereum-name-service-is-still-a-clown-show/</link>
<pubDate>Wed, 26 Jan 2022 12:00:00 +0000</pubDate>
<guid>https://yanmaani.github.io/no-ethereum-name-service-is-still-a-clown-show/</guid>
<description><p><em>Note: This post is about the technical design of ENS, i.e. how it’s supposed to work in theory. I do not cover the numerous implementation issues, i.e. how it actually works in practice. That would be an entire other post, but those issues are (at least theoretically) fixable.</em></p>
<p><em>Disclaimer: I am involved with a competing project. Since I am not in the business of shilling cryptocurrencies, I am not going to name it, though it’s not exactly a secret. I was not paid anything to write this article, I just like laughing at clowns on the Internet.</em></p>
<h2 id="what-is-ens">What is ENS?</h2>
<p>ENS (the “Ethereum Name Service”) is a blockchain-based naming service. It markets itself<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a> as a censorship-resistant and decentralized naming system.</p>
<p>Prior to November 10, 2021, this was a direct lie. While promoters continually represented it as being such, in actuality, the entire contract was controlled by a 4-of-7 multisig, who had total power<a href="#fn2" class="footnote-ref" id="fnref2" role="doc-noteref"><sup>2</sup></a> to seize any domain (including for trademark reasons, or because they received a <a href="https://twitter.com/brokep/status/1389314362561777665">forged court order</a>), and which publically announced<a href="#fn3" class="footnote-ref" id="fnref3" role="doc-noteref"><sup>3</sup></a> their intention to do so if it came to it.</p>
<p>Quote:</p>
<blockquote>
<p>PAUL WOUTERS [IETF]: Sure. Paul Wouters, IETF. So I have a question. Let’s say IETF gets the domain IETF in this naming system and we pay our fees for a couple of years. Everybody uses the site. And then at some point, we forget to pay and the domain falls back into the pool and then somebody else registers it and we don’t know where they are or who they are. Now I go to a court system. I get some legal opinion saying I own this trademark and now I want to get this domain back. Is there any way for me to get this domain back?</p>
</blockquote>
<blockquote>
<p>LEONARD TAN [ENS developer]: So right now, the ENS industry, you can change it because it requires four out of seven people. Most of them are Ethereum developers. And it is a consensus for several of them to make any changes. So it is possible, but it is going to be a very difficult thing to do but it is possible.</p>
</blockquote>
<p>On November 10, ENS changed its “governance structure” to a DAO (“Decentralized Autonomous Organization”). The underlying intent was presumably to solve these problems.</p>
<p>This naturally raises the question: are the problems solved? Is ENS now (1) decentralized and (2) censorship-resistant?</p>
<p>TL;DR: (1) depends on your definition, and (2) not by any stretch of the word.</p>
<h2 id="two-ways-to-skin-a-cat">Two ways to skin a cat</h2>
<p>The <a href="https://bitcoin.org/bitcoin.pdf">Bitcoin whitepaper</a> never directly mentions (de)centralization. It does, however, mention “trusted third parties” a great deal. The closest we come to a definition is this: (emphasis added)</p>
<blockquote>
<p>I’ve developed a new open source P2P e-cash system called Bitcoin. <strong>It’s completely decentralized, with no central server or trusted parties, because everything is based on crypto proof instead of trust.</strong> Give it a try, or take a look at the screenshots and design paper: Download Bitcoin v0.1 at <a href="http://www.bitcoin.org" class="uri">http://www.bitcoin.org</a></p>
</blockquote>
<p>…</p>
<blockquote>
<p>Privacy could always be overridden by the admin based on his judgment call weighing the principle of privacy against other concerns, or at the behest of his superiors. Then strong encryption became available to the masses, and trust was no longer required. <strong>Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.</strong></p>
</blockquote>
<p>— Satoshi Nakamoto, <a href="https://p2pfoundation.ning.com/forum/topics/bitcoin-open-source">Bitcoin open source implementation of P2P currency</a></p>
<p>We’ll call this, in want of a better term, “anarchic decentralization”. The power is moved from a <em>monarch</em>, a single point of failure, but it’s moved <em>to</em> nowhere. For example, who owns Bitcoin? Nobody! People may own <em>bitcoins</em>, but even if you had all 21 million of them, it’s not like you could show up at the annual general meeting and demand changes.</p>
<p>Bitcoin is not really a currency with certain rules, but rather a set of rules with a currency attached to it.</p>
<p>In the words of <a href="https://en.wikipedia.org/wiki/Carl_Schmitt">Carl Schmitt</a>, <em>sovereign is he who decides on the exception</em>. But in Bitcoin, there is no trusted third party. There is no decision to be made, and there is never any exception to or reprieve from the rules.</p>
<p>The reason that this is possible is that the rules can be enforced 100% mechanistically. Because a computer can enforce them, no human is needed to. Because no human is needed in the loop, there is no need for a governance procedure, or any of these other squishy institutions - only cold, hard code. <em>Bitcoin is not decentral as much as it is acentral.</em></p>
<figure>
<img src="https://yanmaani.github.io/odysseus_sirens.jpg" title="Ulysses and the Sirens by Herbert James Draper" alt="" /><figcaption>Because Odysseus knew, ex-ante, that he wouldn’t make very good decisions here, he decided to divest himself of decision-making authority, and to place it instead in a simple and logical set of rules. <a href="https://en.wikipedia.org/wiki/Ulysses_and_the_Sirens_(Draper)">Source</a></figcaption>
</figure>
<p>The other type is, shall we call it, oligarchic decentralization. Here, decentralization simply means that there is no <em>single</em> point of failure. This is a much weaker property. Here, we are not concerned with <em>eliminating</em> trusted third parties, but rather in ensuring there’s many of them across which to spread out the trust. A lot of things are “decentralized” in this weaker sense:</p>
<ul>
<li>The <a href="https://en.wikipedia.org/wiki/Society_for_Worldwide_Interbank_Financial_Telecommunication">SWIFT</a> system - made up by more than 11,000 financial institutions</li>
<li>The <a href="https://en.wikipedia.org/wiki/European_Union">European Union</a> - made up of 27 countries</li>
<li><a href="https://en.wikipedia.org/wiki/JPMorgan_Chase">JPMorgan Chase</a> - owned by what is surely millions of shareholders</li>
</ul>
<h2 id="which-one-is-ens">Which one is ENS?</h2>
<p>ENS <em>is</em> decentralized in the sense that multiple people - by all accounts, at least a few hundred - own it. This is a step up from seven keyholders! Congratulations!</p>
<figure>
<img src="https://yanmaani.github.io/ens_allocation.png" title="Community Treasury: 50%; Core Contributors: 18.96%; Airdrop: 25%" alt="" /><figcaption>The treasury can’t vote, and I can’t think the 137k airdropees (unless they sold it, or delegated their votes) will be that bothered to vote. (The 1% minimum quorum seems like a good indication my hunch is correct here.) The implications of this are left as an exercise to the reader. <a href="https://ensdomains.substack.com/p/ens-token-allocation-claiming-opens">Source</a></figcaption>
</figure>
<p>ENS <em>is not</em> decentralized in the sense that there is binding, non-human, trustless enforcement of what <em>you</em> may consider to be desiderata, such as:</p>
<ul>
<li>not seizing people’s names</li>
<li>not jacking up fees on the people’s names once they’ve invested into them (e.g. in terms of infrastructure)</li>
<li>ensuring that insiders don’t get to register names for free (since the fees go back to them)</li>
</ul>
<p>I can actually prove this. I took these examples <em>directly</em> from the “<a href="https://docs.ens.domains/v/governance/ens-dao-constitution">ENS DAO Constitution</a>,” which is a “set of binding rules that determine what governance actions are legitimate for the DAO to take”.</p>
<p>Note here that, when they use words like “binding” and “legitimate,” they do not mean it in the technical sense. Nothing actually <em>prevents</em> a proposal from doing any of those things - that’s why they have their constitution. (If it weren’t technically possible to do something, why would they need to write a rule against it?) Indeed, as long as a proposal gains more than 50% of the votes with a 1% quorum, it can execute abitrary code on behalf of the DAO - even such code that will give anyone dictatorial control over it in perpetuity.</p>
<h2 id="is-it-censorship-resistant-then">Is it censorship-resistant, then?</h2>
<p>ENS <em>is</em> censorship-resistant in the sense that nobody can directly seize your domain.</p>
<p>ENS <em>is not</em> censorship-resistant in the sense that renewal costs are guaranteed to be stable or even consistent. If the people who own the DAO want to, they could crank up the fee for renewing <em>only your</em> name to $1,000,000,000, and then allocate it to whomever they please once it expires.</p>
<p>In other words, if your ownership of a name is prejudicial to the financial interests of the people who own the DAO, you might get a first-hand tour in what property rights <em>actually</em> mean. I’ll assume that they’d vote to clean out child porn<a href="#fn4" class="footnote-ref" id="fnref4" role="doc-noteref"><sup>4</sup></a> - to do otherwise would surely result in disastrous headlines, and presumably cause for the token to drop in price. Likewise for “hate speech”. In the end, you’ll never know until you try it! Maybe it’s safe, maybe it isn’t! Hate to find out!</p>
<p>To put it even more bluntly: You “own” your domain, but you do not <em>own your ownership</em> of that domain. Your property rights exist only within the ENS system, and that system is in turn owned by what, in practice, forms a trusted third party. That system is the <em>real</em> owner of the domain; you merely lease it from them at a price that they are free to set.</p>
<p>It’s also worth noting that when I use the term “owners,” I’m being a bit loose. Actually, anyone (even you, dear reader!) can borrow some ENS and vote with it, for example using a flash loan contract or some more sophisticated system. This would probably allow you to obtain the votes you need for a quorum at little to no cost - if I understand correctly, you could borrow 0.4% of the outstanding supply right now off Uniswap for not more than the cost of the transaction. And if you have some more money, nothing prevents you from simply bribing people to vote for your proposal, except their own self-interest, which can be solved by yet more bribes.</p>
<p>It seems, then, that the strongest motivators any ENS holder would have to not expropriate your domain are:</p>
<ol type="1">
<li>fear of real-world consequences (lawsuit, murder)</li>
<li>concern that the price of the token will drop</li>
<li>altruistic/ideological motivations (pride, honor)</li>
</ol>
<p>It’s worth noting in this context that (2) is limited by two factors:</p>
<ol type="1">
<li>You can always hedge the risk that your token will fall in price on DeFi markets. For example, if you have 100 ENS and want to vote “YES” on a disastrous proposal, you can always just sell 100 ENSUSD futures and be totally indifferent toward the price. Heck, you could sell 200 ENSUSD futures and have an incentive to cause the price to go down, while keeping your right to vote. (Modern joint-stock corporations have bylaws that prohibit you from voting on a company that you’re shorting. This is not possible in crypto, for obvious reasons.)</li>
<li>If the bribe is big enough, the risk that the price will crash is not really important.</li>
</ol>
<p>In other words, the ultimate guarantors of the supposedly “trustless” system are the real-world legal system, as well as people’s good faith, honesty, and reputation.</p>
<p>If you consider this to be censorship-resistant, then ENS is absolutely the token for you!</p>
<section class="footnotes" role="doc-endnotes">
<hr />
<ol>
<li id="fn1" role="doc-endnote"><p><a href="https://ens.domains" class="uri">https://ens.domains</a><a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn2" role="doc-endnote"><p><a href="https://mailarchive.ietf.org/arch/msg/dnsop/-9zBqWpvNBlekGotR211s1mf6tM/" class="uri">https://mailarchive.ietf.org/arch/msg/dnsop/-9zBqWpvNBlekGotR211s1mf6tM/</a><a href="#fnref2" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn3" role="doc-endnote"><p><a href="https://medium.com/the-ethereum-name-service/why-ens-doesnt-create-more-tlds-responsible-citizenship-in-the-global-namespace-7e66658fe2b1" class="uri">https://medium.com/the-ethereum-name-service/why-ens-doesnt-create-more-tlds-responsible-citizenship-in-the-global-namespace-7e66658fe2b1</a> - “Moving forward, we want to be as responsible as we can. This includes possibly seeking to register .ETH through the normal ICANN process” - note that the “normal ICANN process” for gTLD regitration requires compliance with <a href="https://www.wipo.int/amc/en/domains/gtld/">trademark law</a>.<a href="#fnref3" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn4" role="doc-endnote"><p>I’m not saying they’d necessarily be <em>morally</em> in the wrong here. Child abuse is well into <a href="https://en.wikipedia.org/wiki/Hostis_humani_generis">hostis humani generis</a> territory, and I don’t think I’d act any different if I were given the choice. But that’s why I, unlike certain other people, am not in favour of giving to people this kind of power.<a href="#fnref4" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
</ol>
</section>
</description>
</item>
<item>
<title>A modest proposal to fix web search</title>
<link>https://yanmaani.github.io/a-modest-proposal-to-fix-web-search/</link>
<pubDate>Sun, 02 Jan 2022 23:00:00 +0000</pubDate>
<guid>https://yanmaani.github.io/a-modest-proposal-to-fix-web-search/</guid>
<description><p>The problem with search these days is that Google has begun to produce absolute garbage results.</p>
<p>To try it, just search for something simple like “css center element”. On a fresh session of Tor Browser, here’s my top 10 items on Google:</p>
<ol type="1">
<li>(<code>https://www.w3schools.com</code>) CSS Layout - Horizontal &amp; Vertical Align - W3Schools</li>
<li>(<code>https://www.freecodecamp.org</code>) How to Center Anything with CSS - Align a Div, Text, and More</li>
<li>(<code>https://www.w3.org</code>) CSS: centering things - World Wide Web Consortium (W3C)</li>
<li><em>People also ask</em></li>
<li>(<code>https://developer.mozilla.org</code>) Center an element - CSS: Cascading Style Sheets - MDN Web …</li>
<li>(<code>https://stackoverflow.com</code>) How to horizontally center an element - Stack Overflow</li>
<li>(<code>https://blog.hubspot.com</code>) 11 Ways to Center Div or Text in Div in CSS - HubSpot Blog</li>
<li>(<code>https://css-tricks.com</code>) Centering in CSS: A Complete Guide | CSS-Tricks</li>
<li>(<code>https://dev.to</code>) 3 Ways to Center an Element in CSS - DEV Community</li>
<li>(<code>https://blog.logrocket.com</code>) 13 ways to vertically center HTML elements with CSS</li>
</ol>
<p>It gets even worse on harder queries. Bing/DDG is slightly better (MDN is first result and W3 second, but instant answer is unfortunately w3schools), but their image search is still crap. Yandex has great image search for some reason, but their (English?) text search is unimpressive. To see the real horror, try some really high CPC keywords on your phone, and see how the entire first page is just ads.</p>
<p>I presume the reason for this is because they realized they would make more money absolutely whoring out their search engine than trying to give people good results. At a certain point, you reach the end of the growth stage, and all that remains is extracting as much profit as you can from the decaying carcass of your once-great enterprise.</p>
<p>But the root cause of it all is these heavily SEO’d sites, right? It goes something like:</p>
<ol type="1">
<li>Make a shitty site with information (tutorialspoint, cyberciti, etc)</li>
<li>SEO it to hell</li>
<li>Site places above <a href="https://tldr.sh">tldr pages</a>, <a href="https://wiki.archlinux.org/">Arch Wiki</a>, etc</li>
<li>Earn ad revenue</li>
</ol>
<p>So if the root cause is the profit motive, why can’t you just filter out the sites with big profit?</p>
<p>If you load a site in headless Firefox, you can obviously measure how much ads it has. For example, load it once with and once without uBlock, and then compare e.g. loading times. There are also other things:</p>
<ul>
<li>GDPR popups</li>
<li>excessive JavaScript</li>
<li>presence of modal dialogs requesting email</li>
</ul>
<p>Then, you could get a score of how plagued the site it is. Combine this with the ordinary search rankings from e.g. DDG, Bing, YaCy, or whatever, and Bob’s your uncle.</p>
<p>Heck, you don’t even have to make a new search engine. Just make a block list for uBlock that hides links to plagued sites.</p>
<p>I don’t see how this could fall prey to Goodhart’s law. It’s pretty hard to pretend like your site doesn’t run ads, right?</p>
</description>
</item>
<item>
<title>Bitcoin will never be a stable currency</title>
<link>https://yanmaani.github.io/bitcoin-will-never-be-a-stable-currency/</link>
<pubDate>Sat, 11 Dec 2021 12:00:00 +0000</pubDate>
<guid>https://yanmaani.github.io/bitcoin-will-never-be-a-stable-currency/</guid>
<description><p>People are interested in Bitcoin for two reasons:</p>
<ol type="1">
<li>It allows any two willing parties to transact directly with each other without the need for a trusted third party.</li>
<li>It is an inflation-free asset, <em>hard money</em>, which is assured to preserve your purchasing power over time.</li>
</ol>
<p>I think that the first argument is basically sound, and the second one basically not. The psychological problem with Bitcoin being only a payment network, however, is that <em>Bitcoin qua payment network</em> can be objectively measured and compared against other payment networks. And if it can be <em>weighed in the balances</em>, it can be <em>found wanting</em>.</p>
<figure>
<img src="https://yanmaani.github.io/belshazzars_feast.jpg" title="King Belshazzar sees a disembodied hand write the words &quot;מנא מנא תקל ופרסין&quot; on the wall. This interrupts his meal." alt="" /><figcaption>Numbered, numbered, weighed, divided.</figcaption>
</figure>
<p>For this reason, is it psychologically necessary for its most hardcore promoters to find a <em>sui generis</em> rationale for why Bitcoin is unique. Enter, <em>store of value</em>.</p>
<h2 id="bitcoin-is-not-currently-a-stable-currency">Bitcoin is not currently a stable currency</h2>
<p>Does Bitcoin <em>currently</em> help us attain the political goal<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a> of “sound money”? Is Bitcoin <em>currently</em> a currency free of inflation?</p>
<p>De facto, no. Inflation is conventionally defined as prices going up - the same amount of money giving you less purchasing power. Bitcoin does not, evidently, hold a constant amount of purchasing power:</p>
<p><img src="https://yanmaani.github.io/pp_btc.png" title="Graph showing burchasing power of 1 BTC (fluctuating rapidly)" /></p>
<p>The United States dollar does not, strictly speaking, do this either:</p>
<p><img src="https://yanmaani.github.io/pp_usd.png" title="Graph showing burchasing power of 1 USD (sinking slowly)" /></p>
<p>However, the tracking is clearly much more accurate. For the U.S. dollar - I actually calculated this - annual inflation has stayed between 2.30% and 3.08% between 2011 and 2020. For Bitcoin, during the same period, it has ranged between <strong>-98.26% and 312.24%</strong>. This is not, by any definition, stable. If this were a third world country, you would be laughing at it. Thus, we can not honestly say that Bitcoin - to date - has accomplished the goal of being a stable store of value.</p>
<p>There’s two main objections to be made here:</p>
<ol type="1">
<li>The goal is not to preserve purchasing power, but to have a currency with a constant money supply.</li>
<li>Bitcoin will become stable in the future.</li>
</ol>
<p>The first objection is plainly absurd. What do you need a currency with a stable money supply for? Is it needed to have a non-inflationary currency? If so, that’s your real goal, and keeping the money supply stable is merely a means to an end.</p>
<p>If not - if you don’t care about inflation, but are <em>deeply concerned</em> about increases in the money supply, what’s the point? Is there an intrinsic value, detached from all other considerations, in having a currency whose money supply doesn’t budge? What’s going on here? If you know, please send me an e-mail immediately!</p>
<p>But the second objection is more interesting.</p>
<h2 id="bitcoin-can-never-become-a-stable-currency">Bitcoin can never become a stable currency</h2>
<p>People seem to have some notion of Bitcoin becoming stable with increased adoption. They theory is that, at some unspecified point in the future (with “adoption”), people will start pricing goods in Bitcoin. When that happens, Bitcoin will become a “unit of account,” volatility will plummet, and Bitcoin will suddenly be as stable as the dollar or the euro.</p>
<p>Their problem is that you can’t just build a runway and a control tower and wait for the planes to land. You actually have to understand the underlying reason for why the planes decided to land on your island and so on.</p>
<figure>
<img src="https://yanmaani.github.io/cargo_cult.jpg" title="A ceremonial flag raising performed by members of the John Frum cargo cult on Tanna island in Vanuatu." alt="" /><figcaption>…some folks are born, made to raise the flag? (image credit: <a href="https://commons.wikimedia.org/wiki/File:John_Frum_flag_raising.jpg">Charmaine Tham</a>)</figcaption>
</figure>
<h3 id="some-theory">Some theory</h3>
<p>What does it mean for something to be stable? Looking at it from a distance, it’s quite obvious: something is stable if it has a tendency to stay in on place. But let’s look at it up close. What causes this die to be stable? Why doesn’t it just fall over, or start moving to the side?</p>
<figure>
<img src="https://yanmaani.github.io/die.jpg" title="A single, solitary, die." alt="" /><figcaption>I don’t think I’ve ever seen an inanimate object look so sad before in my life. (image credit: <a href="https://commons.wikimedia.org/wiki/File:Dice_(504524747).jpg">Nazir Amin</a>)</figcaption>
</figure>
<p>The question is almost too stupid to even be able to consider it, right? If you tipped it over a little bit to the side, it would fall back down again. This is what’s called a stable equilibrium<a href="#fn2" class="footnote-ref" id="fnref2" role="doc-noteref"><sup>2</sup></a>. And here’s a literal textbook example of a stable equilibrium:</p>
<figure>
<img src="https://yanmaani.github.io/stability.png" title="A ball in a pit with sloped edges. If it&#39;s perturbed to the side, it will fall back down." alt="" /><figcaption>image credit: <a href="https://commons.wikimedia.org/wiki/File:Stable_equilibrium.svg">Urutseg</a></figcaption>
</figure>
<p>To plagiarize <a href="https://en.wikipedia.org/wiki/Mechanical_equilibrium#Potential_energy_stability_test">Wikipedia</a>:</p>
<blockquote>
<p>A system is in mechanical equilibrium at the critical points of the function describing the system’s potential energy. We can locate these points using the fact that the derivative of the function is zero at these points.</p>
</blockquote>
<p>The derivative of a function means the slope of that function. If the derivative of the potential energy (with respect to a change, like pushing the die) is zero, that means the die doesn’t want to go any <em>particular</em> way if I don’t push it. If it’s also at a local maximum, it means things now are the best they can be, and so will want to go back to the way things were if I push it. <a href="#fn3" class="footnote-ref" id="fnref3" role="doc-noteref"><sup>3</sup></a></p>
<h3 id="some-practice">Some practice</h3>
<p>We can trivially extend this to currencies: what would happen if the U.S. dollar crashed by 90% tomorrow, without any underlying change in the economy? Obviously, any goods priced in dollars would instantly become ten times cheaper, causing foreign consumers to buy more American goods<a href="#fn4" class="footnote-ref" id="fnref4" role="doc-noteref"><sup>4</sup></a>, causing an inflow of foreign currency into the American economy. This inflow would strengthen the dollar. It would stop approximately when the dollar reaches its natural exchange rate.<a href="#fn5" class="footnote-ref" id="fnref5" role="doc-noteref"><sup>5</sup></a></p>
<p>In other words, there’s a negative feedback loop. If the price goes down through some exogenous shock, it will go back up again, and vice versa. We can look at this through the lens of the good old <em>supply and demand curve</em>:</p>
<figure>
<img src="https://yanmaani.github.io/supply_demand.png" title="Demand goes down as price goes up. Supply goes up as price goes up. The two intersect in a point marked &quot;equilibrium&quot;." alt="" /><figcaption>image credit: <a href="https://commons.wikimedia.org/wiki/File:Supply-demand-equilibrium.svg">SilverStar at English Wikipedia</a></figcaption>
</figure>
<p>The dollar is <strong>both supply and demand elastic</strong>. The demand for U.S. dollars varies by price as discussed above, but the supply (i.e. the interest rates) is also centrally planned in pursuit of <em>the dual mandate of price stability and maximum sustainable employment</em>.</p>
<h3 id="does-bitcoin-have-an-elastic-supply">Does Bitcoin have an elastic supply?</h3>
<p>Not in the primary market. The money supply is not affected by the current price. A higher price does not cause more Bitcoins to be mined. The money supply equals, regardless of anything else:</p>
<p><math display="block" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><munderover><mo>∑</mo><mrow><mi>n</mi><mo>=</mo><mn>1</mn></mrow><mi>H</mi></munderover><mn>50</mn><mo>*</mo><msup><mn>2</mn><mrow><mo stretchy="false" form="prefix">⌊</mo><mi>n</mi><mi>/</mi><mn>210000</mn><mo stretchy="false" form="postfix">⌋</mo></mrow></msup></mrow><annotation encoding="application/x-tex">\sum_{n=1} ^{H} 50*2^{\lfloor n/210000\rfloor}</annotation></semantics></math></p>
<p>This converges to a finite value, the famous 21 million. Moreover, the current value depends only on the time (i.e. the block height, <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mi>H</mi><annotation encoding="application/x-tex">H</annotation></semantics></math>), and nothing else.</p>
<p>There is also a second-hand market. If I hold Bitcoin, I may be willing to sell at some price, but not some other. If I’m trying to maximize my profits in fiat terms, I want to sell at the highest price I can get. That decision depends on the price, but also on my expectations of the future price. (If I’m trying to maximize my profits in Bitcoin terms, I may still want to buy and sell, if I believe it will decrease temporarily to rise later.)</p>
<h3 id="does-bitcoin-have-an-elastic-demand">Does Bitcoin have an elastic demand?</h3>
<p>No. Nobody has a price-related demand for Bitcoin: <strong>nobody buys 0.00170844 Bitcoin, they buy $100 worth of Bitcoin</strong>.</p>
<p>If the price goes up, that doesn’t actually price anyone out from buying (as we are helpfully reminded, Bitcoin is divisible down to 10^8 <em>satoshi</em>, so you can buy very small amounts indeed), and if it goes down, it doesn’t make a single person any more able to afford Bitcoin. Yes, it makes them able to buy <em>more Bitcoin</em> for the same amount of dollars, and it makes a <em>specific amount</em> of Bitcoin more affordable in dollar terms, but a lower price doesn’t make them buy more Bitcoin in value terms.</p>
<p>I should note that I’m not really making a psychological point here: even if everyone thought of it in terms of <em>buying Bitcoin</em>, their demand would still not be price-sensitive, except inasmuch as they’re buying a constant amount of it in fiat terms, which is the point I’m making.</p>
<p>Furthermore, from what I can determine, people seem to buy Bitcoin on basis of what they think will happen to the price in the future, which they base on news reports and the like.</p>
<p>If this is true, it would suggest that the price of Bitcoin depends <em>only</em> on the expectation of future price. This is basically the Matt Levine theory that <a href="https://www.bloomberg.com/opinion/articles/2021-11-30/omicron-crypto-is-a-bet-on-attention">crypto is a bet on attention</a>.</p>
<p>Anyway, note how this differs from gold:</p>
<ol type="1">
<li>If gold drastically increases in price, previously unviable mines open again.</li>
<li>If gold drastically decreases in price, certain mines will immediately close.</li>
<li>If gold slightly increases in price, less jewelry and electronics will be produced using gold.</li>
<li>If gold slightly decreases in price, more jewelry and electronics will be produced using gold.</li>
</ol>
<p>If Bitcoin would have goods priced in it, none of this would be a problem. Either if enough people started to do it - see below - or if the protocol<a href="#fn6" class="footnote-ref" id="fnref6" role="doc-noteref"><sup>6</sup></a> intrinsically had some way to burn bitcoins in exchange for, let’s say, increased block space. In that case, cheap bitcoins would mean cheap <em>whatever</em>, which would (theoretically) stimulate capital inflows.</p>
<p>But it doesn’t, so it is. With an entirely fixed supply and a totally price-insensiive demand, Bitcoin is at best <em>astable</em>.</p>
<h2 id="what-would-bitcoin-look-like-if-it-were-stable">What would Bitcoin look like, if it were stable?</h2>
<p>It would have a supply and demand curve where the lines crossed at an angle. Since the supply will always be flat, the demand would have to decrease as price goes up.</p>
<p>This is where we come to the “goods being priced in Bitcoin” part. Pricing a good in Bitcoin can mean two things. To quote <a href="https://www.fooledbyrandomness.com/BTC-QF.pdf">Nassim N. Taleb</a>:</p>
<blockquote>
<p>There is a conflation between “accepting bitcoin for payments” and pricing goods in bitcoin. To “price” in bitcoin, bitcoin the price must be fixed, with a conversion into fiat floating, rather than the reverse.</p>
</blockquote>
<p>There’s two ways to skin a cat. You can either sell something for, let’s say, $100, and then convert that into 0.00170844 bitcoins for your website. Or you can sell something for 0.00100000 bitcoins.</p>
<p>In both cases, I’m <em>pricing goods in Bitcoin</em>. But only one of these contributes to the stability of Bitcoin.</p>
<p>If you’re automatically converting prices, then you’re just using Bitcoin as a payment processor. As Bitcoin goes up or down, the sales of your product will not change, because the price will change accordingly. But if your prices are fixed in Bitcoin, you will add it some stability. If Bitcoin is cheap, getting $100 worth of goods for $50 is a steal, so your sales will go up (and money will flow into Bitcoin). If Bitcoin is expensive, getting $100 worth of goods for $200 is an awful deal, so your sales will dry up (and less money will flow into Bitcoin).</p>
<p>If you do this, you are acting as a buyer of last resort. It is worth noting that this is how the United Kingdom lost £3.3 billion on <a href="https://en.wikipedia.org/wiki/Black_Wednesday">Black Wednesday</a>. If you’re spending money to prop up the market, unless you’re richer than the market, you will eventually run out of money before they do.<a href="#fn7" class="footnote-ref" id="fnref7" role="doc-noteref"><sup>7</sup></a> In economics, this is known as the Impossible Trinity, which states that it is impossible to have all three of the following at the same time:</p>
<ol type="1">
<li>fixed foreign exchange rates</li>
<li>independent monetary policy</li>
<li>free movement of capital</li>
</ol>
<p>The explanation is as follows:</p>
<ol type="1">
<li>Without fixed foreign exchange rates, we can alter our exchange rates to conform to the world market</li>
<li>Without independent monetary policy, we can alter our interest rates to concorm to the world market</li>
<li>Without free capital flows, we can uphold a discrepancy between the two</li>
</ol>
<p>In practice, I think Bitcoin is much worse than even third world currencies here. They’ll have some centralized authority making some effort to uphold the currency. But since Bitcoin is <em>trustless</em>, there is no such authority.<a href="#fn8" class="footnote-ref" id="fnref8" role="doc-noteref"><sup>8</sup></a></p>
<p>Even aside that, there is the other problem: there’s almost nobody who holds Bitcoin for mundane reasons<a href="#fn9" class="footnote-ref" id="fnref9" role="doc-noteref"><sup>9</sup></a> in the same way that companies hold checking accounts of U.S. dollars. This would mean precisely all the investment activity, which governs the price, is based on confidence, or expectations of future price.</p>
<p>If that’s true, it suggests Bitcoin is not just astable, but even unstable: if the price goes down, it will go down even more, because of the panic<a href="#fn10" class="footnote-ref" id="fnref10" role="doc-noteref"><sup>10</sup></a>, but if the price goes up, it will go up even more, because of the mania. As Kevin Kallaugher for the Baltimore Sun puts it:</p>
<p><img src="https://yanmaani.github.io/kal_buy_sell.jpg" title="A stylized stock market hype cycle" /></p>
<p><math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>y</mi><mi>″</mi><mo>&lt;</mo><mn>0</mn></mrow><annotation encoding="application/x-tex">y&#39;&#39; &lt; 0</annotation></semantics></math>.</p>
<section class="footnotes" role="doc-endnotes">
<hr />
<ol>
<li id="fn1" role="doc-endnote"><p>I am not implying that such a thing is universally considered to be desirable, but merely that it is a goal held by some.<a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn2" role="doc-endnote"><p>Well, if you tipped it over more than 45° it would fall down the other way. Exactly at 45°, you have what’s called an unstable equilibrium.<a href="#fnref2" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn3" role="doc-endnote"><p>If it’s at a local minimum, it means literally anything is better and so it’s unstable. If it’s neither, it means it doesn’t care as to which.<a href="#fnref3" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn4" role="doc-endnote"><p>This is also why states want to manipulate their currency to be weak.<a href="#fnref4" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn5" role="doc-endnote"><p>Which would, ceteris paribus, be whatever it used to be.<a href="#fnref5" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn6" role="doc-endnote"><p>This is not intended as an endorsement of any other cryptocurrencies which may have such a monetary policy.<a href="#fnref6" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn7" role="doc-endnote"><p>For this reason, the theory that big banks’ market making desks will voluntarily do this also strikes me as somewhat unlikely. Why would a bank stand willing to buy Bitcoin at some arbitrary price point but not at some other in the absence of an arbitrage condition? First of all, they don’t like to lose money, secondly, they’re all long volatility.<a href="#fnref7" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn8" role="doc-endnote"><p>Other than Tether, maybe.<a href="#fnref8" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn9" role="doc-endnote"><p>No, Michael Saylor of MicroStrategy fame is everything but mundane.<a href="#fnref9" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn10" role="doc-endnote"><p>The recent event<a href="https://www.coindesk.com/markets/2021/12/04/bitcoin-drops-9k-in-an-hour/">(1)</a> <a href="https://davidgerard.co.uk/blockchain/2021/12/04/news-square-goes-block-wikipedia-nft-el-salvador-bitcoin-city-plans-where-the-chinese-mining-rigs-went/">(2)</a> on December 4 when a market sell of 1,500 BTC caused 4,000 BTC worth of liquidations, in turn causing a broader loss of confidence in the currency, may be illustrative.<a href="#fnref10" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
</ol>
</section>
</description>
</item>
<item>
<title>Proof of stake is a scam and the people promoting it are scammers</title>
<link>https://yanmaani.github.io/proof-of-stake-is-a-scam-and-the-people-promoting-it-are-scammers/</link>
<pubDate>Tue, 09 Nov 2021 12:00:00 +0000</pubDate>
<guid>https://yanmaani.github.io/proof-of-stake-is-a-scam-and-the-people-promoting-it-are-scammers/</guid>
<description><p><em>This article has been <a href="https://www.21ideas.org/theory-protocol-pos-is-a-scam/">translated into Russian</a> by the 21ideas/21идея project.</em></p>
<p>Proof of stake is a scam. When I say that, I mean that proof of stake is (1) claimed to be a consensus system, and (2) constitutionally incapable of actually producing a consensus.</p>
<p>To understand why this is the case, we must first study how proof of work works, to be able to see why proof of stake is not an adequate drop-in replacement for it.</p>
<h2 id="how-proof-of-work-works">How Proof of Work works</h2>
<p>Way back in the day, before Bitcoin was created, you had a lot of people trying to create “digital cash”.</p>
<p>They had identified - correctly - that digital signatures were a part of what was needed, but that only got them so far as to reducing the Digital Cash Problem to the Double-Spending Problem. For data can be copied endlessly, and a signature is not guaranteed to be the only one made with that key.</p>
<p>In 2008, Satoshi Nakamoto came along. He proposed solving the problem by introducing a new component known as “proof of work,” lifted from <a href="http://www.hashcash.org/papers/hashcash.pdf">an obscure e-mail spam filtering technique</a>.</p>
<p>The idea is to have a method to burn electricity in a provable way. The electricity used does not directly produce anything of value, except for a proof that (approximately) this amount of electricity was consumed by this or that node.</p>
<p>The specific method is as follows:<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a></p>
<ol type="1">
<li>All nodes can generate lottery tickets.</li>
<li>These lottery tickets are cryptographically tied to their decisions on which transactions they approve.</li>
<li>“Scratching” the lottery ticket requires a certain amount of processing power.</li>
<li>Because of the design of the algorithms used, there is no way to mathematically reveal the lottery ticket, except through scratching it.</li>
<li>The rarity of lottery tickets that are accepted is determined by the network.</li>
<li>If a node can present a lottery ticket of rarity one-in-a-million, the network can conclude the node did about a million lottery tickets’ worth of work, on average.</li>
<li>The network gives digital currency to nodes that present a winning lottery ticket.</li>
<li>Because the lottery tickets are tied to decisions on approving transactions, a node that approves bad transactions will not be able to collect its reward. (More technically, other nodes will not consider its “coinbase transaction” - the transaction in which the reward is paid out - to be a valid one, and so will not build any lottery tickets on top of it)</li>
<li>If a node does this, it will still have spent the real-world cost associated with scratching these tickets (“mining”), such as electricity, but without getting any reward to show for it.</li>
<li>To keep things stable, the network increases the scarcity of winning lottery tickets - the “difficulty” - if people are winning too much. For example: if there currently takes, on average, 10 billion lottery tickets for a single winner, and twenty winners are found in the time it should take to find ten, the difficulty will be increased up to one in twenty billion. (The network tries to target a rate of one winner per ten minutes - if the production is too high, the difficulty goes up, and if the production is too low, the difficulty goes down)</li>
</ol>
<p>However, this is not the whole story. Proof of work is a vital part of the machine, but it is not the machine. For that, we have to go deeper.</p>
<h2 id="the-origins-of-digital-currency">The origins of digital currency</h2>
<blockquote>
<p>Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending.</p>
</blockquote>
<p>—Satoshi Nakamoto, <a href="https://bitcoin.org/bitcoin.pdf">bitcoin.pdf</a></p>
<p>If you have a file on a computer, despite what NFT promoters believe, it is not possible to prevent people from copying it. If that file is your digital currency, this causes a problem. If people can effectively CTRL-C CTRL-V your currency, you do not meaningfully have a currency.<a href="#fn2" class="footnote-ref" id="fnref2" role="doc-noteref"><sup>2</sup></a></p>
<p>A first step to solving this problem was to do “sending” differently. Instead of directly sending a computer file, users would send digital currency to other people by signing it over with a digital signature. This was a huge step forward, but not all the way. The problem that remained was the dreaded double-spending problem.</p>
<p>Basically: if I have $1 worth of digital currency, nothing can prevent me from trying to send that same $1 to two people, thus turning $1 into $2. Unless they can both compare their incoming transactions to see they’re being had, there’s no way to solve this.</p>
<p>(For what it’s worth, there is a <em>partial</em> solution in pure cryptography. Some digital signature schemes cause for the signing key to leak if you try to sign two different things with the same key. However, the method for reconstructing the key is by doing a mathematical calculation over the two signatures. For that to happen, the two signatures have to be collected in one place by one person.)</p>
<p>Before Bitcoin, people had been trying to solve this problem for decades. <a href="https://en.wikipedia.org/wiki/DigiCash">DigiCash</a> was proposed by David Chaum in 1989, and it did solve the problem, but at a cost. All transactions would go through a server called the “mint” (albeit in an encrypted format), and this server would, since it would have a complete list of all transactions, be able to check for double spends.</p>
<p>In 2007, then, the state of the art was basically a choice: a centralized system without double-spending, or a decentralized system with. Since a currency system with double-spending is no currency system at all, this effectively meant that all digital currency systems had to be centralized.</p>
<p>Satoshi Nakamoto, the inventor of Bitcoin, had like four big ideas:</p>
<ol type="1">
<li>If you require that all transactions have to go in a ledger, you can (by definition) ignore the transactions that are not in this ledger. This means that you only have to care about double-spending within this ledger.</li>
<li>If you have two conflicting transactions within a ledger, the correct choice is always to go with the one that was published first.</li>
<li>If you had what’s called a “timestamp server,” you could use this to figure out which transaction came first.</li>
<li>We can build such a timestamp server by relying on proof of work, as outlined above.</li>
</ol>
<p>In more detail: using my node’s local clock, I can check that new blocks coming in (“lottery tickets,” in my analogy) state the time correctly. If I then have a series of blocks (a “block chain”), I can enforce - on threat of refusing to accept them, thus making their money worthless - that these timestamps be accurate, i.e. consistent to my (local) clock.</p>
<p>At this point, I really feel as if I must apologize to my reader for describing this fairly mundane process in such excruciating detail. But it truly is necessary. To understand why a nice mechanical watch is superior to a decent Chinese<a href="#fn3" class="footnote-ref" id="fnref3" role="doc-noteref"><sup>3</sup></a> copy, it isn’t enough to look at the marketing materials, the glossy brochures, and then finish by taking a cursory look at the case (“looks about the same, three hands and a dial”) and observing that it seems to keep time well enough. We have to actually open it up and see what’s inside.</p>
<figure>
<img src="https://yanmaani.github.io/yazole.jpg" title="A cheap &quot;YAZOLE&quot;-brand aviator-style watch" alt="" /><figcaption>For $2, it’s probably decent value.</figcaption>
</figure>
<p>The key points to take away from this are:</p>
<ol type="1">
<li>The entire purpose of the system is to keep time accurately. Time is very, very important here. This <em>cannot</em> be stressed enough.</li>
<li>Proof of work is a vital part of the system, but it is not the system. There are other parts of it as well. And if you want to replace one part with another, it has to be basically the same part. Not only that, but it has to be machined to the same or better tolerances.</li>
</ol>
<p>Is proof of stake basically the same part? Is proof of stake machined to the same tolerances?</p>
<h2 id="how-proof-of-stake-works-in-theory">How Proof of Stake works, in theory</h2>
<p>The basic idea of proof of stake is fairly simple:</p>
<ol type="1">
<li>Instead of buying mining equipment for $1000, nodes can lock up $1000 of cryptocurrency worth (“staking”)</li>
<li>Instead of indicating which blocks are valuable by mining on top of them, they can just vote for them on the network, and sign this with a digital signature</li>
<li>Instead of having the block that had the most<a href="#fn4" class="footnote-ref" id="fnref4" role="doc-noteref"><sup>4</sup></a> mining done on it win, the block that had the most votes will win</li>
<li>If nodes misbehave, instead of losing their rewards from the day’s work, they will literally lose their entire stake - as if their entire mining rig farm burned down in a proof of work system.</li>
</ol>
<p>Promoters will then argue that, because these incentives are equal or superior to those of proof of work (this is true), it is also an equally strong or superior system to proof of work (this is a lie). Their problem is that it is not sufficient to write a wish list of incentives, because they also have to create the system that puts them in place.</p>
<p>To use an analogy, it is as if someone would sit down to design a building in the following way: first, they draw how they would like for the exterior to look. Then, they draw how they would like for the interior to look. They make basic measurements, to confirm that the interior does not exceed the exterior in terms of dimensions. They then suggest that the house is plausible, and send it off to the construction workers to build.</p>
<p>Of course, they are missing the most important part: the structural system of beams and load-bearing walls that ensures the building continues being a building! Our heroes have to lay out, in practice, how their system would work, and this is where the fun starts.</p>
<h2 id="the-nothing-at-stake-problem">The Nothing at Stake problem</h2>
<p>In PoW, nodes that misbehave are punished. The system that causes them to be punished is this: they have spent electricity. If they do not get their money back in cryptocurrency, they make a loss. Only if the system makes the active decision to reward them will they recoup their sunk cost.</p>
<p>In this way, the punishment for misbehaviour - having to pay for electricity without a reward - is assured. Because of the laws of physics, turning energy into heat increases entropy, and the arrow of time is irreversible. Once it happened, it’s a done deal. <strong>A node cannot un-mine a block and get their electricity back.</strong></p>
<p>Proof of stake does not intrinsically have the same system. Just as the double-spending problem, anyone with a digital key can sign anything they want with no repercussions. They therefore have to build a similar, synthetic, incentive structure.</p>
<p>Here’s where the problem starts: because their punishment is synthetic, it exists inside of the system. Because the punishment exists inside of the system, it can only impinge on that which the system has control over - in this case, the nodes’ security deposits. Therefore, once they have withdrawn their deposits, they are untouchable. This is the “nothing at stake” problem. There will inevitably come a point when a node is free to liquidate their entire stake and cash out. At that point, the network has a problem:</p>
<ol type="1">
<li>That key is valid to sign any number of versions of, let’s say, block #200, and there is no objective, system-internal standard for which version is legitimate, other than “the one that was published first”.</li>
<li>The node can sign whatever it wants with that key with no consequences. There is no way to punish it, because it has <em>nothing at stake</em>.<a href="#fn5" class="footnote-ref" id="fnref5" role="doc-noteref"><sup>5</sup></a></li>
</ol>
<p>Virtually all systems attempt to solve this problem in the same way:</p>
<ol type="1">
<li>If a node signs another version of the same block within a reasonably short time period, “slash” their deposits (e.g. punish them inside of the system)</li>
<li>If a node signs another version of the same block, like, a year later, just ignore it.</li>
</ol>
<p>Here’s your problem: <em>how do you know which version was first?</em> If you were there from the start and saw it first hand, it’s easy. But what if you just installed it, and your node is trying to sync? What happens if you’re presented with two identical blocks, and have to decide which one to pick?</p>
<p>The entire point of the consensus mechanism was to allow us to tell which transaction was first, without personally having seen it take place. That’s why you solve the decentralized timestamp problem - so you can solve the transaction ordering problem, so you can solve the double-spending problem.</p>
<p>In this case, it seems as if our alleged consensus mechanism suffers from a double-signing problem. Fortunately, it solves this problem by solving the decentralized block timestamp problem, so it can solve the block ordering problem.</p>
<p>Hahaha, just kidding. It doesn’t actually do that last part. You’ll need <a href="https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/">some other method</a> to figure that out:</p>
<blockquote>
<p>Because of all the arguments above, we can safely conclude that this threat of an attacker building up a fork from arbitrarily long range is unfortunately fundamental, and in all non-degenerate implementations the issue is fatal to a proof of stake algorithm’s success in the proof of work security model. However, we can get around this fundamental barrier with a slight, but nevertheless fundamental, change in the security model.</p>
</blockquote>
<p>—Vitalik Buterin, saying the quiet part out loud</p>
<p>In other words: <em>if measured under the same threat model as proof of work, proof of stake is fundamentally (and fatally!) insecure</em>. This is admitted, even by its chief boosters. Only if we <del>downgrade to a weaker</del> make a “slight, but nevertheless fundamental change” to the security model can it be called “secure”.</p>
<h2 id="some-questions">Some questions</h2>
<p>If there is a fundamental security flaw in a scheme, that can only be “alleviated” by lowering the standards it is measured against, is that scheme “secure”?</p>
<p>If advocates of this supposedly secure scheme know about this, but neglect to tell anyone - in public, that is, not in obscure blog posts - are they committing fraud, malpractice, or merely lying by omission?</p>
<p>If supposedly credible people were aware of this fraud, but neglected to tell those who placed their faith in them about it, how should that reflect on their credibility, and the credibility of those who, in turn, endorsed them?</p>
<blockquote>
<p>But if the watchman see the sword come, and blow not the trumpet, and the people be not warned; if the sword come, and take any person from among them, he is taken away in his iniquity; but his blood will I require at the watchman’s hand.</p>
</blockquote>
<h2 id="the-man-behind-the-curtain">The man behind the curtain</h2>
<p>What can we conclude from this?</p>
<ol type="1">
<li>Since proof of stake can not alone reach a consensus, it is not a consensus mechanism.</li>
<li>If it still has a working system, there has to be a real consensus mechanism (e.g. not proof of stake) behind it.</li>
</ol>
<p>Indeed, I’m not making this up:</p>
<blockquote>
<p>This security assumption, the idea of “getting a block hash from a friend”, may seem unrigorous to many; Bitcoin developers often make the point that if the solution to long-range attacks is some alternative deciding mechanism X, then the security of the blockchain ultimately depends on X, and so the algorithm is in reality no more secure than using X directly - implying that most X, including our social-consensus-driven approach, are insecure.</p>
<p>However, this logic ignores why consensus algorithms exist in the first place. … Weak subjectivity is exactly the correct solution.</p>
</blockquote>
<p>—Vitalik Buterin, not denying the claim he’s attempting to refute</p>
<p>There are, to my knowledge, three such <em>mechanisms X</em> proposed for the <em>actual consensus</em>:</p>
<ol type="1">
<li>Local consensus. This means that every node has their own view of what’s going on. This is, indeed, very decentralized. Unfortunately, it lacks the property of consensus, since every node has their own idea of what’s going on. Case study: <a href="https://blog.bitmex.com/bitcoin-cash-abcs-rolling-10-block-checkpoints/">Bitcoin Cash ABC</a>.</li>
<li>Proof of authority. In plain English, this means that you have a trusted authority that signs the blocks. It’s a very effective method to get a consensus, and one which doesn’t even pretend to be decentralized. Case study: Peercoin.</li>
<li>“Phone-a-friend consensus”. A mythical animal that’s very vaguely specified, but surely both decentralized and an effective consensus mechanism.</li>
</ol>
<p>Obviously, nobody wants either of the first two - decentralized consensus is the name of the game, but getting either in isolation is incredibly easy. So let’s study this “phone-a-friend consensus” - hereinafter PFC - in more detail. More specifically, what do we do when it breaks?</p>
<p>In PoW, we needn’t worry about “the network” being wrong about anything. As long as we’re decently connected, and verifying everything, we know we’re on the right track. We are assured that everyone else will eventually fall in line. Since they’re running the same software, how could they not?</p>
<p>In PFC, however, we adopt a postmodern view of truth. What happens if I saw with my own eyes that block 200A was first, but “the network” thinks block 200B was first? Do I go on reddit and try to convince them? What if they won’t listen? What if the platforms of discourse are censored?</p>
<p>More importantly - what happens if “the community” believes one thing, but the big guys with the money believe another? Now, in theory, both of these attacks seem extremely far-fetched, but what about the real world? Two data points:</p>
<ul>
<li>In 2017, Bitcoin had a contentious and infected debate about what to do with the 1 MB block size limit. During this debate, advocates of the “big block” side found themselves <a href="https://medium.com/@johnblocke/a-brief-and-incomplete-history-of-censorship-in-r-bitcoin-c85a290fe43">banned from /r/bitcoin</a>. In the end, the “small block” side won.<a href="#fn6" class="footnote-ref" id="fnref6" role="doc-noteref"><sup>6</sup></a> Did the bans play a part in this?</li>
<li>In Ethereum, after the <a href="https://davidgerard.co.uk/blockchain/the-dao/">The DAO debacle</a>, the Ethereum foundation decided to do a hardfork to bail the investors out. In the end, Ethereum prevailed and Ethereum Classic (the non-hardfork coin) became consigned to irrelevancy.</li>
</ul>
<p>It seems, then, that in a “community-based consensus”, there’s about four relevant actors. <em>The same thing clearly cannot act or be acted upon in the same part or in relation to the same thing at the same time, in contrary ways; and <strong>therefore whenever this contradiction occurs in things apparently the same, we know that they are really not the same, but different.</strong></em> (emphasis added). They are:</p>
<ol type="1">
<li>The big guys with money and power.</li>
<li>The people who own the discussion platforms.</li>
<li>The broad masses of people.</li>
<li>You.</li>
</ol>
<p>Now, what happens if either of these actors disagree with the other? Let’s study it:</p>
<ol type="1">
<li>Against any of these other groups of people, your opinion is not realistically going to matter.</li>
<li>If the broad masses of people disagree with the platform landlord, their opinion will be altered to conform with the rules, or else they will no longer have a voice.</li>
<li>If the people who actually run the project disagree with the people running their platform, that platform will lose the vaunted “endorsement” status.</li>
<li>If the people running the project disagree with the community, the community has the choice of forking off - losing all of the institutional capital and whatever else, like in Ethereum - or getting back in line.</li>
</ol>
<p>In practice, then, “community consensus” is just an obfuscated and convoluted version of “proof of authority”. And as Mr. Buterin knows from first-hand experience, “the security of the blockchain ultimately depends on X”.</p>
<h2 id="if-it-doesnt-work-then-how-come-it-works">If it doesn’t work, then how come it works?</h2>
<p>We’ve already established that a system that works the way the promoters suggest it does is literally impossible. A system, then, that actually works, must sacrifice one of three things - either it isn’t proof-of-stake (e.g. concealed proof of work), it isn’t decentralized, or it doesn’t have a consensus.</p>
<p>In practice, however, there often isn’t a bright line between these things. If the same people own all the tokens, control all of the staking pools, the project governance, and run all the full nodes, an attack isn’t even possible. It’s so centralized, it produces the impression of decentralization from a distance.</p>
<p>Think of it the CAP theorem: In the presence of a partition, you have to make the choice between consistency and availability, but in the absence of one, you get both and don’t even have to choose. If all of the people with the technical means of doing an attack are the owners’ cronies, the ship keeps on floating. Or as <a href="https://davidgerard.co.uk/blockchain/2018/05/13/ethereum-casper-only-has-to-work-well-enough-worse-is-better-in-action/">David Gerard puts it</a>:</p>
<blockquote>
<p>The market doesn’t care about the Bitcoin ideology behind decentralisation. … The market treats centrally administered ICO tokens, and centrally-controlled cryptocurrencies like Ripple (XRP), as the same class of object as Bitcoins or ether. The market wants what it wants, not what ideologues want it to want. …</p>
</blockquote>
<blockquote>
<p>As long as:</p>
<ul>
<li>the network remains secure enough to function at all</li>
<li>the price of ether doesn’t crash</li>
<li>the ICO tokens keep pumping and dumping</li>
<li>the latest <a href="https://davidgerard.co.uk/blockchain/2018/04/21/news-14000-cryptokitties-to-kill-ethereum-history-of-earn-coms-pitato-ransomware-cryptographers-on-cryptocurrency/">CryptoKitties</a> doesn’t clog it too badly</li>
<li>and it doesn’t have any disasters that are more expensive than the ones the current system has, like The DAO or the <a href="https://davidgerard.co.uk/blockchain/2017/11/08/the-ethereum-parity-wallet-disaster-play-by-play/">Parity wallet disaster</a></li>
</ul>
<p>— then Casper will be a <em>good enough</em> proof-of-stake that the community can live with it.</p>
<p>Casper doesn’t have to work well enough for the ideologues — it just has to work well enough for the market.</p>
</blockquote>
<h2 id="the-paper-moderated-ink-cooled-reactor">The paper-moderated, ink-cooled reactor</h2>
<p>It’s not hard to see why people are taken in by this. Proof of work promises them, in principle, a bad<a href="#fn7" class="footnote-ref" id="fnref7" role="doc-noteref"><sup>7</sup></a> system that produces a certain result, through methods that are plainly inscrutable to an average reader. Proof of stake promises them a good system, which produces the same result, through methods that are about equally inscrutable.</p>
<p>The people promoting this are either unaware of the security properties of the technology they’re promoting, in which case they are clowns (whose endorsements of technology you cannot trust), or they are aware (but neglecting to tell you), in which case they are scammers (whose endorsements of technology you <em>definitely</em> cannot trust).</p>
<p>In either case, the fact that an individual promotes proof of stake, or takes seriously those who do, ought to be enough to disqualify them from being considered authorities on any matter ever again. The fact that this is not done, and overt scammers are enthusiastically rehabilitated, is a damning indictment of the alleged “cryptocurrency community”.</p>
<h2 id="is-there-any-replacement-for-proof-of-work">Is there any replacement for proof of work?</h2>
<p>I don’t know if we will ever replace proof of work. Probably, in ten years they might have something. To fit the security model of Bitcoin, it must have the following desiderata:</p>
<ol type="1">
<li>Costly - mining a block must create a sunk cost roughly equivalent to the block reward</li>
<li>Irreversible - these costs must arise in the real-world, from processes that are not cheaply reversible in the short term</li>
<li>Self-certifying - it must be possible to validate solely within computer software, without reference to anything else</li>
</ol>
<p>PoW has all three, but at some cost.</p>
<p>PoS has one of these, barely - it fails on the other two (irreversibility and being self-certifying)</p>
<p>Proof of space seems like it could work, but only if the date stored is useless, thus <a href="https://blog.dshr.org/2021/07/alternatives-to-proof-of-work.html">moving</a> the <a href="https://davidgerard.co.uk/blockchain/2021/05/22/news-everybody-hates-chia-defi100-rugpull-china-versus-mining-china-versus-crypto/">waste</a><a href="#fn8" class="footnote-ref" id="fnref8" role="doc-noteref"><sup>8</sup></a> from electricity to electronics. I’m not endorsing Chia’s specific implementation here, though.</p>
<p>Perhaps there is a small glimmer of hope in combining proof of work and proof of stake. That way, you could replace some of the mining with staking. I don’t really know, but that’s my hunch. I do know one thing, though: when it comes to promises about the future made by cryptocurrency promoters, don’t believe it until you see it.</p>
<p>What makes people buy into their cryptocurrency isn’t actual technological advances that have already happened, it’s promises of what’s yet to come. In fact, their best incentive is to perpetually keep the moon on the horizon, so as to helpfully inform the would-be bagholders they’re getting in on the ground floor.</p>
<p>Cynical people will observe that this is also how most cryptocurrency projects actually operate - not only is it more profitable, it’s also cheaper. They’re not strictly lying when they say you’re getting in on the ground floor, only when they imply that there will ever be a second one built.</p>
<section class="footnotes" role="doc-endnotes">
<hr />
<ol>
<li id="fn1" role="doc-endnote"><p>This is, believe it or not, a simplification.<a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn2" role="doc-endnote"><p>I’m not trying to make some type of hardcore anti-inflation argument here. All I’m saying is that you can’t have a currency based on taking whatever paper you happen to have on you and writing the largest number you can come up with.<a href="#fnref2" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn3" role="doc-endnote"><p>There’s nothing wrong with Chinese horology, there’s many quality Chinese watch brands, and many of the “Western” brands have production there too. I am not suggesting that all East Asian products are low quality, just that (virtually) all low quality products are made in East Asia. (The objection could be made that all products of any kind are made in East Asia.)<a href="#fnref3" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn4" role="doc-endnote"><p>Probabilistically, that is.<a href="#fnref4" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn5" role="doc-endnote"><p>Sometimes, people redefine “nothing at stake” to refer to something else, and call this the long-range attack instead.<a href="#fnref5" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn6" role="doc-endnote"><p>I’m not endorsing either side in this conflict here, all I’m saying is that platforms have power.<a href="#fnref6" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn7" role="doc-endnote"><p>In terms of wasting energy, for example. As a consensus system, it’s excellent.<a href="#fnref7" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn8" role="doc-endnote"><p>That’s not to say wasting $100 of hard drive isn’t slightly preferable to wasting $100 of electricity, though.<a href="#fnref8" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
</ol>
</section>
</description>
</item>
<item>
<title>Perfect forward secrecy in PGP with time-based ratcheting</title>
<link>https://yanmaani.github.io/perfect-forward-secrecy-in-pgp-with-time-based-ratcheting/</link>
<pubDate>Fri, 05 Nov 2021 12:00:00 +0000</pubDate>
<guid>https://yanmaani.github.io/perfect-forward-secrecy-in-pgp-with-time-based-ratcheting/</guid>
<description><p><em>Standard disclaimer: This is probably a bad idea in some way, and I am almost certainly not the first one to come up with it. However, I do not have any kind of training in cryptography, and so I would not know how or by whom.</em></p>
<p>Update 2021-11-09: <a href="https://github.com/stealth/opmsg">opmsg</a> seems like it does some of what I want with the deniable signatures, and does stateful ratcheting in a semi-interesting way. I haven’t looked into it much, but at least it clearly disproves my point that nobody is trying to innovate.</p>
<p>PGP is an encryption software from the 1990s. Like many other things from that time period, it has <a href="https://latacora.micro.blog/2019/07/16/the-pgp-problem.html">various problems</a> and serious cryptography people <a href="https://blog.filippo.io/giving-up-on-long-term-pgp/">do not like</a> it. However, they <a href="https://latacora.micro.blog/2020/02/19/stop-using-encrypted.html">do not like anything that has anything to do with e-mail</a>, and so they are not going to invent anything better:</p>
<blockquote>
<p>Encrypting email is asking for a calamity. Recommending email encryption to at-risk users is malpractice. Anyone who tells you it’s secure to communicate over PGP-encrypted email is putting their weird preferences ahead of your safety.</p>
</blockquote>
<p>The logical result of this situation is that we are stuck with a terrible piece of software that nobody actually likes, because it is ugly, but that nobody wants to replace, because the replacement would also be ugly.</p>
<p>The root cause of the problem is that PGP is <em>stateless</em>. To encrypt a message to someone, I need only their public key. To sign them, I need only my private key. This is opposed to something like <a href="https://signal.org/docs/specifications/doubleratchet/">Signal</a>, where I need a smart external third-party server and lots of state, or <a href="https://otr.cypherpunks.ca/otr-wpes.pdf">OTR</a>, where I have to be on-line at the same time as my conversation partner and exchange keys with them and stuff.</p>
<p>The pros of this approach? In PGP, I can just touch and go, no need for handshakes.<br />
The cons of this approach? In PGP, I can just touch and go, no need for handshakes.</p>
<p>Astute observers will notice this as a textbook example of the so-called “New Jersey style,” also known as “<a href="https://dreamsongs.com/RiseOfWorseIsBetter.html">Worse Is Better</a>”: <em>it is often undesirable to go for the right thing first. It is better to get half of the right thing available so that it spreads like a virus. Once people are hooked on it, take the time to improve it to 90% of the right thing.</em></p>
<p>In PGP’s case, they neglected to do the second half, and this is where the fun starts.</p>
<h2 id="perfect-forward-secrecy">Perfect forward secrecy</h2>
<p>Let’s picture the simplest possible way to do e-mail encryption: each e-mail address has a public key associated to it. To send an e-mail to someone, you encrypt it with their public key. If you want to prove you sent it, you also sign it with your private key.</p>
<p>Since PGP does things in the simplest way imaginable<a href="#fn1" class="footnote-ref" id="fnref1" role="doc-noteref"><sup>1</sup></a>, you are currently picturing PGP.</p>
<p>The downside of this system is that anyone who obtains their private key can decrypt the message, and anyone who has a copy of the message can see it’s signed.</p>
<p>Naively, this would maybe not seem like a terrible problem. We expect secret keys to remain secret. If they don’t, that is outside of the threat model. And surely the purpose of a signature is to verify who sent the message?</p>
<p>The devil is in the details: the secret keys are supposed to stay secret, but for how long? If someone is monitoring your e-mail and taking copies of all your (encrypted) messages, you’re deleting all your e-mails after two weeks, and your key is compromised, what happens?</p>
<ol type="A">
<li>The messages of the last two weeks are compromised<br />
</li>
<li>All the messages I have sent with that key, ever, are compromised</li>
<li>None of the messages are compromised</li>
</ol>
<p>You guessed it. The answer is, of course, B.</p>
<p>This problem is further compounded by the lack of <em>deniability</em>. When the e-mails inevitably leak, there will be a cryptographic record that links the sender to his e-mail.</p>
<p>So, the PGP developers foresaw this problem. And being ardent adherents of <em>simple and robust</em> design philosophies (after all, it got them to where they are now), they applied the principle of “it is more important for the implementation to be simple than the interface”. If it causes problems when old keys are compromised, users will either have to make sure that never happens or rotate them every now and then. And so PGP was built with this assumption in mind, and users who fail to rotate their keys are <em>outside the threat model</em>.</p>
<p>In practice, what happens is people forget to rotate their keys. Even when they don’t, they’ll still keep the old ones around “for good measure”. And whenever their key gets compromised, that’s that.</p>
<p>So how would a good encryption system work? One that follows the “MIT style”, and writes genuinely good software, that sacrifices simplicity for correctness? Let’s take a look at a hypothetical protocol<a href="#fn2" class="footnote-ref" id="fnref2" role="doc-noteref"><sup>2</sup></a> which actually would be secure:</p>
<ol type="1">
<li>Obtain your interlocutor’s public key.</li>
<li>Send them your public key.</li>
<li>Use their public key and your private key to generate a <em>shared secret</em>. Because of the nature of <a href="https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange">the algorithm</a> that is used, the shared secret will be the same whether generated with their private key and your public key, or with their public key and your private key (that’s why it’s shared and that’s why it’s secret).</li>
<li>Generate an “ephemeral” (temporary) key pair based on random data.</li>
<li>Sign its public key with a <a href="https://en.wikipedia.org/wiki/Message_authentication_code">message authentication code</a>, using the shared secret you derived in step 3. Basically, calculate signature = SHA-256(ephemeral public key || shared secret)<a href="#fn3" class="footnote-ref" id="fnref3" role="doc-noteref"><sup>3</sup></a> and send ephemeral public key + signature over the wire.</li>
<li>Receive their signed ephemeral public key in the same way.</li>
<li>Generate a new shared secret using those two, and use this<a href="#fn4" class="footnote-ref" id="fnref4" role="doc-noteref"><sup>4</sup></a> to communicate using <a href="https://en.wikipedia.org/wiki/Authenticated_encryption">authenticated encryption</a>.</li>
<li>Every now and then, generate a new ephemeral keypair and throw away the old one.</li>
</ol>
<p>The magic happens in step four. Since our master keys - the keys from step 1-2 - are only ever used for signatures, they can be totally compromised after the fact, without loss of privacy. Even if he has them, all he can do is use them to sign ephemeral keys. But he can’t go back in time and actually make us use those keys. The keys that we used to actually encrypt the material have already been discarded. In this way, we have <a href="https://en.wikipedia.org/wiki/Forward_secrecy">forward secrecy</a>: <em>session keys will not be compromised even if long-term secrets used in the session key exchange are compromised</em>.</p>
<p>Now, if PGP users did rotate their keys every three months or whatever happens to be the latest guidance, they, too, would enjoy this. The problem is that nobody ever does. For one, that would require them to change their key, which would require them to redistribute it again, and key exchange is always the weak point.</p>
<p>There is also another interesting property here, <a href="https://en.wikipedia.org/wiki/Deniable_authentication">deniable (“repudiable”) authentication</a>. During the conversation, all the messages are authenticated, and a third party can’t forge messages so they look like my interlocutor sent them. However, if my interlocutor is logging the conversation to leak it to the press afterwards, there’s no signatures there that actually binds me to the conversation.</p>
<p>How is this accomplished? Simple - messages are signed with the shared secret. During the conversation, I obviously know which messages I’m sending and which ones I amn’t. But for someone looking at the transcript afterwards, he only knows they were signed by one of the two.</p>
<p>Actually, it is possible to accomplish this in PGP too. First, use a separate key for signatures. Second, post its <em>private key</em> online after you’re done. The problem is that nobody actually does this, because it would - if nothing else - require them to do key rotation.</p>
<h2 id="the-proposal-deniable-signatures">The proposal: deniable signatures</h2>
<p>If I’m sending something to someone and signing it with my key, I actually already have everything I need for a deniable signature. I’ll take their public key and my private key, compute a shared secret, and then use this to compute a MAC over the whole message. If a third party then gets ahold of this MAC, one of two things will be true:</p>
<ol type="1">
<li>They do not have either private key, in which case they will not be able to verify anything.</li>
<li>They have at least one private key, in which case they can forge any signature they want.</li>
</ol>
<p>Replacing old PGP signatures with this would actually be very easy. Since nobody checks them anyway, you could just replace them all tomorrow and nobody would notice. Whoever did want to verify signatures could just install a version of PGP with support for them. Because they’ve already bolted on so much crap, another half-baked encryption scheme would hardly even be noticed.</p>
<figure>
<img src="https://yanmaani.github.io/1181.png" title="If you want to be extra safe, check that there&#39;s a big block of jumbled characters at the bottom." alt="" /><figcaption><a href="https://xkcd.com/1181/">Source</a></figcaption>
</figure>
<p>Another advantage of these signatures is that they would be considerably shorter. HMAC-SHA256 produces “signatures” of 32 bytes. Here’s what that would look like when encoded in base64:</p>
<pre><code>-----BEGIN PGP SIGNATURE-----
47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
-----END PGP SIGNATURE-----</code></pre>
<p>The downside of this is that it would require PGP users to standardize on a single public key format. Oh, the horrors!</p>
<h2 id="the-proposal-forward-secrecy">The proposal: forward secrecy</h2>
<p>Now, if you’re a <em>nice</em> protocol, there’s a simple way you can get forward secrecy. <a href="https://www.signal.org/blog/advanced-ratcheting/">Ratcheting</a>. Each message, you take your old key, you hash it, and now you have a new key. Because hashes are irreversible - you can’t turn the hamburger back into a cow - the compromise of the new key doesn’t lead to the compromise of the old key. That way, you have forward secrecy. (You do not have “backward secrecy”, because the old key still leads to the new key.)</p>
<p>This system basically resembles <a href="https://en.wikipedia.org/wiki/HMAC-based_one-time_password">HOTP</a>. You have a common counter which is synchronized, and then the HMAC over our secret key and the counter is used to generate an authentication key. The problem with this is that it isn’t stateless. For PGP-like systems, we can’t really keep a synchronized counter like that. So what can we do?</p>
<p>Well, there’s one thing that we still have access to, without any advanced synchronization. <strong>Time.</strong> That’s why everyone switched to the much simpler <a href="https://en.wikipedia.org/wiki/Time-based_One-Time_Password">TOTP</a> protocol instead. Instead of using a counter, it just uses your clock. As long as your clock is somewhat accurate, you can agree on the same number as the device without needing to coordinate anything.</p>
<p>TOTP, however, doesn’t have forward secrecy. For that, we need to look at an even older protocol, <a href="https://en.wikipedia.org/wiki/S/KEY">S/KEY</a>. Here’s how S/KEY works:</p>
<ol type="1">
<li>Take your password, <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mi>W</mi><annotation encoding="application/x-tex">W</annotation></semantics></math>.</li>
<li>Let <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msup><mi>H</mi><mi>n</mi></msup><mo stretchy="false" form="prefix">(</mo><mi>W</mi><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">H^n(W)</annotation></semantics></math> denote a hash chain <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mi>n</mi><annotation encoding="application/x-tex">n</annotation></semantics></math> times, e.g. <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msup><mi>H</mi><mn>3</mn></msup><mo stretchy="false" form="prefix">(</mo><mi>W</mi><mo stretchy="false" form="postfix">)</mo><mo>=</mo><mi>H</mi><mo stretchy="false" form="prefix">(</mo><mi>H</mi><mo stretchy="false" form="prefix">(</mo><mi>H</mi><mo stretchy="false" form="prefix">(</mo><mi>W</mi><mo stretchy="false" form="postfix">)</mo><mo stretchy="false" form="postfix">)</mo><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">H^3(W) = H(H(H(W)))</annotation></semantics></math> - “hash W thrice”.</li>
<li>Keep a synchronized counter between the server and the client. Initiate it at, say, <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>n</mi><mo>=</mo><mn>1000</mn></mrow><annotation encoding="application/x-tex">n = 1000</annotation></semantics></math>.</li>
<li>Store on the server <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>P</mi><mo>=</mo><msup><mi>H</mi><mi>n</mi></msup><mo stretchy="false" form="prefix">(</mo><mi>W</mi><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">P = H^n(W)</annotation></semantics></math>.</li>
<li>To log in the first time, calculate <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>p</mi><mo>=</mo><msup><mi>H</mi><mn>999</mn></msup><mo stretchy="false" form="prefix">(</mo><mi>W</mi><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">p = H^999(W)</annotation></semantics></math> and send this to the server. The server checks that <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>H</mi><mo stretchy="false" form="prefix">(</mo><mi>p</mi><mo stretchy="false" form="postfix">)</mo><mo>=</mo><mi>P</mi></mrow><annotation encoding="application/x-tex">H(p) = P</annotation></semantics></math>, i.e. that <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>H</mi><mo stretchy="false" form="prefix">(</mo><msup><mi>H</mi><mn>999</mn></msup><mo stretchy="false" form="prefix">(</mo><mi>W</mi><mo stretchy="false" form="postfix">)</mo><mo stretchy="false" form="postfix">)</mo><mo>=</mo><msup><mi>H</mi><mn>1000</mn></msup><mo stretchy="false" form="prefix">(</mo><mi>W</mi><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">H(H^999(W)) = H^1000(W)</annotation></semantics></math>. If so, the login was successful, both parties decrement W by 1, and the server replaces <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mi>P</mi><annotation encoding="application/x-tex">P</annotation></semantics></math> with the succesful <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mi>p</mi><annotation encoding="application/x-tex">p</annotation></semantics></math>. Note that the server doesn’t actually know what <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mi>p</mi><annotation encoding="application/x-tex">p</annotation></semantics></math> is supposed to be in advance.</li>
<li>The next time, the client has to calculate <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>p</mi><mo>=</mo><msup><mi>H</mi><mn>998</mn></msup><mo stretchy="false" form="prefix">(</mo><mi>W</mi><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">p = H^998(W)</annotation></semantics></math> instead. Note that, even though no encryption is used, an attacker can’t glean any useful information from monitoring the connection - after it’s been used to log in once, <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msup><mi>H</mi><mn>999</mn></msup><mo stretchy="false" form="prefix">(</mo><mi>W</mi><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">H^999(W)</annotation></semantics></math> no longer grants you any access.</li>
</ol>
<p>My<a href="#fn5" class="footnote-ref" id="fnref5" role="doc-noteref"><sup>5</sup></a> idea, then, is that we basically do this for keys, but using the time instead of a synchronized counter. All we need is a hash function<a href="#fn6" class="footnote-ref" id="fnref6" role="doc-noteref"><sup>6</sup></a> that works on keys. Ideally, it would have these properties (k is a private key and K is its corresponding public key):</p>
<ol start="0" type="1">
<li>There exists <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>N</mi><mo stretchy="false" form="prefix">(</mo><mi>k</mi><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">N(k)</annotation></semantics></math> such that <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>N</mi><mo stretchy="false" form="prefix">(</mo><mi>k</mi><mo stretchy="false" form="postfix">)</mo><mo>=</mo><mi>K</mi></mrow><annotation encoding="application/x-tex">N(k) = K</annotation></semantics></math> (e.g. <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><mi>N</mi><mo stretchy="false" form="prefix">(</mo><mi>k</mi><mo stretchy="false" form="postfix">)</mo><mo>=</mo><mi>k</mi><mi>G</mi><mo>=</mo><mi>K</mi></mrow><annotation encoding="application/x-tex">N(k) = kG = K</annotation></semantics></math> for ECC), but no <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msub><mi>f</mi><mi>x</mi></msub><mo stretchy="false" form="prefix">(</mo><mi>K</mi><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">f_x(K)</annotation></semantics></math> such that <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msub><mi>f</mi><mi>x</mi></msub><mo stretchy="false" form="prefix">(</mo><mi>K</mi><mo stretchy="false" form="postfix">)</mo><mo>=</mo><mi>k</mi></mrow><annotation encoding="application/x-tex">f_x(K) = k</annotation></semantics></math>.</li>
<li>There exists <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msub><mi>f</mi><mn>1</mn></msub><mo stretchy="false" form="prefix">(</mo><mi>k</mi><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">f_1(k)</annotation></semantics></math> such that <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msub><mi>f</mi><mn>1</mn></msub><mo stretchy="false" form="prefix">(</mo><msub><mi>k</mi><mi>i</mi></msub><mo stretchy="false" form="postfix">)</mo><mo>=</mo><msub><mi>f</mi><mn>1</mn></msub><mo stretchy="false" form="prefix">(</mo><msub><mi>k</mi><mrow><mi>i</mi><mo>+</mo><mn>1</mn></mrow></msub><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">f_1(k_i) = f_1(k_{i+1})</annotation></semantics></math></li>
<li>There exists <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msub><mi>f</mi><mn>2</mn></msub><mo stretchy="false" form="prefix">(</mo><mi>K</mi><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">f_2(K)</annotation></semantics></math> such that <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msub><mi>f</mi><mn>2</mn></msub><mo stretchy="false" form="prefix">(</mo><msub><mi>K</mi><mi>i</mi></msub><mo stretchy="false" form="postfix">)</mo><mo>=</mo><msub><mi>f</mi><mn>2</mn></msub><mo stretchy="false" form="prefix">(</mo><msub><mi>K</mi><mrow><mi>i</mi><mo>+</mo><mn>1</mn></mrow></msub><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">f_2(K_i) = f_2(K_{i+1})</annotation></semantics></math></li>
<li>There <strong>does not</strong> exist <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msub><mi>f</mi><mn>3</mn></msub><mo stretchy="false" form="prefix">(</mo><mi>k</mi><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">f_3(k)</annotation></semantics></math> such that <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msub><mi>f</mi><mn>3</mn></msub><mo stretchy="false" form="prefix">(</mo><msub><mi>k</mi><mi>i</mi></msub><mo stretchy="false" form="postfix">)</mo><mo>=</mo><msub><mi>f</mi><mn>3</mn></msub><mo stretchy="false" form="prefix">(</mo><msub><mi>k</mi><mrow><mi>i</mi><mo>−</mo><mn>1</mn></mrow></msub><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">f_3(k_i) = f_3(k_{i-1})</annotation></semantics></math></li>
<li>There <strong>does not</strong> exist <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msub><mi>f</mi><mn>4</mn></msub><mo stretchy="false" form="prefix">(</mo><mi>K</mi><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">f_4(K)</annotation></semantics></math> such that <math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msub><mi>f</mi><mn>4</mn></msub><mo stretchy="false" form="prefix">(</mo><msub><mi>K</mi><mi>i</mi></msub><mo stretchy="false" form="postfix">)</mo><mo>=</mo><msub><mi>f</mi><mn>4</mn></msub><mo stretchy="false" form="prefix">(</mo><msub><mi>K</mi><mrow><mi>i</mi><mo>−</mo><mn>1</mn></mrow></msub><mo stretchy="false" form="postfix">)</mo></mrow><annotation encoding="application/x-tex">f_4(K_i) = f_4(K_{i-1})</annotation></semantics></math></li>
<li><math display="inline" xmlns="http://www.w3.org/1998/Math/MathML"><semantics><mrow><msub><mi>f</mi><mn>0</mn></msub><mo stretchy="false" form="prefix">(</mo><msub><mi>f</mi><mn>1</mn></msub><mo stretchy="false" form="prefix">(</mo><msub><mi>k</mi><mi>i</mi></msub><mo stretchy="false" form="postfix">)</mo><mo stretchy="false" form="postfix">)</mo><mo>=</mo><msub><mi>f</mi><mn>2</mn></msub><mo stretchy="false" form="prefix">(</mo><msub><mi>K</mi><mi>i</mi></msub><mo stretchy="false" form="postfix">)</mo><mo>=</mo><msub><mi>K</mi><mrow><mi>i</mi><mo>+</mo><mn>1</mn></mrow></msub></mrow><annotation encoding="application/x-tex">f_0(f_1(k_i)) = f_2(K_i) = K_{i+1}</annotation></semantics></math></li>
</ol>
<p>Unfortunately, I can’t find any protocols that both have properties 2 and 5.<a href="#fn7" class="footnote-ref" id="fnref7" role="doc-noteref"><sup>7</sup></a> If you know one, please contact me! However, if we accept that third parties won’t be able to derive our public keys, we can steal a protocol used by Bitcoin. <a href="#fn8" class="footnote-ref" id="fnref8" role="doc-noteref"><sup>8</sup></a></p>
<p>That protocol is <a href="https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Child_key_derivation_CKD_functions">BIP32</a>, and it tells us exactly how to do this. The specific protocol we are going to be ripping off is “hardened child key derivation”. Since I am not at all competent or licensed in this, I am just going to use it without attempting to improve or optimize it in any way.</p>
<p>With this knowledge in hand, we can use a private key to generate a new private key. After a certain interval, we will delete the old one. This enables us to do automatic key rotation/ratcheting, without having to keep anything synchronized with anyone.</p>
<h2 id="could-this-be-integrated-into-pgp">Could this be integrated into PGP?</h2>
<p>Theoretically, yes. You’d just do “normal” key rotation and upload the chain of signatures to a PGP server.</p>
<h2 id="would-this-be-a-panacea">Would this be a panacea?</h2>
<p>No, OTR is still better. If an old private key of ours is leaked today, that enabled an adversary to decrypt all conversations after that point. But in OTR, even if you have their key, you still have to carry out the actual MITM attack. To see why this is superior, study the following timeline:</p>
<ol type="1">
<li>2020-01-01: Key is generated.</li>
<li>2020-06-01: Private key is stored in some backup, somewhere.</li>
<li>2021-06-01: Backup service hacked, private key revealed.</li>
</ol>
<p>Under OTR, an <em>active</em> adversary can decrypt all communications after <em>June 1, 2021</em> - the moment they got the key. Under “slightly less shitty PGP”, a <em>passive</em> adversary can decrypt all communications after <em>June 1, 2020</em> - the age of the key that was leaked.</p>
<p>I am not sure what this property is called, but it seems pretty important! If you know, please leave a comment or send me an e-mail!</p>
<p>Since this protocol is still bad, nobody is going to make it. Mainly because it would be aesthetically unpleasing and nobody wants to work with aesthetically unpleasing software, but also because <em>modern software</em> can’t ship with such security flaws. <em>Old software</em>, like PGP, is grandfathered in, to the chagrin of expert cryptographers around the world. But only something with the rough security level, such that it is, of PGP, is simple enough to actually work for e-mail encryption.</p>
<p>We are thus stuck with a terrible piece of software that nobody actually likes, because it is ugly, but that nobody wants to replace, because the replacement would also be ugly.</p>
<h2 id="addendum">Addendum</h2>
<p>As a proof of concept, I wrote a <a href="https://yanmaani.github.io/ratchet_secp256k1.py">Python script</a> to actually do this key ratcheting. While it’s a mostly faithful implementation of BIP32, it has a home-rolled replacement for the chain code functionality, because implementing that properly would require a new storage format.</p>
<p>If that were implemented, you should be able to leak old signing keys with impunity, because there is additional material being used in the deriveation. At some point, I imagine <a href="https://www.gwern.net/Self-decrypting-files">time-lock encryption</a> will actually become viable. With that, you would be able to rig it up to automatically leak old signing keys.</p>
<p>This is released into the public domain, with even less warranty than the usual “NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE”. Seriously, you really should not use this for anything.</p>
<p>Usage:</p>
<pre><code>$ openssl ecparam -name secp256k1 -genkey -out sk.pem
$ ./ratchet_secp256k1.py sk.pem &lt;itercount&gt;
-----BEGIN EC PRIVATE KEY-----
***
-----END EC PRIVATE KEY-----</code></pre>
<section class="footnotes" role="doc-endnotes">
<hr />
<ol>
<li id="fn1" role="doc-endnote"><p>Not simple in the way that you would want it, but simple in the way that they would want it. That is to say, it was a simple and elegant design at one point in the 1990s.<a href="#fnref1" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn2" role="doc-endnote"><p>I would have used OTR, but it’s <a href="https://otr.cypherpunks.ca/Protocol-v2-3.1.0.html">slightly more complicated</a> - basically, you do step 1, then steps 4 and 6, then step 7, and then step 2-3, and then finally step 5, but in reverse - sign the shared secret from step 7 with the shared secret from step 3. In this way, you first set up an encrypted channel with ephemeral keys, and then verify the long-term keys.<a href="#fnref2" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn3" role="doc-endnote"><p>In a serious protocol, I think you would generate a new, random key, and then only use the shared secret once, to sign and and encrypt that key using authenticated encryption.<a href="#fnref3" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn4" role="doc-endnote"><p>In practice, there’s some padding and stuff going on too, but we can disregard it in this example. Also, a MAC is not technically a signature.<a href="#fnref4" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn5" role="doc-endnote"><p>This is a lie.<a href="#fnref5" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn6" role="doc-endnote"><p>Technically, a one-way function.<a href="#fnref6" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn7" role="doc-endnote"><p><a href="https://www.cs.ucdavis.edu/~franklin/ecs228/2007/ijsn_survey_final.pdf">This paper</a> seems like it does what I want, at least from a quick glance.<a href="#fnref7" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
<li id="fn8" role="doc-endnote"><p>It’s still better than PGP :^)<a href="#fnref8" class="footnote-back" role="doc-backlink">↩︎</a></p></li>
</ol>
</section>
</description>
</item>
</channel>
</rss>