Utilizzo del DNS per coordinare i pagamenti in Bitcoin
Tradotto dall’originale di Shinobi – pubblicato il 20 feb 2024
Matt Corallo ha proposto poco più di una settimana fa un BIP per il coordinamento dei pagamenti in Bitcoin. Effettuare pagamenti in Bitcoin ha sempre rappresentato una sfida in termini di coordinamento, sia on-chain che off-chain con protocolli come Lightning, per diverse ragioni. Quando si tratta di sistemi digitali come la posta elettronica o i sistemi di pagamento come Paypal, Cashapp, ecc. le persone sono molto abituate al concetto di un singolo identificatore statico. Se si vuole inviare un’e-mail a John, basta inviare un’e-mail a “john@[inserire dominio]“. Se si vuole inviare a John del denaro su Cashapp, basta inviare un pagamento a @John su Cashapp.
Questa è l’esperienza utente con cui le persone hanno familiarità e quando si tratta di comportamenti e aspettative radicate degli utenti è incredibilmente difficile spingerli a un cambiamento sostanziale o netto del loro comportamento. Se si presenta loro uno strumento che lo richiede, si crea un forte attrito e molto probabilmente si disincentiva la maggior parte delle persone a utilizzarlo.
I pagamenti on-chain incontrano un problema con questa aspettativa, non a causa dell’incapacità di avere un identificatore statico (un singolo indirizzo), ma a causa delle implicazioni sulla privacy di pubblicare un singolo indirizzo on-chain e far sì che tutti coloro con cui si interagisce lo usino per pagare. L’intera cronologia dei pagamenti e il possesso di monete sono sotto gli occhi di tutti. Se si riceve denaro solo raramente, ad esempio quando si viene pagati per il lavoro o si saldano i conti del bar, non è affatto un peso aprire semplicemente il portafoglio e generare un nuovo indirizzo a cui ricevere. Se invece ricevete denaro di frequente, in particolare nei casi in cui non sollecitate direttamente il pagamento, questo rappresenta un serio onere.
Per questo motivo sono stati creati strumenti come BTCPay Server (di cui sono orgoglioso utilizzatore, n.d.t.), al fine di abbassare la barriera d’ingresso per le persone che desiderano creare l’infrastruttura necessaria per automatizzare la ricezione dei fondi senza fare qualcosa di ingenuo come pubblicare un singolo indirizzo da riutilizzare per tutti coloro che vi pagano. Tuttavia, ciò richiede la gestione di un server costantemente disponibile online. Sebbene il progetto abbia abbassato drasticamente la soglia di comprensione richiesta, si tratta comunque di un onere elevato per un utente che voglia semplicemente ricevere passivamente del denaro.
Lo stesso vale per Lightning, ma peggio. Una fattura è valida solo per un singolo pagamento. A differenza di un indirizzo on-chain, che può essere riutilizzato anche se è una pratica orribile, una fattura Lightning non può essere utilizzata. Una volta che la fattura è stata pagata o è scaduta, il nodo Lightning in questione negherà qualsiasi tentativo di pagamento. Questa dinamica ha portato alla creazione della specifica LNURL e degli indirizzi Lightning costruiti su di essa. LNURL è un protocollo per la connessione a un server HTTP attraverso un IP statico che può essere condiviso una volta per ottenere dal server una fattura Lightning da pagare. Su questa base, gli indirizzi Lightning sono uno schema di denominazione su LNURL strutturato in modo simile agli indirizzi e-mail: John@[dominio del server LNURL].
Tutte queste soluzioni presentano degli svantaggi. L’obbligo di eseguire un software aggiuntivo (un server HTTP) che rimane sempre online oltre al portafoglio Bitcoin o al nodo Lightning; la richiesta al server BTCPay/LNURL fa trapelare l’indirizzo IP del mittente al destinatario; inoltre è necessario affidarsi alle autorità di certificazione TLS.
E’ sufficeinte usare il DNS
Gli strumenti per i server HTTP come LNURL, se abbinati a Lightning Address, utilizzano i domini per risolvere la connessione al server HTTP. Allo stesso modo, i server BTCPay sono tutti configurati con domini piuttosto che con indirizzi IP grezzi. L’intuizione di Matt è: perché non eliminare la dipendenza dall’HTTP e utilizzare il sistema dei nomi di dominio?
Il DNS consente di associare record TXT a un determinato nome di dominio, creando piccoli record leggibili dall’uomo (o dalla macchina) che possono essere interrogati dai server DNS. In combinazione con le estensioni di sicurezza del sistema dei nomi di dominio (DNSSEC), i record TXT del DNS forniscono un meccanismo che può essere utilizzato per interrogare le informazioni sui pagamenti senza l’onere di gestire un server HTTP, oltre a offrire una maggiore flessibilità e apertura. Il protocollo DNSSEC fornisce una serie di strumenti per firmare crittograficamente le voci DNS, compresi i record TXT, con le chiavi DNS inerenti alla struttura gerarchica del DNS. In questo modo si garantisce che il record TXT che si sta interrogando è il record firmato e distribuito ai server DNS di livello inferiore dal server/chiave radice locale.
Questo evidenzia il vero vantaggio del DNS come mezzo per recuperare i dati di pagamento: dite addio all’obbligo di gestire un server HTTP. Un record TXT può codificare un indirizzo Bitcoin on-chain (sebbene il BIP raccomandi specificamente di non farlo se non si è in grado di ruotare regolarmente i nuovi indirizzi per evitare che vengano riutilizzati), ma soprattutto può contenere un’ Offerta Lightning BOLT 12.
Questi record possono essere recuperati da qualsiasi server DNS, dal proprio DNS personale, dal quello del proprio ISP, persino da un server pubblico come Google o Cloudflare. Da questo punto di vista, una delle carenze delle soluzioni basate su HTTP è stata risolta: non state più facendo trapelare il vostro indirizzo IP alla persona che state cercando di pagare. Ora, nel caso in cui si utilizzi il DNS del proprio ISP o un server pubblico come Google o Cloudflare senza una VPN o Tor, si rivela il proprio indirizzo IP; il BIP incoraggia chiaramente il supporto della risoluzione DNS tramite una VPN o Tor proprio per questo motivo.
La combinazione di questa proposta con BOLT 12 elimina la necessità di eseguire software ausiliari che rappresentano un problema di sicurezza molto reale per gli utenti poco esperti, e consente alla proprietà di un dominio di fornire agli utenti tutto ciò di cui hanno bisogno per avere un meccanismo per individuare le informazioni di pagamento con un semplice identificatore leggibile dall’uomo. BOLT 12 non richiede alcun server HTTP, gestendo l’effettiva consegna delle fatture tramite connessioni onion instradate direttamente attraverso la rete Lightning, e supporta le Offerte, un identificatore statico che può essere utilizzato per trovare un percorso onion verso quel nodo Lightning. Il problema è che l’offerta è codificata come un’enorme stringa casuale, come la fattura stessa, il che la rende un pessimo identificatore leggibile/utilizzabile dall’uomo, se non attraverso l’uso di codici QR o il copia e incolla.
Memorizzando un’offerta in un record DNS TXT, tutto ciò di cui un utente ha bisogno per effettuare un pagamento è il dominio di qualcuno da digitare nel proprio portafoglio, in modo che possa recuperare il record TXT, recuperare l’offerta BOLT 12 ed effettuare il pagamento. L’utente non ha bisogno di ospitare alcun server o di eseguire alcun software oltre al proprio nodo Lightning: il sistema DNS gestisce tutto al posto suo, ospitando l’Offerta BOLT 12 in modo che gli utenti che desiderano pagarla possano trovarla.
Si tratta di un sistema perfettamente privo di fiducia? No. È molto meglio dei sistemi basati su HTTP? Assolutamente sì. Il problema di questioni come questa è che esiste una certa aspettativa di UX e di comportamento che la maggior parte delle persone ha in mente per quanto riguarda il funzionamento dei sistemi digitali. Senza replicare tale UX, grandi gruppi di persone utilizzeranno semplicemente alternative che soddisfano tale aspettativa. Data questa realtà, nel tentativo di inserire il Bitcoin nella scatola delle aspettative UX, l’obiettivo del design dovrebbe essere quello di soddisfare le esigenze degli utenti con la minima quantità di fiducia, il minimo onere imposto agli utenti e il minimo potenziale di perdita di privacy in nuovi modi. Credo che il BIP di Matt sia in grado di soddisfare tutte queste esigenze rispetto alle soluzioni esistenti.
Come acquistare Bitcoin?
Reputo il miglior servizio quello offerto da Relai.
Per acquistare bitcoin risparmiando lo 0,5% in commissioni puoi usare il codice “REL3166”.
Si tratta di un’applicazione sviluppata da un’azienda svizzera che applica una politica di KYC light: a differenza dei grandi exchange non richiede registrazioni o dati personali, tutto ciò che serve per acquistare è il tuo IBAN.
E’ lo strumento ottimale per impostare dei piani di accumulo (DCA).
Per ridurre al massimo le commissioni di acquisto, ti consiglio di:
effettuare acquisti maggiori di 100€ (-0,5%)
impostare un piano di accumulo settimanale o mensile (-0,5%)
applicare il codice invito REL3166 (-0,5%)
Una delle migliori caratteristiche è il servizio non-custodial. Gli euro bonificati a Relai vengono convertiti automaticamente in bitcoin e trasferiti su un wallet di cui sei solo tu ad avere il controllo. I grossi exchange, al contrario, non forniscono le chiavi private ai clienti. In più Relai non vende centinaia di inutili criptovalute, ma solo bitcoin.
Cosa ci guadagno? Quello che fanno guadagnare i referral code. In questo caso se acquisti usando il codice “REL3166” risparmi lo 0,5% sulle commissioni e io ricevo (in bitcoin) lo 0,5% dell’importo che hai deciso di investire.
Per ulteriori informazioni, o per effettuare il primo acquisto, premi sul pulsante sottostante e ti verrà mostrata una dettagliata guida in italiano.
NOTA – Questo NON è un messaggio pubblicitario. Relai è un servizio che utilizzo personalmente e che reputo tra i migliori sul mercato in termini di affidabilità, sicurezza e facilità d’uso. Lo consiglio spesso ad amici e parenti.
Articolo originale: Read More
