Si Matt Corallo ay nagmungkahi ng higit sa isang linggo na ang nakalipas ng isang BIP para sa koordinasyon ng paggawa ng mga pagbabayad sa Bitcoin. Ang paggawa ng mga pagbabayad sa bitcoin ay palaging nagpapakita ng isang bagay ng isang hamon sa mga tuntunin ng koordinasyon, parehong on-chain at off-chain na may mga protocol tulad ng Lightning, para sa iba't ibang dahilan. Pagdating sa mga digital system tulad ng email o mga sistema ng pagbabayad tulad ng Paypal, Cashapp, atbp. ang mga tao ay napakasanay sa konsepto ng isang solong static na identifier. Kung gusto mong magpadala ng email kay John, mag-email ka lang sa “john@[insert domain].” Kung gusto mong magpadala ng pera kay John sa Cashapp, magpadala ka lang ng bayad kay @John sa Cashapp.
Ito ang karanasan ng user na pamilyar sa mga tao, at pagdating sa nakaugat na gawi ng user at mga inaasahan sa mga bagay, napakahirap na itulak sila sa isang malaki o matinding pagbabago sa kanilang pag-uugali. Kung ipapakita mo sa kanila ang isang tool na nangangailangan nito, ito ay nagpapakita ng isang malaking antas ng alitan at higit sa malamang ay simpleng pag-dissincentivize ng karamihan sa mga tao mula sa paggamit ng tool na iyon.
Ang mga on-chain na pagbabayad ay nagkakaroon ng problema sa inaasahan na ito, hindi dahil sa kawalan ng kakayahang magkaroon ng static na identifier (isang solong address), ngunit dahil sa mga implikasyon sa privacy ng pag-post ng isang on-chain na address at paggamit ng lahat ng iyong nakakasalamuha. para bayaran ka. Inilalagay nito ang iyong buong kasaysayan ng pagbabayad at pagmamay-ari ng barya sa pampublikong view ng lahat. Kung bihira ka lang makatanggap ng pera paminsan-minsan, ibig sabihin, kapag binabayaran ka para sa trabaho o nakikipag-ayos sa mga tab sa bar sa mga tao, hindi ito isang pabigat na buksan lang ang iyong wallet at bumuo ng bagong address na matatanggap. Kung madalas kang tumatanggap ng pera gayunpaman, partikular sa mga pagkakataon kung saan hindi mo direktang hinihingi ang pagbabayad, na naghahatid ng malubhang pasanin.
Ito ang dahilan kung bakit nilikha ang mga tool tulad ng BTCPay Server, upang mapababa ang hadlang sa pagpasok para sa mga tao na paikutin ang kinakailangang imprastraktura upang i-automate ang pagtanggap ng mga pondo nang hindi gumagawa ng isang bagay na walang muwang tulad ng pag-post ng isang solong address para sa lahat ng nagbabayad sa iyo upang magamit muli. Gayunpaman, ito ay nangangailangan ng pagpapatakbo ng isang server na palaging magagamit online. Bagama't lubhang ibinaba ng proyekto ang antas ng pag-unawa na kinakailangan, ito ay isang mataas na pasanin pa rin para sa isang user na nais lamang na makatanggap ng pera nang walang pag-aalinlangan.
Totoo rin ito para sa Lightning maliban sa mas masahol pa. Ang isang invoice ay mabuti lamang para sa isang pagbabayad. Hindi tulad ng isang on-chain na address, na maaaring magamit muli kahit na ito ay kakila-kilabot na kasanayan, ang isang Lightning invoice ay hindi maaaring gamitin. Kapag nabayaran na o nag-expire na ang invoice, tatanggihan ng Lightning node na pinag-uusapan ang anumang pagtatangkang bayaran ito. Ang dynamic na ito ay humantong sa paglikha ng detalye ng LNURL, pati na rin ang Lightning Addresses na binuo sa ibabaw nito. Ang LNURL ay isang protocol para sa pagkonekta sa isang HTTP server sa pamamagitan ng isang static na IP na maaaring ibahagi nang isang beses upang makakuha ng aktwal na Lightning invoice na babayaran mula sa server. Bilang karagdagan, ang Lightning Addresses ay isang scheme ng pagbibigay ng pangalan sa itaas ng LNURL na nakaayos katulad ng mga email address: John@[domain ng LNURL server].
Ang lahat ng mga solusyon na ito ay may mga downside. Ang pangangailangan na magpatakbo ng karagdagang piraso ng software (isang HTTP server) na nananatiling online sa lahat ng oras bilang karagdagan sa iyong Bitcoin wallet o Lightning node; ang paghiling sa BTCPay/LNURL server ay naglalabas ng IP address ng nagpadala sa tatanggap; umaasa sa TLS Certificate Authority.
Gumamit lang ng DNS
Ang HTTP server tooling tulad ng LNURL kapag ipinares sa Lightning Address ay gumagamit ng mga domain upang malutas ang koneksyon sa HTTP server. Katulad nito, ang lahat ng BTCPay Server ay naka-configure sa mga domain sa halip na gumamit ng mga hilaw na IP address. Ang insight ni Matt ay bakit hindi na lang putulin ang pagtitiwala sa HTTP at gamitin ang Domain Name System mismo?
Binibigyang-daan ka ng DNS na iugnay ang mga tala ng TXT sa isang ibinigay na domain name, na lumilikha ng maliliit na talaan na nababasa ng tao (o makina) na maaaring i-query mula sa mga DNS server. Sa kumbinasyon ng Domain Name System Security Extensions (DNSSEC) DNS TXT records ay nagbibigay ng mekanismo na magagamit upang mag-query ng impormasyon sa pagbabayad nang walang overhead at pasanin sa pagpapatakbo ng isang HTTP server, at nag-aalok din ng kaunting flexibility at pagiging bukas. Nagbibigay ang DNSSEC ng ilang tool para sa cryptographically signing DNS entries, kabilang ang mga TXT record, na may mga DNS key na likas sa hierarchical structure ng DNS. Nagbibigay ito ng garantiya na ang TXT record na iyong itatanong ay ang record na nilagdaan at ipinamahagi sa mas mababang antas ng mga DNS server mula sa lokal na root server/key.
Nakukuha nito ang tunay na pakinabang ng DNS bilang isang paraan para sa pagkuha ng data ng pagbabayad: magpaalam sa pangangailangan na magpatakbo ng isang HTTP server. Ang isang TXT record ay maaaring mag-encode ng isang on-chain na Bitcoin address (bagama't ang BIP ay partikular na nagrerekomenda ng LABAN sa paggawa nito kung hindi mo kaya ng regular na pag-ikot ng mga bagong address upang maiwasan ang muling paggamit ng address), ngunit higit sa lahat maaari rin itong maglaman ng BOLT 12 Lightning Offer.
Ang mga rekord na ito ay maaaring makuha mula sa anumang DNS server, sa sarili mong lokal, sa iyong ISP, kahit sa isang pampublikong server tulad ng Google o Cloudflare. Mula sa pangunahing puntong ito, isang pagkukulang ng mga solusyong batay sa HTTP ang nalutas; hindi mo na nilalabas ang iyong IP address sa taong sinusubukan mong bayaran. Ngayon, sa kaso ng paggamit ng DNS ng iyong ISP o isang pampublikong server tulad ng Google o Cloudflare na walang VPN o Tor ay ibinubunyag mo ang iyong IP address sa kanila; malinaw na hinihikayat ng BIP ang suporta para sa resolusyon ng DNS sa isang VPN o Tor para sa partikular na kadahilanang ito.
Ang pagsasama-sama ng panukalang ito sa BOLT 12 ay nag-aalis ng pangangailangan para sa pagpapatakbo ng ancillary software na nagpapakita ng isang tunay na alalahanin sa seguridad para sa mga hindi sopistikadong user, at nagbibigay-daan sa pagmamay-ari ng isang domain na mag-isa na ibigay sa mga user ang lahat ng kailangan nila para magkaroon ng mekanismo para mahanap ang impormasyon ng pagbabayad sa isang simpleng tao. nababasang identifier. Ang BOLT 12 ay hindi nangangailangan ng HTTP server, na pinangangasiwaan ang aktwal na paghahatid ng invoice sa mga onion routed na koneksyon nang direkta sa pamamagitan ng Lightning Network, at sumusuporta sa Mga Alok, isang static na identifier na maaaring magamit upang maghanap ng ruta ng sibuyas patungo sa Lightning node na iyon. Ang problema ay ang Alok ay naka-encode bilang isang napakalaking random na tila string tulad ng isang invoice mismo, na ginagawa itong isang kakila-kilabot na nababasa/nagagamit na pantukoy ng tao maliban sa pamamagitan ng paggamit ng mga QR code o pagkopya at pag-paste.
Sa pamamagitan ng pag-iimbak ng Alok sa isang DNS TXT record, ang kailangan lang ng user para makapagbayad ay domain ng isang tao para mag-type sa kanilang wallet para makuha nito ang TXT record, makuha ang BOLT 12 Alok, at pagkatapos ay magbayad. Hindi nila kailangang mag-host ng anumang server o magpatakbo ng anumang software maliban sa kanilang Lightning node, pinangangasiwaan ng DNS system ang lahat para sa kanila hanggang sa pagho-host ng kanilang BOLT 12 Alok sa isang tao na mahahanap ng mga user na gustong magbayad sa kanila.
Ito ba ay isang ganap na walang tiwala na sistema? Hindi. Ito ba ay mas mahusay kaysa sa mga sistemang batay sa HTTP? Talagang. Ang problema sa mga isyu na tulad nito ay mayroong isang tiyak na inaasahan ng UX at pag-uugali na mayroon ang karamihan sa mga tao hangga't ang mga digital system ay dapat na gumana sa kanilang isipan. Nang hindi ginagaya ang UX na iyon, ang malalaking grupo ng mga tao ay gagamit lang ng mga alternatibong nakakatugon sa inaasahan ng UX na iyon. Dahil sa katotohanang iyon, sa pagtatangkang ipasok ang Bitcoin sa kahon ng mga inaasahan ng UX na iyon, ang layunin ng disenyo ay dapat na matugunan ang mga pangangailangan ng user na iyon na may kaunting tiwala na naaalis, ang kaunting pasanin na iniatang sa mga user, at ang kaunting potensyal para sa pagkawala ng privacy sa mga bagong paraan. Sa tingin ko, sinusuri ng BIP ni Matt ang lahat ng mga kahon kung ihahambing sa mga umiiral nang solusyon.
Pinagmulan: https://bitcoinmagazine.com/technical/using-dns-to-coordinate-bitcoin-payments