Matt Corallo valamivel több mint egy hete javasolt egy BIP-et a Bitcoin-fizetések koordinálására. A bitcoinos fizetések végrehajtása mindig is kihívást jelentett a koordináció terén, mind a láncon belüli, mind a láncon kívüli protokollokkal, mint például a Lightning, különböző okokból. Amikor olyan digitális rendszerekről van szó, mint az e-mail vagy fizetési rendszerek, mint a Paypal, Cashapp stb., az emberek nagyon hozzászoktak az egyetlen statikus azonosító fogalmához. Ha e-mailt szeretne küldeni Johnnak, csak írjon a „john@[domain beszúrása]” címre. Ha pénzt szeretne küldeni Johnnak a Cashappon, egyszerűen küldjön egy fizetést @John on Cashapp-on.
Ez az a felhasználói élmény, amelyet az emberek ismernek, és amikor a felhasználói viselkedésről és a dolgokkal kapcsolatos elvárásokról van szó, akkor hihetetlenül nehéz rákényszeríteni őket, hogy viselkedésükben jelentős vagy éles változást hajtsanak végre. Ha olyan eszközt ad nekik, amely ezt igényli, az nagymértékű súrlódást okoz, és több mint valószínű, hogy a legtöbb embert elriasztja az eszköz használatától.
A láncon belüli fizetések problémába ütköznek ezzel az elvárással, nem azért, mert nem áll rendelkezésre statikus azonosító (egyetlen cím), hanem azért, mert egyetlen láncon belüli cím közzétételének adatvédelmi vonatkozásai vannak, és mindenki, akivel kapcsolatba lép, használja ezt hogy fizessek neked. A fizetési előzményeket és az érmetulajdonjogokat mindenki számára nyilvánossá teszi. Ha csak ritkán kap pénzt olykor-olykor, azaz amikor fizetést kap a munkáért, vagy ha az emberekkel leszámol, akkor egyáltalán nem teher egyszerűen kinyitni a pénztárcáját, és új címet generálni, amelyre átveheti. Ha azonban gyakran kap pénzt, különösen olyan esetekben, amikor nem közvetlenül kéri a kifizetést, az komoly terhet jelent.
Ezért hoztak létre olyan eszközöket, mint a BTCPay Server, hogy csökkentsék a belépési korlátot az emberek előtt, hogy felállítsák a szükséges infrastruktúrát a pénzek fogadásának automatizálásához anélkül, hogy valami naiv dolgot tennének, például egyetlen címet adnának meg mindenkinek, aki fizet Önnek, hogy újra felhasználhassa. Ehhez azonban olyan szervert kell futtatni, amely folyamatosan online elérhető. Noha a projekt drasztikusan lejjebb engedte a megértés mércéjét, még mindig nagy teher a felhasználó számára, aki egyszerűen csak passzívan szeretne pénzt kapni.
Ugyanez igaz a Lightningre is, kivéve a rosszabbat. A számla csak egyszeri fizetésre jó. Ellentétben a láncon belüli címekkel, amelyek újrafelhasználhatók, bár ez szörnyű gyakorlat, a Lightning számlát nem lehet használni. Miután a számlát kifizették vagy lejár, a szóban forgó Lightning csomópont megtagad minden fizetési kísérletet. Ez a dinamika vezetett az LNURL specifikáció, valamint az arra épülő Lightning Addresses létrehozásához. Az LNURL egy protokoll a HTTP-kiszolgálóhoz való csatlakozáshoz egy statikus IP-címen keresztül, amely egyszer megosztható annak érdekében, hogy tényleges Lightning-számlát kaphasson a szerverről. Ezen túlmenően a Lightning Addresses egy elnevezési séma az LNURL tetején, amely az e-mail címekhez hasonlóan épül fel: John@[LNURL-szerver tartománya].
Mindezeknek a megoldásoknak vannak árnyoldalai. Egy extra szoftver (HTTP-szerver) futtatásának követelménye, amely folyamatosan online marad a Bitcoin pénztárcán vagy a Lightning csomóponton kívül; a BTCPay/LNURL szerverhez intézett kérés kiszivárogtatja a küldő IP-címét a címzetthez; a TLS tanúsító hatóságokra támaszkodva.
Csak használja a DNS-t
A HTTP-szerver eszközök, például az LNURL Lightning-címmel párosítva, tartományokat használnak a HTTP-kiszolgálóval való kapcsolat feloldására. Hasonlóképpen, a BTCPay szerverek mindegyike tartományokkal van konfigurálva, nem pedig nyers IP-címek használatával. Matt meglátása az, hogy miért nem szüntetheti meg a HTTP-függőséget, és magát a tartománynévrendszert használja?
A DNS lehetővé teszi a TXT rekordok társítását egy adott tartománynévhez, kisméretű, emberi (vagy gépi) olvasható rekordokat hozva létre, amelyek lekérdezhetők a DNS-kiszolgálókról. A Domain Name System Security Extensions (DNSSEC) szolgáltatással kombinálva a DNS TXT rekordok olyan mechanizmust biztosítanak, amellyel fizetési információk lekérdezhetők a HTTP-kiszolgáló üzemeltetésének többletköltsége és terhe nélkül, valamint egy kicsit nagyobb rugalmasságot és nyitottságot biztosítanak. A DNSSEC számos eszközt biztosít a DNS-bejegyzések kriptográfiai aláírásához, beleértve a TXT-rekordokat is, a DNS hierarchikus szerkezetében rejlő DNS-kulcsokkal. Ez garantálja, hogy a lekérdezett TXT rekord a helyi gyökérkiszolgáló/kulcs által aláírt és az alacsonyabb szintű DNS-kiszolgálókhoz terjesztett rekord.
Ez a DNS-nek, mint fizetési adatok lekérésének eszközének valós hasznát jelenti: mondjon búcsút a HTTP-kiszolgáló futtatásának követelményének. A TXT rekord kódolhat egy láncon belüli Bitcoin-címet (bár a BIP kifejezetten ezt javasolja ELLENI, ha nem tudja rendszeresen forgatni az új címeket a címek újrafelhasználásának megakadályozása érdekében), de ami még fontosabb, tartalmazhat egy BOLT 12 Lightning Offer-t is.
Ezek a rekordok lekérhetők bármely DNS-szerverről, a saját helyi szerveréről, az internetszolgáltatótól, akár egy nyilvános szerverről is, mint a Google vagy a Cloudflare. Ebből az alappontból a HTTP alapú megoldások egyik hiányossága megoldódik; többé nem szivárogtatja ki az IP-címét annak a személynek, akit fizetni próbál. Most, ha az internetszolgáltató DNS-ét vagy nyilvános szervert, például a Google-t vagy a Cloudflare-t VPN vagy Tor nélkül használja, felfedi számukra az IP-címét; a BIP egyértelműen támogatja a DNS-feloldást VPN-en vagy Toron keresztül, kifejezetten ezért.
Ennek a javaslatnak a BOLT 12-vel való kombinálása megszünteti az olyan kiegészítő szoftverek futtatásának szükségességét, amelyek nagyon komoly biztonsági aggodalmat jelentenek a nem kifinomult felhasználók számára, és lehetővé teszi, hogy a domain tulajdonlása önmagában mindent megadjon a felhasználóknak, hogy rendelkezzenek egy olyan mechanizmussal, amellyel egyszerű emberrel megtalálhatják a fizetési információkat. olvasható azonosító. A BOLT 12 nem igényel HTTP-kiszolgálót, amely a tényleges számlakézbesítést közvetlenül a Lightning hálózaton keresztül irányított kapcsolatokon keresztül kezeli, és támogatja az Offers nevű statikus azonosítót, amellyel a Lightning csomóponthoz vezető útvonalat lehet megtalálni. A probléma az, hogy az ajánlat egy hatalmas, véletlenszerűnek tűnő karakterláncként van kódolva, mint maga a számla, így szörnyű, ember által olvasható/használható azonosító, kivéve QR-kódok vagy másolás és beillesztés révén.
Ha egy ajánlatot DNS TXT rekordban tárol, a felhasználónak csak egy domainre van szüksége a fizetéshez, amelyet be kell írnia a pénztárcájába, hogy lekérhesse a TXT rekordot, lekérhesse a BOLT 12 ajánlatot, majd végrehajthassa a fizetést. Nincs szükségük kiszolgálóra vagy más szoftver futtatására a Lightning csomóponton kívül, a DNS-rendszer mindent elintéz helyettük, egészen a BOLT 12-es ajánlatuk tárolásáig.
Ez egy teljesen megbízhatatlan rendszer? Nem. Sokkal jobb, mint a HTTP alapú rendszerek? Teljesen. Az ehhez hasonló problémákkal az a probléma, hogy a legtöbb embernek bizonyos elvárásai vannak az UX-től és viselkedéstől, ami a digitális rendszerek működését illeti. Az UX megismétlése nélkül az emberek nagy csoportjai egyszerűen olyan alternatívákat fognak használni, amelyek megfelelnek az UX-elvárásnak. Tekintettel arra, hogy a valóság, amikor a Bitcoint megpróbáljuk beilleszteni az UX elvárások keretébe, a tervezési célnak az kell lennie, hogy megfeleljen ezeknek a felhasználói igényeknek a minimális mértékű bizalommal, a felhasználókra nehezedő minimális teherrel és a minimális potenciállal. a magánélet elvesztése új módokon. Szerintem Matt BIP-je ezeket a négyzeteket a meglévő megoldásokkal összehasonlítva ellenőrzi.
Forrás: https://bitcoinmagazine.com/technical/using-dns-to-coordinate-bitcoin-payments