Peter Todd

Imagine precisar de demonstrar que determinada versão de um contrato existia antes de começar um litígio. OpenTimestamps, projeto associado a Peter Todd, responde a essa necessidade. O seu anúncio histórico de 2016 apresentou uma versão pública experimental e agradeceu a Riccardo Casatta o desenvolvimento e os testes. Regista a colaboração da época; não significa que o projeto tenha permanecido experimental. Todd também trabalhou nas condições de gastos futuros e nos pagamentos que aguardam confirmação. Comecemos por estas duas áreas. [1]

O BIP 65 de Todd introduziu OP_CHECKLOCKTIMEVERIFY, ou CLTV. Esta instrução permite condicionar uma via específica de gasto a uma altura de bloco ou a um limite temporal. Pense num acesso de recurso a poupanças partilhadas que o destinatário só poderá usar mais tarde. Até lá, a condição temporal bloqueia essa via. Quando é satisfeita, as moedas não são enviadas automaticamente: continua a ser necessária uma transação válida e cumprir os restantes requisitos, como fornecer uma assinatura. Se houver outra via de gasto, terá as suas próprias condições; o bloqueio não abrange necessariamente todas as possibilidades. [2]

O bloqueio não segue simplesmente o relógio apresentado pela carteira. BIP 65 verifica a relação entre o script, as instruções que definem as condições de gasto, e o campo nLockTime da transação. Ambos têm de usar o mesmo tipo de limite: altura de bloco ou tempo. O campo nSequence da entrada também não pode ter o valor final que impediria a verificação. É um limite absoluto, não a idade relativa da saída desde a sua confirmação. Cumpri-lo não garante inclusão num segundo exato; um mineiro ainda tem de colocar a transação num bloco válido. [2]

Uma transação transmitida pode ficar no mempool, o conjunto de transações não confirmadas guardadas por um nó. Se as taxas subirem, o remetente pode querer oferecer mais através de uma transação de substituição. David A. Harding e Peter Todd descreveram as regras originais de substituição opt-in no BIP 125. A possibilidade de substituição era sinalizada por nSequence ou herdada de uma transação antecessora não confirmada cuja saída o pagamento gasta. Assim, também importavam as dependências entre transações. Uma taxa superior pode ajudar, mas não garante confirmação imediata. [3]

Substituir uma transação no mempool muda o candidato que o nó conserva para confirmação. Não reescreve o histórico confirmado. BIP 125 descreve também uma política histórica opt-in, não uma lei imutável para todos os programas. Versões posteriores de Bitcoin Core tornaram habitual a substituição sem esse sinal, mantendo condições para aceitar a nova transação. Para o destinatário, a lição é simples: a ausência do sinal não demonstra que o pagamento seja definitivo. Da mesma forma, a indicação «enviado» numa carteira não significa inclusão num bloco confirmado. [3] [6]

Voltemos ao contrato. OpenTimestamps cria uma prova verificável de que determinados dados existiam antes de um limite temporal comprovado. Usa um hash, uma impressão digital curta do conteúdo, e uma prova ancorada em Bitcoin. Alterar o documento produz uma impressão diferente durante a verificação. O carimbo não comprova a autoria, a veracidade do conteúdo nem o instante exato de criação. Também é possível carimbar atempadamente um relato falso. A prova limita o momento mais tardio em que os dados poderiam ter surgido; não diz há quanto tempo existiam. [1] [4]

O cliente OpenTimestamps não envia o documento aos servidores de calendário. Processa a sua impressão digital com um valor aleatório, impedindo o servidor de deduzir o conteúdo a partir do que recebe. Um calendário é aqui um serviço que reúne pedidos e ajuda a ancorá-los em Bitcoin. Proteger o conteúdo não equivale a anonimato completo: a proximidade temporal ou provas criadas em conjunto podem revelar ligações. O ficheiro .ots não é uma cópia de segurança. Guarde-o com o original exato; a impressão digital não recupera texto perdido e uma cópia alterada já representa outros dados. [5]

Um carimbo recém-criado pode ainda não estar ancorado num bloco confirmado. A existência do ficheiro .ots não demonstra, por si só, que o processo terminou. O cliente OpenTimestamps distingue uma prova pendente de uma completa, que contém o percurso até ao bloco. O comando ots upgrade pode obter e guardar a informação restante quando estiver disponível; não força a mineração de um bloco. Depois, é necessário verificar a prova face aos dados originais e à cadeia Bitcoin. Tal como num pagamento pendente, interessa o estado real, não apenas o aparecimento de um ficheiro ou aviso. [5]