Collaborative Custody é uma organização de custódia em que o proprietário e outra pessoa ou serviço participam da proteção dos bitcoins. Em um modelo comum, o proprietário mantém chaves suficientes para pagar sozinho, enquanto o serviço ajuda quando surge um problema. Essa autonomia precisa estar nas regras da carteira, não apenas no nome do produto.
Pedro gerencia seus bitcoins com a própria carteira. Sua preocupação é perder um dispositivo ou uma cópia de segurança. Uma carteira é um aplicativo ou dispositivo para receber e enviar bitcoins. Assinar significa aqui usar uma chave privada, um valor numérico secreto, para criar uma prova verificável de autorização do pagamento. Outras pessoas podem conferir a assinatura sem conhecer esse segredo. A Unchained descreve um modelo 2-of-3: um pagamento exige assinaturas de duas das três chaves. Pedro guarda A e B; o serviço, C. As combinações válidas são A+B, A+C e B+C; C sozinha não basta. Exigir várias assinaturas é chamado de Multisig. Pedro pode pagar sem o serviço e pedir ajuda se perder uma chave. Dois dispositivos restaurados com a mesma Seed Phrase, a mesma cópia em palavras, não são independentes: a exposição do segredo comum compromete ambos. [1] [4] [8]
Enquanto Pedro tiver A+B utilizáveis e os registros completos da carteira, uma queda do serviço não o impede, por si só, de pagar. Se restar apenas A, ele precisará do serviço para A+C. Uma falha ou recusa em assinar pode então bloquear a recuperação. Se perder A e B, C sozinha não o salvará. Por isso, a saída independente e a recuperação assistida devem ser testadas separadamente. As instruções da Casa para recuperação sem sua infraestrutura também pressupõem explicitamente a indisponibilidade da chave do serviço. Procedimento e equipamentos dependem do produto; não podem ser deduzidos da palavra “collaborative”. [1] [6]
Pedro tem suas cópias, mas outro aplicativo ainda precisa saber qual carteira reconstruir. Um 2-of-3 convencional exige as chaves públicas dos três participantes, inclusive do serviço, e suas regras de uso. Chaves públicas verificam assinaturas; privadas as criam. Um Output Descriptor descreve essa configuração em formato legível por software, incluindo a derivação de endereços. Duas cópias pessoais de Seed Phrase não recriam a chave pública ausente do provedor. Pedro salva e verifica a exportação enquanto o serviço funciona. Antes de compartilhá-la, confere seu conteúdo: o formato geral de descriptor também pode conter chaves privadas. [4] [5]
Um coordenador reúne os dados da transação; quem assina possui a chave que a autoriza. PSBT, o formato descrito no BIP 174, transporta uma transação incompleta e seus dados entre programas e dispositivos. Criar o arquivo não fornece uma assinatura ausente. Mesmo sem chave, um coordenador pode causar dano ao propor outro destinatário. Antes de assinar, verifique endereço, valor, taxa e change: o restante devolvido à sua própria carteira. Uma Hardware Wallet ajuda a separar a chave do computador; ainda importa o que sua tela permite conferir e o que Pedro realmente aprova. [2] [3]
Um erro pode surgir antes do primeiro pagamento, durante a criação da carteira compartilhada. O BIP 129 descreve a troca de chaves e configuração para que os participantes comparem o limite de assinaturas exigidas, as chaves incluídas e o primeiro endereço. Isso abrange o tipo de script, que expressa condições de gasto, e os caminhos de derivação das chaves seguintes. Configurações adulteradas podem desviar depósitos. O documento não cobre, por si só, a resistência do armazenamento do dispositivo nem suas verificações posteriores de endereços de recebimento e change. Suportar o padrão não certifica a segurança do produto inteiro. [2]
Um XPUB é uma chave pública estendida usada para derivar chaves públicas de um ramo da carteira. Conhecer esses dados e a configuração pode permitir ao provedor acompanhar endereços e pagamentos sem assinaturas suficientes para gastar. Associá-los a uma conta no nome do cliente cria outro vínculo. Privacidade e poder de gasto são questões distintas. A afirmação de que o serviço não pode pagar sozinho também tem condições: ele pode obter outra chave de Pedro ou enganá-lo para assinar uma transação prejudicial. Reduzir os poderes do provedor limita alguns riscos, mas não todos. [2] [4]
Pedro perde uma chave e cria outra no aplicativo. Isso não invalida a antiga para depósitos anteriores. Uma saída de transação registra um valor e as condições para gastá-lo depois. Os depósitos anteriores existem como UTXOs, saídas de transações ainda não gastas, com condições próprias. No Multisig convencional, é preciso criar novas condições e transferir os fundos correspondentes para elas em uma transação confirmada. Depois, confere-se o que restou nos endereços antigos. Mudar a senha da conta ou o nome da chave não substitui a transferência. A configuração e as instruções familiares também precisam ser atualizadas, para que os herdeiros não sigam um plano incompatível com os fundos. [4] [9]
Um ensaio útil usa uma carteira de teste separada. Pedro importa a configuração salva em um programa compatível, compara endereços e verifica se consegue assinar com suas chaves sem o serviço original. O modo watch-only exibe endereços e saldo, mas não comprova a capacidade de assinar. Caravan é um coordenador de código aberto; o suporte ao formato e aos dispositivos específicos precisa ser verificado. Recuperação assistida, chave indisponível, taxas e change também fazem parte do ensaio. O resultado deve ser um procedimento claro e registrado, com as versões usadas, não apenas tranquilidade ao ver um saldo. [3] [6] [7]
Para ter uma visão mais completa, leia este verbete junto com Multisig, Autocustódia, Output Descriptor, PSBT, Bitcoin Inheritance Plan, Counterparty risk. Também há referências a este verbete em Bitcoin Inheritance Plan, Institutional custody.