O que torna a agregação de assinatura de entrada cruzada complicada de implementar?

Question

O que torna a agregação de assinatura de entrada cruzada complicada de implementar? Exceto por razões de espaço de design, por que não foi incluído no BIP-Taproot? (A agregação de chave em uma entrada pode ser obtida com MuSig, MuSig2 etc, mas as assinaturas não podem ser agregadas em diferentes entradas com BIP-Taproot.)

Esta pergunta foi feita por Thorkil Vaerge no Twitter .

Answer 1

Pieter Wuille respondeu a isso no Twitter .

A complicação mais importante de agregação de entrada cruz é explicado neste Bitcoin dev lista de discussão pós por AJ Cidades.

TL; DR: se os softforks alterarem quais assinaturas são verificadas, eles não devem alterar o que está agregado. Isso é especialmente complicado quando eles interagem com o mecanismo de atualização OP_SUCCESSx do BIP341, o que poderia facilmente permitir que os softforks futuros mudassem totalmente a semântica do script. Não há nada fundamentalmente difícil aqui - é apenas complexidade de engenharia para garantir que tudo funcione bem em conjunto.

Pieter adicionado em um London BitDevs Socratic Seminar on BIP-Taproot:

Graftroot e agregação de entrada cruzada são mudanças profundamente conceituais. Você não pode permitir construí-los mais tarde. É uma mudança estrutural na forma como os scripts funcionam. Essas coisas não são algo que pode ser adicionado posteriormente no topo da Taproot. Você precisa de um sucessor. Agregação de entrada cruzada, o conceito de verificação de script não é mais algo por entrada, mas por transação. Você não pode fazer isso com eficiência ideal, acho que você pode inventar coisas. O tipo de extensibilidade que é embutido são novos opcodes, novos tipos de chaves públicas, novos tipos de sighash, todas essas coisas são bastante fáceis e quase não trazem desvantagens em comparação a não fazê-las imediatamente. Mudanças estruturais reais na execução do script, eles precisam de algo mais.