Co sprawia, że implementacja agregacji sygnatur między danymi wejściowymi jest skomplikowana?
Co sprawia, że implementacja agregacji sygnatur między danymi wejściowymi jest skomplikowana? Inaczej niż z powodów związanych z przestrzenią projektową, dlaczego nie trafił do BIP-Taproot? (Agregację kluczy w ramach jednego wejścia można osiągnąć za pomocą MuSig, MuSig2 itp., Ale sygnatury nie mogą być agregowane na różnych wejściach za pomocą BIP-Taproot.)
To pytanie zadał Thorkil Vaerge na Twitterze .
Odpowiedzi
Pieter Wuille odpowiedział na to na Twitterze .
Najważniejsza komplikacja agregacji krzyżowych danych wejściowych została wyjaśniona w tym poście na liście mailingowej deweloperów Bitcoin autorstwa AJ Towns.
TL; DR: jeśli softfork zmienia, które podpisy są sprawdzane, nie może zmieniać tego, co jest razem agregowane. Jest to szczególnie skomplikowane, gdy współdziałają z mechanizmem aktualizacji OP_SUCCESSx BIP341, który może z łatwością pozwolić przyszłym softforkom całkowicie zmienić semantykę skryptu. Nie ma tu nic zasadniczo trudnego - wystarczy złożoność inżynieryjna, aby upewnić się, że wszystko działa dobrze.
Pieter dodał na londyńskim seminarium BitDevs Socratic na BIP-Taproot:
Graftroot i agregacja danych krzyżowych to tak głębokie konceptualne zmiany. Nie możesz pozwolić na ich późniejsze zbudowanie. To taka strukturalna zmiana w działaniu skryptów. Te rzeczy nie są czymś, co można po prostu dodać później, na wierzchu Taproot. Potrzebujesz następcy. Agregacja cross-input, koncepcja weryfikacji skryptu nie jest już kwestią poszczególnych danych wejściowych, ale kwestią związaną z transakcją. Nie da się tego zrobić z optymalną wydajnością, myślę, że można coś wymyślić. Typ wbudowanej rozszerzalności to nowe kody rozkazów, nowe typy kluczy publicznych, nowe typy westchnień, wszystkie te rzeczy są dość łatwe i nie mają prawie żadnych wad w porównaniu z brakiem wykonywania ich od razu. Prawdziwe zmiany strukturalne w wykonywaniu skryptów, potrzebują czegoś innego.