Às vezes, pego a mim mesmo assumindo que, se eu controlar meu Bitcoin, sou eu quem assina cada transação. Parece ser assim que a autogestão funciona. Você tem a chave, decide quando os fundos se movem, a cadeia confirma. Então comecei a pesquisar a Babylon Labs e percebi que os seus Cofres de Bitcoin Sem Confiança (Trustless) foram construídos com outra premissa.
A parte interessante não é exatamente a criação do cofre em si. Muitos protocolos permitem que você bloqueie Bitcoin. O que me pegou de surpresa foi o fluxo de resgate. O tomador quita o empréstimo. Aí não acontece nada. O Provedor do Cofre envia uma prova, uma janela de contestação é aberta. A chave privada do usuário fica ociosa. Nenhuma assinatura é necessária. Se isso ainda é autogestão, por que não é a pessoa que supostamente possui o ativo quem aprova o movimento final?
Eu precisei rastrear isso duas vezes ao contrário, porque primeiro pensei que o resgate devia envolver alguma assinatura oculta em algum lugar. Não envolve. A resposta está na criação do cofre. Antes do cofre ser ativado, o usuário coassina um script do Taproot que contém cada caminho de gasto possível: quitação, liquidação, reembolso. Tudo pré-assinado por todos os participantes. Depois da ativação, nenhum novo caminho pode ser introduzido. Então o resgate não está pedindo permissão porque a permissão já foi concedida. Talvez semanas antes.
Isso muda quando o controle realmente acontece. Não é exercido no momento do movimento. Ele fica embutido na arquitetura do cofre antes de qualquer coisa se mover. O usuário ainda decide tudo. Mas decide antes, não em resposta a eventos.
Claro, isso significa que o recurso de fallback de auto-reivindicação vira outra coisa que precisa estar correta. Se o Provedor do Cofre desaparecer, o usuário ainda consegue recuperar seu BTC unilateralmente. Mas apenas se tiver guardado os artefatos do claimer desde a criação do cofre. Se perder isso, esse caminho se fecha. Ainda não tenho certeza se o problema mais difícil é desenhar os scripts pré-assinados ou fazer com que os usuários mantenham um arquivo seguro que talvez não precisem por meses. Essa é apenas minha opinião, não é conselho de investimento.
#baby $BABY @BabylonLabs_io
A parte interessante não é exatamente a criação do cofre em si. Muitos protocolos permitem que você bloqueie Bitcoin. O que me pegou de surpresa foi o fluxo de resgate. O tomador quita o empréstimo. Aí não acontece nada. O Provedor do Cofre envia uma prova, uma janela de contestação é aberta. A chave privada do usuário fica ociosa. Nenhuma assinatura é necessária. Se isso ainda é autogestão, por que não é a pessoa que supostamente possui o ativo quem aprova o movimento final?
Eu precisei rastrear isso duas vezes ao contrário, porque primeiro pensei que o resgate devia envolver alguma assinatura oculta em algum lugar. Não envolve. A resposta está na criação do cofre. Antes do cofre ser ativado, o usuário coassina um script do Taproot que contém cada caminho de gasto possível: quitação, liquidação, reembolso. Tudo pré-assinado por todos os participantes. Depois da ativação, nenhum novo caminho pode ser introduzido. Então o resgate não está pedindo permissão porque a permissão já foi concedida. Talvez semanas antes.
Isso muda quando o controle realmente acontece. Não é exercido no momento do movimento. Ele fica embutido na arquitetura do cofre antes de qualquer coisa se mover. O usuário ainda decide tudo. Mas decide antes, não em resposta a eventos.
Claro, isso significa que o recurso de fallback de auto-reivindicação vira outra coisa que precisa estar correta. Se o Provedor do Cofre desaparecer, o usuário ainda consegue recuperar seu BTC unilateralmente. Mas apenas se tiver guardado os artefatos do claimer desde a criação do cofre. Se perder isso, esse caminho se fecha. Ainda não tenho certeza se o problema mais difícil é desenhar os scripts pré-assinados ou fazer com que os usuários mantenham um arquivo seguro que talvez não precisem por meses. Essa é apenas minha opinião, não é conselho de investimento.
#baby $BABY @BabylonLabs_io
