Quem faz pagamentos para uma empresa sabe: o mais difícil de evitar talvez não sejam as faturas falsas. O nome do fornecedor é verdadeiro, o contrato também é verdadeiro — só que a conta de recebimento foi trocada pela de outra pessoa. Olhando cada campo separadamente, tudo parece estar certo; mas juntos, acabam fazendo o dinheiro ir para o lugar errado.
Até em cross-chain existe esse tipo de perigo. Não é que todos os dados sejam falsos; é que a chave pública do Bitcoin e o endereço do Ethereum, sem legitimidade, são forçados a serem relacionados.
Nos pedidos de alocação (build) do Trustless Bitcoin Vaults (TBV) com o @BabylonLabs_io , ao mesmo tempo são incluídos um endereço Ethereum, uma chave pública Bitcoin, a escolha do provedor do Vault, o compromisso WOTS e a prova de posse de chave do BIP-322. O que me preocupa aqui não é a quantidade de termos, mas sim quem tem qualificação para apertar o botão de confirmar.
Uma vez que o pedido é aceito, os passos seguintes tratam as ações em duas cadeias como se fossem a mesma relação de autorização. Se o iniciador nem consegue controlar a chave pública Bitcoin correspondente, isso não é um detalhe pequeno: é alguém abrindo uma conta em nome de outra pessoa e ainda direcionando quem seria o contato posterior.
Com o BIP-322 aqui, fica ainda mais como uma verificação de elegibilidade antes de abrir a porta. Primeiro, obter a capacidade real de controle sobre a chave pública do Bitcoin; só então faz sentido falar em como conectar a conta e a aplicação do lado do Ethereum. Ele não torna o mundo mais simples — apenas impede que estranhos copiem uma sequência de informações públicas e, assim, prenda juntas as duas pontas que não pertencem a elas.
Muitos problemas na internet não acontecem porque os arquivos foram falsificados, e sim porque as relações foram apropriadas indevidamente. O número de celular é verdadeiro, a conta bancária é verdadeira, o nome também é verdadeiro — e, no final, o erro é de quem tem o direito de juntá-los em uma operação. Se o sistema só checa os componentes e não checa as pessoas que estabelecem a relação, quanto mais rápida a automação, mais rápido o erro também corre.
Nas discussões relacionadas ao $BABY , essa barreira talvez não seja tão “barulhenta” quanto no BTC nativo, mas está ainda mais próxima da essência de segurança do dia a dia. O protocolo primeiro recusa quem não tem direito básico de iniciar o pedido; só então os passos seguintes fazem sentido.
O BIP-322 não é KYC e não vai julgar, por vias judiciais reais, a quem o BTC pertence. Ele protege a entrada do protocolo, não a totalidade da propriedade no mundo social. O limite é estreito, mas a posição é exatamente a certa.
Muitos acidentes não acontecem porque as peças são falsas; acontecem porque peças verdadeiras são conectadas à pessoa errada. #baby
Até em cross-chain existe esse tipo de perigo. Não é que todos os dados sejam falsos; é que a chave pública do Bitcoin e o endereço do Ethereum, sem legitimidade, são forçados a serem relacionados.
Nos pedidos de alocação (build) do Trustless Bitcoin Vaults (TBV) com o @BabylonLabs_io , ao mesmo tempo são incluídos um endereço Ethereum, uma chave pública Bitcoin, a escolha do provedor do Vault, o compromisso WOTS e a prova de posse de chave do BIP-322. O que me preocupa aqui não é a quantidade de termos, mas sim quem tem qualificação para apertar o botão de confirmar.
Uma vez que o pedido é aceito, os passos seguintes tratam as ações em duas cadeias como se fossem a mesma relação de autorização. Se o iniciador nem consegue controlar a chave pública Bitcoin correspondente, isso não é um detalhe pequeno: é alguém abrindo uma conta em nome de outra pessoa e ainda direcionando quem seria o contato posterior.
Com o BIP-322 aqui, fica ainda mais como uma verificação de elegibilidade antes de abrir a porta. Primeiro, obter a capacidade real de controle sobre a chave pública do Bitcoin; só então faz sentido falar em como conectar a conta e a aplicação do lado do Ethereum. Ele não torna o mundo mais simples — apenas impede que estranhos copiem uma sequência de informações públicas e, assim, prenda juntas as duas pontas que não pertencem a elas.
Muitos problemas na internet não acontecem porque os arquivos foram falsificados, e sim porque as relações foram apropriadas indevidamente. O número de celular é verdadeiro, a conta bancária é verdadeira, o nome também é verdadeiro — e, no final, o erro é de quem tem o direito de juntá-los em uma operação. Se o sistema só checa os componentes e não checa as pessoas que estabelecem a relação, quanto mais rápida a automação, mais rápido o erro também corre.
Nas discussões relacionadas ao $BABY , essa barreira talvez não seja tão “barulhenta” quanto no BTC nativo, mas está ainda mais próxima da essência de segurança do dia a dia. O protocolo primeiro recusa quem não tem direito básico de iniciar o pedido; só então os passos seguintes fazem sentido.
O BIP-322 não é KYC e não vai julgar, por vias judiciais reais, a quem o BTC pertence. Ele protege a entrada do protocolo, não a totalidade da propriedade no mundo social. O limite é estreito, mas a posição é exatamente a certa.
Muitos acidentes não acontecem porque as peças são falsas; acontecem porque peças verdadeiras são conectadas à pessoa errada. #baby