Replay protection zrobione lepiej, czyli jak to powinno wyglądać

Wygadany
Awatar użytkownika
Posty: 593
Rejestracja: 8 lutego 2020
Reputacja: 1114
Reputacja postu: 
5
Napiwki za post: 0 BTC
Lokalizacja: 7-bit secp256k1

Replay protection zrobione lepiej, czyli jak to powinno wyglądać

Postautor: garlonicon » sobota, 18 czerwca 2022, 23:25

Historii nie cofniemy, transakcji na takim BCH i BSV jest już mnóstwo. Żeby to naprawić, można byłoby użyć na przykład sidechainów, ale nie sądzę, aby w najbliższym czasie którakolwiek ze stron chciała załatać taką kwestię i posprzątać po podziale. Żeby jednak ludzie mieli świadomość tego, co się da, a także wiedzieli na przyszłość, jak to można zrobić lepiej, opiszę technikalia, a nuż się komuś przydadzą przy jakichś altcoinach.

Ważna transakcja w 2010 powinna nadal być ważna w 2100r.
Ten cytat mnie zainspirował do tego wpisu. Na początku kwestia zasadnicza: ani BCH, ani BSV, nie dowozi niczego takiego. Jeśli ktoś miał w 2015 roku transakcję na BTC, która była zabezpieczona przez timelock transakcji (to ważne! chodzi o pole locktime w samej transakcji, ostatnie cztery bajty, nie żadne timelocki na wejściach/wyjściach!) i na przykład miał w tym 2015 roku transakcję, która mogłaby być rozgłoszona w 2025, no to lipa, po podziale taka transakcja jest nieprawidłowa. Żeby się o tym przekonać, wystarczy utworzyć transakcję i podpisać ją na BTC, a następnie spróbować puścić na BCH lub na BSV, komunikat będzie prosty i mówiący o tym, że SIGHASH_FORKID się nie zgadza. Pole locktime było dostępne od zawsze, od pierwszej wersji w 2009, więc takie przypadki jak najbardziej są możliwe, choć ciężko ocenić, ile ich było, no bo jak tu pokazać, ile monet się "nie przesunęło, a powinno", bo nagle się sygnatury okazały bezwartościowe.

No ale dobra, narzekasz, to sam wymyśl coś lepszego. Nie ma problemu, po to jest ten wpis. Przede wszystkim, kwestia zasadnicza jest taka, że baza monetarna nie powinna się w ogóle dzielić. Nie było takiej potrzeby. No ale załóżmy, że ludzie tego chcą i że chcą mieć dobrze zrobiony "replay protection". W porządku, da się to załatwić. Wystarczy zrobić transakcję, która przesyła każdą monetę za pomocą SIGHASH_SINGLE|SIGHASH_ANYONECANPAY z jednego adresu na drugi. Dokładnie ta sama kwota, adresy mogą być różne, żeby nie było wiadomo, czy to nie jest przy okazji płatność za coś, zawsze to mniej bajtów za to samo (ale jakby się ktoś uparł, to może użyć tych samych adresów).

Co dalej? Otóż jeśli ktoś miałby 1 BTC, to by wziął taką monetę, ustawił ją jako wejście transakcji, no i ustawiłby również 1 BTC na wyjściu. To oznaczałoby zerową opłatę od transakcji. Takie podejście zniechęciłoby taki łańcuch jak BTC do tego, aby to wykopywać. Wtedy takie BCH albo BSV mogłoby dać użytkownikom jednorazową zniżkę: jeśli masz monety z bloku przed podziałem, to masz do dyspozycji jedną darmową transakcję, w celu rozdzielenia monet. Proste, prawda?

Co by się stało dalej? Otóż użytkownicy mający stare monety mieliby możliwość jednorazowego wykonania darmowego przesyłu. Aby górnicy się zgodzili, musieliby mieć możliwość dołączania swoich wyjść z transakcji coinbase jako wejścia do transakcji użytkowników. Stąd flaga SIGHASH_ANYONECANPAY, która mówi: "górniku! możesz doczepić swoje monety do tej transakcji i nadal będzie prawidłowa". Żeby jednak górnicy nie byli zbyt charytatywni, pojawia się druga flaga: SIGHASH_SINGLE. Ta z kolei mówi: "tylko na tym jednym wyjściu mi zależy, każdy górnik może dołożyć własne wyjścia i to nadal będzie w porządku, bez zmian sygnatur".

Co by było, gdyby jakiś górnik na BTC zgodził się to wykopać? Otóż wtedy monety by się rozdzieliły, bo taki górnik dołożyłby monetę ze swojej transakcji coinbase. Innymi słowy: na którymkolwiek łańcuchu by to się nie stało, to taka transakcja oznaczałaby zerowy koszt z punktu widzenia użytkowników (bo czemu niby użytkownicy mają płacić za to, że się programiści nie dogadali?), a także automatycznie prowadziła do rozdzielenia monet wśród tych, którzy tego chcą, przy jednoczesnym nierozdzielaniu monet tych, którzy tego nie chcą. Da się? Da się.

Jest jeszcze bonus: takie sighashe powodują, że mamy podpisane tylko jedno wejście i jedno wyjście. To oznacza tyle, że takie rzeczy można łączyć. Innymi słowy: jeśli w mempoolu jest sto takich transakcji, to można je wszystkie pozbierać i wpakować do jednej z nich, wtedy jedno wyjście z transakcji coinbase może rozdzielić wiele monet wielu użytkowników naraz. Proste, łatwe i przyjemne.

Podsumowując: SIGHASH_SINGLE|SIGHASH_ANYONECANPAY oraz zerowa opłata od transakcji załatwia sprawę, zaś numer bloku, przy którym transakcja może być darmowa (czyli coś a'la coinage, tylko deczko w innym celu i nieco inaczej liczone), chroni przed zaspamowaniem sieci samymi darmowymi transakcjami, a całość spina transakcja coinbase, której wyjście stanowi podstawę podziału.

Wróć do „Bitcoin”

Kto jest online

Użytkownicy przeglądający to forum: Obecnie na forum nie ma żadnego zarejestrowanego użytkownika i 12 gości