Coisas para saber: |
- O Miniscript torna possível construir carteiras de software Bitcoin que tornam um backdoor impossível de explorar. Temos o prazer de dizer que a Ledger é a primeira fabricante de carteira de hardware comercial a oferecer suporte ao miniscript.
- Os recursos adicionais podem ser implementados sem comprometer a experiência do usuário. |
Os dispositivos de assinatura de hardware são projetados para proteger o usuário de vários vetores de ataque comuns, como:
- Acesso não autorizado e extração da semente
- Malware infectando sua carteira de software associada
- Vulnerabilidades de software no próprio dispositivo
Como em qualquer empresa, é do interesse do fabricante fabricar dispositivos tão inquebrável como eles podem. Ter sucesso nessa missão é fundamental, e empresas de segurança como a Ledger contam com uma reputação construída em seu histórico.
No entanto, alguns usuários ainda podem ter preocupações. O que impede a própria empresa de esconder um Porta dos fundos nos aparelhos?
Em auto-custódia, nós não confie, nós verificamos.
Mas o usuário pode clientes verificar se um dispositivo não tem backdoor?
Essa é a questão-chave em que este artigo se aprofunda. Mais precisamente, este artigo aborda os seguintes tópicos:
- o que é um backdoor e por que é difícil, se não impossível, provar que não existe um;
- por que apenas os usuários podem se proteger desse risco;
- como miniscript permite soluções práticas para este desafio para carteiras de bitcoin.
Por ser a primeira carteira de hardware a suportar miniscrito, esperamos inspirar os desenvolvedores a criar soluções seguras e atualizar todo o nosso setor e eliminar a chance de tal risco sistêmico se materializar.
Como construir o sem backdoor dispositivo de assinatura
Vamos colocar de forma clara: você não pode.
Para se defender contra um possível backdoor, você precisa de um modelo de ataque diferente do descrito acima: nesse cenário, o adversário pode ser o próprio fornecedor ou um insider corrompido.
A solução frequentemente elogiada para esse problema é o código aberto: afinal, se você puder inspecionar o código, o que poderia dar errado?
No entanto, a verdade é mais complexa. Como o fornecedor monta o hardware, um backdoor pode estar totalmente contido nele. O hardware pode ser projetado para desconsiderar o software em determinados pontos e, em vez disso, executar códigos maliciosos.
Ao contrário do software executado em dispositivos de computação de propósito geral (como seu laptop ou telefone), examinar o hardware é praticamente impossível com a tecnologia atual. Mesmo que as especificações de hardware fossem totalmente de código aberto, completas com os detalhes de cada porta do circuito, você ainda precisaria de equipamentos de alto custo para verificar se um chip específico foi construído de acordo com elas.
Como fazer backdoor de uma carteira de hardware
Aqui estão alguns dos métodos mais simples que um fornecedor de hardware malicioso pode usar para introduzir um backdoor, juntamente com algumas maneiras pelas quais os usuários avançados podem se proteger hoje.
Geração de sementes
Muitos dispositivos oferecem a capacidade de gerar uma semente (também chamada de Frase de recuperação secreta) diretamente no dispositivo, usando um Gerador de números aleatórios verdadeiros.
😈 O dispositivo maligno pode gerar sementes que parecem aleatórias, mas na verdade são previsíveis para o invasor.
🛡️ Usuários avançados podem contornar esse problema gerando um mnemônico offline. Além disso, incorporando um robusto passphrase também pode gerar uma semente totalmente independente que o fornecedor de hardware não pode prever. A desvantagem é que os usuários devem garantir o backup adequado da frase secreta, além das palavras mnemônicas.
Derivação de chave pública
As carteiras de hardware derivam e exportam o chaves públicas (também chamado xpubs, abreviatura de chave pública estendida conforme definido em BIP-32. O xpubs são usados para gerar os endereços possíveis para recebimento de moedas.
😈 O dispositivo maligno pode retornar chaves públicas controladas pelo invasor em vez das corretas derivadas da semente.
🛡️ Os usuários podem validar o derivado xpub em outro dispositivo off-line. No entanto, inserir a semente em outros dispositivos traz seus próprios riscos. Os usuários conscientes da segurança podem considerar qualquer dispositivo que tenha acessado a semente como perigoso, potencialmente a ponto de destruí-los. O usuário típico pode se esforçar para executar corretamente este procedimento enquanto gerencia os riscos adicionais.
Vazamento de informações
An espaço de ar é frequentemente proposto como uma solução para impedir que um dispositivo malicioso ou comprometido extraia chaves privadas. Afinal, se um dispositivo não consegue se comunicar com o mundo exterior, ele não pode fazer nada de mal, certo?
Não exatamente!
O dispositivo sempre pode se comunicar quando está em uso: ele produz assinaturas. Essas assinaturas acabam dentro de transações que são transmitidas e armazenadas para sempre no blockchain.
Uma assinatura é uma string de bytes de aparência aleatória de pelo menos 64 bytes. No entanto, como mais de uma assinatura válida pode corresponder à mesma mensagem, um dispositivo malicioso pode comunicar alguns bits de informação toda vez que uma assinatura é produzida, gerando várias assinaturas e escolhendo seletivamente qual publicar.
😈 Um dispositivo não autorizado pode produzir assinaturas não aleatórias que, ao longo de muitas transações, revelam a semente ao invasor!
Um invasor bem-sucedido em instalar esse backdoor teria apenas que esperar que as assinaturas maliciosas aparecessem no blockchain até que tivessem informações suficientes para reconstruir toda a semente.
🛡️ Para assinaturas ECDSA, usando um método padronizado para derivar o nonce de forma determinística (como RFC6979) impede esse ataque, desde que valide que a assinatura produzida corresponde à esperada. No entanto, para garantir isso, é necessário carregar um segundo dispositivo com a mesma semente, o que leva aos mesmos problemas práticos mencionados na seção anterior.
🛡️ Uma abordagem interessante é usar uma forma inteligente de força o dispositivo para realmente escolher um nonce aleatório. Um protocolo para esse fim, conhecido como anti-exfil or anticleptomaníaco, está atualmente implementado nas carteiras de hardware Blockstream Jade e ShiftCrypto BitBox02. Leia mais em blog da ShiftCrypto, que também inclui uma descrição técnica de como tal ataque pode ser executado.
Ok, então, não há esperança?
A maioria das defesas🛡️ listadas acima exigem que o usuário execute ações explícitas e intrusivas para se proteger: seja gerando a semente por conta própria (essencialmente, usando o cérebro para substituir a funcionalidade da carteira de hardware) ou utilizando um dispositivo adicional para verificar se os cálculos são executados corretamente.
No entanto, o protocolo anti-exfil se destaca: como sempre há uma máquina intermediária entre o signatário do hardware e o mundo exterior, essa máquina pode ajudar. Por meio de um protocolo interativo com o signatário do hardware, ele pode aplicar o uso de um nonce genuinamente aleatório, diminuindo ou eliminando assim a chance de manipular significativamente a assinatura final.
Nesta postagem de blog, estamos interessados principalmente nesses tipos de medidas: embora as estratégias que pioram significativamente o UX possam ser atraentes para usuários avançados, elas provavelmente farão as coisas pior na prática para os usuários menos aptos tecnicamente - que é a grande maioria.
O modelo de segurança
Modelo padrão para signatários de hardware
Os fabricantes de signatários de hardware visam proteger os usuários de uma variedade de ameaças potenciais (para obter mais detalhes, consulte Modelo de Ameaça). Neste artigo, nos concentramos em uma propriedade muito importante, que pode ser resumida da seguinte forma:
Os usuários não podem ser enganados em uma ação que resulte em perda de fundos, desde que compreendam e verifiquem as informações na tela antes da aprovação.
A aprovação é necessária para qualquer ação delicada, especialmente assinaturas. Proteger a semente seria inútil se o malware pudesse produzir assinaturas para mensagens arbitrárias, como uma transação que drena todos os fundos!
É crucial enfatizar que a propriedade acima deve ser verdadeira mesmo se a carteira de software estiver completamente comprometida. O que é exibido na tela do seu laptop/telefone não é confiável: o malware pode substituir endereços, enganar você sobre quais endereços são seus, apresentar uma transação, mas encaminhar outra diferente para o dispositivo para assinatura, etc.
Portanto, o firmware e os aplicativos executados em um dispositivo de assinatura de hardware consideram a carteira de software inerentemente não confiável e não confiável.
Modelo de segurança anti-backdoor para carteiras de software
Nesta seção, invertemos completamente os papéis. Agora queremos projetar um carteira de software que impeça o fabricante de hardware de roubar ou causar perda de fundos, mesmo que o dispositivo seja completamente malicioso.
Portanto, isso não pode ser uma propriedade do dispositivo: em vez disso, é uma propriedade do carteira de software configurar. Poderíamos resumir da seguinte forma:
Desde que a carteira de software não seja comprometida, o fabricante do hardware não pode fazer com que o usuário perca fundos.
Isso pode parecer contraintuitivo, pois contradiz diretamente o modelo de segurança padrão detalhado acima. No entanto, “não ter backdoor” significa “fazer exatamente o que deve fazer”. Como a carteira de software é o sol interface entre o dispositivo de assinatura e o mundo externo, é o único lugar onde a proteção contra mau comportamento pode ser aplicada - seja por causa de um bug ou comprometimento explícito do dispositivo.
Observe que esse modelo se estende significativamente além de uma falha de dispositivo, como um bug explorável. Nesse caso, estamos operando em um cenário em que o dispositivo está tentando ativamente causar perda de fundos.
Obviamente, não há proteção possível se o fabricante tiver comprometido com sucesso ambos o dispositivo e também sua máquina que executa a carteira de software. Portanto, é absolutamente vital garantir que sua carteira de software seja de código aberto e auditável, especialmente se construída pelo mesmo fornecedor que fabrica o hardware.
O papel do miniscript
O Miniscript equipa os desenvolvedores de carteira com a capacidade de utilizar totalmente os recursos avançados do bitcoin Script. Para uma visão geral das incríveis possibilidades que o miniscript desbloqueia, consulte nossa postagem anterior no blog. Você também pode querer ouvir Episódio 452 do Podcast de Stephan Livera para uma discussão sobre o que o miniscript traz para o cenário bitcoin.
O aplicativo Ledger Bitcoin suporta miniscript desde seu lançamento 2.1.0, que foi implantado em fevereiro de 2023. Na conferência Bitcoin 2023 em Miami, a Wizardsardine anunciou o lançamento 1.0 de seu carteira liana, a primeira carteira implantada baseada em miniscript.
A ideia básica deste post é que uma conta de carteira bitcoin pode ser protegida não apenas com uma, mas com múltiplo chaves. Isso permite estruturas de segurança flexíveis em que até mesmo uma falha total ou comprometimento de uma chave não é catastrófico.
reflexões multisig
Multisig é uma atualização significativa na força de uma solução de autocustódia. Ao alavancar a programabilidade do Bitcoin Script, ele permite a criação de carteiras que exigem várias chaves em vez de apenas uma. A k-do-n carteira multisig requer uma combinação de k assinaturas válidas, de um total de n possíveis.
No entanto, o multisig também coloca uma carga de UX no usuário e introduz novas oportunidades de erros. Uma configuração multisig 3 de 3, envolvendo três chaves diferentes com backup seguro em locais separados, oferece forte segurança... solteiro chave for perdida, as moedas ficarão permanentemente inacessíveis!
Portanto, as configurações que oferecem mais redundância (como 2 de 3 ou 3 de 5) tendem a ser mais populares: se uma única chave for perdida, as outras chaves ainda podem facilitar a recuperação. Mas isso apresenta uma compensação: se uma chave for comprometida sem o seu conhecimento, a segurança geral será significativamente reduzida!
Empresas como Início e Capital desencadeado especializam-se em soluções de auto-custódia onde detêm uma minoria das chaves de seus clientes. Eles também auxiliam seus usuários, orientando-os no processo de integração e simplificando o uso de sistemas de custódia, que de outra forma podem ser assustadores para a maioria dos usuários não técnicos.
Miniscript e caminhos de recuperação com bloqueio de tempo
Liana usa miniscript para criar carteiras com múltiplas formas de gastar:
- uma condição de gasto primário, que está imediatamente disponível;
- uma ou mais condições de gastos adicionais que se tornam disponíveis após um determinado período (o chamado timelock).
Isso permite muitos casos de uso interessantes:
- Recuperacao: Uma carteira padrão com assinatura única ou multisig como o caminho principal de gastos; mas um mecanismo de recuperação separado (uma chave com uma semente diferente, um multisig, um amigo experiente em tecnologia, um guardião) fica disponível após 6 meses.
- Governance: Uma empresa com dois diretores pode estabelecer um 2 de 2 para a tesouraria da empresa; em caso de desacordo, um advogado de confiança pode acessar os fundos após 6 meses.
- Decaindo multissig: uma carteira começa como 3 de 3, passa para 2 de 3 após 6 meses e se torna 1 de 3 após 9 meses.
- Herança automática: O caminho de recuperação após 6 meses inclui 2 de 3 de seus três filhos; talvez um segundo caminho de recuperação após 1 ano envolva um notário, caso os herdeiros não cheguem a um consenso.
Observação: todos os exemplos acima usam um bloqueio de tempo relativo, que se refere à idade das moedas (ou seja: a última vez que os fundos foram movimentados). A desvantagem é que o usuário deve se lembrar de gastar as moedas (enviando-as para si mesmo) se o timelock estiver próximo do vencimento.
Estes são apenas alguns exemplos, mas devem ser suficientes para convencer o leitor de que o miniscript é um passo significativo para a realização do potencial do Bitcoin como dinheiro programável.
Registro da política de carteira
Para contas de carteira Bitcoin que utilizam várias chaves (seja multisig ou soluções mais sofisticadas baseadas em miniscript), é crucial treinar o dispositivo para identificar os endereços que pertencem a essa conta. Essa é a única maneira de o dispositivo ajudar o usuário a garantir que ele receba ou gaste dos endereços corretos…
Validar a política e o xpubs do fiador contra um backup confiável é essencial, mas relativamente demorado.
A boa notícia é que isso só precisa ser feito uma vez:
Assim que uma apólice for registrada com um nome (no exemplo “Decaying 3of3”), seu dispositivo será capaz de reconhecê-la sempre que tal apólice for empregada.
Os interessados em detalhes técnicos podem encontrar mais informações no proposta BIP.
Política de backup
Um aspecto crítico a ser observado é que, embora as políticas multichave permitam um subconjunto do chaves privadas para autorizar transações, o conhecimento de todos os as chaves públicas (e o exato política) são obrigatórios.
No entanto, ao contrário da semente, o backup da política e das chaves públicas é muito menos arriscado: se alguém descobrisse, poderia rastrear todas as transações vinculadas a essa política. Embora isso não seja o ideal - a privacidade é importante! − não é tão desastroso quanto perder suas moedas e menos atraente para possíveis invasores. Consequentemente, armazenar várias cópias da apólice em carteiras quentes, imprimi-las e armazená-las em vários locais, criptografá-las e armazená-las em armazenamento em nuvem e assim por diante são estratégias viáveis.
A carteira de assinatura única sem backdoor
Vamos dar um passo para trás. Discutimos carteiras de assinatura múltipla, mas agora vamos voltar ao básico para criar uma carteira de assinatura única. Mais precisamente, queremos uma carteira que sente e looks como uma carteira de assinatura única, após uma fase inicial de configuração. No entanto, pretendemos criar uma carteira da qual o fabricante não possa roubar seus fundos, mesmo que sejam maliciosos 😈, e o dispositivo de assinatura de hardware se comporte de maneiras imprevisíveis.
A abordagem pode ser facilmente generalizada para carteiras com várias assinaturas.
Os exemplos abaixo serão escritos em uma linguagem chamada Privacidade, em vez de miniscript. A política é mais fácil para os humanos lerem e pensarem, e pode ser compilada em miniscript com ferramentas automatizadas. Leia mais sobre miniscript e política.
A carteira de hardware pode protegê-lo no modelo de segurança padrão. O Miniscript pode protegê-lo no modelo de segurança anti-backdoor (e muito mais!).
Passo zero: o status quo
Essa é a política que a maioria dos usuários usa hoje: uma única chave derivada de uma semente produzida na carteira de hardware.
pk(key_ledger)
Claro, não há como provar a ausência de um backdoor.
Etapa um: dobre essas chaves
O primeiro passo é simples:
and(pk(key_ledger), pk(key_client))
Aqui, key_client
é gerado na máquina do usuário, portanto, um Tecla. Essencialmente, é uma configuração multisig 2 de 2. O aspecto chave é que o usuário não interage muito com key_client
: a carteira de software gera esta chave, inclui-a no backup da carteira e assina sempre que necessário (por exemplo, enquanto o usuário está ocupado assinando com seu signatário de hardware).
Isso já parece bastante interessante: os recursos são ingastráveis sem key_client
, que não está disponível para o fornecedor de hardware; mesmo que o fornecedor maligno tivesse pleno conhecimento da chave no dispositivo, ele ainda seria incapaz de movimentar os fundos sem visar explicitamente o usuário, por exemplo, comprometendo a máquina que executa sua carteira de software.
No entanto, há um problema: durante a integração da carteira, o signatário do hardware é a única entidade capaz de gerar a chave pública (xpub) key_ledger
usado na carteira. Portanto, o dispositivo pode gerar intencionalmente um Wrongs xpub controlado pelo invasor e posteriormente recusar (ou ser incapaz) de assinar. Indiscutivelmente, este é um cenário de ataque bastante extremo: o criador do backdoor não pode roubar os fundos e o máximo que pode fazer é atingir individualmente o usuário e exigir um resgate (“Posso ajudá-lo a recuperar seu dinheiro se você pagar metade para mim”).
Mais realisticamente, isso aumenta a chance de erros de erros: agora você tem duas sementes/chaves privadas e precisa ambos para poder gastar. Perca qualquer um deles e as moedas ficarão bloqueadas para sempre.
Etapa dois: recuperação com bloqueio de tempo
Apresentamos uma chave de recuperação separada, acessível somente após um bloqueio de tempo específico: and(older(25920)
, pk(key_recovery))
, onde 25920 é o número aproximado de blocos em 6 meses. A política completa se torna:
or(
and(pk(key_ledger), pk(key_client)), and(after(25920), pk(key_recovery))
)
Isso é semelhante ao cenário anterior, mas com uma diferença: se key_ledger
or key_client
fica indisponível por qualquer motivo (mais comumente, perder o backup inicial!), um caminho de recuperação torna-se acessível após 6 meses.
Existem várias opções para key_recovery
, cada um com suas próprias compensações:
a. Use outro Tecla. Esta é uma solução prática, desde que o usuário se lembre de redefinir o timelock. No entanto, se as teclas de atalho forem comprometidas (um cenário que geralmente deve ser considerado bastante provável!), o invasor pode tentar acessar os fundos assim que o bloqueio de tempo expirar, iniciando uma corrida com o proprietário legítimo.
b. Use um dispositivo de assinatura de hardware separado. Esta é uma solução robusta e pode ser usada em combinação com um fornecedor diferente, se desejado; no entanto, aumenta a complexidade de configuração e o custo para o usuário em termos de experiência do usuário.
c. Use um serviço externo confiável. A carteira de software pode importar um xpub de um serviço externo, usando-o como key_recovery
. Este terceiro só é confiável se o timelock expirar, o que pode ser uma compensação atraente para alguns usuários.
Conforme mencionado, como para qualquer política com timelocks, é importante que o usuário se lembre de atualizar as moedas antes do vencimento do timelock.
Etapa três: o terceiro não confiável
Vamos combinar as duas ideias (a) e (c): para o caminho de recuperação, precisamos de uma tecla de atalho local key_recovery_local
e um key_recovery_remote
que esteja hospedado em um serviço semiconfiável; nós também mantemos o timelock.
or(
and(pk(key_ledger), pk(key_client)),
and(older(25920),
and(pk(key_recovery_local), pk(key_recovery_remote))
)
)
Isso diminui o nível de confiança necessário do serviço de recuperação. No entanto, devemos ter cautela: o próprio serviço pode estar monitorando o blockchain e detectar nossos UTXOs − afinal, eles nos forneceram o key_recovery_remote
xpub, para que possam procurar UTXOs contendo pubkeys derivados de key_recovery_remote
. Eles poderão aprender sobre nosso histórico financeiro, mesmo antes que o timelock expire, e mesmo que nunca tenhamos utilizado o serviço deles.
Observação: as árvores de raiz principal podem eliminar esse problema de privacidade para determinadas políticas, mas nem sempre é o caso e requer uma avaliação cuidadosa com base na política específica.
Passo quatro: cegar o terceiro 🙈
Para evitar que o serviço de recuperação conheça nosso histórico financeiro, em vez de usar a chave pública que eles nos comunicam, podemos usar um xpub cego técnica explicado por mflaxman em detalhes aqui. Resumindo, ao invés de usar key_recovery_remote
em nossa política, escolhemos quatro números aleatórios de 31 bits a
, b
, c
, d
(O fatores de cegueira), e usamos o seguinte BIP-32 chave pública derivada:
key_recovery_remote_blind = key_recovery_remote_blind/a/b/c/d
É crucial que também adicionemos key_recovery_remote
, e os fatores de cegueira a
, b
, c
e d
para nosso backup, para referência futura.
Se precisarmos usar o serviço de recuperação, revelaremos a
, b
, c
, d
para eles. Até então, eles não têm como descobrir que as chaves derivadas de seus key_recovery_remote
estão sendo publicados no blockchain: o número de combinações possíveis para os 4 fatores de cegueira é 2^(31*4) = 2^124
, o que torna impossível usar força bruta em todos eles.
Etapa cinco: muitas teclas de atalho podem queimar você 🔥
Conseguimos tornar nossa carteira de software sem backdoor. No entanto, introduzimos um problema diferente: ambas as condições de gasto usam uma fonte gerada localmente, quente chave que não é verificada pela carteira de hardware. Portanto, se a máquina host estiver comprometida, isso pode induzi-lo a registrar a política usando as chaves públicas key_client
e key_recovery_local
, mas coloque chaves privadas aleatórias e não relacionadas em nosso backup (lembre-se, o quente as chaves fazem parte do nosso backup!).
Isso basicamente faria com que quaisquer fundos enviados para a carteira não gastável, já que ninguém controla as chaves privadas necessárias para assinar.
Existem algumas soluções para resolver este problema:
- Durante a integração, depois de imprimir nosso backup em papel, podemos usar um dispositivo separado para verificar se as teclas de atalho privadas e públicas no backup realmente correspondem. Essa abordagem eliminaria o problema, pois teríamos certeza de que temos todas as chaves necessárias para reconstrução e assinatura.
- Podemos adicionar outra condição de gasto com um timelock ainda maior (9 meses, 38880 blocos) que requer apenas um
key_ledger_failsafe
do dispositivo de hardware. Dessa forma, no pior cenário absoluto em que tudo o mais falha, voltamos à segurança de um único dispositivo de assinatura. Em operações normais, nunca deixaríamos o primeiro timelock expirar, portanto, o segundo timelock também não expiraria!
Com a segunda abordagem, a política final ficaria assim
or(
and(pk(key_ledger), pk(key_client)),
or(
and(older(25920),
and(pk(key_recovery_local), pk(key_recovery_remote_blind))
),
and(older(38880), pk(key_ledger_failsafe))
),
)
Esta configuração de carteira de software satisfaz todas as propriedades de segurança que reivindicamos no início. Além disso, oferece um caminho de recuperação caso as principais chaves de gastos key_ledger
estão perdidos. Um bom recurso para se ter!
Integração à carteira de software sem backdoor
Como seria a experiência do usuário para uma carteira usando uma política tão complexa? Aqui está uma breve visão geral:
- O usuário abre a carteira de software e começa a criar uma nova conta.
- A carteira de software solicita que o usuário conecte seu dispositivo de assinatura e recupere os xpubs para
key_ledger
ekey_ledger_failsafe
. - A carteira de software gera autonomamente a chave de atalho key_client.
- A carteira de software obtém
key_recovery_remote
de um serviço de co-assinatura ou permite que o usuário especifique uma chave de outra maneira. Opcionalmente, calcula okey_recovery_remote_blind
usando a técnica de cegueira mencionada anteriormente. - A carteira de software gera um backup de política contendo a política miniscript precisa, todos os xpubs e a chave privada estendida para o
key_client
tecla de atalho. Este backup é armazenado com segurança (por exemplo, impresso em papel ou salvo em um dispositivo separado). - Por fim, a carteira de software instrui o usuário a registrar a política no dispositivo. O usuário verifica o backup (em papel ou qualquer outro meio que não seja a tela controlada pela carteira de software).
A carteira de software gerencia a maioria das etapas acima, tornando o envolvimento do usuário não mais oneroso do que o esforço esperado necessário hoje para configurar uma carteira multiassinatura.
A integração deve exigir apenas alguns minutos depois que um bom UX for criado para ele. Depois de concluída, a carteira de software pode fornecer uma experiência de usuário muito semelhante à de uma carteira de assinatura única típica. É assim que o miniscript vai mudar tudo: desaparecendo da vista do usuário!
Melhorias na raiz principal
Ledger suporta miniscript desde a versão 2.1.0 do aplicativo Bitcoin, lançado em março. Embora o suporte para receber e gastar de endereços de raiz principal tenha sido ativado desde o forquilha de raiz principal em novembro de 2021, agora estamos dando os toques finais na próxima etapa do roteiro: suporte a miniscript para taproot.
O Taproot terá um grande impacto na usabilidade das abordagens apresentadas neste artigo. Se o caminho de gastos primário for uma condição de gasto de chave única, a existência de caminhos de gastos de recuperação será indetectável no blockchain, a menos que sejam utilizados. Isso melhorará muito a privacidade, eliminando completamente quaisquer impressões digitais para o caminho de gastos padrão. Além disso, melhora a escalabilidade, pois o caminho de gastos padrão torna-se o mais econômico possível. Isso significa que nenhum custo adicional será incorrido devido à presença de caminhos de recuperação, a menos que sejam usados. Esta é uma atualização significativa das transações SegWit, que exigem a publicação de todo o script, incluindo todas as condições de gastos, durante qualquer gasto.
Finalmente, protocolos mais avançados como MuSig2 (recentemente padronizado) e FROST sobrecarregará o caminho-chave principal. Construídos sobre assinaturas Schnorr, esses protocolos permitem criar um único pubkey agregado que pode ser usado para representar um n-do-n assinatura múltipla ou um k-do-n esquema de limite. Isso permitiria o uso do keypath taproot mesmo em casos que hoje são mais comumente representados com scripts multisig específicos.
Conclusões
Este artigo explora um pequeno (mas importante) nicho do vasto espaço de design que o miniscript libera para carteiras de software.
Mostramos como o miniscript pode ser usado para criar uma carteira de software “unbackdoorable”, além de adicionar um caminho de recuperação adicional que permite evitar perdas desastrosas de chaves. Embora os dispositivos de assinatura de hardware não possam impor o modelo de segurança anti-backdoor, ao oferecer suporte ao miniscript, eles permitem carteiras de software que fazem exatamente isso!
Ao utilizar de forma inteligente uma combinação de esquemas de assinatura múltipla, timelocks, xpubs cegos e teclas de atalho, demonstramos uma configuração de carteira segura que equilibra segurança, privacidade e robustez.
Além disso, argumentamos que isso é possível sem impactar negativamente a experiência do usuário, pois a complexidade da configuração não se traduz em uma grande carga adicional de UX.
Estamos entusiasmados com as possibilidades que o miniscript abrirá para a próxima geração de autocustódia de bitcoin.
- Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
- PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
- PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
- PlatãoESG. Automotivo / EVs, Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
- BlockOffsets. Modernizando a Propriedade de Compensação Ambiental. Acesse aqui.
- Fonte: https://www.ledger.com/blog/towards-a-trustless-bitcoin-wallet-with-miniscript
- :tem
- :é
- :não
- :onde
- $UP
- 1
- 2021
- 2023
- 30
- 7
- 9
- a
- habilidade
- Capaz
- Sobre
- acima
- absoluto
- absolutamente
- Acesso
- acessadas
- acessível
- conformidade
- Conta
- Contas
- Açao Social
- ações
- ativamente
- adicionar
- acrescentando
- Adição
- Adicional
- Adicionalmente
- endereços
- avançado
- Depois de
- contra
- idade
- Ajuda
- visar
- Todos os Produtos
- permitir
- permite
- juntamente
- já
- tb
- Apesar
- sempre
- an
- e
- anunciou
- Outro
- qualquer
- nada
- app
- atraente
- aparecer
- aplicações
- abordagem
- se aproxima
- aprovação
- aproximado
- SOMOS
- indiscutivelmente
- argumentou
- artigo
- AS
- aspecto
- auxiliar
- associado
- At
- ataque
- auditável
- autorizar
- Automatizado
- autonomamente
- disponível
- em caminho duplo
- Porta dos fundos
- Apoiado
- apoio
- backup
- saldos
- baseado
- basic
- Basicamente
- fundamentos básicos
- BE
- Porque
- tornam-se
- torna-se
- antes
- Começo
- ser
- abaixo
- MELHOR
- entre
- Pós
- Bitcoin
- Bitcoin Wallet
- carteiras de bitcoin
- Blend
- blockchain
- Blocos
- Blockstream
- Blog
- ambos
- Cérebro
- Traz
- transmissão
- Bug
- construir
- construído
- carga
- queimar
- negócio
- ocupado
- mas a
- by
- chamado
- CAN
- não podes
- capaz
- cuidadoso
- casas
- casos
- catastrófico
- Causar
- causando
- cautela
- certo
- desafiar
- chance
- alterar
- Crianças
- lasca
- Escolha
- escolha
- afirmou
- claramente
- Na nuvem
- armazenamento em nuvem
- código
- Moedas
- combinação
- combinações
- comercial
- comum
- geralmente
- comunicar
- Empresas
- Empresa
- Empresa
- completar
- completamente
- integrações
- complexidade
- Comprometido
- comprometendo
- cálculos
- computação
- Preocupações
- condição
- condições
- Conferência
- Configuração
- Contato
- Consenso
- Consequentemente
- Considerar
- considerado
- contida
- controlado
- controles
- convencer
- correta
- corrompido
- Custo
- poderia
- Para
- crio
- Criar
- criação
- criador
- crítico
- aspecto crítico
- crucial
- Atualmente
- custodiante
- Custódia
- Clientes
- Perigoso
- Rejeitar
- diminui
- julgar
- definido
- Demanda
- demonstraram
- implantado
- Derivado
- descrição
- Design
- projetado
- desejado
- detalhe
- detalhado
- detalhes
- descobrir
- desenvolvedores
- dispositivo
- Dispositivos/Instrumentos
- diferente
- difícil
- diminuindo
- diretamente
- Administração
- desaparecendo
- desastroso
- descobrir
- descobrindo
- discutido
- discussão
- exibido
- do
- parece
- Não faz
- feito
- duplo
- dois
- durante
- cada
- mais fácil
- facilmente
- esforço
- ou
- eliminado
- eliminando
- outro
- enfatizar
- empregada
- permitir
- habilitado
- permite
- final
- aplicar
- suficiente
- garantir
- assegurando
- entrar
- sedutor
- Todo
- inteiramente
- entidade
- equipamento
- erros
- especialmente
- essencial
- essencialmente
- estabelecer
- etc.
- avaliação
- Mesmo
- SEMPRE
- Cada
- tudo
- exatamente
- exemplo
- exemplos
- animado
- executar
- executado
- Exercício
- existência
- esperado
- vasta experiência
- expiração
- Explorar
- explora
- exportar
- se estende
- externo
- extremo
- facilitar
- fatores
- falha
- Falha
- bastante
- Cair
- longe
- Característica
- Funcionalidades
- Fevereiro
- poucos
- final
- financeiro
- história financeira
- Encontre
- Primeiro nome
- flexível
- Giro
- Foco
- seguinte
- segue
- Escolha
- para sempre
- para a frente
- quatro
- enquadramentos
- freqüentemente
- amigos
- da
- cheio
- totalmente
- funcionalidade
- fundo
- fundos
- Além disso
- Fútil
- futuro
- propósito geral
- geralmente
- gerar
- gerado
- gera
- gerando
- geração
- dado
- Go
- vai
- Bom estado, com sinais de uso
- ótimo
- grandemente
- tinha
- Metade
- Hardware
- dispositivo de hardware
- Hardware Wallet
- Fabricante de carteira de hardware
- Carteiras de Hardware
- prejudicial
- Ter
- ter
- ajudar
- conseqüentemente
- história
- segurar
- esperança
- hospedeiro
- hospedado
- HOT
- Como funciona o dobrador de carta de canal
- Contudo
- http
- HTTPS
- enorme
- Humanos
- idéia
- ideal
- idéias
- identificar
- if
- imediatamente
- Impacto
- impactando
- implementado
- importar
- importante
- impossível
- melhorar
- in
- inclui
- Incluindo
- incorporando
- Aumenta
- incrível
- de fato
- de treinadores em Entrevista Motivacional
- Individualmente
- indústria
- INFORMAÇÕES
- inerentemente
- do estado inicial,
- dentro
- Informante
- inspirar
- instalando
- instância
- em vez disso
- intencionalmente
- interagir
- interativo
- interesse
- interessado
- interessante
- Interface
- para dentro
- introduzir
- introduzido
- Introduz
- intrusivo
- envolvimento
- envolvendo
- emitem
- IT
- ESTÁ
- se
- apenas por
- apenas um
- Chave
- chaves
- Saber
- Conhecimento
- conhecido
- paisagem
- língua
- laptop
- Sobrenome
- mais tarde
- advogado
- Leads
- APRENDER
- aprendizagem
- mínimo
- Ledger
- esquerda
- legítimo
- menos
- deixar
- Nível
- aproveitando
- como
- Provável
- ligado
- Listado
- carregamento
- local
- locais
- trancado
- longo
- mais
- olhar
- parece
- perder
- perder
- fora
- perdas
- perdido
- máquina
- a Principal
- Maioria
- fazer
- FAZ
- Fazendo
- malwares
- gestão
- gestão
- manipulando
- maneira
- Fabricante
- Fabricantes
- muitos
- Março
- Match
- Posso..
- significa
- medidas
- mecanismo
- média
- mencionado
- apenas
- mensagem
- mensagens
- método
- métodos
- Miami
- poder
- miniscrito
- minoria
- Minutos
- Missão
- erros
- modelo
- dinheiro
- monitoração
- mês
- mais
- Além disso
- a maioria
- na maioria das vezes
- mover
- movido
- muito
- múltiplo
- Multisig
- devo
- nome
- aproximando
- necessário
- você merece...
- necessário
- Cria
- negativamente
- networking
- nunca
- Novo
- notícias
- Próximo
- agradável
- não
- não técnico
- normal
- Novembro
- Novembro de 2021
- agora
- número
- números
- obtém
- of
- oferecer
- oferecendo treinamento para distância
- Oferece
- modo offline
- on
- Onboarding
- uma vez
- ONE
- queridos
- só
- aberto
- open source
- abre
- operando
- Operações
- oportunidades
- Opções
- or
- ordem
- Outros
- de outra forma
- A Nossa
- Fora
- delineado
- lado de fora
- Acima de
- global
- Visão geral
- próprio
- proprietário
- Papel
- Supremo
- parte
- particularmente
- festa
- caminho
- Pagar
- Realizar
- possivelmente
- significativo
- permanentemente
- fase
- telefone
- Lugar
- Locais
- platão
- Inteligência de Dados Platão
- PlatãoData
- ponto
- pontos
- políticas
- Privacidade
- Popular
- possibilidades
- possível
- possivelmente
- Publique
- potencial
- potencialmente
- poder
- Prática
- praticamente
- prática
- preciso
- justamente
- predizer
- Previsível
- presença
- presente
- apresentado
- evitar
- impede
- anterior
- anteriormente
- principalmente
- primário
- impressão
- Prévio
- política de privacidade
- privado
- chave privada
- Chaves Privadas
- Problema
- problemas
- procedimentos
- processo
- produzir
- Produzido
- produz
- devidamente
- Propriedades
- propriedade
- proposto
- proteger
- protegido
- proteger
- proteção
- protocolo
- protocolos
- Prove
- fornecer
- fornecido
- público
- chave pública
- chaves públicas
- publicar
- publicado
- Publishing
- propósito
- colocar
- Colocar
- questão
- Corrida
- acaso
- Resgate
- em vez
- alcançar
- Leia
- Leitor
- percebendo
- razão
- receber
- recentemente
- reconhecer
- registro
- recuperação
- refere-se
- cadastre-se
- registrado
- registro
- relativamente
- liberar
- liberado
- depender
- lembrar
- substituir
- representar
- representado
- reputação
- requerer
- requeridos
- exige
- resultando
- reter
- retorno
- revelar
- certo
- Risco
- riscos
- Arriscado
- roadmap
- uma conta de despesas robusta
- robustez
- Tipo
- papéis
- corrida
- é executado
- mesmo
- dizer
- AMPLIAR
- digitalização
- cenário
- esquema
- esquemas
- Schnorr
- Peneira
- Scripts
- Segundo
- Seção
- seguro
- firmemente
- segurança
- Vejo
- semente
- SEEDS
- busca
- parecem
- parece
- SegWit
- Auto-custódia
- envio
- sensível
- enviei
- separado
- serviço
- conjunto
- instalação
- vários
- Baixo
- rede de apoio social
- mostrou
- assinar
- Assinaturas
- periodo
- de forma considerável
- assinatura
- Sinais
- semelhante
- simples
- simplificando
- desde
- solteiro
- pequeno
- smart
- So
- Software
- solução
- Soluções
- RESOLVER
- alguns
- Alguém
- em breve
- sofisticado
- fonte
- Espaço
- especializar-se
- específico
- especificações
- gastar
- Passar
- padrão
- fica
- começa
- Status
- Passo
- Passos
- Ainda
- armazenamento
- armazenadas
- armazenar
- estratégias
- força
- Tanga
- mais forte,
- Lutar
- bem sucedido
- entraram com sucesso
- tal
- resumir
- Sobrecarregar
- ajuda
- Apoiar
- suportes
- suposto
- sistêmico
- risco sistémico
- sistemas
- Desarmes
- Tire
- arrancar
- Target
- alvejando
- Dados Técnicos:
- tecnicamente
- Tecnologia
- condições
- do que
- que
- A
- As Moedas
- deles
- Eles
- si mesmos
- então
- Lá.
- assim
- assim sendo
- Este
- deles
- coisas
- think
- Terceiro
- isto
- aqueles
- ameaças
- três
- limiar
- Através da
- Assim
- tempo
- demorado
- para
- hoje
- hoje
- também
- ferramentas
- Temas
- Total
- para
- Traçar
- pista
- historial
- Trem
- transação
- Transações
- transições
- traduzir
- tesouraria
- Árvores
- verdadeiro
- Confiança
- confiável
- sem confiança
- Verdade
- torção
- dois
- tipos
- típico
- incapaz
- compreender
- desencadeia
- ao contrário
- destravar
- destranca
- imprevisível
- até
- atualização
- us
- usabilidade
- usar
- usava
- Utilizador
- Experiência do Usuário
- usuários
- usos
- utilização
- utilizar
- utilizado
- Utilizando
- ux
- VALIDAR
- variedade
- vário
- Grande
- fornecedor
- verificado
- verificar
- versão
- muito
- viável
- vital
- vulnerabilidades
- esperar
- Wallet
- Carteiras
- queremos
- foi
- Caminho..
- maneiras
- we
- foram
- O Quê
- quando
- sempre que
- se
- qual
- enquanto
- inteiro
- porque
- Wikipedia
- precisarão
- de
- dentro
- sem
- palavras
- mundo
- seria
- escrito
- Errado
- ano
- ainda
- Vocês
- investimentos
- você mesmo
- zefirnet
- zero