O PayNym é um código de pagamento reutilizável que proporciona segurança ao ser compartilhado publicamente. Cada carteira compatível com BIP47 lê o código secreto no PayNymID e gera um novo endereço público válido exclusivo para cada par de usuários. A chave pública estendida escondida no PayNymID, combinada com o código secreto único para cada par de usuários, impede que terceiros rastreiem as chaves públicas dos usuários. Os pagamentos não são enviados diretamente para o código de pagamento do usuário, mas para endereços Bitcoin públicos únicos gerados pelo segredo compartilhado da carteira e pelo código de pagamento reutilizável do destinatário. Estes endereços públicos são gerados quando é feito o primeiro Tx para o PayNymID, garantindo privacidade desde o início da transação. Isso é feito criando um Tx especial que é enviado com os dados da saída OP_RETURN para um endereço de notificação obtido do código de pagamento do destinatário. Este Bitcoin Tx, que é enviado para um endereço de observação/notificação, não é um pagamento real. É uma saída OP_RETURN de 80 bytes com os dados necessários para criar novos endereços públicos derivados de algoritmos com base nas informações de chave pública estendida. Uma vez estabelecido o canal direto entre os usuários, o Tx restante para PayNym segue o mesmo processo que qualquer outra transação Bitcoin. A privacidade é mantida ao compartilhar o PayNym, já que não são divulgados os endereços BTC públicos, apenas o código de pagamento reutilizável BIP47. A premissa do protocolo BIP-47 é que não se pode espionar o que não se pode ver, garantindo assim a privacidade das transações. O PayNym oferece uma maneira relativamente privada de realizar transações, mesmo que isso exija mais esforço e taxas mais elevadas.

O PayNymID incorpora a chave pública estendida do proprietário do PayNym, uma informação codificada que a carteira BIP47 interpreta para criar novos endereços Bitcoin públicos. Esses novos endereços são derivados dos endereços originais controlados pelo proprietário das chaves privadas.

Como a carteira é individual e independente e depende da frase-semente mantida pelo proprietário do PayNym e da carteira, cada carteira BIP47 que lê o código secreto gerará endereços BTC públicos válidos. Esses endereços são exclusivos para cada par de usuários, diferentemente dos gerados por outra carteira que lê o mesmo PayNym, criando canais de pagamento com endereços Bitcoin únicos para cada dupla de usuários.

Para efetuar pagamentos para um PayNymID, é necessário primeiro abrir um canal de pagamento seguro. Isso é feito criando uma transação especial que inclui os dados da saída OP_RETURN e é enviada para um endereço de notificação obtido do código de pagamento do destinatário.

A transação de notificação especial é executada apenas uma vez do remetente para o destinatário. Uma vez aberto, o restante das transações enviadas ao PayNym será como qualquer outra transação Bitcoin.

Esta primeira transação especial tem um custo de 15.000 satoshis mais a taxa de rede na carteira Samourai. É individual para cada canal de pagamento seguro que você deseja abrir com qualquer PayNymID. Ou seja, cada PayNym requer uma única transação especial para abrir cada canal de pagamento.

Uma vez estabelecido o canal de pagamento para o PayNym, você pode realizar transações de forma privada e segura, sem expor seu saldo ou histórico de transações. Da mesma forma, qualquer pessoa que queira fazer um pagamento para o seu PayNym precisará seguir o mesmo procedimento de abrir um canal de pagamento seguro com sua própria carteira.

Essa abordagem permite criar uma rede de contatos seguros, onde você pode conduzir transações de maneira totalmente privada, sem o risco de divulgar informações confidenciais, como seu histórico de transações ou saldo da carteira.

https://medium.com/@ottosch/how-bip47-works-ee641cc14bf3

Ashigaru foi desenvolvida para quem busca uma solução robusta de privacidade e anonimato ao transacionar com Bitcoin, construída sobre princípios de código aberto.

Principais Funcionalidades

• Suporte ao PayNym: Facilmente migre para um novo diretório utilizando o esquema de avatar Pepehash, que representa códigos de pagamento reutilizáveis BIP47.
  

• Roteamento via Onion (Tor): Conecte-se ao seu nó Dojo e transmita suas transações pela rede Tor, garantindo anonimato total.

• Ricochete: Aumente a distância entre a origem e o destino de suas transações, mitigando a vigilância e dificultando o rastreamento por terceiros.

• Recuperação de Chave Criptografada: Proteja suas chaves mnemônicas com uma senha e as importe para outras carteiras compatíveis, garantindo a recuperação segura dos seus fundos.

• Gastos Pós-Mixagem: Importe suas chaves privadas da Samourai Wallet e mantenha suas contas segregadas para maior privacidade em transações futuras.

• Despesas em Lote: Economize nas taxas compondo várias transações em uma única operação.

• Modo Stealth: Oculte sua carteira de buscas físicas com um aplicativo de chamariz funcional no inicializador do dispositivo.

• Coinjoins Ponto a Ponto: Participe de transações colaborativas, ajudando a minar as heurísticas usadas pelos observadores da blockchain.

• Controle de Moedas: Selecione, rotule, congele e descongele UTXOs (Unspent Transaction Outputs) em sua carteira, garantindo controle total sobre seus fundos.

• Taxas de Mineração Inteligentes: Um algoritmo avançado calcula as melhores taxas de transação com base no estado do mempool, otimizando o custo das transações.

Código Aberto e Livre

A Ashigaru Wallet é lançada sob a licença FOSS (GNU General Public License Versão 3), permitindo que qualquer pessoa revise, contribua e verifique a segurança do código.

Links Úteis

• Repositório de Código somente Tor

http://ashigaruprvm4u263aoj6wxnipc4jrhb2avjll4nnk255jkdmj2obqqd.onion/

• Site Oficial da Ashigaru Wallet

https://ashigaru.rs/

• Baixar a Carteira Ashigaru

https://ashigaru.rs/docs/mobile-wallet-download-install/

• Versão Onion para Download

http://ashicodepbnpvslzsl2bz7l2pwrjvajgumgac423pp3y2deprbnzz7id.onion/Ashigaru/Ashigaru-Mobile/releases/download/v1.0.0/ashigaru_mobile_v1.0.0.apk

https://21ideas.org/en/bitcoin-fungibility/

Feito por @e4pool_com e @TonyCrusoe com

#FREESAMOURAI
#SamouraiWallet
#SamouraiDev
#TDevD

Esta apresentação foi apresentada por TDevD https://x.com/SamouraiDev?t=fTisNWjO8dy6u5xDF3vQsQ&s=09  no podcast Dirtcoin Diaries https://twitter.com/i/broadcasts/1kvKpoogOMPxE?t=Ojh6FOPmc_b0U-1CY9ZqWA&s=09

Ok, basicamente é apenas minha opinião sobre o estado atual da fungibilidade do Bitcoin. Vou tentar evitar qualquer fluxo de consciência e ir direto ao ponto.

Vou começar bancando o advogado do diabo. Talvez todos os nossos problemas de fungibilidade sejam culpa nossa, talvez tenhamos deixado cair a bola e permitido que o Bitcoin fosse definido como “dinheiro” pelo estado. Agora, é verdade que seguimos a sugestão de Satoshi, que escreveu um white paper sobre dinheiro digital, mas pegamos a bola e corremos com ela. Poderíamos ter lutado desde o início para manter o Bitcoin definido como texto. As carteiras, por exemplo, nada mais são do que chaveiros. E embora tudo isso seja altamente técnico para alguns e não seja favorável à adoção em massa, manter o Bitcoin definido como uma solução baseada em texto teria sido uma forma de manter a captura regulatória sob controle, desde que essa coisa não fosse percebida como sendo dinheiro.

Assim, como afirmado anteriormente, desde finais de 2014, início de 2015, a captura regulamentar tem vindo a aumentar. É claro que muitas bolsas mudaram quase todas para KYC/AML. Temos as directrizes do FATF, que embora sejam apenas directrizes e não regulamentos, não são leis, ainda estão a ser adoptadas e postas em prática por alguns intervenientes no espaço. E o pior de tudo, temos conformidade preventiva. Vimos grupos que, na verdade, sem qualquer pedido do Estado, se precipitariam, por assim dizer. Dois exemplos são La Maison du Bitcoin em Paris e Bull Bitcoin no Canadá. O chefe da Bull Bitcoin realmente se gabou de ter assumido a liderança e negociado com o estado para garantir que as coisas não piorassem, se você pode acreditar nisso.

Outro problema no espaço, especialmente desde que o GBTC tem sido a financeirização, ou seja, basicamente Wall Street entrando e definindo de acordo com seus próprios termos o que é Bitcoin. Falar de ETFs é um tema recorrente. Atualmente, existem ETFs nas Bermudas e no Canadá. Eles ainda não foram lançados nos Estados Unidos, mas isso é algo que continua surgindo desde então, acredito, desde 2014. E não tenho ideia de por que quereríamos um ETF Bitcoin com tudo o que isso implica no que diz respeito à captura regulatória e apenas capturado por entidades financeiras de Wall Street. Quero dizer, não é algo que devamos considerar favorável. E, claro, temos os futuros que foram lançados há algum tempo e que definitivamente têm impacto no preço geral.

O próprio espaço está sujeito a uma espécie de síndrome de Stockholm. NgU praticamente assumiu o controle da mentalidade. E NgU - o número sobe - nada mais é do que escravização ao decreto. Isso significa que o Bitcoin está sempre pensando em dólares americanos, nada mais. Temos essas noções ridículas sobre a tecnologia NgU, como se ela estivesse de alguma forma enraizada no software que é intelectualmente preguiçoso. Temos um pensamento mágico sobre como essa coisa foi projetada para bombear para sempre, como se tivéssemos descoberto a máquina de movimento perpétuo. É impossível. Nada pode bombear para sempre. É evidentemente ridículo.

Os novos usuários que estão chegando são, eu não colocaria um número percentual nisso, mas em grande parte KYC - DCA . Eles estão chegando via CashApp, RobinHood, Revolut e o que chamo mais tarde de L2 de fato. LnStrike é outro exemplo. E toda essa onda de adoção do KYC-DCA

KYC - https://21ideas.org/en/privacy/no-kyc/

DCA - https://21ideas.org/en/dollar-cost-averaging/

foi impulsionada por quase todos os influenciadores de podcast, à medida que esses serviços patrocinam seus podcasts.

O foco tem sido muito no NgU e no preço. E no que diz respeito à privacidade, retardamos o crescimento do protocolo no nível do software. Está sendo falado da boca para fora, mas basicamente sempre faltam dois ou três anos. É sempre, costumava ser Taproot, agora não é mais Taproot, é outra coisa. Quando continuamos chutando a lata no caminho. Temos problemas com elitismo tóxico e " Não foi inventada aqui " ( NIH ). Isso nos afetou um pouco no Samourai, coisas como BIP47/PayNyms. - https://21ideas.org/en/bip47-the-ugly-duckling/ Basicamente, não foi ungido ou aprovado pelos poderes constituídos. Então, basicamente, fica uma merda. Arrasto de pé por Core. Acho que ninguém está mais falando sobre Dandelion.- https://github.com/bitcoin/bips/blob/master/bip-0156.mediawiki Estava programado para ser lançado. A agregação de assinaturas de entrada cruzada (CISA) - https://bitcoinops.org/en/topics/cross-input-signature-aggregation/ – o mesmo negócio. o mesmo negócio. Todo o repositório BIP - https://github.com/bitcoin/bips está uma bagunça. Não sei, algo aconteceu ultimamente porque as coisas saíram do controle com Luke - https://x.com/LukeDashjr?t=4kEojqcEy9rt_8uAxTVIoA&s=09 e alguém entrou para ser secretário ou algo assim porque pull requests não estavam sendo mesclados e as notas não estavam sendo atualizadas porque Luke aceita exceções para certas coisas. Recebemos discussões muito acadêmicas e acadêmicas sobre a “ossificação” do protocolo, que nada mais é do que joelheiras. Isso significa que basicamente melhorias não serão feitas porque muitas vezes a desculpa dada para isso é que você não pode fazer alterações em softwares que executam um número X de valor de bilhões de dólares. E apela à autoridade, caras como Maxwell - https://nt4tn.net/ Será apresentado um argumento para não fazer algo porque GMax fez um tweet, olá, meia-noite, ou ele, nullc - https://www.reddit.com/user/nullc/  , escreveu um post no Reddit ou algo parecido.

Então, o que está acontecendo agora? Na frente da fungibilidade, temos a abordagem policial bom-policial mau por parte de vários atores. E no policial bom, bem, basicamente é apenas uma leve construção de um jardim murado. Os endereços de retirada estão sendo controlados. Chain analysis  https://21ideas.org/en/privacy/oxt/ está sendo aplicada a depósitos e retiradas. E temos um rápido surgimento de L2 de facto. Então não é Lightning, não é Liquid. É algo controlado por entidades do setor privado, PayPal, CashApp, Revolut, RobinHood e outras. E eles estão basicamente retirando muita atividade da cadeia. Então você pode ver os efeitos no mempool. Mas também controlam muito o que os usuários podem fazer com o que chamam de Bitcoin. Basicamente, é um sistema baseado em contas onde as pessoas acreditam ter Bitcoin, mas basicamente têm valor de Bitcoin em uma conta. E, claro, estas entidades irão ignorar a fungibilidade desse controlador.

O lado do policial mau, bem, é claro que temos listas negras, temos OFAC, as listas negras do governo americano. Ultimamente temos algumas novilínguas assustadoras, algo, por exemplo, “carteiras não hospedadas”.

Basicamente, uma carteira não hospedada é uma carteira ou qualquer coisa que não esteja em uma exchange e sem custódia, ou seja, Samourai e a carteira Core que você pode estar usando no seu PC ou em qualquer dispositivo que esteja usando. Todas essas são carteiras não hospedadas. Agora que as carteiras não hospedadas foram definidas e rotuladas, você pode ter certeza de que, mais cedo ou mais tarde, haverá algum tipo de regulamentação sobre as carteiras não hospedadas e os endereços que elas controlam.Despertar https://21ideas.org/en/privacy/no-kyc/ . Bem, recentemente passamos por alguns episódios com isso com mineradores em conformidade e também fundos de investimento dizendo que só negociariam ou investiriam em empresas que usam Bitcoin gerado com energia verde e todo esse tipo de coisa. E, claro, a sinalização de CoinJoins, que está em andamento há dois anos, eu diria.

Os efeitos imediatos sobre a fungibilidade no nível mais básico são que em lugares como Dread, onde as pessoas fazem transações todos os dias, Dread é um quadro de mensagens onde há pessoas que fazem transações todos os dias. Eles precisam fazer transações usando Bitcoin. O medo agora está procurando outro lugar. Se você for lá e ler os artigos, verá que o Bitcoin está muito em desvantagem por lá. Darknet Bible, que se você olhar nas primeiras edições, tratava de como usar Bitcoin nos mercados Darknet. Agora, na verdade, diz às pessoas para evitarem o Bitcoin. Os mercados da Darknet estão olhando para outro lugar, sendo o mercado de Wall Street o melhor exemplo. E vemos o surgimento de coisas como Chainalysis, que acredito que anteontem, eles arrecadaram US$ 100 milhões e agora estão avaliados em US$ 4,2 bilhões. E isso ocorre basicamente porque a não fungibilidade do Bitcoin é agora um grande negócio.

Então chegamos a como existimos neste nicho? Como podemos contornar essas coisas? Quais são as ferramentas que podemos usar?

A rede Lightning não é uma solução de privacidade, embora tenha sido apresentada como tal, inclusive muito recentemente. Está pronto para o banco. Vimos exemplos em que acredito, não tenho certeza, acho que o BottlePay está pedindo às pessoas informações públicas sobre seus nós para passar pelo sistema. Vemos que o Lightning tem uma forte tendência de recorrer à UI e UX de custódia. E as armadilhas de privacidade do Lightning agora são melhor compreendidas. Recentemente, houve um artigo https://21ideas.org/en/lightning-network-privacy/
que o detalhou detalhadamente e incluo o link lá.

O Liquid foi originalmente apresentado como uma ferramenta de compensação cambial, mas, na verdade, vemos que está sendo posicionado como um cavalo de Tróia de custódia. Ele está sugando e neutralizando os recursos de privacidade. Tem uma versão prejudicada de transações confidenciais. E tenho certeza de que a agregação de assinaturas de entrada cruzada https://bitcoinops.org/en/topics/cross-input-signature-aggregation/ terminará no Liquid e não na cadeia principal. Veremos, mas. Eu ficaria muito surpreso se algum dia víssemos agregação de assinaturas na cadeia.

Então, basicamente, acabei de chegar aos nossos recursos da Carteira Samourai, tenho certeza que muitos de vocês estão familiarizados com eles. Ricochet foi nosso primeiro recurso premium. Na verdade, foi baseado em uma palestra sobre fungibilidade proferida por Adam Back e Blue Matt. Você pode encontrar esse vídeo no YouTube https://youtu.be/AvS3tp0qqgA?si=DVPt9Zpyj5Auhd6t . Eu esqueci onde eles conversaram. Acredito que foi no final de 2016.

BIP47/PayNyms https://21ideas.org/en/bip47-the-ugly-duckling/ . É um recurso muito popular entre nossos usuários que estão familiarizados com ele e dependem dele. É um ótimo recurso de privacidade porque priva a análise da cadeia de um ponto de partida para acompanhar seus pagamentos. Infelizmente, tem havido uma falta de adoção por outras carteiras por uma série de razões. Voltando a coisas como “não inventado aqui” e coisas assim, isso certamente desempenha um papel. Além disso, o fato de o BIP47 ter sido escrito por Justus Ranvier, que estava definitivamente em desacordo com o Core na época. Portanto, o BIP47 nesse aspecto não é nada apreciado. E novamente, só para repetir, vou repetir o que disse anteriormente. Se você voltar a abril de 2015, quando o BIP47 foi publicado pela primeira vez, o próprio termo endereços furtivos, porque o BIP47 foi promovido como endereços furtivos móveis, os endereços furtivos eram muito associados à Dark Wallet. E que entramos em contato com algumas outras carteiras depois que os vetores de teste originais foram publicados. Eles estavam trabalhando ativamente na replicação dos vetores de teste e na implementação do BIP47, e foram praticamente instruídos a interromper o trabalho pela administração ou por seus acionistas devido à forte associação com a Dark Wallet.

Então chegamos ao CoinJoin. CoinJoin feito errado. Bem, é claro, temos o exemplo do ZeroLink https://github.com/nopara73/ZeroLink , razão pela qual Wasabi afirma ter implementado o ZeroLink. Eles definiram o ZeroLink, mas nunca o implementaram. E depois que as coisas começaram a desmoronar com Wasabi, houve o que foi considerado uma guerra contra o CoinJoin. Na verdade, a guerra começou dentro de carroças circulando em torno de Wasabi e recusando-se a reconhecer as falhas na sua implementação. E basicamente, eles ignoraram tudo o que estavam fazendo de errado. Vimos exemplos de FUD por influenciadores. A propósito, essa é uma citação de que CoinJoin é “ provavelmente ilegal ” https://x.com/danheld/status/1334152359346368513?t=GH0MUuf3Rh3byFSHWKICOw&s=19 de um famoso influenciador. Deixei lá uma pista sobre quem ele é. Na minha opinião, o CoinSwap faz parte do ataque ao CoinJoin. Foi rotulado por Chris Belcher https://x.com/chris_belcher_?t=CMb9a4sSyoPNRB2hkKBdyA&s=09 e seus apoiadores como a próxima geração em privacidade do Bitcoin que superaria em muito qualquer coisa relacionada a qualquer CoinJoin em qualquer lugar: JoinMarket, Wasabi ou Whirlpool. Mas vejo que recentemente Belcher recuou nessas afirmações e foi até citado em um artigo recente dizendo que se você quiser provar que seu histórico de transações UTXO foi quebrado, você deve usar CoinJoin https://archive.is/eM97I em vez de CoinSwap. De qualquer forma, o desenvolvimento atual do CoinSwap, pelo que percebi, parece ter desacelerado um pouco. Acho que o nome foi alterado para Teletransporte https://github.com/bitcoin-teleport/teleport-transactions Espero que o CoinSwap seja um serviço de nicho muito pequeno, usado por poucas pessoas que podem executar esse software, ou seja, não muitas. E bem, P2EP – Pay-To-Endpoint. Pay-To-Endpoint é um caso interessante. Novamente, parece uma loucura durante o início desta suposta guerra contra o CoinJoin como uma alternativa ao CoinJoin. Fomos convocados por vários partidos para implementá-lo, caso contrário nunca seríamos levados a sério. E o que vimos é que ele nasceu morto. Está presente em vários servidores, graças ao servidor BTCPay, mas permanece inativado. Incluindo alguns de seus maiores vigaristas que administram lojas e nunca se preocupam em ativar o P2EP. Então, basicamente, esse é um projeto natimorto, na minha opinião. Belcher recentemente implorou às pessoas que intensificassem a adoção, mas não acho que tenha havido qualquer mudança nesse aspecto.

CoinJoin bem feito é 100% CoinJoins de entropia https://github.com/Samourai-Wallet/boltzmann . Esses são os únicos CoinJoins que garantem quebrar links e quebrar seu histórico UTXO. E no momento, o único CoinJoin que garante 100% de entropia sempre é o Samourai Whirlpool. Ficaríamos muito felizes em ver outros fazendo o mesmo, mas isso não está acontecendo e não parece que vá acontecer tão cedo. Acompanhamos o espaço de muito perto e os desenvolvimentos de muito perto. Cahoots, novamente, também são CoinJoins. E eles têm seus vários usos e compensações. Stonewall é importante porque garante um valor mínimo de entropia. Assim, por exemplo, um Stonewall com duas entradas e quatro saídas tem uma entropia mínima garantida de 1,58. Temos desenvolvimentos em andamento para atualizações do Stonewall, e elas estarão prontas ainda este ano. E, novamente, todos envolvem a garantia de um valor mínimo de entropia para os usuários. Isso é algo que mesmo outros CoinJoins não podem garantir ou não garantem um valor mínimo de entropia, seja porque você pode medir completamente a entropia e ver que ela não está lá, ou eles simplesmente jogam tudo o que podem em uma transação, ou seja, um grande número de entradas e resultados, tornando assim tecnicamente inviável até mesmo calcular qualquer entropia que esteja, de fato, ali, se houver.

A propósito, essa é minha única foto na apresentação.

E em breve: há alguns grupos trabalhando ativamente no desenvolvimento de Monero/Bitcoin Atomic Swaps https://github.com/comit-network/xmr-btc-swap . Estamos trabalhando no lado do Bitcoin para integrá-lo à Carteira Samourai. Estamos em contato com outras pessoas do lado do Monero que estão trabalhando para integrá-lo em suas carteiras Monero e estamos no momento, há dois grupos trabalhando ativamente no protocolo em si e estamos em contato próximo com um deles e o desenvolvimento está em andamento . Mais uma vez penso que há um interesse mútuo de ambos os lados em avançar com isto. É verdade que Bitcoin e Monero maxis não são necessariamente aliados naturais. Acho que Bitcoin e Monero são aliados naturais, mas as máximas de ambos os lados não são necessariamente aliadas naturais. Isso pode complicar um pouco as coisas, mas é assim que as coisas são. Pessoalmente, acho que trabalhar com esses Swaps Atômicos é uma ótima maneira de o Bitcoin voltar a entrar em contato com seu espírito. E estamos ansiosos para lançar algo o mais rápido possível.

Cashu é um sistema ecash Chaumian gratuito e de código aberto criado para Bitcoin. Cashu oferece privacidade quase perfeita para usuários de aplicativos Bitcoin de custódia. Ninguém precisa saber quem você é, quanto dinheiro você tem e com quem você faz transações.

O que é Cashu?

Cashu é um novo protocolo ecash para aplicativos de custódia Bitcoin que está totalmente integrado à rede Lightning. Um sistema Ecash consiste em duas partes, a carteira mint e a carteira ecash. Transações Ecash não rastreáveis, instantâneas e sem taxas. Cashu é construído para Bitcoin. As carteiras usam o nó Lightning da casa da moeda para fazer ou receber pagamentos em Bitcoin em troca de ecash. Uma casa da moeda Cashu não sabe quem você é, qual é o seu saldo ou com quem você está negociando.Os usuários de uma casa da moeda podem trocar ecash de forma privada, sem que ninguém saiba quem são as partes envolvidas. Os pagamentos em Bitcoin são executados sem que ninguém possa censurar usuários específicos.

A postagem de David Wagner em 1996 na lista de discussão Cypherpunk é a base da criptografia Cashu. Wagner descreve um sistema ecash usando troca de chave cega Diffie-Hellman em vez de RSA, na qual a implementação original de David Chaum foi baseada.

https://cypherpunks.venona.com/date/1996/03/msg01848.html

https://en.m.wikipedia.org/wiki/Ecash

Como isso começou.

Como vão as coisas.

Como funciona A Carteira Cashu é através de um esquema criptográfico chamado assinaturas cegas, descrito pela primeira vez pelo cypherpunk e criptógrafo David Chaum. Pense assim:você produz uma mensagem secreta e a envolve em um envelope feito de papel carbono que você envia para a casa da moeda.

A casa da moeda não pode ver o que está dentro do envelope. Ele assina do lado de fora dizendo "qualquer que seja esse segredo, vale 420 Satoshis”e o envia de volta para você. Como o envelope é realmente criptografado, somente você pode abri-lo e ver sua mensagem secreta (agora assinada por carbono).

Este segredo assinado é na verdade o seu token Ecash e vale Satoshis.

Você pode enviar e receber esses tokens para qualquer outra pessoa como quiser, seja com um mensageiro, via e-mail ou um pombo. A casa da moeda não sabe nada disso.

A anatomia de um token Cashu.

Um breve passo a passo de uma carteira cashu deixará tudo isso bem claro.

Comece abrindo

https://nutstash.app/

Pressione " WALLET "

Pressione "+ ADD ".

Agora a carteira cashu está aberta…

O próximo passo é deposite alguns sats com a Casa da moeda.

Pra depositar Pressione o botão "MINT".

Digite a quantidade de sats a ser depositado na carteira cashu depois Pressione " REQUEST MINT ".

Você Pode copiar a fatura ou ler o qrcode , no meu caso usei a carteira LNbits pra pagar a fatura de 10 sats , você tem 10 minutos pra pagar fatura.

Agora pra enviar Ecash.

Pressione “SEND”

Digite 10 , Pressione “SEND”

Então o token Ecash usando a assinatura cega da casa da moeda foi criado.

O Token Ecash foi criado é esse logo abaixo.

eyJwcm9vZnMiOlt7ImlkIjoiME5JM1RVQXMxU2Z5IiwiYW1vdW50IjoyLCJzZWNyZXQiOiJrWjNBOVorSXkyREJOcDdhdFhYRTIvclVXOFRnR2ZoTDgzWEFXZ0dKUXhVPSIsIkMiOiIwMmM0NjA4NDYwNDhjNzI1ZjgwMDc3M2IyNmRmOTcxNDU1MTJmOTI0YjgyNzYyZTllYzdkZjZjOTkzNGVmYjJhNmMifSx7ImlkIjoiME5JM1RVQXMxU2Z5IiwiYW1vdW50Ijo4LCJzZWNyZXQiOiJXdTZmdWlxNGt4Tkh3UkF1UzFhMmVYaGZtRnRHU2tRQkNYZFNnUzcreHkwPSIsIkMiOiIwMzFhYWI3MzY3MTJhY2Y5MWU4NzE4YmM5OTlmNWE2MGEwYzNjODQ5YTA1MWE2OTA5MzRkMTc4NWNmZGNkNDcyYTAifV0sIm1pbnRzIjpbeyJ1cmwiOiJodHRwczovL2xlZ2VuZC5sbmJpdHMuY29tL2Nhc2h1L2FwaS92MS80Z3I5WGNtejNYRWtVTndpQmlRR29DIiwiaWRzIjpbIjBOSTNUVUFzMVNmeSJdfV19

Se pressionar o botão " send as link "

Então criar link do token Ecash.

https://wallet.nutstash.app/#eyJwcm9vZnMiOlt7ImlkIjoiME5JM1RVQXMxU2Z5IiwiYW1vdW50IjoyLCJzZWNyZXQiOiJrWjNBOVorSXkyREJOcDdhdFhYRTIvclVXOFRnR2ZoTDgzWEFXZ0dKUXhVPSIsIkMiOiIwMmM0NjA4NDYwNDhjNzI1ZjgwMDc3M2IyNmRmOTcxNDU1MTJmOTI0YjgyNzYyZTllYzdkZjZjOTkzNGVmYjJhNmMifSx7ImlkIjoiME5JM1RVQXMxU2Z5IiwiYW1vdW50Ijo4LCJzZWNyZXQiOiJXdTZmdWlxNGt4Tkh3UkF1UzFhMmVYaGZtRnRHU2tRQkNYZFNnUzcreHkwPSIsIkMiOiIwMzFhYWI3MzY3MTJhY2Y5MWU4NzE4YmM5OTlmNWE2MGEwYzNjODQ5YTA1MWE2OTA5MzRkMTc4NWNmZGNkNDcyYTAifV0sIm1pbnRzIjpbeyJ1cmwiOiJodHRwczovL2xlZ2VuZC5sbmJpdHMuY29tL2Nhc2h1L2FwaS92MS80Z3I5WGNtejNYRWtVTndpQmlRR29DIiwiaWRzIjpbIjBOSTNUVUFzMVNmeSJdfV19

Este token Ecash pode ser compartilhado como você quiser. Você pode enviá-lo por e-mail para alguém, enviá-lo em uma mensagem privada, um SMS ou convertê-lo em um código QR e imprimi-lo. Quem tiver este token pode resgatá-lo com o 10 sats.

Você verá que seu saldo caiu para 20 sats:

Para resgatar um token Ecash sem o link, pressione o botão “Receive ”

cole-o token Ecash no campo

" token: "pressione "RECEIVE"

Com o Link do token Ecash só pressionar no link vai abrir a tela já preencher automáticamente só pressionar " RECEIVE "

Pra Ativa o Nostr na carteira vai na aba settings , pressione o botão ativa o Nostr.

Por padrão ficar ativo pra usar o " Use external Key (nos2x , outros) " Mas Nesse caso não vou usar vou desativar e vou ativa " Edit Nostr Keys "

Ao pressionar esse botão

é gerar um novo par de chaves privadas e pública , assim podemos usar uma nova chave a cada pagamentos.
Aumentando a privacidade no pagamentos.

A pois Ativa o Nostr na carteira , você pode enviar Sats / Ecash via Nostr.

Pressione " Send "

Pressione " Send "

Agora pode adicionar npud / hex / nip-05 pra enviar token.

Pressione " SEND OVER NOSTR " pra enviar o token Ecash.

Pra quem não tem a carteira nutstash , pode entra no seu cliente Nostr no meu caso e snort nostr , Demora algums minutos pra chegar mensagem com o token Ecash..

Ja se a outra pessoa usar carteira nutstash com a chave pública que você mandou chegar mais rápido.
Essa bolinha azul no campo " Indox " Indica que você recebeu o pagamento já está pronto pra ser regastado.

Pressione "Indox " depois pressione a seta.

Pressione " TRUS MINT " pra recebe os Token Ecash.

O aplicativo de resgate Cashu, que permite resgatar tokens Ecash via Lightning.

https://redeem.cashu.me/

Cola o Token no campo " paste in your Cashu Ecash token.. "

Pressione " REDEEM " pra converter Ecash em Lightning.

Você pode editar e manda já pronto pra pessoa só basta a pessoa ou você aberta em " REDEEM " pra converter Ecash em Lightning.

https://redeem.cashu.me/?token=token ecash=&to=Lightning address

Exemplo:

https://redeem.cashu.me/?token=eyJwcm9vZnMiOlt7ImlkIjoiUEVuMVdLalFoN2pGIiwiYW1vdW50IjoyLCJDIjoiMDJhYWE5OWJiMmUwODQyYjJmNzdmNDRlZWEyZjEzMmNkOTNhZjJlNWU0MzI3ZjhjMTE5ODcxZWNiMTNhMTUxYjY0Iiwic2VjcmV0IjoicE5jb3hFRHJRT1ovTXU4d3d2SlpvMnRIaXBSM3pPYkRrSWJUUlB6VXh5bz0ifSx7ImlkIjoiUEVuMVdLalFoN2pGIiwiYW1vdW50IjoxNiwiQyI6IjAzNDM4ZDc1NmZmMjdmYjgyZmQxNWNhNzg3NzgwNTAyZWU4NzdmMzQ5MmYyMWQzMTMwMzc1NTdlNWNmMDJlOWQ0MCIsInNlY3JldCI6Im9DTXQwUTRVT0MvZWhmd2FVOWt5aGFJZUdHdXhiYUNzQTZ2STh2a0w2N1U9In0seyJpZCI6IlBFbjFXS2pRaDdqRiIsImFtb3VudCI6MzIsIkMiOiIwMmIyMmQ4MDEwZWU5MDA2MWYyNWQzODAyY2UyMDE3ZjAwMmVjMDVmMjM5NjIwNGNkYjllMmU2ODllYWY3YTZkYjIiLCJzZWNyZXQiOiI5ejVVMEdzWHZiUS84Rjd4ZFdYUXRxUDlvWGFyVnBRTzRFdUtzb2JSck1vPSJ9XSwibWludHMiOlt7InVybCI6Imh0dHBzOi8vbGVnZW5kLmxuYml0cy5jb20vY2FzaHUvYXBpL3YxL29DcXNTR3I1enphTTZxM1hWZU5ZNXQiLCJpZHMiOlsiUEVMVdLalFoN2pGIl19XX0=&to=alexemidio@ln.tips

Obs: o teclado do celular pode adicionar "=" a mais ou corrigir " &to " com "&tô" assim escrevendo errado, tanto erro no link.

" SWAP " transferência de uma carteira para outra.
Pressione " INTER-MINT SWAP"

A carteira que você selecionar em cima é a carteira de saídas e a carteira de baixo e a carteira de entrada.

Agora digita o valor que quer fazer o SWAP.
Após Pressione " CONFIRM AMOUNT"

Depois Tem que pressionar " SWAP " não esqueça.

Pronto antes a primeira Carteira tinha 10 Ecash, e segunda carteira tinha 8 Ecash.

Somando 18 Ecash.

Apois o SWAP Agora as duas tem 9.

Somando 18.

Fazer o backup da sua carteira cashu ecash.
Pressione " BACKUP TOKENS "

Você pode editar o nome do backup
E pode alterar o local aonde vai salva o arquivo 📂 do backup.
Depois só pressionar " Baixar "

Agora pra recuperar a carteira cashu ecash.
Pressione " RESTORE "

Pressione " CONTINUAR "

Click no espaço em branco vai abrir pra encontrar o arquivo 📂 Do backup..

Selecionar o arquivo 📂 de backup.

Pressione " CONTINUE"

Pressione " CONTINUE"

Backup feito com sucesso.
Só aberta " Ok "

O eCash pode ser útil em diversas situações, oferecendo várias vantagens. Uma das principais vantagens do uso de tokens eCash é a privacidade que oferece. Como as transações usando eCash são quase impossíveis de rastrear, isso pode ser útil para quem deseja manter sua atividade financeira privada.
O eCash pode ser especialmente útil para Pagamento de serviços em áreas rurais , pode ser difícil acessar serviços financeiros tradicionais, como bancos ou caixas eletrônicos. O uso de tokens eCash pode permitir que as pessoas paguem por serviços como transporte , serviços de saúde ou eletricidade sem a necessidade de viajar para áreas urbanas.
No entanto, é importante lembrar que o uso do eCash ainda apresenta riscos e desafios. Como o eCash cashubtc ainda é bem novo , pode haver falhas de segurança ou outras vulnerabilidades que ainda não foram identificadas use com cautela poucos Sats.

Obrigado por ler, e espero que você dedique alguns minutos para experimentar o eCash e ver do que se trata melhor.

Alguma artigos e vídeos a baixo.

https://cashu.space/

https://docs.cashu.space/

https://github.com/cashubtc/

https://youtu.be/UNjVc-WYdgE

https://youtu.be/_XmQSpAhFN4

https://youtu.be/zdtRT7phXBo

https://maxmoney.substack.com/p/ecash-for-better-bitcoin-privacy?utm_source=substack&utm_campaign=post_embed&utm_medium=web

https://cypherpunks.venona.com/date/1996/03/msg01848.html

Encontre-me ou envie um zap para nostr alexemidio@ln.tips alexemidio@alexemidio.github.io

Twitter: alexemidio7

Swap da Lightning Network (LN) para Bitcoin Onchain utilizando a plataforma Boltz.

Basta acessar o site Onion da Boltz:

http://boltzzzbnus4m7mta3cxmflnps4fp7dueu2tgurstbvrbt6xswzcocyd.onion/

Também é possível visitar o site oficial em:

https://boltz.exchange/

Primeiro, selecione qual tipo de Swap deseja realizar, por exemplo, você pode escolher LN para Bitcoin Onchain. Em seguida, insira o endereço Onchain de sua carteira. Após isso, basta efetuar o pagamento da fatura LN com o valor necessário e o Swap será concluído com sucesso!

Criar Atomic Swap.
O pagamento inclui taxas de serviço de rede e boltz Enviar Mín .: 50.000 , Máx .: 1.000.0000

Para melhorar a resistência à censura e a privacidade, o Boltz não está disponível nas lojas de aplicativos, mas pode ser instalado como Progressive Web App (PWA) em todos os dispositivos Android e iOS, bem como em computadores desktop.

Como instalar o Boltz como App PWA.

Android.

1. Abra https://boltz.exchange/ em um navegador móvel como chorme ou Vanadium abra o menu do navegador e toque em "Instalar aplicativo":
   

2. Confirme em "Install":
   

3. Agora você encontra o Boltz como ícone do aplicativo na tela inicial, que pode ser usado como qualquer outro aplicativo.

iOS

1. Abra https://boltz.exchange/ em seu navegador móvel Safari e toque no botão de compartilhamento
   

2. Toque em "Adicionar á tela incial ":
   

3. Confirme tocando em "adicionar ":
   

4. Agora você encontra o Boltz como ícone do aplicativo na tela inicial, que pode ser usado como qualquer outro aplicativo.

Desktop

1. Aqui está um exemplo de como instalar o Boltz como aplicativo em um computador desktop Ubuntu usando Chromium: Abra https://boltz.exchange/ e clique no ícone de instalação que aparece automaticamente:

2. Confirme clicando em "Install":
   

3. Agora você encontra o Boltz como ícone do aplicativo em sua coleção de aplicativos:
   

Também pode executá-lo localmente:

Incentivamos nossos usuários técnicos a verificar o código e executar o aplicativo da web localmente a partir da fonte, seguindo as instruções abaixo.

Dependências.

Certifique-se de ter o Node.js LTS e NPM mais recente instalado. Recomendamos usar o nvm para gerenciar instalações do npm: nvm install --lts

Execução.

Clone o repositório, mude para a pasta do projeto e execute
" npm install " para instalar todas as dependências. Em seguida, execute " npm run mainnet " e " npx serve dist " para iniciá-lo.

Abra: http://localhost:3000

no seu navegador e comece a trocar!

https://github.com/BoltzExchange/boltz-web-app#run

https://docs.boltz.exchange/

O coinjoin é uma técnica poderosa de privacidade para aqueles com um conhecimento intermediário do Bitcoin. Aprender o que é o coinjoin e como ele funciona pode ser uma ferramenta valiosa para sua caixa de ferramentas no mundo do Bitcoin. Antes de entrarmos em detalhes, é fundamental compreender o funcionamento dos endereços e das UTXOs (Unspent Transaction Outputs) do Bitcoin, bem como os princípios básicos da privacidade no Bitcoin.

Para começar, todas as transações padrão do Bitcoin são registradas publicamente na blockchain. Isso significa que se alguém identificar um endereço como pertencente a você, poderá rastrear o saldo desse endereço e acompanhar como seus Bitcoins são movimentados. No entanto, ao enviar Bitcoin para um coinjoin, você torna extremamente difícil para qualquer pessoa continuar associando UTXOs ou partes específicas de Bitcoin à sua identidade. Em essência, os coinjoins permitem que você recupere a privacidade perdida e, em certa medida, corrija erros de privacidade cometidos no passado.

Agora, vamos explorar como os coinjoins funcionam. O conceito é relativamente simples. Um coinjoin é uma colaboração sem confiança entre várias pessoas para criar uma transação. Na forma mais básica, cada pessoa envolvida contribui com uma quantia igual de Bitcoin como entrada para a transação e, em seguida, recebe essa mesma quantia de Bitcoin de volta como saída. Para ilustrar, considere este exemplo:

Imagine um coinjoin envolvendo você e mais quatro participantes. Cada pessoa retira 0,05 Bitcoin de um endereço vinculado à sua identidade e paga uma taxa para contribuir para a transação global. Após a transmissão e confirmação da transação, cada pessoa recebe 0,05 Bitcoin de volta como um novo UTXO em um novo endereço de carteira que controlam. As cinco novas addresses que recebem os UTXOs devem ser anônimas, o que significa que qualquer observador da blockchain não terá ideia de qual delas pertence a você. Mas Claro Você pode participar de múltiplos coinjoins com um número muito maior de participantes.

Aumento no número de maneiras pelas quais as coinjoins da Whirlpool podem ser interpretadas na cadeia

5 entradas/5 saídas = 1.496 interpretações (existentes)

6 entradas/6 saídas = 22.482 interpretações

7 entradas/7 saídas = 426.833 interpretações

8 entradas/8 saídas = 9.934.563 interpretações

Lembre-se de que, após submeter Bitcoins a um coinjoin, eles podem novamente ser associados à sua identidade por meio de ações subsequentes, como enviar Bitcoin para um serviço financeiro que conhece a sua identidade, o Bitcoin será naturalmente vinculado a você aos olhos desse provedor de serviços. #Bitcoin #privacidade

https://medium.com/oxt-research/understanding-bitcoin-privacy-with-oxt-part-1-4-8177a40a5923

https://medium.com/oxt-research/understanding-bitcoin-privacy-with-oxt-part-2-4-20010e0dab97

https://medium.com/oxt-research/understanding-bitcoin-privacy-with-oxt-part-3-4-9a1b2b572a8

https://medium.com/oxt-research/understanding-bitcoin-privacy-with-oxt-part-4-4-16cc0a8759d5

https://medium.com/samourai-wallet/introducing-whirlpool-surge-cycles-b5b484a1670f

https://medium.com/samourai-wallet/diving-head-first-into-whirlpool-anonymity-sets-4156a54b0bc7

https://blog.samourai.is/why-we-coinjoin/

https://docs.samourai.io/whirlpool

https://youtu.be/0YwiL978p1c?si=DRZNEH_aHKHjb2-m

Esse guia foi baseado na postagem da Samourai Wallet , Basicamente vamos seguir o que está escrito abaixo.

Vamos Precisa de dois aplicativos pra verificação do aplicativo samourai Wallet.

OpenKeychain
HashEasily

Primeiramente baixe a carteira samourai Wallet no Site oficial : https://samouraiwallet.com/download

-Importar a chave pública PGP do desenvolvedor.

-Verifique se a impressão digital hash foi assinada pela chave PGP do desenvolvedor.

-Execute o hash sha256 no arquivo baixado.

-Compare visualmente as duas impressões digitais hash.

-antes de instalação da Samourai wallet desligue rede , Wi-Fi, Bluetooth é coloque em modo avião.

-Instale a Samourai Wallet.

Vídeo com a explicação pra fazer a verificação da carteira Samourai wallet em 1:40 e bem curto vídeo.

Você Pode baixar e verificar no celular online e passa pro celular offline via cabo OTG ou Bluetooth.

• Por padrão, a MAINNET está habilitada. Toque em "Ok".

• Começar e avance nas configurações.

• Vai aparecer esse mensagem pra escolher o local pra guarda o arquivo criptografado com sua passphase e PIN escolha um local ou criar uma pasta nova. No caso não vamos salva , se for utilizar o celular com hardwallet salve o backup.

Toque em "criar uma nova"

Atenção agora vamos pro próximo passo muito IMPORTANTE e que demanda muita atenção e cuidado. Você vai criar uma passphase pra sua carteira , é padrão tem que ter a passphase.

Atenção! A passphase deve ser algo fácil de lembrar, mas que ao mesmo tempo , não seja tão óbvio.

Use sua imaginação , guarde na sua mente a passphase, não vai no óbvio. Igual a passphase que usei " testesamourai "

Toque em “ próximo ”

Agora próximo passo é Definir o Código PIN.
PIN pode ter de 5 a 8 números.
Novamente escolha um PIN fácil de lembrar mas não tão óbvio.

Após escolher o PIN digitar duas vezes vai pra próxima tela só toque em Avança.

Atenção agora vamos pro próximo passo muito IMPORTANTE e que demanda muita atenção e cuidado. O aplicativo te impede de tira print da tela. Pra você não deixa essa informação importante exporta em nenhum local , não guarde online essa informação.

ESCREVA AS 12 PALAVRAS NO PAPEL.

escreva com calma é atenção de uma forma legível de preferência letra de Forma , Após escreve todas as palavras revise se escreveu corretamente.Você pode escrever em vários papéis pra guarda locais diferentes.

Se voce perde essa palavras , você numca mais terá acesso aos Seus Bitcoin guarde bem as palavras..

Apos anotar as palavras no papel só dá toque em “ avança”

Vai aparece a sua passphrase pra você certificar que é exatamente o que você digitou verifique e guarde bem na sua mente de preferencia.

Ter um toque em “ SKIP” e pronto carteira feita totalmente off-line.

Depois pra testa se anotou corretamente as Seed pode apagar a carteira e testa backup Seed novamente.

Lado esquerdo superior toque no símbolo do robô depois em
"configurações"

Toque na opção “carteira”

Na última opção "apagar a carteira de forma segura"

Pronto foi apagado só fazer o procedimento de recuperação da Seed.

Toque na Opção " Restore uma carteira existente"

Toque na opção de recuperação da sua carteira de bitcoin com seed e passphase.

Após fazer a verificação que deu certo o backup da Seed ,Agora vamos pro próximo passo.

Prepare-se para configurar sua carteira Sentinel, uma aplicação móvel exclusivamente voltada para visualização que permite monitorar saldos e transações em suas carteiras Bitcoin. Essa carteira é projetada de forma a nunca ter acesso às suas chaves privadas, assegurando a proteção dos seus fundos.

O Sentinel é capaz de rastrear diversos tipos de endereços Bitcoin e chaves públicas estendidas. Além disso, oferece funcionalidades como a criação de PSBTs (transações de bitcoin parcialmente assinadas), permitindo que sejam assinadas offline pela sua carteira Samourai ou carteira de hardware.

Ao utilizar o Sentinel, você pode gerar facilmente endereços de recebimento de bitcoin a partir de qualquer uma das suas chaves públicas rastreadas. Além disso, o aplicativo oferece integração nativa com o Tor, proporcionando roteamento seguro no Sentinel.

Para começar, faça o download da carteira Sentinel no site oficial: https://samouraiwallet.com/download

Realize a mesma verificação feita na primeira etapa com a Samourai Wallet.

Em seguida, toque na opção "Configuração".

Toque na opção "configuração"

Toque na opção "exibir SegWit ZPUB" Quando você quiser adicionar endereços de sua carteira Samourai ao Sentinel, basta inserir a chave pública estendida (geralmente zpub para endereços SegWit bech32 nativos).

Com esse código ou qrcode só basta baixa a carteira de visualização da Samourai a Sentinel e pronto adicionar Zpub pra visualização do saldo. Pronto agora é só apagar a carteira samourai Wallet e desinstalar o app ou ficar com a carteira samourai airgap você cria transações offline com o Sentinel, assinar com sua carteira Samourai offline e as transmite com o Sentinel. Parabéns, você acabou de economizar mais de R$500 em uma "carteira de hardware" para a qual você precisa anotar as 12 palavras de qualquer maneira.
Este guia é especialmente dedicado aos iniciantes que estão no início de sua jornada no universo do Bitcoin, buscando opções acessíveis para começar. Ao seguir os passos abaixo, mesmo com recursos limitados, é possível criar uma carteira segura e iniciar sua trajetória no mundo do Bitcoin.

https://medium.com/@alexemidio/samourai-wallet-um-carteira-de-bitcoin-pra-ruas-3003ebb79e57

https://blog.ronindojo.io/discover-version-5-0-0-of-sentinel/

COMO FUNCIONAM OS PAGAMENTOS SILENCIOSOS, SIMPLIFICADOS
Antes de nos aprofundarmos no motivo pelo qual estou entusiasmado com os Pagamentos Silenciosos, é importante que você entenda em um nível muito simplista como os Pagamentos Silenciosos funcionam tanto para o remetente quanto para o destinatário.
PARA O REMETENTE
Quando alguém deseja enviar fundos para um endereço de pagamento silencioso, na prática, tudo o que precisa fazer é digitalizar ou copiar/colar o código de pagamento em sua carteira favorita (supondo que seja compatível) e enviar o pagamento normalmente. Mas o que exatamente está acontecendo nos bastidores?
Quando o remetente insere o endereço de Pagamento Silencioso em sua carteira, sua carteira combina três chaves para criar um endereço único e único, do qual apenas o destinatário pretendido pode gastar. Esse endereço exclusivo é criado combinando a chave pública (ou “endereço”, em termos leigos) de uma das entradas que o remetente deseja passar para o destinatário, a chave pública do destinatário (contida no endereço de pagamento silencioso), e uma chave “segredo compartilhado” que o remetente gera e que apenas o remetente e o destinatário conhecem. Graças a algo conhecido como propriedade “comutativa” na criptografia, o remetente pode combinar essas chaves, mas não pode gastar do endereço resultante , pois não conhece a chave privada do destinatário (é claro).
Quando o remetente combina essas três chaves, ele gera uma nova chave pública (ou endereço) e envia os fundos pretendidos para esse novo endereço que somente o destinatário controla. Na cadeia, esta transação se parece exatamente com qualquer outro gasto de tipo e script semelhantes, e não há nenhum fator distintivo que torne aparente para observadores externos que um Pagamento Silencioso foi usado, muito menos quem possui o endereço de Pagamento Silencioso.
PARA O DESTINATÁRIO
Assim que chegarmos ao destinatário, veremos onde entra a principal desvantagem dos pagamentos silenciosos. Se você se lembra de que o remetente usa a chave pública de uma entrada que está sendo gasta para gerar o endereço único e único, pode estar se perguntando: “Como o destinatário sabe que recebeu fundos e para qual endereço?”
Esta questão está no centro da proposta de pagamentos silenciosos e significa que os destinatários precisam fazer uma varredura relativamente cara de todas as transações na blockchain do Bitcoin depois de criarem seu endereço de pagamento silencioso. Essa varredura permite que o destinatário veja se uma chave pública de entrada mais um segredo compartilhado gerado usando seu endereço de pagamento silencioso e uma chave pública de saída em qualquer transação corresponde adequadamente às suas chaves privadas e, se for o caso, adicioná-la à carteira.
Essa varredura é bastante cara em comparação com a varredura de carteira Bitcoin padrão, pois você não pode simplesmente comparar uma lista de endereços derivados de sua carteira com uma lista de saídas de transações para obter o saldo de sua carteira. Em vez disso, você precisa passar por cada transação, calcular o segredo compartilhado para cada entrada e comparar com as saídas, algo que Somsen comparou a “verificar cada assinatura duas vezes, em vez de uma vez” em “Bitcoin Explained ” .
Idealmente, essa varredura será feita durante o download do bloco inicial (a primeira vez que você sincronizar todo o blockchain do Bitcoin) ou um software autônomo que descarregue a varredura de sua carteira e nó Bitcoin.

OTIMIZANDO O TEMPO DE DIGITALIZAÇÃO PARA O DESTINATÁRIO

Embora essa varredura seja computacionalmente cara, ela pode se tornar mais eficiente sem sacrificar a privacidade ou a fungibilidade por meio de três otimizações principais:

1. Crie uma data de “aniversário” ao criar um endereço de pagamento silencioso e salve-o, para que, quando precisar restaurar, você possa começar a digitalizar apenas a partir desse bloco adiante na cadeia, em vez do bloco de gênese.

2. Verifique apenas as saídas Taproot, pois muito poucas saídas na cadeia são atualmente Pay-to-Taproot (“ P2TR ”), isso eliminará uma grande porcentagem de transações e reduzirá bastante o tempo de verificação. Idealmente, isso se tornará menos útil à medida que o Taproot for mais usado, mas provavelmente será uma otimização extremamente eficaz por algum tempo.

3.Verifique apenas o conjunto UTXO em vez de verificar todas as transações históricas, pois você está preocupado apenas com saídas novas, recebidas e não gastas destinadas ao seu endereço de pagamento silencioso. Isso tem a desvantagem de não fornecer histórico de transações e exigiria um banco de dados adicional sobre os métodos normais.

Artigos sobre Silent Payments 🤫

https://bitcoinmagazine.com/technical/silent-payments-make-bitcoin-more-private

https://bitcoinmagazine.com/technical/silent-payments-improve-privacy-without-bitcoin-data

https://bitcoinmagazine.com/technical/bitcoin-silent-payments-secret-keys

https://bitcoinmagazine.com/technical/improving-bitcoin-privacy-with-silent-payments

https://foundationdevices.com/2023/02/making-sense-of-stealth-addresses/

Videos sobre Silent Payments 🤫

https://youtu.be/vOCWO_zX7X8

https://youtu.be/42PMLaz7Avk

https://youtu.be/YCMaqS-LhLc

Space sobre Silent Payments 🤫

https://twitter.com/bitcoinoptech/status/1668949342814609408?t=UY6nEc0ghPiPxgfydUzW6w&s=19
Recompensa pra carteira mobile suporte ao Silent Payments 🤫

https://twitter.com/gladstein/status/1684567103297445888?t=tY6WQ8fzPn3vNs_YrvXDmQ&s=19

BIP 352 Silent Payments 🤫

https://github.com/bitcoin/bips/pull/1458#issuecomment-1613507274

Mercury Layer é uma implementação de um protocolo statechain de camada 2 que permite a transferência e liquidação fora da cadeia de saídas de Bitcoin que permanecem sob a custódia total do proprietário o tempo todo, enquanto se beneficia de transações instantâneas e de custo zero. A capacidade de realizar esta transferência sem exigir a confirmação (mineração) de transações em cadeia tem vantagens em uma variedade de aplicações diferentes.

um sistema de transferência e controle de propriedade do Bitcoin, especificamente focado em saídas de transações não gastas (UTXOs),

um resumo detalhado dos principais elementos e procedimentos do sistema:

1. Saída de Transação Não Gasta (UTXO): UTXO é a unidade fundamental que representa valor e propriedade no Bitcoin. Cada UTXO é identificado por um ID de transação (TxID) e um número de índice de saída (n) e possui duas propriedades essenciais: valor em BTC e condições de gasto, definidas em um Script. As condições de gasto geralmente envolvem uma chave pública que requer uma transação assinada com a chave correspondente.

2. Transferência de Propriedade sem Transação On-Chain: O sistema permite a transferência de propriedade de UTXOs controlados por uma única chave pública (P) de uma parte para outra sem a necessidade de executar transações na cadeia (on-chain) do Bitcoin ou alterar as condições de gasto. Isso é facilitado por um mecanismo chamado "Statechain Entity" (SE).

3. Compartilhamento de Chave Privada: A chave privada (s) para a chave pública P é compartilhada entre o SE e o proprietário. No entanto, nenhuma das partes conhece a chave privada completa. Isso requer cooperação entre o proprietário e o SE para gastar o UTXO.

4. Atualização/Transferência de Chave: A propriedade do UTXO pode ser transferida para um novo proprietário através de um processo de atualização de chave. Isso envolve a substituição do compartilhamento de chave privada do SE para que corresponda ao compartilhamento de chave do novo proprietário, tudo sem revelar compartilhamentos de chave ou a chave privada completa.

5. Transações de Backup: Além da transferência de propriedade, o sistema inclui transações de backup que podem ser usadas para reivindicar o valor do UTXO pelo atual proprietário, caso o SE não coopere ou desapareça. Essas transações são assinadas cooperativamente pelo proprietário atual e pelo SE e possuem um bloqueio de tempo (nLocktime) que permite a recuperação dos fundos em uma altura de bloco futura especificada.

6. Mecanismo de Redução do Backup de Timelock: Para limitar o número de transferências possíveis durante um período de tempo, o sistema utiliza um mecanismo de decremento do nLocktime. O usuário é responsável por enviar as transações de backup no momento adequado.

7. Cadeias Estaduais (Statechains): O sistema opera usando cadeias estaduais, que são uma camada adicional que permite a transferência de propriedade de UTXOs. O SE precisa seguir o protocolo, mas não armazena informações sobre compartilhamentos de chave anteriores.

8. Cegagem (Blinding): O servidor da camada Mercury (SE) é cego, o que significa que não tem conhecimento das moedas que está assinando. Isso é alcançado através do uso de criptografia de chave pública para ocultar informações de chave privada compartilhada entre as partes.

9. Protocolo de Camada Mercury: O protocolo detalha os procedimentos desde o depósito inicial até a transferência de propriedade, atualizações de chave, retiradas ordenadas e recuperação de backup.

10. Recuperação de Backup: Caso o SE não coopere ou desapareça, o proprietário atual pode recuperar os fundos, enviando a transação de backup quando o nLocktime for atingido.

11. Publicação de Compartilhamento de Chaves: O SE não tem acesso aos IDs de transação individuais das moedas, mas publica compartilhamentos de chaves públicas para cada moeda na lista de ativos. Essa lista é comprometida com a blockchain para provar a exclusividade da propriedade.

Este sistema é projetado para fornecer uma maneira segura e eficiente de transferir e controlar a propriedade do Bitcoin, permitindo a recuperação de fundos em caso de problemas com o servidor.

No sistema de controle de propriedade de saídas de transações não gastas (UTXOs), cada UTXO é uma chave compartilhada composta por duas partes: o proprietário e o servidor de compartilhamento. Juntos, eles colaboram para criar transações de backup com bloqueio de tempo, que transferem a propriedade da UTXO para o novo proprietário. Durante essa transferência, a chave pública compartilhada permanece inalterada, mas o compartilhamento da chave do servidor é atualizado por meio de um Protocolo de Computação Multifuncional (MPC) para se alinhar apenas com o novo proprietário. Essa atualização resulta na criação de uma nova transação de backup, direcionada à chave pública do novo proprietário, com um tempo de bloqueio mais curto.

A confiabilidade do servidor é essencial, pois ele é responsável por excluir o compartilhamento de chave anterior. Isso garante que não seja possível conspirar com os proprietários anteriores. O proprietário atual pode gastar a UTXO a qualquer momento, desde que o faça em cooperação com o servidor. No entanto, se o servidor for desligado ou desaparecer, o proprietário atual deve aguardar até que o tempo de bloqueio expire antes de enviar sua transação de backup.

É importante ressaltar que o remetente nunca possui a chave privada completa; ele possui apenas uma parte do compartilhamento. Assim, todas as transações requerem a assinatura conjunta do servidor. Quando a UTXO é transferida para um novo proprietário, o compartilhamento do servidor é atualizado para que ele não possa mais assinar em nome do proprietário anterior, apenas em nome do novo proprietário. Esse sistema de transações de backup com bloqueio de tempo é projetado para proteger contra cenários de não cooperação ou apreensão do servidor, garantindo a segurança das UTXOs e a integridade da rede.

https://github.com/layer2tech/mercury-wallet

https://mercurylayer.com/

https://twitter.com/TTrevethan/status/1689929527420387328?t=0f5oF6w_ZRjWRYGah3HX8Q&s=19

• Schnorr Signatures (BIP 340)

• Taproot (BIP 341)

• Tapscript (BIP 342)

• Melhor privacidade;

• Redução de custos para transações multisig;

• Melhorias no Lightning Network com PTLCs e chaves agregadas como âncoras de canal;

• Uma série de melhorias em scripts com DLCs, assinaturas de adaptadores e Taptrees.

Uma das principais mudanças Taproot é o novo tipo de saída chamado P2TR, que é mais eficiente em termos de espaço de bloco e utiliza assinaturas Schnorr em vez de ECDSA. As assinaturas Schnorr são menores e permitem a agregação de várias assinaturas em uma única assinatura. Isso possibilita recursos interessantes, como a agregação de chaves, assinaturas de adaptadores e o uso do Taptree.

O Taptree é uma maneira de usar tanto assinaturas de chave única quanto multisig, permitindo maior flexibilidade na transação.

o Tapscript é compatível com o Miniscript, facilitando o desenvolvimento de contratos inteligentes. PTLCs são uma alternativa mais eficiente aos HTLCs na Lightning Network.
Com Taproot, as transações multisig serão mais baratas e as transações de chave única e multisig serão praticamente indistinguíveis, melhorando a privacidade dos usuários.

As melhorias no Lightning Network permitirão a utilização de PTLCs e chaves agregadas como âncoras de canal, aumentando a eficiência e a segurança da rede.

Taproot é uma atualização que trazendo uma série de benefícios significativos e tornando a rede mais eficiente e flexível em sua funcionalidade.

bips/bip-0340.mediawiki at master · bitcoin/bips
https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

https://murchandamus.medium.com/2-of-3-multisig-inputs-using-pay-to-taproot-d5faf2312ba3

https://b10c.me/blog/006-evolution-of-the-bitcoin-signature-length/

https://suredbits.com/payment-points-part-1/

https://bitcoinops.org/en/topics/adaptor-signatures/

https://tlu.tarilabs.com/cryptography/introduction-schnorr-signatures

https://tlu.tarilabs.com/cryptography/introduction-schnorr-signatures

https://bitcoin.sipa.be/miniscript/

https://learnmeabitcoin.com/technical/p2pk

https://twitter.com/TorqLN/status/1647605539486957575?s=19

https://twitter.com/TorqLN/status/1693335249927749869?s=19

https://twitter.com/TorqLN/status/1688190723869356032?s=19

1. Instalação do Tails:

   • Baixe a imagem do Tails no site oficial (https://tails.boum.org/).

  - depois baixar no site vai Aberta " verificar seu  download"
Você vai Verifique no próprio site se o tails que você baixou é tails compilado e desenvolvido pelo equipe Tails.

• Grave a imagem do Tails em um pendrive ou cartão de memória usando um software de gravação adequado, como o Rufus.

• Reinicie o computador e inicie a partir do pen drive ou cartão de memória que contém o Tails. Certifique-se de configurar o computador para inicializar a partir de um dispositivo externo.

• Siga as instruções na tela para completar a configuração do Tails.

2. Configuração do disco persistente:

   • Após iniciar o Tails, defina uma senha para criptografar o disco persistente.

   • Abra o menu "Applications" e selecione "Favorites".

   • Em seguida, escolha "Configure Persistent Volume".

   • Selecione as opções para salvar no seu pendrive no disco persistente.

   • Procure pela opção Bitcoin client e habilite-a.

   • Essa senha é necessária para acessar e salvar seus arquivos e configurações persistentes, incluindo a carteira Electrum.

   • No menu do Tails, clique em "Applications" e, em seguida, em "Internet". Selecione "Electrum Bitcoin Wallet".

   • O Electrum será iniciado e você poderá criar uma nova carteira selecionando "Criar uma nova carteira" e escolhendo um nome para a carteira.

   • Selecione "Carteira padrão" e escolha se deseja criar uma nova carteira ou restaurar a partir de um backup.

   • Se optar por fazer o backup da carteira, selecione a opção "semente BIP39".

   • Se desejar adicionar uma passphrase à carteira Electrum, clique no botão "Opção" e escolha "Estender esta semente com a palavra personalizada". Insira uma passphrase forte e siga as instruções para concluir a configuração da carteira.

Anote e guarde a passphrase em um local seguro, separadamente das palavras-chave de recuperação (seed).

Depois Aberta em "próximo"
Vai aparece a Tela "Tipo de script e caminho derivação"
Selecionar a opção "Native segwit (p2wpkh) aberta em "próximo" agora vai aparecer uma tela pra adicionar senha para criptógrafa o arquivo da carteira electrum. So insira uma senha.

Obs: você tem três senha diferente pra lembrar.
Senha disco persistent.
Senha passphrse.
Senha criptógrafa o arquivo da carteira electrum.

Anote e guarde a passphrase em um local seguro, separadamente das palavras-chave de recuperação (seed).

• guarde em um local seguro as palavras-chave de recuperação (seed) fornecidas pelo Electrum. Essas palavras são importantes para recuperar sua carteira se você perder o acesso ao Tails.

Parte 2: Assinatura e envio da transação

Assinatura da transação no Tails (offline):

• Desconecte o computador do Tails da internet, removendo o cabo de rede ou desativando a conexão Wi-Fi.

1. No tails vai na opção "Carteira" logo em seguida na opção "informações da carteira"
   Depois Aberta em exibe o QR Code da chave pública XPUB que está no Tails.

Configuração do celular:

   - No seu celular, abra a carteira Electrum e clique na opção "Criar nova carteira".

   - Atribua um nome à carteira e, em seguida, selecione a opção "Carteira padrão" (Standard Wallet) seguida da opção "Usar chave mestra" (Use Master Key).

   - Agora, você precisará escanear com a câmera do celular o código QR da chave pública XPUB que está no Tails. Essa chave mestra permitirá que você acompanhe o saldo e as transações da sua carteira, mas não poderá gastar os fundos ou assinar transações diretamente.

   - Toque em "Próxima" para iniciar o processo de sincronização da carteira no celular.

Pra recebe pagamento com o celular deixa o Tails totalmente offine.

É Só ir na Aba "recebe" depois em "pedir"

Você pode copiar o endereço ou exibe o Qrcode pra pagamento. você pode verificar que o endereço de recebe que aparece no celular eo mesmo que está no seu Tails offine.

Pra enviar vai na Aba "enviar"

Aberta em "escanear" verificar as informações endereço é escolher o valor da taxa.

Depois Aberta em "pagar"

Vai parece um aviso "transação teve ser substituível ?"

Aberta em "sim" Se a taxa foi muito baixa não confimar nos próximos dias para poder aumentar se precisar.

Vai exibe na tela a quanti a enviar é total taxa de mineração
Aberta em "concluir"

Vai mostra quantia a ser enviada ID da transação de saída mas ela não está assinada. Atráves do Qrcode que está no celular você vai exibir Qrcode que você vai escanear com a câmara Web do seu Tails

Vai volta no Tails na opção "ferramentas"

• logo em seguida escolhar a opção "carregar transação"

depois na opção "a partir de um código Qr" vai abrir a câmera do Tails você mostra o código Qr que está no celular para a câmera Tails.

No tails vai mostrar todas as informações da transação.
Após confimar as informações da transação, clique em "Assinar"

Digite a senha da carteira Electrum para desbloquear a chave privada.

Em seguida, clique em "Exportar" e selecione a opção "Mostrar como um código QR"

No celular aberta em "escanear"
O código Qr da transação assinada.

Vai aparecer na tela do seu celular Status da transação assinada é informações da transação.

Então finalmente você aberta em "Transmitir" para enviar a transação assinada para a rede Bitcoin.

Ao optar por usar o Tails como base para criar e assinar transações, você está garantindo a segurança da sua chave privada no ambiente protegido do Tails, enquanto utiliza o celular apenas para visualizar informações e enviar a transação assinada para a rede.

Uma medida adicional de segurança é a criptografia do disco persistente do Tails com uma senha forte, juntamente com o uso de senhas fortes para proteger a carteira Electrum e a chave privada. Essas camadas extras de proteção ajudam a manter suas informações seguras.

É fundamental tomar todas as precauções necessárias para proteger seus dispositivos. Certifique-se de manter o Tails atualizado, utilizar software confiável para gravá-lo em um pendrive ou cartão de memória, e proteger adequadamente seu dispositivo móvel com senhas e atualizações de segurança.

Embora essa abordagem ofereça uma camada mais segura para proteger sua chave privada durante o processo de envio de transações, é importante lembrar de fazer backups regulares das suas palavras-chave de recuperação (seed). Além disso, considere tomar medidas adicionais de segurança de acordo com suas necessidades e recursos disponíveis.

Tenha em mente que a segurança absoluta não pode ser garantida, por isso é essencial adotar boas práticas de segurança digital.

Seguindo essas orientações e tomando as devidas precauções, você estará fortalecendo a segurança das suas transações ao utilizar o Tails para criar e assinar transações, mantendo a chave privada protegida no ambiente seguro do Tails, e utilizando o celular de forma segura para enviar a transação assinada para a rede.

https://youtu.be/abXkgXQ8BvI

https://youtu.be/NBj9-TolpvI

Fig. 1. Alice pode enviar um pagamento para Carol roteando-o por Bob. Como as contas não podem sair do cordão em que estão, Bob acaba com uma conta a mais em seu cordão com Alice e uma conta a menos em seu cordão com Carol.

Isso é tudo que você precisa saber para entender como o dinheiro pode fluir na Lightning Network. No entanto, esse modelo não nos diz nada sobre por que os pagamentos na Lightning são seguros. Por exemplo, o que impede Bob de simplesmente manter a conta que Alice empurrou para ele e nunca enviar uma para Carol? O objetivo deste artigo é responder à pergunta "o que torna os pagamentos na Lightning 'sem confiança'?"

Ao final do artigo, revelaremos o sujo segredinho da Lightning Network: que os pagamentos pequenos não são realmente "sem confiança" — nós nós de roteamento podem perder fundos dos clientes.

Contratos Hash-Time-Lock (HTLCs)
Para explicar o que impede Bob de manter a conta de Alice sem enviá-la para Carol, precisamos introduzir "travas" em nossa analogia física para os canais Lightning. Travas podem ser colocadas nos cordões para restringir o movimento das contas e só são abertas se condições específicas forem atendidas. Os contratos hash-time-lock (HTLCs) usados nos pagamentos Lightning envolvem dois tipos de travas (cf. Fig. 2): a primeira é uma trava que se abre se apresentada com a senha correta (vamos chamá-la de "hash-lock"), e a segunda é uma trava que se abre automaticamente após um atraso de tempo (vamos chamá-la de "time-lock").

Fig. 2. O hash-lock se abre quando uma senha é inserida e gera o valor especificado (45f8 neste caso). O time-lock se abre após o tempo especificado ter decorrido (48 horas neste caso).

Agora, voltemos ao pagamento de uma conta de Alice para Carol por meio de Bob. Para tornar o pagamento "sem confiança", Alice, Bob e Carol precisam estar online ao mesmo tempo e participar de um elaborado ritual.

Primeiro, Alice pede a Carol que pense em uma senha secreta e diga a ela o hash da senha. Vamos fingir que a senha que Carol inventou foi "boondoggle" e seu hash foi "45f8". Em seguida, Alice coloca um hash-lock entre ela e Bob, configurado para abrir quando apresentado com uma senha que gera o hash "45f8". Neste ponto, nem Alice nem Bob podem abrir a trava, pois nenhum deles conhece a senha. Alice então empurra uma conta contra o hash-lock. Por fim, ela coloca um time-lock no lado esquerdo da conta, configurado para abrir automaticamente após 48 horas (Fig. 3).

Fig. 3. Com o conhecimento do hash da senha secreta de Carol, Alice pode configurar um hash-lock para proteger a conta que ela transfere para Bob (para depois encaminhar para Carol). Ela trava a conta com um time-lock para que ela possa recuperá-la caso Bob não conclua o pagamento dentro de 48 horas.

Bob percebe que a conta é dele se conseguir descobrir a senha antes de 48 horas se passarem. Ele também sabe (porque Alice disse a ele) que Carol revelará a senha em troca de uma de suas contas. Para incentivar Carol a agir, Bob coloca o mesmo hash-lock entre ele e Carol, empurra uma de suas contas e então a trava com outro time-lock (Fig. 4). Ele sabe que, para Carol abrir o hash-lock e pegar a conta, ela precisará inserir a senha — à vista de todos — que é a mesma senha que Bob precisa para abrir o hash-lock com Alice.

Fig. 4. Bob percebe que a conta de Alice é dele se Carol revelar sua senha antes de 48 horas. Ele configura o mesmo hash-lock, empurra uma conta em direção a Carol e a trava com um time-lock. A única maneira de Carol pegar a conta de Bob é revelar a senha que Bob precisa para reivindicar a conta de Alice.

Carol, ao ver que a conta está lá para ser pega, insere "boondoggle" na trava (lembre-se de que está à vista de Bob). A CPU da trava confirma que hash("boondoggle") = 45f8, e então se abre. Carol move a conta para o lado dela do cordão (Fig. 5).

Fig. 5. Carol revela sua senha para abrir a trava e pegar a conta.

Com o conhecimento da senha de Carol, Bob desbloqueia sua conta de Alice da mesma forma (Fig. 6). O pagamento está completo.

Fig. 6. Com o conhecimento da senha secreta de Carol, Bob pode agora pegar a conta de Alice, completando assim o pagamento.

Você pode se perguntar por que Bob se incomodaria em participar desse ritual em primeiro lugar. Se Carol não tivesse sido cooperativa, sua conta poderia ter sido congelada até que o time-lock expirasse. Na prática, Alice enviaria a Bob um pouco mais do que ela pede a Bob para enviar a Carol, como uma taxa para compensar por esse risco e pelo esforço de Bob. Quando o pagamento estiver completo, Bob terá um pouco mais do que começou, motivando-o assim a concluir o pagamento.

Você também pode se perguntar qual é o propósito dos time-locks. Os time-locks permitem que os participantes recuperem seus fundos se o pagamento falhar. Por exemplo, imagine que Bob se torna não cooperativo depois que Alice transfere sua conta e adiciona os dois locks. O time-lock é o que permite a Alice recuperar seus fundos. Ela só precisa esperar o time-lock expirar. Não há como Bob roubar a conta nesse ínterim, porque ele precisa da senha de Carol, o que ele não pode obter sem dar a Carol uma de suas contas e, assim, completar o pagamento.

Leitores interessados podem explorar o que acontece se uma das partes se tornar não cooperativa em diferentes etapas do processo de pagamento do Lightning para se convencer de que nem Alice, Bob, nem Carol estão em risco de perder dinheiro devido às ações de suas contrapartes.

O Sujo Pequeno Segredo da Lightning Network
A Lightning Network tem um sujo pequeno segredo que poucas pessoas conhecem. Para entender qual é o segredo — e suas ramificações para os pagamentos do Lightning — precisamos cavar um pouco mais.

Lembre-se de que quando Alice enviou o pagamento para Carol através de Bob, o estado intermediário mostrado na Fig. 7 existia. Quando expresso como uma transação de bitcoin, o estado do canal contém três saídas: as moedas de Alice, as moedas de Bob e a moeda "em voo".

Fig. 7. A transação de estado do canal Lightning neste ponto do tempo contém três saídas: as moedas de Alice, as moedas de Bob e as moedas em trânsito.

Aqui está o problema: se o valor em trânsito estiver abaixo do limite de poeira do BTC, então não pode ser representado como uma terceira saída na transação de estado do canal! Portanto, não é possível usar hash- e time-locks para proteger o pagamento se o pagamento for muito pequeno.

Para explicar como o LN lida com esse problema, devo primeiro fazer uma confissão. Não é exatamente verdade que o número de contas em uma string seja constante. Na verdade, há um balde ao lado de cada string rotulado como "Taxa do Minerador" que contém pequenas frações de contas. O valor neste balde é reivindicado pelo minerador que confirma a transação de estado do canal, caso o estado do canal seja empurrado para o blockchain. Frações de contas podem se mover da string para o balde, ou do balde de volta para a string, mas apenas se as pessoas em ambos os lados do canal concordarem.

Em vez de travar o valor em trânsito com hash- e time-locks, para pagamentos pequenos, Alice e Bob simplesmente movem o valor em trânsito para o balde de taxas (Fig. 8). Bob confia que Alice cooperará com ele para retirar o valor em trânsito do balde de taxas quando ele revelar a senha secreta de Carol.

Fig. 8. Se as moedas em trânsito estiverem abaixo do limite de poeira, o mecanismo HTLC não pode ser usado porque a transação de estado do canal não seria minerada se fosse transmitida. Em vez de usar o mecanismo HTLC, as moedas em trânsito são despejadas no balde de "Taxa do Minerador".

Fig. 8. Se as moedas em trânsito estiverem abaixo do limite mínimo ("dust threshold"), o mecanismo HTLC não pode ser usado, pois a transação do estado do canal não seria minerada se transmitida. Em vez de utilizar o mecanismo HTLC, as moedas em trânsito são depositadas no "Miner's Fee" (Taxa do Minerador).

Neste esquema alternativo, Bob transfere o valor em trânsito para um segundo compartimento de taxas que ele compartilha com Carol, prometendo entregá-lo a ela se contar a Bob a senha secreta. Carol revela o segredo a Bob, e juntos movem o pagamento do compartimento de taxas para o lado de Carol. Bob então volta para Alice, conta a ela o segredo de Carol e, se tudo correr bem, Alice coopera com ele para retirar o valor em trânsito do compartimento de taxas e colocá-lo no lado de Bob da sequência.

Ao contrário do esquema HTLC descrito anteriormente, este esquema depende da confiança. Por exemplo, Carol poderia revelar a senha a Bob, que poderia deixar o pagamento no compartimento de taxas e ainda assim ir a Alice e entregar a senha em troca de seu pagamento.

As opções de Carol nesse cenário são limitadas: ou ela não faz nada e aceita a perda, ou ela encerra o canal com Bob. No entanto, encerrar o canal com Bob não a deixa totalmente compensada, pois o valor que ela deveria ter recebido é enviado para um minerador!

Apesar de parecer quebrado, esse esquema realmente funciona razoavelmente bem na prática. Bob não tem um incentivo real para não dar o dinheiro a Carol. Se ele não devolver, ele não ficará em uma situação melhor (o minerador ficará com os fundos extras, não ele) e provavelmente em uma situação pior (Carol provavelmente fechará o canal, já que Bob se mostrou não confiável). O dano que Bob pode causar parece limitado ao valor do pagamento mais o custo de estabelecer um novo canal relâmpago.

Por que isso é significativo
O segredo sujo do Lightning é significativo porque revela como a fricção da Camada 1 (L1) vaza para a L2, forçando soluções complexas e mal compreendidas¹ para o protocolo L2. A solução alternativa neste caso alterou a natureza "sem confiança" dos pagamentos do Lightning: para pagamentos acima do limite de poeira, nem Alice, Bob, nem Carol podem perder dinheiro devido às ações de suas contrapartes. Para pagamentos abaixo do limite de poeira, Alice, Bob e Carol podem perder dinheiro sem culpa própria. É um modelo de segurança fundamentalmente diferente do que as pessoas entendiam.

Alguém poderia argumentar: "estamos falando apenas de pagamentos pequenos, então quem se importa?" Eu não concordo com esse argumento por duas razões:

• O plano de escalonamento do Core, usando o blockchain como uma camada de liquidação com taxas elevadas, aumentará o limite para o que constitui "poeira". Poeira são saídas que não podem ser gastas economicamente porque a taxa on-chain para gastá-las é maior do que seu valor. Com taxas de $100, a maior parte do salário mensal de todo o mundo é "poeira".

• Perder vários pagamentos pequenos em rápida sucessão (por exemplo, devido a um ataque de roteamento no LN) poderia resultar em uma perda significativa.

Imagine um futuro em que a maioria dos pagamentos ocorra na Lightning Network, e as taxas de transação na L1 sejam consistentemente superiores a $100. As saídas de poeira abaixo de $100 na mainchain não têm valor porque custa mais gastá-las do que valem.

Agora a Lightning Network enfrenta o problema de que até mesmo pagamentos de $50 não são "sem confiança". No caso em que $50 estão abaixo do limite de poeira (o que seria uma política razoável considerando que $50 seria economicamente impossível de gastar na L1), então os HTLCs não podem ser usados para proteger o pagamento de $50. Os clientes podem perder pagamentos de $50 sem culpa própria.

No caso em que os desenvolvedores tentam contornar alguma "brecha legal" definindo o limite de poeira como $1 para que os HTLCs ainda possam ser usados, o efeito ainda é uma perda de $50 para o cliente, pois a saída não será economicamente gasta! Os clientes ainda podem perder pagamentos de $50 sem culpa própria.

Alguém poderia argumentar "bem, os nós de roteamento podem perder fundos dos clientes e esses fundos podem ser significativos em um futuro com taxas altas, mas os nós de roteamento são pares, não empresas." Eu também não concordo com isso porque o objetivo principal do roteamento de pagamentos do Lightning é ganhar dinheiro em taxas de transação em troca de empréstimo de liquidez. Já hoje, os desenvolvedores do Lightning abandonaram a ideia de que todos os usuários roteariam pagamentos; agora é incentivado que usuários normais usem canais não divulgados e nunca roteiem.

Em um futuro com altas taxas, um hub tem controle custodial efetivo sobre o dinheiro de seus usuários. Um usuário não pode liquidar no blockchain para recuperar fundos de pagamentos não protegidos por HTLCs. Além disso, se o saldo do usuário estiver na mesma ordem de grandeza das taxas on-chain, o usuário também está preso ao hub. Não vale a pena escapar de um canal "ruim", pois isso custaria ao usuário todo o seu saldo. Hubs também podem bloquear os fundos do cliente indefinidamente, recusando-se a rotear pagamentos a menos que certas condições sejam atendidas (por exemplo, desembrulhar as informações de roteamento de cebola para fins de AML/KYC). A única escolha do usuário é liquidar no blockchain e perder todo o seu dinheiro — o que não é uma escolha real! Hubs também podem roubar seus usuários na forma de taxas exorbitantes. Novamente, o usuário está preso e não tem escolha a não ser pagar se quiser acessar seu dinheiro.

Hubs significativamente conectados na Lightning Network, em um futuro com taxas elevadas na camada base, deveriam ser regulamentados devido ao controle efetivo que possuem sobre os fundos de seus clientes.

Gostaria de propor a hipótese de que o seguinte princípio existe:

Pagamentos na Camada 2, para quantias abaixo do que é economicamente viável na Camada 1, não podem alcançar uma natureza "sem confiança".

A eficácia do Lightning depende da liberdade da blockchain subjacente, alinhando-se com as expectativas dos usuários.

Isso é apenas uma das muitas razões pelas quais um futuro em que a maioria das transações ocorre na Lightning Network e a blockchain possui taxas elevadas será muito diferente do que as pessoas esperam. Outras razões incluem:

• O Lightning dimensiona transações, não usuários. O custo de operar um nó completo de validação ainda será alto.

• A fricção na Camada 1 afeta a fungibilidade na Camada 2; as moedas têm um valor dependente da posição.

• Liquidez: a maioria dos "estados de riqueza" não é alcançável por meio de transações na Lightning. Falhas em pagamentos são inevitáveis.

• Roteamento é difícil se o grafo de rede for extenso: os hubs da Lightning tenderão a se centralizar para reduzir problemas de roteamento e liquidez.

• A experiência típica do usuário ao executar uma carteira não custodial sempre será complicada: os usuários precisam estar online para receber dinheiro, contratar torres de vigilância para monitorar fraudes em canais, assinar serviços de roteamento de origem para enviar pagamentos e fazer backup dinâmico de seus estados de canal contra corrupção de dados.

• Risco sistêmico: uma quantidade muito grande de moedas precisa ser bloqueada em canais da Lightning (carteiras quentes) para fornecer a liquidez necessária.

• As taxas agregadas dos mineradores na Camada 1 não serão suficientes para garantir a segurança da blockchain quando a recompensa por bloco se esgotar.

Esse texto apontar que LN não é “sem confiança” para pequenos pagamentos e que os fundos dos clientes poderiam ser redirecionados para o mineradores sem culpa do cliente. A crença amplamente difundida, mas falsa, dentro da comunidade BTC era que todos os pagamentos Lightning eram “sem confiança” por design .

1. Prova e Verificação:

   • Uma pessoa atua como uma comprovadora, enquanto 99 pessoas são verificadoras.
   • Antes de depositar na sidechain, a comprovadora faz um contrato com os verificadores. Ela coloca 100 BTC como garantia.
   • Se um verificador alegar que alguém fez uma solicitação de saque válida na sidechain, a comprovadora deve provar que processou essa solicitação em X blocos. Caso contrário, qualquer verificador pode penalizá-la, resultando na perda da garantia.

2. Mecanismo de Penalidade e Rotação:

   • Se a comprovadora for penalizada, o próximo verificador na fila assume como a nova comprovadora.
   • Cada verificador também tem 100 BTC como garantia.
   • A nova comprovadora (ex-verificadora) deve provar que processou a solicitação de saque dentro de X blocos ou será penalizada.

3. Segurança em Camadas:

   • A garantia impede comportamentos inadequados, garantindo que todos os participantes tenham algo em jogo.
   • O modelo de pegada dupla oferece camadas adicionais de segurança. Qualquer tentativa de fraude pode ser detectada e punida.

4. Contratos Laterais e Confiança Mínima:

   • Um usuário pode fazer um "contrato lateral" com qualquer verificador. Se uma solicitação de saque válida for apresentada, o verificador deve provar o processamento dentro de X blocos.
   • Não é necessário confiar apenas em uma pessoa; se a comprovadora falhar, ela pode ser penalizada.

5. Prova de Ocorrência em Sidechain:

   • O bitVM requer a capacidade de "provar" que algo aconteceu em uma sidechain.
   • Um cliente leve SPV no bitVM, compreendendo as regras de consenso da sidechain, é essencial.

6. Depósito e Saque:

   • Para depositar, a comprovadora fornece garantia e prova que processará futuras solicitações de saque.
   • Ao sacar, o bitVM valida a solicitação. Se a comprovadora não processar, ela é penalizada, e o usuário recebe 100 BTC de um verificador.

7. Garantia como Parâmetro Variável:

   • Tanto comprovadoras quanto verificadoras devem postar garantias.
   • A quantidade de garantia é um parâmetro variável; mais garantia significa uma sidechain mais segura.

O sidechain bitVM propõe uma abordagem descentralizada e segura, onde a confiança é distribuída e a segurança é reforçada por penalidades significativas. Este modelo inovador tem o potencial de oferecer eficiência e confiança aprimoradas nas transações de sidechain.

Ótima explicação sobre bitVM.
Supertest , Robin .

https://open.spotify.com/episode/6rcOVwcxkzcZRXnVcwKlTq?si=s5E31_HWQEqOoRbzoAzpZQ