Zrozumieć Taproot

[Peer]

Hej. Jak pewnie wiecie, od paru miesięcy w Bitcoinie funkcjonuje Taproot - najnowszy softfork
Motywowany artykułem, który napisałem, wyjaśniący w stosunkowo przystepny sposób zmiany, nowości, możliwości w Bitcoinie po wprowadzeniu Taproot,
chciałem stworzyć szerszy wątek dotyczący Taproot.

Taproot to ogólnie złożony temat, trudny technicznie, jednocześnie IMAO bardzo ekscytujący.
Być może sa tutaj spece rozumiejący składowe Taproot (i jak działają) i jednocześnie widzicie możliwości wykorzystania ich, o czym możemy pogadać.

Na początek zapraszam do artykułu, który wprowadza do Taproot: https://www.mobycrypt.com/pl/zrozumiec- ... k-taproot/

Na zajawkę wrzucę wycinek artykułu w skrócie wyjaśniający softfork Taproot:
Aktualizacja Taproot z wykorzystaniem podpisów Schnorra oraz MAST wprowadza do Bitcoina nowy typ transakcji: P2TR. Ten typ transakcji:

- zwiększa prywatność adresów multisignature, wykorzystując podpisy Schnorr i ich możliwość agregacji do pojedynczej sygnatury i klucza. Oznacza to, że adresy multisig będą nie do rozróżnienia względem normalnych adresów.

- zwiększa możliwości tworzenia skryptów zabezpieczających wydanie Bitcoinów oraz znacząco poprawia ich prywatność – można tworzyć reguły wydania BItcoinów (wysłania transakcji), definiując wiele alternatywnych warunków, jednak w taki sposób, że warunki te nie będą jawnie widoczne w blockchainie, a nawet nie będą widoczne w momencie wydawania tych Bitcoinów (oprócz pojedynczego warunku z listy zdefiniowanych, tego, który ma autoryzować konkretną transakcję).

Język Tapscript to uaktualniona nazwa języka skryptowego Bitcoin, zawierająca m.in. komendy dodane do tego języka, w celu umożliwienia funkcjonalności opisanych wyżej.

[zdzicho2000]

@Peer strona jest Twoja? Bo wyskakujące okno z zachętą otrzymywania na mail materiałów zasłania prawie cały ekran i nie da się jej zamknąć. Przez co na razie nie przeczytałem Twego artykułu. Na smartfonie takie rzeczy sie dzieją. Przeglądarka Brave i Duckduckgi

[Peer]

@zdzicho2000 Hej, wyłączyłem tego popupa, dzięki za info.

[zdzicho2000]

Dzieki!
A tak w skrócie na zdrowy chłopski-
Zwiekszona prywatnosc wystepuje tylko transakcji multisign?

A jeśli w normalnej to w jakiej konfiguracji adresow? Tylko adres taproot - adres taproot, czy w krzyżowych też?

[Peer]

@zdzicho2000 Jeśli nawiązujesz do sygnatur Schnorra, to prywatność w kontekście tego, że zapisana jest jedna sygnatura w blockchain, w sumie nie do odróżnienia dla postronnego obserwatora względem normalnego podpisu (pojedynczego)

[garlonicon]

Zwiekszona prywatnosc wystepuje tylko transakcji multisign?

Nie tylko. Chodzi o to, że jak masz adres Taproot, to zawsze istnieje uzasadniona wątpliwość, że "te monety można wydać jeszcze na inne sposoby, które nie zostały ujawnione". Każdą monetę z adresu Taproot możesz wydać na dwa sposoby: albo poprzez złożenie sygnatury pasującej do klucza publicznego (który jest ustawiony w samym adresie, tu nie ma żadnego hashowania, jeśli znasz adres Taproot, to znasz klucz publiczny, a nie hash klucza publicznego, jak to było w przypadku starszych typów adresów), albo poprzez TapScript. Drugi sposób polega na tym, że ujawniasz klucz publiczny (to ważne, bo nie musisz wtedy znać klucza prywatnego), a następnie pokazujesz taki script, którego hash dodany do tego klucza spowoduje uzyskanie adresu Taproot, z którego wydajesz środki. Sama konstrukcja gwarantuje, że najpierw musisz przygotować wszystkie sposoby, na które można wydać daną monetę, a potem powstaje z tego adres, którego można użyć. Ponieważ ujawniasz tylko jeden z tych sposobów, nie ma żadnej gwarancji co do tego, że tych samych monet nie dało się przesunąć inaczej. Być może się dało, wie o tym tylko twórca adresu Taproot.

Innymi słowy: Taproot to taka hybryda, takie połączenie P2PK oraz P2SH w taki sposób, że możesz te same monety wydać albo przez klucz, albo przez TapScript. Jeśli wydajesz przez klucz, wtedy wjeżdżają sygnatury Schnorra, co powoduje, że nie wiadomo, czy został użyty jeden klucz, czy też N kluczy. Po prostu zawsze masz wtedy jedną sygnaturę. Jeśli natomiast ludzie się pokłócą i nie dojdą do porozumienia, to zawsze mogą pokazać jakiś wcześniej ustalony klucz publiczny, udowodnić, że dany TapScript jest powiązany z tym adresem Taproot, a następnie wydać monety poprzez TapScript, czyli włożyć na stos takie dane, aby została ostatecznie wartość OP_TRUE, która odpowiada na pytanie, czy monety można przesunąć. Natomiast TapScript to już cały predykat ciągnie za sobą, co oznacza, że warunki mogą być dowolne i nie muszą wymagać żadnych kluczy.

Edit: Przy okazji taka ciekawostka: niektórzy myślą, że taki opkod OP_CHECKLOCKTIMEVERIFY musi być w całości podany jako wyjście. Otóż to nieprawda. Można zrobić tak, aby mieć na przykład adres multisig zmajstrowany tak, aby czas określany jako locktime znalazł się jako wejście, a nie był z góry wrzucony na wyjściu. To wiele zmienia. Tak samo można rozdzielić multisig i umożliwić dodanie dowolnego klucza publicznego do listy. Choćby coś takiego:

zamiast: "OP_2 <pubkeyAlice> <pubkeyBob> OP_2 OP_CHECKMULTISIG"
można też tak: "OP_TOALTSTACK OP_2 OP_FROMALTSTACK <pubkeyBob> OP_2 OP_CHECKMULTISIG"
(nawiasem mówiąc: w przypadku Taproota został wycofany klasyczny multisig, zamiast tego należy używać OP_CHECKSIGADD, więc ten przykład pasuje jedynie do starszych typów adresów, ale może niektórym otworzy nieco oczy na to, co jest możliwe)

a zamiast: "<locktime> OP_CHECKLOCKTIMEVERIFY OP_DROP <pubkeyAlice> OP_CHECKSIG"
można też tak: "OP_CHECKLOCKTIMEVERIFY OP_DROP <pubkeyAlice> OP_CHECKSIG"

Także cóż, nawet jeśli wszystkie warunki należy ustalić z góry, to jest tutaj dużo swobody. Nie mówiąc już o takich sztuczkach: "<signatureAlice> OP_SWAP OP_CHECKSIGVERIFY <pubkeyBob> OP_CHECKSIG".