Matt Corallo propôs há pouco mais de uma semana um BIP para a coordenação de fazer pagamentos Bitcoin. Fazer pagamentos de bitcoin sempre representou um desafio em termos de coordenação, tanto dentro quanto fora da rede, com protocolos como o Lightning, por diferentes razões. Quando se trata de sistemas digitais como e-mail ou sistemas de pagamento como Paypal, Cashapp, etc. as pessoas estão muito acostumadas com o conceito de um único identificador estático. Se você quiser enviar um e-mail para John, basta enviar um e-mail para “john@[inserir domínio]”. Se você quiser enviar algum dinheiro para John no Cashapp, basta enviar um pagamento para @John no Cashapp.

Esta é a experiência do usuário com a qual as pessoas estão familiarizadas e, quando se trata de comportamento e expectativas arraigados do usuário em relação às coisas, é incrivelmente difícil forçá-los a uma mudança substancial ou acentuada em seu comportamento. Se você apresentar a eles uma ferramenta que exige isso, ela apresentará um grande grau de atrito e muito provavelmente irá simplesmente desincentivar a maioria das pessoas de usar essa ferramenta.

Os pagamentos em cadeia enfrentam um problema com esta expectativa, não por causa da incapacidade de ter um identificador estático (um único endereço), mas por causa das implicações de privacidade de postar um único endereço em cadeia e fazer com que todos com quem você interage usem isso para pagar você. Ele coloca todo o seu histórico de pagamentos e propriedade de moedas à vista do público de todos. Se você raramente recebe dinheiro de vez em quando, ou seja, quando é pago pelo trabalho ou acerta contas de bar com outras pessoas, não é um fardo simplesmente abrir sua carteira e gerar um novo endereço para receber. No entanto, se você recebe dinheiro com frequência, especificamente nos casos em que não solicita o pagamento diretamente, isso representa um fardo sério.

É por isso que ferramentas como o BTCPay Server foram criadas, a fim de diminuir a barreira de entrada para as pessoas criarem a infraestrutura necessária para automatizar o recebimento de fundos sem fazer algo ingênuo como postar um único endereço para todos que pagam. para reutilizar. No entanto, isso requer a execução de um servidor que esteja constantemente disponível online. Embora o projeto tenha reduzido drasticamente o nível de compreensão necessário, ainda é um fardo elevado para um usuário que deseja simplesmente receber dinheiro passivamente.

O mesmo vale para o Lightning, só que pior. Uma fatura só é válida para um único pagamento. Ao contrário de um endereço na rede, que pode ser reutilizado mesmo que seja uma prática horrível, uma fatura Lightning não pode ser usada. Assim que a fatura for paga ou expirar, o nó Lightning em questão negará qualquer tentativa de pagá-la. Essa dinâmica levou à criação da especificação LNURL, bem como de Endereços Lightning construídos sobre ele. LNURL é um protocolo para conexão a um servidor HTTP por meio de um IP estático que pode ser compartilhado uma vez para obter uma fatura real do Lightning para pagar no servidor. Com base nisso, os Endereços Lightning são um esquema de nomenclatura sobre LNURL estruturado de forma semelhante aos endereços de e-mail: John@[domínio do servidor LNURL].

Todas essas soluções têm desvantagens. A exigência de executar um software extra (um servidor HTTP) que permaneça online o tempo todo, além de sua carteira Bitcoin ou nó Lightning; fazer uma solicitação ao servidor BTCPay/LNURL vaza o endereço IP do remetente para o destinatário; contando com autoridades de certificação TLS.

Basta usar DNS

As ferramentas de servidor HTTP, como LNURL, quando combinadas com o Lightning Address, usam domínios para resolver a conexão com o servidor HTTP. Da mesma forma, os servidores BTCPay são todos configurados com domínios em vez de usar endereços IP brutos. A visão de Matt é por que não simplesmente cortar o d dependência de HTTP e usar o próprio Sistema de Nomes de Domínio?

O DNS permite associar registros TXT a um determinado nome de domínio, criando pequenos registros legíveis por humanos (ou máquinas) que podem ser consultados em servidores DNS. Em combinação com extensões de segurança do sistema de nomes de domínio (DNSSEC), os registros DNS TXT fornecem um mecanismo que pode ser usado para consultar informações de pagamento sem a sobrecarga e a carga de executar um servidor HTTP, além de oferecer um pouco mais de flexibilidade e abertura. O DNSSEC fornece diversas ferramentas para assinar criptograficamente entradas DNS, incluindo registros TXT, com as chaves DNS inerentes à estrutura hierárquica do DNS. Isso fornece uma garantia de que o registro TXT que você está consultando é o registro assinado e distribuído para servidores DNS de nível inferior a partir do servidor/chave raiz local.

Isso traz o benefício real do DNS como meio de obter dados de pagamento: diga adeus à necessidade de executar um servidor HTTP. Um registro TXT pode codificar um endereço Bitcoin na cadeia (embora o BIP recomende especificamente CONTRA fazer isso se você não for capaz de alternar regularmente novos endereços para evitar a reutilização de endereços), mas o mais importante, ele também pode conter um Oferta relâmpago do BOLT 12.

Esses registros podem ser obtidos de qualquer servidor DNS, do seu próprio servidor local, do seu ISP, até mesmo de um servidor público como Google ou Cloudflare. A partir deste ponto básico, uma deficiência das soluções baseadas em HTTP é resolvida; você não está mais vazando seu endereço IP para a pessoa que está tentando pagar. Agora, no caso de usar o DNS do seu ISP ou um servidor público como Google ou Cloudflare sem VPN ou Tor você está revelando seu endereço IP para eles; o BIP claramente incentiva o suporte à resolução de DNS por meio de VPN ou Tor especificamente por esse motivo.

A combinação desta proposta com o BOLT 12 elimina a necessidade de executar software auxiliar que apresenta uma preocupação de segurança muito real para usuários não sofisticados e permite que a propriedade de um domínio por si só forneça aos usuários tudo o que precisam para ter um mecanismo para localizar informações de pagamento com um identificador simples e legível por humanos. O BOLT 12 não requer servidor HTTP, lidando com a entrega real da fatura por meio de conexões roteadas cebola diretamente por meio da Lightning Network, e oferece suporte a Ofertas, um identificador estático que pode ser usado para encontrar uma rota cebola para esse nó do Lightning. O problema é que a oferta é codificada como uma enorme sequência de caracteres aleatória, como a própria fatura, tornando-a um identificador horrível legível/utilizável por humanos, exceto por meio do uso de códigos QR ou de copiar e colar.

Ao armazenar uma oferta em um registro DNS TXT, tudo que um usuário precisa para fazer um pagamento é o domínio de alguém para digitar em sua carteira para que possa buscar o registro TXT, buscar a oferta BOLT 12 e então faça o pagamento. Eles não precisam hospedar nenhum servidor ou executar nenhum software além do nó Lightning, o sistema DNS cuida de tudo para eles, desde hospedar seu BOLT 12 Offer, alguém que os usuários que desejam pagar possam encontrar.

Este é um sistema perfeitamente confiável? Não. É muito melhor que sistemas baseados em HTTP? Absolutamente. O problema com questões como essa é que há uma certa expectativa de UX e comportamento que a maioria das pessoas tem em relação ao funcionamento dos sistemas digitais em suas mentes. Sem replicar essa UX, grandes grupos de pessoas simplesmente usarão alternativas que atendam às expectativas de UX. Dada essa realidade, ao tentar encaixar o Bitcoin na caixa dessas expectativas de UX, o objetivo do design deveria ser atender a essas expectativas.