Matt Corallo mencadangkan lebih sedikit daripada seminggu yang lalu BIP untuk penyelarasan membuat pembayaran Bitcoin. Membuat pembayaran bitcoin sentiasa memberikan sesuatu yang mencabar dari segi penyelarasan, kedua-dua rantaian dan luar rantaian dengan protokol seperti Lightning, atas sebab yang berbeza. Apabila ia berkaitan dengan sistem digital seperti e-mel atau sistem pembayaran seperti Paypal, Cashapp, dll., orang ramai sangat terbiasa dengan konsep pengecam statik tunggal. Jika anda ingin menghantar e-mel kepada John, anda hanya e-mel "john@[masukkan domain]." Jika anda ingin menghantar wang kepada John di Cashapp, anda hanya menghantar bayaran kepada @John di Cashapp.
Ini adalah pengalaman pengguna yang biasa digunakan oleh orang ramai, dan apabila ia berkaitan dengan tingkah laku dan jangkaan pengguna yang kukuh dengan perkara, adalah amat sukar untuk mendorong mereka ke dalam perubahan besar atau mendadak dalam tingkah laku mereka. Jika anda membentangkannya dengan alat yang memerlukannya, ia memberikan tahap geseran yang besar dan kemungkinan besar hanya akan menghalang kebanyakan orang daripada menggunakan alat itu.
Pembayaran dalam rantaian menghadapi masalah dengan jangkaan ini, bukan kerana ketidakupayaan untuk mempunyai pengecam statik (satu alamat), tetapi kerana implikasi privasi menyiarkan satu alamat dalam rantaian dan meminta semua orang yang anda berinteraksi menggunakan itu untuk membayar anda. Ia meletakkan keseluruhan sejarah pembayaran anda dan pemilikan syiling dalam pandangan umum semua orang. Jika anda jarang menerima wang sekarang dan sekali lagi, iaitu apabila dibayar untuk kerja atau menyelesaikan tab bar dengan orang, ia tidak membebankan sama sekali untuk membuka dompet anda dan menjana alamat baru untuk diterima. Walau bagaimanapun, jika anda kerap menerima wang, khususnya dalam keadaan di mana anda tidak meminta bayaran secara langsung, itu memberikan beban yang serius.
Inilah sebabnya alat seperti Pelayan BTCPay dicipta, untuk mengurangkan halangan kepada kemasukan untuk orang ramai memutarkan infrastruktur yang diperlukan untuk mengautomasikan penerimaan dana tanpa melakukan sesuatu yang naif seperti menyiarkan satu alamat untuk semua orang yang membayar anda untuk digunakan semula. Walau bagaimanapun, ini memerlukan menjalankan pelayan yang sentiasa tersedia dalam talian. Walaupun projek itu telah merendahkan tahap pemahaman yang diperlukan secara drastik, ia masih menjadi beban yang tinggi bagi pengguna yang hanya mahu dapat menerima wang secara pasif.
Perkara yang sama berlaku untuk Lightning kecuali lebih teruk. Invois hanya baik untuk satu pembayaran. Tidak seperti alamat dalam rantaian, yang boleh digunakan semula walaupun ia merupakan amalan yang mengerikan, invois Lightning tidak boleh digunakan. Setelah invois sama ada telah dibayar atau tamat tempoh, nod Lightning yang berkenaan akan menafikan sebarang percubaan untuk membayarnya. Dinamik ini membawa kepada penciptaan spesifikasi LNURL, serta Alamat Kilat yang dibina di atasnya. LNURL ialah protokol untuk menyambung ke pelayan HTTP melalui IP statik yang boleh dikongsi sekali untuk mendapatkan invois Lightning sebenar untuk membayar daripada pelayan. Di samping itu, Alamat Lightning ialah skema penamaan di atas LNURL yang distrukturkan sama seperti alamat e-mel: John@[domain pelayan LNURL].
Semua penyelesaian ini mempunyai kelemahan. Keperluan untuk menjalankan perisian tambahan (pelayan HTTP) yang kekal dalam talian sepanjang masa sebagai tambahan kepada dompet Bitcoin atau nod Lightning anda; membuat permintaan kepada pelayan BTCPay/LNURL membocorkan alamat IP penghantar kepada penerima; bergantung pada Pihak Berkuasa Sijil TLS.
Hanya Gunakan DNS
Perkakas pelayan HTTP seperti LNURL apabila dipasangkan dengan Alamat Lightning menggunakan domain untuk menyelesaikan sambungan ke pelayan HTTP. Begitu juga Pelayan BTCPay semuanya dikonfigurasikan dengan domain dan bukannya menggunakan alamat IP mentah. Wawasan Matt ialah mengapa tidak hanya mengurangkan pergantungan pada HTTP dan menggunakan Sistem Nama Domain itu sendiri?
DNS membolehkan anda mengaitkan rekod TXT dengan nama domain yang diberikan, mencipta rekod kecil yang boleh dibaca manusia (atau mesin) yang boleh ditanya daripada pelayan DNS. Dalam kombinasi dengan Sambungan Keselamatan Sistem Nama Domain (DNSSEC) rekod DNS TXT menyediakan mekanisme yang boleh digunakan untuk menanyakan maklumat pembayaran tanpa overhed dan beban menjalankan pelayan HTTP, serta menawarkan sedikit lebih fleksibiliti dan keterbukaan. DNSSEC menyediakan beberapa alat untuk menandatangani entri DNS secara kriptografi, termasuk rekod TXT, dengan kunci DNS yang wujud dalam struktur hierarki DNS. Ini memberikan jaminan bahawa rekod TXT yang anda tanya adalah rekod yang ditandatangani dan diedarkan kepada pelayan DNS peringkat rendah daripada pelayan/kunci akar tempatan.
Ini mendapat manfaat sebenar DNS sebagai cara untuk mengambil data pembayaran: ucapkan selamat tinggal kepada keperluan untuk menjalankan pelayan HTTP. Rekod TXT boleh mengekod alamat Bitcoin dalam rantaian (walaupun BIP secara khusus mengesyorkan TERHADAP melakukan ini jika anda tidak mampu untuk kerap memutarkan alamat baharu untuk mengelakkan penggunaan semula alamat), tetapi yang lebih penting ia juga boleh mengandungi Tawaran Kilat BOLT 12.
Rekod ini boleh diambil dari mana-mana pelayan DNS, pelayan tempatan anda sendiri, ISP anda, malah pelayan awam seperti Google atau Cloudflare. Dari sudut asas ini, satu kelemahan penyelesaian berasaskan HTTP diselesaikan; anda tidak lagi membocorkan alamat IP anda kepada orang yang anda cuba bayar. Sekarang, dalam hal menggunakan DNS ISP anda atau pelayan awam seperti Google atau Cloudflare tanpa VPN atau Tor, anda mendedahkan alamat IP anda kepada mereka; BIP jelas menggalakkan sokongan untuk resolusi DNS melalui VPN atau Tor untuk sebab ini secara khusus.
Menggabungkan cadangan ini dengan BOLT 12 menghilangkan keperluan untuk menjalankan perisian sampingan yang memberikan kebimbangan keselamatan yang sangat nyata untuk pengguna yang tidak canggih, dan membenarkan pemilikan domain sahaja untuk memberikan pengguna semua yang mereka perlukan untuk mempunyai mekanisme untuk mencari maklumat pembayaran dengan manusia yang mudah. pengecam yang boleh dibaca. BOLT 12 tidak memerlukan pelayan HTTP, mengendalikan penghantaran invois sebenar melalui sambungan laluan bawang secara terus melalui Rangkaian Lightning, dan menyokong Tawaran, pengecam statik yang boleh digunakan untuk mencari laluan bawang ke nod Lightning itu. Masalahnya ialah Tawaran dikodkan sebagai rentetan besar yang kelihatan rawak seperti invois itu sendiri, menjadikannya pengecam boleh dibaca/boleh digunakan manusia yang mengerikan kecuali melalui penggunaan kod QR atau salin dan tampal.
Dengan menyimpan Tawaran dalam rekod TXT DNS, semua yang pengguna perlukan untuk membuat pembayaran ialah domain seseorang untuk menaip ke dalam dompet mereka supaya ia boleh mengambil rekod TXT, mengambil Tawaran BOLT 12 dan kemudian membuat pembayaran. Mereka tidak perlu mengehos mana-mana pelayan atau menjalankan sebarang perisian selain daripada nod Lightning mereka, sistem DNS mengendalikan segala-galanya untuk mereka setakat mengehos Tawaran BOLT 12 mereka kepada seseorang yang pengguna yang ingin membayar mereka boleh temui.
Adakah ini sistem tanpa amanah? Tidak. Adakah ia lebih baik daripada sistem berasaskan HTTP? betul-betul. Masalah dengan isu seperti ini ialah terdapat jangkaan tertentu terhadap UX dan tingkah laku yang kebanyakan orang miliki sejauh sistem digital sepatutnya berfungsi dalam fikiran mereka. Tanpa mereplikasi UX itu, kumpulan besar orang hanya akan menggunakan alternatif yang memenuhi jangkaan UX tersebut. Memandangkan realiti itu, dalam cubaan untuk memasukkan Bitcoin ke dalam kotak jangkaan UX tersebut, matlamat reka bentuk adalah untuk memenuhi keperluan pengguna tersebut dengan jumlah kepercayaan minimum yang dicelah, jumlah beban minimum yang diletakkan kepada pengguna, dan potensi minimum untuk kehilangan privasi dengan cara baharu. Saya rasa BIP Matt menyemak semua kotak tersebut berbanding dengan penyelesaian sedia ada.
Sumber: https://bitcoinmagazine.com/technical/using-dns-to-coordinate-bitcoin-payments