Fedimint

Imagine Anna usando uma carteira conectada a uma federação local, cujo e-cash Petr aceita na cafeteria. Não é preciso gerar uma transação Bitcoin separada para cada café. Os aplicativos lidam com tokens emitidos por uma casa da moeda compartilhada, o mint. Os bitcoins continuam na reserva da federação; entre Anna e Petr são transferidos os tokens. Fedimint fornece os componentes, os guardiões operam uma federação específica e a carteira é a interface de Anna. São coisas diferentes. Os módulos padrão cuidam de Bitcoin, Lightning Network e e-cash; outros podem adicionar serviços. Cada federação tem funcionamento e reservas próprios. Seus tokens não valem automaticamente em todas as outras. Mesmo quando os guardiões concordam entre si, as regras da rede Bitcoin continuam valendo. [1] [2]

A federação busca evitar que operações importantes dependam de um único operador. Num limiar ilustrativo 3-of-4, emitir um token exige três partes válidas de assinatura de quatro guardiões. Um indisponível ainda deixa partes suficientes; dois, não. Mas três detentores que cooperem também podem assinar sem autorização do restante. Dividir poderes não garante honestidade nem reservas suficientes. É Counterparty risk: depender de pessoas ou organizações que podem não pagar. A assinatura de e-cash por limiar e Multisig, a autoridade compartilhada sobre a reserva Bitcoin, também cumprem funções diferentes. Verifique as regras da federação escolhida. [3] [4]

Quando Anna deposita bitcoin diretamente pela blockchain, o histórico público das transações confirmadas, o aplicativo fornece uma prova da saída correspondente que a federação deve aceitar segundo suas regras. Cada saída registra um valor e as condições para gastá-lo. Na retirada, a federação monta e assina uma transação Bitcoin a partir da reserva. O token sozinho não dá a Anna uma chave para retirar sem os outros. Essa é uma diferença crucial em relação à Self-Custody, o controle das chaves usadas para assinar seus pagamentos Bitcoin. Ainda são necessários guardiões disponíveis, fundos, taxas e as confirmações exigidas. Transferências internas rápidas não prometem retiradas igualmente rápidas de qualquer valor. [4] [7]

A privacidade do e-cash se apoia numa Blind Signature, uma assinatura cega. O cliente oculta matematicamente o token específico, pede a assinatura e depois remove a ocultação. O resultado é verificável, mas o mint não consegue ligar, pelo token sozinho, seu resgate posterior a um pedido específico de emissão. Para quem quer o detalhe técnico, a documentação descreve assinaturas BLS por limiar sobre BLS12-381, não FROST como assinatura do token. O cliente combina partes válidas suficientes numa assinatura verificável. Cada denominação tem sua chave, portanto ocultar a identidade do token não esconde do mint as faixas de valor emitidas. [3]

Petr pode verificar a assinatura válida da federação. Isso não diz se alguém já resgatou o token. Dados digitais podem ser copiados e Anna talvez conserve o mesmo token. A federação registra então identificadores gastos, chamados nonces, e rejeita seu uso repetido. O destinatário precisa concluir a troca por tokens novos, em vez de confiar na promessa de que outra cópia não será usada. Assinatura autêntica, token não gasto e reserva suficiente são três questões distintas. Verificar uma não responde às demais. [3]

Se a cafeteria aceita um pagamento comum pela Lightning Network, uma gateway, ou ponte de pagamentos, pode cuidar da transferência. Ela conecta a federação à Lightning e precisa de liquidez, ou seja, fundos disponíveis, dos dois lados. Não precisa ser guardiã da federação. A documentação do módulo V2 descreve contratos que condicionam a liberação de fundos ao pagamento e uma pré-imagem, valor secreto revelado quando a condição é cumprida. Falhas têm caminhos de devolução conforme o contrato, mas não há garantia de disponibilidade contínua. Uma ponte indisponível ou sem liquidez pode impedir o pagamento mesmo com o mint funcionando. [5]

Uma assinatura cega impede que o mint relacione a emissão do token ao resgate posterior com base apenas no token. Não elimina todos os rastros. A contraparte pode saber que Anna pagou; a ponte vê dados necessários ao pagamento Lightning; um observador pode comparar horários ou valores. Dados da conexão também podem oferecer pistas. Pergunte sempre o que deve ficar oculto e de quem: guardião, cafeteria, ponte ou observador da rede. Uma circulação mais privada não anonimiza automaticamente todos os depósitos, retiradas e contatos pessoais. [3] [5]

Perder o telefone não significa necessariamente perder os tokens se o aplicativo oferece recuperação corretamente configurada. O projeto documentado usa um valor secreto principal a partir do qual o aplicativo pode recalcular os dados necessários, cópias de estado criptografadas e o histórico disponível da federação. O procedimento depende do aplicativo e da versão; não basta inserir uma Seed Phrase Bitcoin em qualquer carteira. Antes de depender do serviço, teste separadamente a recuperação e uma pequena retirada. O backup ajuda na perda de dados, mas não repõe reservas vazias nem obriga os guardiões necessários a cooperar. [6] [4]