Matt Corallo je prije nešto više od tjedan dana predložio BIP za koordinaciju plaćanja bitcoinima. Plaćanje bitcoinom uvijek je predstavljalo izazov u smislu koordinacije, kako na lancu tako i izvan lanca s protokolima poput Lightninga, iz različitih razloga. Kada je riječ o digitalnim sustavima poput e-pošte ili sustavima plaćanja poput Paypala, Cashappa itd. ljudi su jako navikli na koncept jednog statičkog identifikatora. Ako želite poslati Johnu e-poštu, jednostavno pošaljite e-poruku "john@[umetnite domenu]." Ako želite poslati Johnu nešto novca na Cashappu, samo pošaljite uplatu na @John na Cashappu.
To je korisničko iskustvo s kojim su ljudi upoznati, a kada se radi o ukorijenjenom ponašanju korisnika i očekivanjima od stvari, nevjerojatno ih je teško natjerati na značajnu ili oštru promjenu ponašanja. Ako im predstavite alat koji to zahtijeva, to predstavlja veliki stupanj trvenja i više je nego vjerojatno da će većinu ljudi jednostavno odvratiti od korištenja tog alata.
Plaćanja u lancu nailaze na problem s ovim očekivanjem, ne zbog nemogućnosti posjedovanja statičkog identifikatora (jedna adresa), već zbog implikacija na privatnost objavljivanja jedne adrese u lancu i potrebe da je koriste svi s kojima komunicirate da ti platim. Stavlja vašu cjelokupnu povijest plaćanja i vlasništvo nad novčićima u javni uvid svima. Ako tek rijetko primate novac s vremena na vrijeme, npr. kada ste plaćeni za posao ili kad se obračunavate s ljudima u baru, uopće nije teret jednostavno otvoriti novčanik i generirati novu adresu na koju ćete primati. Međutim, ako često primate novac, posebno u slučajevima kada ne tražite izravno isplatu, to predstavlja ozbiljno opterećenje.
Zbog toga su stvoreni alati kao što je BTCPay Server, kako bi se smanjila barijera za ulazak ljudi kako bi razvili potrebnu infrastrukturu za automatiziranje primanja sredstava bez činjenja nečeg naivnog kao što je objavljivanje jedne adrese za sve koji vam plaćaju za ponovnu upotrebu. Međutim, to zahtijeva pokretanje poslužitelja koji je stalno dostupan na mreži. Iako je projekt drastično snizio ljestvicu potrebnog razumijevanja, još uvijek predstavlja veliko opterećenje za korisnika koji jednostavno želi biti u mogućnosti pasivno primati novac.
Isto vrijedi i za Lightning, samo još gore. Faktura vrijedi samo za jednokratno plaćanje. Za razliku od adrese u lancu, koja se može ponovno koristiti iako je to užasna praksa, Lightning faktura se ne može koristiti. Nakon što je faktura ili plaćena ili istekne, dotični Lightning čvor će odbiti svaki pokušaj plaćanja. Ova dinamika dovela je do stvaranja LNURL specifikacije, kao i Lightning adresa izgrađenih na njoj. LNURL je protokol za povezivanje s HTTP poslužiteljem putem statične IP adrese koja se može podijeliti jednom kako bi se dobila stvarna faktura za Lightning za plaćanje s poslužitelja. Nadovezujući se na to, Lightning adrese su shema imenovanja na vrhu LNURL-a strukturirana slično adresama e-pošte: John@[domena LNURL poslužitelja].
Sva ova rješenja imaju nedostatke. Zahtjev za pokretanjem dodatnog dijela softvera (HTTP poslužitelja) koji ostaje online cijelo vrijeme uz vaš Bitcoin novčanik ili Lightning čvor; postavljanje zahtjeva prema BTCPay/LNURL poslužitelju propušta IP adresu pošiljatelja do primatelja; oslanjajući se na TLS tijela za izdavanje certifikata.
Samo koristite DNS
Alati HTTP poslužitelja kao što je LNURL kada su upareni s Lightning adresom koriste domene za rješavanje veze s HTTP poslužiteljem. Slično tome, svi BTCPay poslužitelji konfigurirani su s domenama, a ne korištenjem neobrađenih IP adresa. Mattov uvid je zašto jednostavno ne isključiti ovisnost o HTTP-u i koristiti sam sustav naziva domena?
DNS vam omogućuje povezivanje TXT zapisa s danim nazivom domene, stvarajući male zapise čitljive ljudima (ili stroju) kojima se može postavljati upit s DNS poslužitelja. U kombinaciji sa sigurnosnim proširenjima sustava naziva domena (DNSSEC) DNS TXT zapisi pružaju mehanizam koji se može koristiti za upite podataka o plaćanju bez opterećenja i tereta pokretanja HTTP poslužitelja, kao i nude malo više fleksibilnosti i otvorenosti. DNSSEC pruža niz alata za kriptografsko potpisivanje DNS unosa, uključujući TXT zapise, s DNS ključevima svojstvenim hijerarhijskoj strukturi DNS-a. Ovo daje jamstvo da je TXT zapis koji tražite zapis potpisan i distribuiran DNS poslužiteljima niže razine s lokalnog korijenskog poslužitelja/ključa.
Ovo donosi stvarnu korist od DNS-a kao sredstva za dohvaćanje podataka o plaćanju: oprostite se od zahtjeva za pokretanjem HTTP poslužitelja. TXT zapis može kodirati Bitcoin adresu u lancu (iako BIP izričito preporučuje da se to NE radi ako niste sposobni redovito rotirati nove adrese kako biste spriječili ponovnu upotrebu adrese), ali što je još važnije, može sadržavati i BOLT 12 Lightning ponudu.
Ovi se zapisi mogu dohvatiti s bilo kojeg DNS poslužitelja, vašeg lokalnog, vašeg ISP-a, čak i javnog poslužitelja poput Googlea ili Cloudflarea. S ove osnovne točke, riješen je jedan nedostatak rješenja temeljenih na HTTP-u; više ne odajete svoju IP adresu osobi kojoj pokušavate platiti. Sada, u slučaju korištenja DNS-a vašeg ISP-a ili javnog poslužitelja poput Googlea ili Cloudflarea bez VPN-a ili Tor-a, otkrivate im svoju IP adresu; BIP jasno potiče podršku za DNS rezoluciju preko VPN-a ili Tor-a upravo iz ovog razloga.
Kombinacija ovog prijedloga s BOLT-om 12 uklanja potrebu za pokretanjem pomoćnog softvera koji predstavlja vrlo stvarnu sigurnosnu zabrinutost za nesofisticirane korisnike i omogućuje samo vlasništvo nad domenom kako bi korisnicima dalo sve što im je potrebno da imaju mehanizam za lociranje podataka o plaćanju jednostavnim ljudskim čitljiv identifikator. BOLT 12 ne zahtijeva HTTP poslužitelj, upravlja stvarnom isporukom faktura preko onion usmjerenih veza izravno kroz Lightning mrežu i podržava ponude, statički identifikator koji se može koristiti za pronalaženje onion rute do tog Lightning čvora. Problem je u tome što je Ponuda kodirana kao golemi nasumični prividni niz poput same fakture, što ju čini užasnim identifikatorom čitljivim/upotrebljivim za ljude osim korištenjem QR kodova ili kopiranjem i lijepljenjem.
Pohranjivanjem ponude u DNS TXT zapis, sve što korisnik treba da bi izvršio plaćanje je nečija domena koju treba upisati u svoj novčanik kako bi mogao dohvatiti TXT zapis, dohvatiti ponudu BOLT 12 i zatim izvršiti plaćanje. Ne trebaju ugostiti nijedan poslužitelj ili pokrenuti bilo koji softver osim svog Lightning čvora, DNS sustav upravlja svime umjesto njih što se tiče ugošćavanja njihovog BOLT 12 Ponudite nekoga koga mogu pronaći korisnici koji im žele platiti.
Je li ovo potpuno nepovjerljiv sustav? Ne. Je li mnogo bolji od sustava temeljenih na HTTP-u? Apsolutno. Problem s ovakvim problemima je u tome što postoji određeno očekivanje od UX-a i ponašanja koje većina ljudi ima što se tiče digitalnih sustava koji bi trebali funkcionirati u njihovim glavama. Bez repliciranja tog UX-a, velike grupe ljudi jednostavno će koristiti alternative koje ispunjavaju ta UX očekivanja. S obzirom na tu stvarnost, u pokušaju da se Bitcoin uklopi u okvir tih UX očekivanja, cilj dizajna trebao bi biti zadovoljiti te potrebe korisnika s minimalnom količinom povjerenja, minimalnom količinom opterećenja koja se stavlja na korisnike i minimalnim potencijalom za gubitak privatnosti na nove načine. Mislim da Mattov BIP ispunjava sve te okvire u usporedbi s postojećim rješenjima.
Izvor: https://bitcoinmagazine.com/technical/using-dns-to-coordinate-bitcoin-payments