Matt Corallo föreslog för lite mer än en vecka sedan en BIP för samordning av att göra Bitcoin-betalningar. Att göra bitcoinbetalningar har alltid varit något av en utmaning när det gäller koordinering, både on-chain och off-chain med protokoll som Lightning, av olika anledningar. När det kommer till digitala system som e-post eller betalningssystem som Paypal, Cashapp, etc. är människor väldigt vana vid konceptet med en enda statisk identifierare. Om du vill skicka ett e-postmeddelande till John, mailar du bara "john@[infoga domän]." Om du vill skicka lite pengar till John på Cashapp, skickar du bara en betalning till @John på Cashapp.
Det här är användarupplevelsen som folk känner till, och när det kommer till förankrat användarbeteende och förväntningar på saker är det otroligt svårt att driva dem till en väsentlig eller kraftig förändring i deras beteende. Om du presenterar dem med ett verktyg som kräver det, uppvisar det en stor grad av friktion och kommer mer än sannolikt helt enkelt att avskräcka de flesta människor från att använda det verktyget.
Kedjebetalningar stöter på ett problem med denna förväntning, inte på grund av oförmågan att ha en statisk identifierare (en enda adress), utan på grund av integritetskonsekvenserna av att lägga upp en enda on-chain-adress och att alla du interagerar med använder den att betala dig. Det gör att hela din betalningshistorik och myntägande visas för alla. Om du bara sällan får pengar då och då, det vill säga när du får betalt för arbete eller när du löser barflikar med folk, är det inte alls en börda att helt enkelt öppna plånboken och skapa en ny adress att ta emot till. Om du däremot ofta får pengar, särskilt i fall där du inte direkt begär betalningen, utgör det en allvarlig börda.
Det är därför verktyg som BTCPay Server skapades för att sänka inträdesbarriären för människor att bygga upp den nödvändiga infrastrukturen för att automatisera att ta emot pengar utan att göra något naivt som att lägga upp en enda adress för alla som betalar dig för att återanvända. Detta kräver dock att man kör en server som ständigt är tillgänglig online. Även om projektet drastiskt har sänkt ribban för förståelse som krävs, är det fortfarande en hög börda för en användare som helt enkelt vill kunna passivt ta emot pengar.
Detsamma gäller för Lightning förutom värre. En faktura är bara bra för en engångsbetalning. Till skillnad från en adress i kedjan, som kan återanvändas trots att det är hemsk praxis, kan en Lightning-faktura inte användas. När fakturan antingen har betalats eller löper ut kommer Lightning-noden i fråga att neka alla försök att betala den. Denna dynamik ledde till skapandet av LNURL-specifikationen, såväl som Lightning Addresses som byggdes ovanpå den. LNURL är ett protokoll för att ansluta till en HTTP-server via en statisk IP som kan delas en gång för att ta en faktisk Lightning-faktura att betala från servern. Utöver detta är Lightning Addresses ett namnschema ovanpå LNURL strukturerat på samma sätt som e-postadresser: John@[domän för LNURL-servern].
Alla dessa lösningar har nackdelar. Kravet på att köra en extra mjukvara (en HTTP-server) som är online hela tiden förutom din Bitcoin-plånbok eller Lightning-nod; att göra en begäran till BTCPay/LNURL-servern läcker avsändarens IP-adress till mottagaren; förlitar sig på TLS-certifikatutfärdare.
Använd bara DNS
HTTP-serververktyg som LNURL när de paras ihop med Lightning Address använder domäner för att lösa anslutningen till HTTP-servern. På liknande sätt är alla BTCPay-servrar konfigurerade med domäner istället för att använda råa IP-adresser. Matts insikt är varför inte bara ta bort beroendet av HTTP och använda själva domännamnssystemet?
DNS låter dig associera TXT-poster med ett givet domännamn, skapa små mänskliga (eller maskinläsbara) poster som kan frågas från DNS-servrar. I kombination med Domain Name System Security Extensions (DNSSEC) tillhandahåller DNS TXT-poster en mekanism som kan användas för att söka efter betalningsinformation utan omkostnader och börda för att köra en HTTP-server, samt erbjuder lite mer flexibilitet och öppenhet. DNSSEC tillhandahåller ett antal verktyg för kryptografisk signering av DNS-poster, inklusive TXT-poster, med DNS-nycklarna som ingår i den hierarkiska strukturen för DNS. Detta ger en garanti för att TXT-posten du frågar efter är posten som signeras av och distribueras till lägre nivå DNS-servrar från den lokala rotservern/nyckeln.
Detta får den verkliga fördelen med DNS som ett sätt att hämta betalningsdata: säg adjö till kravet att behöva köra en HTTP-server. En TXT-post kan koda en Bitcoin-adress i kedjan (även om BIP specifikt rekommenderar MOT att göra detta om du inte har möjlighet att regelbundet rotera nya adresser för att förhindra återanvändning av adresser), men ännu viktigare kan den också innehålla ett BOLT 12 Lightning-erbjudande.
Dessa poster kan hämtas från vilken DNS-server som helst, din egen lokala, din ISP, till och med en offentlig server som Google eller Cloudflare. Från denna grundläggande punkt är en brist med HTTP-baserade lösningar löst; du läcker inte längre din IP-adress till personen du försöker betala. Nu, om du använder din internetleverantörs DNS eller en offentlig server som Google eller Cloudflare utan en VPN eller Tor, avslöjar du din IP-adress för dem; BIP uppmuntrar tydligt stöd för DNS-upplösning över en VPN eller Tor av specifikt denna anledning.
Kombinationen av detta förslag med BOLT 12 tar bort behovet av att köra tilläggsprogramvara som utgör ett mycket reellt säkerhetsproblem för osofistikerade användare, och tillåter att ägandet av en domän enbart ger användarna allt de behöver för att ha en mekanism för att hitta betalningsinformation med en enkel människa läsbar identifierare. BOLT 12 kräver ingen HTTP-server, som hanterar den faktiska fakturaleveransen via lökdirigerade anslutningar direkt genom Lightning Network, och stöder Offers, en statisk identifierare som kan användas för att hitta en lökväg till den Lightning-noden. Problemet är att erbjudandet är kodat som en massiv slumpmässig till synes sträng som en faktura i sig, vilket gör det till en hemsk läsbar/användbar identifierare utom genom användning av QR-koder eller kopiering och inklistring.
Genom att lagra ett Erbjudande i en DNS TXT-post behöver en användare bara göra en betalning att någons domän kan skrivas in i sin plånbok så att den kan hämta TXT-posten, hämta BOLT 12-erbjudandet och sedan göra betalningen. De behöver inte vara värd för någon server eller köra någon annan programvara än deras Lightning-nod, DNS-systemet hanterar allt åt dem så långt som värd för deras BOLT 12 Erbjudande någon som användare som vill betala dem kan hitta.
Är detta ett helt tillitslöst system? Nej. Är det mycket bättre än HTTP-baserade system? Absolut. Problemet med sådana här frågor är att det finns en viss förväntan på UX och beteende som de flesta har så långt som digitala system ska fungera i deras sinnen. Utan att replikera det UX, kommer stora grupper av människor helt enkelt att använda alternativ som uppfyller UX-förväntningarna. Med tanke på den verkligheten, i ett försök att passa in Bitcoin i rutan för dessa UX-förväntningar, borde designmålet vara att möta dessa användarbehov med den minimala mängden förtroende som skjuts in, den minimala bördan som läggs på användarna och den minimala potentialen för förlust av integritet på nya sätt. Jag tror att Matts BIP markerar alla dessa rutor i jämförelse med befintliga lösningar.
Källa: https://bitcoinmagazine.com/technical/using-dns-to-coordinate-bitcoin-payments