Simplifying Bitcoin Addresses DNS – Bitcoin Magazine

Simplifying Bitcoin Addresses DNS – Bitcoin Magazine

Dies ist eine redaktionelle Stellungnahme von Mark Jeftovic, Mitbegründer und CEO von easyDNS Technologies Inc. und Autor von „Managing Mission Critical Domains and DNS“.

Von dem Moment an, als ich Bitcoin im Jahr 2013 entdeckte, wusste ich, dass es irgendwann eine Möglichkeit geben würde, Wallet-Adressen mit menschenlesbaren Etiketten zu referenzieren.

Das große Problem mit den langen Adressen von Bitcoin ist, dass sie nicht einprägsam sind, und trotz der pseudonymen oder anonymen Merkmale von Bitcoin möchten Sie oft einfach behaupten oder verifizieren können, dass eine Wallet-Adresse zu einer bestimmten Entität gehört – denken Sie Spenden an eine Wohltätigkeitsorganisation oder einen Crowdfund. Dies betrifft jede Blockchain.

Als DNS-Typ (Domain Name System) habe ich diesen Film schon einmal gesehen: DNS wurde erfunden, um das gleiche Problem mit der IPv4-Adressierung zu lösen. Im Laufe der Zeit hat sich DNS zu viel mehr entwickelt – DNS hat nicht nur die Fähigkeit hinzugefügt, IPv6-Adressen aufzulösen, sondern wird auch zunehmend verwendet, um Metadaten über einen Namespace zu übermitteln. Denken Sie an SRV-Einträge, NAPTRs, RBL-Blocklisten, Reaktionsrichtlinienzonen (RPZs) und den allgegenwärtigen TXT-Eintrag (der für SPF, DMARC, DKIM und alles andere verwendet wird, das nicht nativ zum Protokoll passt).

Da kommt Bitcoin und wir haben das gleiche Problem, schreiben Sie groß.

Das spezifische Problem von Bitcoin und Lightning

Es sieht so aus, als würde ein Großteil der Zahlungstransaktionsaktivitäten mit Protokollen wie Lightning und zuletzt mit dem Aufkommen der Lightning Address auf Layer 2 verlagert.

Lightning-Adressen basieren auf dem LNURL-Pay-Protokoll und sehen ziemlich wie eine E-Mail-Adresse aus:

über: https://github.com/andrerfneves/lightning-address/blob/master/README.md

Die Nomenklatur von E-Mail-Adressen ist der perfekte Weg, um Identitätsinformationen zu übermitteln. Es grenzt Organisationen leicht ab und unterteilt sie weiter in Einheiten oder Personen darin. Jeder ist bereits an dieses Format gewöhnt und hat, wie wir sehen werden, das Potenzial, viel mehr Informationen zu übermitteln als Zielpostfächer.

Jahrelang habe ich damit gerechnet, dass dieses Format zum De-facto-Standard für Identitätsendpunkte mit Session Initiation Protocol (SIP) und XMPP wird.

SIP und XMPP haben die Welt nicht so erobert, wie ich es erwartet hatte (zumindest noch nicht), und für eine Weile begannen Identifikatoren, sich auf zentralisierte Plattformen wie Twitter-Handles und Github-Benutzer-IDs zu konzentrieren. Ich fand das immer merkwürdig, besonders unter Bitcoinern.

Mit Lightning Addresses sehen wir einen Weg zurück zu dezentralisierten Identifikatoren, da E-Mail-Adressen selbst dezentralisiert sind, innerhalb der Grenzen des DNS-Systems selbst (mehr dazu weiter unten).

Es gibt nur ein Problem: Der definierten LNURL-Spezifikation fehlt eine Abstraktionsebene. Ohne sie wird der Anwendungsfall für Beleuchtungsadressen sehr eingeschränkt.

Angesichts der Lightning-Adresse:

[email protected]

Das bedeutet, dass sich der Zahlungsdeskriptor gemäß der aktuellen Spezifikation wie folgt befindet:

https://example.com/.well-known/lnurlp/satoshi/

Was aber, wenn Satoshi keinen Zugriff auf den Webserver von example.com hat? Wenn wir bei der E-Mail-Adress-Analogie bleiben: Nur weil Sie diese als Ihre Adresse haben, bedeutet das nicht, dass der Server mit dem passenden Hostnamen dort ankommt, wo die E-Mail zugestellt wird.

Tatsächlich ist das wahrscheinlich nicht häufiger der Fall als es ist. Aus diesem Grund gibt es im DNS den MX-Eintragstyp, der eine zusätzliche Umleitungsebene hinzufügt, um das Ziel für E-Mails zu steuern. Sie können die E-Mail-Zustellung an Hostnamen leiten, die unter einem völlig anderen Domänennamen arbeiten (denken Sie an Personen, die einen externen E-Mail-Anbieter verwenden, jedoch mit ihrer eigenen benutzerdefinierten Domäne).

Dasselbe muss aus weitgehend denselben Gründen mit Lightning-Adressen geschehen. Der Hostname rechts neben dem „@“ hat möglicherweise überhaupt keinen Webserver, oder der Benutzer ist unangemessen darauf beschränkt, eine Lightning-Adresse zu verwenden, bei der die Hostnamenkomponente nur die des Webservers sein kann, auf dem die JSON-Datei gehostet wird. Das kann ein Problem sein, wenn eine Lightning-Adresse veröffentlicht wird, die der Benutzer später ändern möchte.

Als DNS-Typ schien die Lösung offensichtlich zu sein, aber ich war schuldig, sie zu überdenken:

2017 wurde ich von der damaligen Ethereum Name Service Working Group zu einem Treffen in London eingeladen, um die Spezifikation für die ENS Registry auszuarbeiten.

Ich verließ dieses Meeting mit dem Gedanken, dass es einen neuen DNS-Ressourceneintrag geben muss, einen neuen Eintragstyp, der in der Lage wäre, Blockchain-Ressourcen innerhalb des alten DNS zu referenzieren.

In meinen Augen würde es so etwas wie ein SRV- oder NAPTR-Eintrag aussehen, der unterschiedliche Felder für Protokolle, Ports und Gewichtungen hätte (die Tatsache, dass Webbrowser heute immer noch nicht in SRV-Einträgen nach Webadressen suchen, ist eine der großen verpassten Gelegenheiten von das Internetzeitalter).

Meine Arbeitskürzel dafür war „BCPTR“ für „Blockchain Pointer“ und es hatte eine überkomplizierte, verschlungene Spezifikation, um genau darauf hinzuweisen, auf welche Blockchain ein Datensatz verwies und um welche Art von Ressource es sich handelte.

Dann schlug jemand in der Lightning-GitHub-Ausgabe, in der der LNURL-RFC diskutiert wurde, vor, einfach eine Adresse mit der Subdomain „_lud16“ voranzustellen.

Die Verwendung von Unterstrichen zur Unterscheidung bestimmter Namensattribute von tatsächlichen Hostnamen gibt es schon seit einiger Zeit. Es wurde in der ursprünglichen SRV RR-Spezifikation RFC2872 verwendet und später in RFC 8552 als „Underscore Scoping“ beschrieben.

Der Vorschlag explodierte sofort in meinem Gehirn und mir wurde klar, dass ich jahrelang darüber nachgedacht hatte.

Bei einem bereichsbezogenen Label in DNS, wie _tcp oder _udp, wird die Groß-/Kleinschreibung nicht beachtet, und wir sehen sie in SRV- und NAPTR-Einträgen zur Verwendung in SIP-, VOIP- und ENUM-Anwendungen, Lastverteilung, ganz zu schweigen von TXT-Einträgen für DKIM und DomainKeys.

So ziemlich jedes gültige DNS-Label, wie _lud16 oder _btc, bietet uns einen Mechanismus, um eine Antwort auf eine Abfrage zu beschränken, die dem Bereich entspricht, unter dem übergeordneten Knoten im DNS-Baum.

Bedeutung:

$ORIGIN example.com.
_ie.test IN TXT „das ist ein Test“

_eg.test IN TXT „Dies ist ein separater Test“

Eine DNS-Abfrage für den Typ TXT auf „test.example.com“ liefert keine Antwort (NXDOMAIN).

Eine DNS-Abfrage für den Typ TXT auf „_ie.test.example.com“ gibt nur ein Ergebnis für den ersten Datensatz zurück.

Eine DNS-Abfrage für den Typ TXT auf „test._ie.example.com“ gibt nur den zweiten Eintrag zurück.

Mit anderen Worten, wir haben mehrere TXT-Einträge für das Blatt test.example.com, wir geben jedoch nur den mit dem Scoped-Label abgefragten zurück, der mit einem Unterstrich beginnt.

Es stellt sich heraus, dass dies für unsere Zwecke ziemlich leistungsfähig ist. Es ist auch die einfachste, optimale Lösung in unserem Anwendungsfall, weil:

Jeder kann es verwenden. Es ist ein leicht zu erkennendes Format. Es kann über DNS in jede vorhandene E-Mail-Adresse nachgerüstet werden jede Art von Nutzlast. Kann über alle Blockchains hinweg arbeiten.

Wie Underscore Scoping in Blockchains verwendet werden könnte

Indem wir das in Lightning Addresses: verwendete E-Mail-Adressformat verwenden, können wir die Konvention über das DNS verwenden, um alle Arten von Endpunkten für dieselbe Identität anzugeben:

$ORIGIN www.bombthrower.com.
_lud16.markjr IN TXT „https://my.ln-node/.well-known/lnurlp/markjr“
_btc.markjr IN TXT „bc1qu059yx6ygg9e6tgedktlsndm56jrckyf3waszl“
_ens.markjr IN TXT „0xEbE7CcC5A0D656AD3A153AFA3d543160B2E9EdFb“

Wir können von hier aus dorthin gelangen, ohne etwas bereits vorhandenes zu beschädigen:

Anwendungen, die bereits eine LNURL-Adresse verwenden, können diese weiterhin verwenden. Anwendungen können die DNS-Suche hinzufügen

Aber DNS ist zentralisiert!

Es stimmt, dass DNS eine umgekehrte Baumstruktur hat, die am Stamm „.“ endet. Aber selbst diese Wurzel ist ziemlich dezentralisiert und umfasst Tausende von Servern, die von mindestens 13 unterschiedlichen Betreibern betrieben werden. Das alte DNS mag logisch zentralisiert sein, funktioniert aber in Wirklichkeit eher wie eine Art dezentraler Verbund.

Auch dies verändert sich, entwickelt sich. Ich denke, wo wir letztendlich landen, ist, wo Namespaces sowohl die bestehende invertierte Baumwurzel als auch vollständig dezentralisierte Blockchains überspannen.

Einiges davon ist heute bereits vorhanden: Sie könnten so etwas wie Stacks und .btc-Domains verwenden, die an Bitcoin anheften, und es wird wahrscheinlich andere Namespaces geben, die direkt auf Bitcoin aufgebaut sind.

Nicht alle dezentralen Namespaces haben ältere DNS-Resolver, aber auch das wird sich ändern. Es wird auch an einer neuen DNSresolvers-Implementierung gearbeitet, die Stacks, .btc- und HNS-Domains per Handshake sowie unaufhaltsame Top-Level-Domains auflöst. Sie können es über Lookups auf alpha.dnsresolvers.com testen:

% dig +short easydns.btc @alpha.dnsresolvers.com

3.14.49.122

(Dieser Server ist ein Proof-of-Concept und wird in Zukunft verschwinden, bitte fügen Sie ihn nicht zu Ihrer resolv.conf hinzu.)

All dies, und es löst auch das Problem des gefälschten Twitter-Handles!

Sobald wir es uns zur Konvention gemacht haben, den Bereich der Unterstriche zu verwenden, stellen wir fest, dass wir alle möglichen Probleme mit vorhandenen Methoden lösen können.

Schauen wir uns das Problem mit gefälschten Twitter-Handles an, das den Bitcoin-Raum plagt.

Die Datenstruktur eines Twitter-Nutzers sieht folgendermaßen aus:

Mit dem Unterstrich-Scoping können wir das wahre Twitter-Handle aus dem Hostnamen im URL-Element unter Verwendung der folgenden Konvention bestätigen:

$ORIGIN www.bombthrower.com.

stuntpope._twitter IN TXT „Stuntpope“

*._twitter IN TXT „gefälscht“

An sich bringt das nichts. Niemand wird ein Terminalfenster öffnen und Folgendes eingeben:

„dig -t TXT +short stuntpope._twitter.bombthrower.com“

… um herauszufinden, ob die Person Ihnen sagt: „Wie läuft Ihr Trading heute?“ bin wirklich ich oder einer der Heerscharen von StuntPope-Betrügern da draußen auf Twitter. (Ich scherze natürlich, niemand, der bei klarem Verstand ist, würde sich für mich ausgeben. Aber für viele Fintwit-Koryphäen ist dies ein echtes Problem.)

Aber was kann passieren, wenn dies zur Konvention wird? Entwickler können Quick-and-Dirty-Hooks in ihre Apps einbauen, um diese Lookups durchzuführen.

Wenn sich ein gefälschtes Twitter-Profil für jemanden ausgibt, kopieren sie normalerweise alle Daten wörtlich, einschließlich des Hostnamens in das URL-Feld des Twitter-Profils. Wenn der echte Benutzer über die oben beschriebenen Datensätze verfügt, wird die Konvention, den gefälschten Twitter-Handle unter der echten URL nachzuschlagen, den tatsächlichen _twitter TXT-Datensatz für das echte Profil verfehlen und den Wildcard-Datensatz treffen, was zu einer Nichtübereinstimmung führt.

Wir haben eine Proof-of-Concept-Chrome-Erweiterung über easyDNS Github veröffentlicht, die genau das mit drei Modi tut:

A) Keine Angaben gemacht;

B) Das Profil stimmt mit den behaupteten Informationen überein;

C) Das Profil stimmt nicht mit den behaupteten Informationen überein (es ist eine Fälschung).

All dies und mehr kann mit sehr einfachen Konventionen in einem allgegenwärtigen Protokoll durchgeführt werden, das bereits implementiert ist.

Fazit

Wallet-Adressen eignen sich dafür, eine Art Benennungsmechanismus zu benötigen. Es gibt mehrere Anwendungsfälle, in denen die Notwendigkeit, eine Adresse von einer Identität sicher zu behaupten, Vorrang vor Pseudonymität oder Anonymität hat.

Um von Menschen lesbare Labels oder Identifikatoren zu verwenden, benötigen wir außerdem eine Abstraktionsschicht, die Flexibilität und ein leicht erkennbares Format bietet.

All dies können wir schließlich mit dem DNS erreichen, das bereits die technische Infrastruktur des Internets untermauert, bereits eine dezentrale Föderation ist und auf dem Weg ist, sich auf dezentralen Schicht-1-Protokollen zu verankern. Wir können dies tun, ohne neue Aufzeichnungstypen hinzuzufügen oder Protokollergänzungen zu den bestehenden Spezifikationen vorzunehmen.

Dies ist ein Gastbeitrag von Mark Jeftovic. Die geäußerten Meinungen sind ausschließlich ihre eigenen und spiegeln nicht unbedingt die von BTC Inc oder Bitcoin Magazine wider.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert