co się dzieje z transakcjami używającymi adresów taproot
Przede wszystkim: adresy Taproot to takie, które zaczynają się od bc1p. Sam adres po prostu koduje klucz publiczny w formacie bech32. W przeciwieństwie do typowych adresów, w przypadku Taproota klucz publiczny jest bezpośrednio umieszczony w adresie, adres Taproot to nie jest hash klucza publicznego, to jest sam klucz publiczny. Oznacza to tyle, że jeśli utworzysz sygnaturę pasującą do takiego klucza, to możesz przesunąć środki wrzucone na taki adres.
Adres Taproot można wydać na dwa sposoby: albo przez klucz, albo przez TapScript. Jeśli wydajesz przez klucz, to po prostu umieszczasz pojedynczą prawidłową sygnaturę i na tym cała zabawa się kończy. Jeśli natomiast wydajesz przez TapScript, to umieszczasz klucz publiczny, TapScript oraz dane potwierdzające, że możesz przesunąć monety z tego adresu. Innymi słowy: adres Taproot łączy w sobie cechy adresów pay-to-key oraz pay-to-script, przy wydawaniu monet możesz wybrać, w jaki sposób chcesz to zrobić. Co więcej, jest to pay-to-script na sterydach, bo nie ujawniasz całego TapScriptu: pokazujesz tylko ten konkretny kawałek, za pomocą którego chcesz wydać te monety. Poza tym, pay-to-key też jest odpowiednio dopakowany, bo zamiast zwykłych sygnatur masz sygnatury Schnorra, więc każdy N-of-N multisig możesz wydać za pomocą pojedynczej sygnatury, co oznacza, że wygląda to tak, jakby to robiła jedna osoba.
Bo muun umożliwia generowanie tego typu adresów?
Jeśli masz adres zaczynający się od bc1p, to jest to adres Taproot. Na podstawie tego, w jaki sposób monety są przesuwane możesz stwierdzić, czy zostało to zrobione przez klucz, czy przez TapScript.
gdy jest taproot- taproot?
Działa to tak samo, jak w przypadku, gdy jest "cokolwiek->taproot", czy też "taproot->cokolwiek". Tutaj nie ma agregacji wejść i wyjść na poziomie transakcji, cała sztuczka polega na tym, że jedno i to samo wyjście typu Taproot może należeć do wielu osób i jeśli te osoby wydadzą swoje środki przez klucz, a nie przez TapScript, to będzie to nierozróżnialne od przypadku, gdy jedno wyjście należy do jednej osoby. Konsekwencje są takie, że jeśli analizujesz blockchain i widzisz jakiś adres Taproot, to nie jesteś w stanie stwierdzić, do ilu osób należy. A nawet jeśli ktoś wydaje środki przez TapScript, to nie jesteś w stanie stwierdzić, na ile jeszcze sposobów można było wydać te same monety, więc jest uzasadniona wątpliwość co do tego, że "tam mogło być więcej ludzi, ale nikt o tym nie wie".
A co gdy jedną stroną transakcji jest adres taproot, a drugą legacy lub segwit?
To jest soft-fork przeprowadzony w analogiczny sposób, co Segwit: każdy stary klient przepuszcza wszystkie bloki z transakcjami Taproot jako prawidłowe. Konsekwencje są analogiczne, co w przypadku połączenia adresów legacy z adresami segwit: każde wejście musi zostać wydane adekwatnie do typu, a wyjścia mogą być dowolnego typu, bo ich poprawność będzie sprawdzona dopiero, gdy staną się wejściami w ramach innej transakcji.
I czy tak można, nic ze środkami się nie stanie?
Możesz żonglować typami adresów wedle życzenia. Jeśli masz wątpliwości, to testnet pozwala sprawdzić, czy to, co chcesz zrobić, jest zgodne z konsensusem. Natomiast regtest pozwoli zobaczyć, czy taka transakcja będzie standardowa (to znaczy, czy będziesz w stanie ją przeprowadzić bez dodatkowego wsparcia górników). W najnowszych klientach transakcje typu Taproot są standardowe i wszelkie kombinacje z wcześniej istniejącymi typami adresów są dopuszczalne.