Matt Corallo mengusulkan BIP lebih dari seminggu yang lalu untuk koordinasi melakukan pembayaran Bitcoin. Melakukan pembayaran bitcoin selalu menghadirkan tantangan dalam hal koordinasi, baik on-chain maupun off-chain dengan protokol seperti Lightning, karena berbagai alasan. Ketika berbicara tentang sistem digital seperti email atau sistem pembayaran seperti Paypal, Cashapp, dll., orang-orang sudah sangat terbiasa dengan konsep pengenal statis tunggal. Jika Anda ingin mengirim email kepada John, cukup kirim email ke “john@[masukkan domain].” Jika Anda ingin mengirim sejumlah uang kepada John di Cashapp, Anda cukup mengirimkan pembayaran ke @John di Cashapp.
Ini adalah pengalaman pengguna yang familiar bagi banyak orang, dan jika menyangkut perilaku dan ekspektasi pengguna yang sudah mengakar terhadap berbagai hal, sangat sulit untuk mendorong mereka melakukan perubahan besar atau tajam dalam perilaku mereka. Jika Anda memberi mereka alat yang memerlukan hal tersebut, hal ini akan menimbulkan banyak hambatan dan kemungkinan besar hanya akan membuat sebagian besar orang enggan menggunakan alat tersebut.
Pembayaran on-chain mengalami masalah dengan ekspektasi ini, bukan karena ketidakmampuan untuk memiliki pengidentifikasi statis (satu alamat), namun karena implikasi privasi dari memposting satu alamat on-chain dan meminta semua orang yang berinteraksi dengan Anda menggunakannya. untuk membayarmu. Ini membuat seluruh riwayat pembayaran dan kepemilikan koin Anda terlihat oleh semua orang. Jika Anda jarang menerima uang sesekali, misalnya ketika dibayar untuk pekerjaan atau menyelesaikan masalah dengan orang lain, tidak menjadi beban sama sekali untuk membuka dompet Anda dan membuat alamat baru untuk menerima uang. Namun jika Anda sering menerima uang, khususnya ketika Anda tidak meminta pembayaran secara langsung, hal ini akan menjadi beban yang serius.
Inilah sebabnya mengapa alat seperti Server BTCPay diciptakan, untuk menurunkan hambatan masuk bagi orang-orang untuk menyiapkan infrastruktur yang diperlukan untuk mengotomatiskan penerimaan dana tanpa melakukan sesuatu yang naif seperti memposting satu alamat untuk semua orang yang membayar Anda untuk digunakan kembali. Namun, hal ini memerlukan server yang selalu tersedia online. Meskipun proyek ini telah secara drastis menurunkan standar pemahaman yang diperlukan, hal ini masih menjadi beban berat bagi pengguna yang hanya ingin menerima uang secara pasif.
Hal yang sama juga berlaku untuk Lightning kecuali yang lebih buruk. Faktur hanya berlaku untuk satu pembayaran. Berbeda dengan alamat on-chain, yang dapat digunakan kembali meskipun merupakan praktik yang buruk, faktur Lightning tidak dapat digunakan. Setelah faktur telah dibayar atau habis masa berlakunya, node Lightning yang dimaksud akan menolak segala upaya untuk membayarnya. Dinamika ini mengarah pada pembuatan spesifikasi LNURL, serta Alamat Lightning yang dibangun di atasnya. LNURL adalah protokol untuk menghubungkan ke server HTTP melalui IP statis yang dapat dibagikan satu kali untuk mengambil faktur Lightning sebenarnya untuk membayar dari server. Selain itu, Alamat Lightning adalah skema penamaan di atas LNURL yang terstruktur mirip dengan alamat email: John@[domain server LNURL].
Semua solusi ini memiliki kelemahan. Persyaratan untuk menjalankan perangkat lunak tambahan (server HTTP) yang tetap online sepanjang waktu selain dompet Bitcoin atau node Lightning Anda; membuat permintaan ke server BTCPay/LNURL membocorkan alamat IP pengirim ke penerima; mengandalkan Otoritas Sertifikat TLS.
Cukup Gunakan DNS
Perkakas server HTTP seperti LNURL ketika dipasangkan dengan Lightning Address menggunakan domain untuk menyelesaikan koneksi ke server HTTP. Demikian pula, Server BTCPay semuanya dikonfigurasi dengan domain daripada menggunakan alamat IP mentah. Wawasan Matt adalah mengapa tidak menghilangkan ketergantungan pada HTTP dan menggunakan Sistem Nama Domain itu sendiri?
DNS memungkinkan Anda mengaitkan data TXT dengan nama domain tertentu, membuat data kecil yang dapat dibaca manusia (atau mesin) yang dapat ditanyakan dari server DNS. Dikombinasikan dengan Domain Name System Security Extensions (DNSSEC) catatan TXT DNS menyediakan mekanisme yang dapat digunakan untuk menanyakan informasi pembayaran tanpa overhead dan beban menjalankan server HTTP, serta menawarkan lebih banyak fleksibilitas dan keterbukaan. DNSSEC menyediakan sejumlah alat untuk menandatangani entri DNS secara kriptografis, termasuk catatan TXT, dengan kunci DNS yang melekat dalam struktur hierarki DNS. Hal ini memberikan jaminan bahwa data TXT yang Anda tanyakan adalah catatan yang ditandatangani oleh dan didistribusikan ke server DNS tingkat lebih rendah dari server/kunci akar lokal.
Hal ini memberikan manfaat nyata dari DNS sebagai sarana untuk mengambil data pembayaran: ucapkan selamat tinggal pada persyaratan harus menjalankan server HTTP. Catatan TXT dapat menyandikan alamat Bitcoin on-chain (walaupun BIP secara khusus merekomendasikan untuk TIDAK melakukan hal ini jika Anda tidak mampu merotasi alamat baru secara teratur untuk mencegah penggunaan kembali alamat), namun yang lebih penting, catatan ini juga dapat berisi Penawaran BOLT 12 Lightning.
Catatan ini dapat diambil dari server DNS mana pun, server lokal Anda, ISP Anda, bahkan server publik seperti Google atau Cloudflare. Dari titik dasar ini, satu kelemahan solusi berbasis HTTP terpecahkan; Anda tidak lagi membocorkan alamat IP Anda kepada orang yang Anda coba bayar. Sekarang, jika menggunakan DNS ISP Anda atau server publik seperti Google atau Cloudflare tanpa VPN atau Tor, Anda mengungkapkan alamat IP Anda kepada mereka; BIP dengan jelas mendorong dukungan untuk resolusi DNS melalui VPN atau Tor khususnya karena alasan ini.
Menggabungkan proposal ini dengan BOLT 12 menghilangkan kebutuhan untuk menjalankan perangkat lunak tambahan yang menimbulkan masalah keamanan yang sangat nyata bagi pengguna yang tidak berpengalaman, dan memungkinkan kepemilikan domain saja untuk memberikan semua yang dibutuhkan pengguna untuk memiliki mekanisme untuk menemukan informasi pembayaran dengan manusia yang sederhana. pengenal yang dapat dibaca. BOLT 12 tidak memerlukan server HTTP, menangani pengiriman faktur sebenarnya melalui koneksi yang dirutekan bawang langsung melalui Jaringan Lightning, dan mendukung Penawaran, pengidentifikasi statis yang dapat digunakan untuk menemukan rute bawang ke node Lightning tersebut. Masalahnya adalah Penawaran dikodekan sebagai string besar yang tampak acak seperti faktur itu sendiri, menjadikannya pengenal yang dapat dibaca/digunakan manusia kecuali melalui penggunaan kode QR atau salin dan tempel.
Dengan menyimpan Penawaran dalam data TXT DNS, yang dibutuhkan pengguna untuk melakukan pembayaran hanyalah domain seseorang untuk diketik ke dalam dompetnya sehingga dapat mengambil data TXT, mengambil Penawaran BOLT 12, dan kemudian melakukan pembayaran. Mereka tidak perlu menghosting server apa pun atau menjalankan perangkat lunak apa pun selain node Lightning mereka, sistem DNS menangani segalanya untuk mereka sejauh menghosting BOLT 12 Tawarkan seseorang yang dapat ditemukan oleh pengguna yang ingin membayar.
Apakah ini sistem yang tidak bisa dipercaya? Tidak. Apakah ini jauh lebih baik daripada sistem berbasis HTTP? Sangat. Masalah dengan masalah seperti ini adalah adanya ekspektasi tertentu terhadap UX dan perilaku yang dimiliki kebanyakan orang mengenai sistem digital yang seharusnya berfungsi dalam pikiran mereka. Tanpa mereplikasi UX tersebut, sekelompok besar orang hanya akan menggunakan alternatif yang memenuhi harapan UX tersebut. Mengingat kenyataan tersebut, dalam upaya memasukkan Bitcoin ke dalam ekspektasi UX tersebut, tujuan desainnya haruslah memenuhi kebutuhan pengguna tersebut dengan tingkat kepercayaan minimal, beban minimal yang ditanggung pengguna, dan potensi minimal untuk keuntungan. hilangnya privasi dengan cara baru. Saya pikir BIP Matt memeriksa semua kotak itu dibandingkan dengan solusi yang ada.
Sumber: https://bitcoinmagazine.com/technical/using-dns-to-coordinate-bitcoin-pays