As mnemônicas ainda existem, por que um self-claim ainda pode falhar
As mnemônicas conseguem restaurar uma carteira Bitcoin comum, mas não conseguem reconstruir automaticamente os materiais exclusivos gerados durante a criação de um Vault. Nos Trustless Bitcoin Vaults (TBV) da Babylon, o par de chaves WOTS e os artefatos do claimer não são credenciais de custódia de BTC; são entradas necessárias para que o depositante execute self-claim de forma independente após o provedor do Vault ficar inacessível.
Na atual testnet pública, cada Vault tem um WOTS independente e de uso único, cujo hash da chave pública é submetido ao Ethereum. O Assert então usa a chave privada correspondente do WOTS para comprometer um proof ZK. A chave privada comum do Bitcoin controla a saída do claim do depositante, mas não substitui essa autorização de prova.
WOTS também não substitui os artefatos do claimer. Estes incluem o transaction graph, a verifying key e os dados da sessão BABE correspondentes a cada challenger; o protocolo também prepara, na fase de criação, os caminhos de Claim, Assert e Payout de depositor-as-claimer. Com apenas uma assinatura de uso único — sem o grafo de transações e sem os materiais de prova — ainda não é possível compor um fluxo de retirada completo.
O self-claim não permite saque a qualquer momento. Depois que as condições de resgate no lado da aplicação são atendidas e é emitido VaultClaimableBy, o watchtower só então usa os dois tipos de materiais desse Vault para transmitir Claim, Assert e Payout. Após o challenge window normal da testnet atual, o BTC ainda só entrará no endereço do depositante determinado no momento da criação.
Isso mudou o meu critério de avaliação de autodepósito: não basta verificar quem detém a chave privada do Bitcoin; é preciso considerar se, quando o papel principal do serviço fica inacessível, o usuário ainda tem os materiais para executar todas as transações necessárias. Se faltar qualquer uma das entradas, o que falha é o self-claim, não a propriedade do BTC; quando o provedor do Vault responde normalmente, o redemption padrão ainda pode ser concluído. Se ambos os tipos de materiais forem perdidos e o Provider também ficar inacessível, a documentação atual exige uma atualização para um procedimento de recuperação off-chain com participação do Security Council, e não que um terceiro reescreva o destino do BTC.$BTC $ETH
@BabylonLabs_io
$BABY
#baby
As mnemônicas conseguem restaurar uma carteira Bitcoin comum, mas não conseguem reconstruir automaticamente os materiais exclusivos gerados durante a criação de um Vault. Nos Trustless Bitcoin Vaults (TBV) da Babylon, o par de chaves WOTS e os artefatos do claimer não são credenciais de custódia de BTC; são entradas necessárias para que o depositante execute self-claim de forma independente após o provedor do Vault ficar inacessível.
Na atual testnet pública, cada Vault tem um WOTS independente e de uso único, cujo hash da chave pública é submetido ao Ethereum. O Assert então usa a chave privada correspondente do WOTS para comprometer um proof ZK. A chave privada comum do Bitcoin controla a saída do claim do depositante, mas não substitui essa autorização de prova.
WOTS também não substitui os artefatos do claimer. Estes incluem o transaction graph, a verifying key e os dados da sessão BABE correspondentes a cada challenger; o protocolo também prepara, na fase de criação, os caminhos de Claim, Assert e Payout de depositor-as-claimer. Com apenas uma assinatura de uso único — sem o grafo de transações e sem os materiais de prova — ainda não é possível compor um fluxo de retirada completo.
O self-claim não permite saque a qualquer momento. Depois que as condições de resgate no lado da aplicação são atendidas e é emitido VaultClaimableBy, o watchtower só então usa os dois tipos de materiais desse Vault para transmitir Claim, Assert e Payout. Após o challenge window normal da testnet atual, o BTC ainda só entrará no endereço do depositante determinado no momento da criação.
Isso mudou o meu critério de avaliação de autodepósito: não basta verificar quem detém a chave privada do Bitcoin; é preciso considerar se, quando o papel principal do serviço fica inacessível, o usuário ainda tem os materiais para executar todas as transações necessárias. Se faltar qualquer uma das entradas, o que falha é o self-claim, não a propriedade do BTC; quando o provedor do Vault responde normalmente, o redemption padrão ainda pode ser concluído. Se ambos os tipos de materiais forem perdidos e o Provider também ficar inacessível, a documentação atual exige uma atualização para um procedimento de recuperação off-chain com participação do Security Council, e não que um terceiro reescreva o destino do BTC.$BTC $ETH
@BabylonLabs_io
$BABY
#baby