Matt Corallo propôs há pouco mais de uma semana um BIP para a coordenação dos pagamentos em 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@[insert domain].” 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 do comportamento e das expectativas arraigadas do usuário em relação às coisas, é incrivelmente difícil empurrá-los para 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 na rede enfrentam um problema com essa 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 na rede e fazer com que todas as pessoas com quem você interage usem esse 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 reutilizá-lo. 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 pesado para um usuário que deseja simplesmente receber dinheiro passivamente.
O mesmo vale para 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 aos endereços Lightning construídos sobre ela. 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@[domain of LNURL server].
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
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 ideia de Matt é: por que não eliminar a dependência do 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 novos endereços regularmente para evitar a reutilização de endereços), mas o mais importante, ele também pode conter uma oferta BOLT 12 Lightning.
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 execução de 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 simples humano. identificador legível. 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 o que um usuário precisa para efetuar 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, em seguida, efetuar 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 deve ser atender às necessidades do usuário com o mínimo de confiança depositada, o mínimo de carga colocada sobre os usuários e o mínimo potencial de perda de privacidade de novas maneiras. Acho que o BIP de Matt verifica todas essas caixas em comparação com as soluções existentes.
Fonte: bitcoinmagazine.com
