Twierdzi się, że OP_IF jest zawsze niepotrzebny w skryptach taproot. To jest fałsz. Ten skrypt cytowany od @mononautical jest w rzeczywistości tańszy, jeśli jest połączony: wszystkie ścieżki wydatków wymagają w każdym razie 4 kluczy publicznych. Po 4 OP_CHECKSIGADD, reszta skryptu ma mniej niż 32 bajty, więc taniej jest pozostawić go połączonym. Rozdzielając, usuwasz koniec skryptu, który sprawdza timelocki, ale dodajesz 32 bajty do bloku kontrolnego, ponieważ skrypt jest teraz na głębokości 1 zamiast 0. Dlatego kompilator, który optymalizuje pod kątem kosztów wydatków, _będzie_ produkować połączony skrypt (to znaczy taptree z pojedynczym liściem), ponieważ jest to nieco tańsze nawet w głównej ścieżce wydatków (3 z 4). Użytkownicy optymalizujący wyłącznie pod kątem prywatności najprawdopodobniej będą chcieli go rozdzielić. Innymi słowy, produkcja najlepszego taptree to problem optymalizacji z dwoma zmiennymi: koszt wydatków i prywatność, a bardzo często nie można optymalizować obu jednocześnie. Spodziewałbym się, że większość użytkowników nie będzie absolutnie optymalizować żadnej ze zmiennych wyłącznie, a raczej wybierze taptree z całkiem dobrym kosztem i całkiem dobrą prywatnością. Dla skryptu, który pokazuje @mononautical, taptree z tylko dwoma liśćmi byłby całkiem dobry: główna ścieżka to po prostu proste 3 z 4 i byłaby używana do większości wydatków, a reszta warunków wydatków (możliwe, że połączona w jednym tapleafie) mam nadzieję, że nigdy nie trafi na łańcuch. Gdy w równaniu uwzględnisz MuSig i FROST, pojawia się jeszcze więcej zmiennych: MuSig i FROST mogą obniżyć koszty i poprawić prywatność, ale zwiększają wymagania dotyczące interaktywności i złożoności implementacji. Co wybiorą deweloperzy i użytkownicy? Nie wiem! Tylko idioci nie mają wątpliwości.