Gregory Maxwell

Maxwell łączył rozwój Bitcoina z prywatnością i bezpieczeństwem. Współzałożył Blockstream, gdzie pełnił funkcję CTO, czyli dyrektora technicznego. Firma ogłosiła 19 stycznia 2018, że odszedł z tego stanowiska, aby skupić się na Bitcoinie. To data ogłoszenia, nie dowód dokładnego dnia odejścia. Komunikat nie określa też jego obecnego zatrudnienia. Ważniejsze są tu konkretne problemy, nad którymi pracował, niż nazwa stanowiska. [1]

Wyobraź sobie kilka osób łączących płatności w jedną transakcję. Każda dodaje swoje wejścia, czyli wcześniej otrzymane monety, które teraz wydaje, i podpisuje zgodę na ich użycie. Obserwator nie może więc z samego połączenia pewnie wywnioskować, że wszystkie należą do jednej osoby. Pod pseudonimem gmaxwell Maxwell opisał CoinJoin 22 sierpnia 2013. Wyraźnie wspomniał o wcześniejszym ograniczonym użyciu; rozwiązanie nie wymagało zmiany reguł protokołu Bitcoin. [2]

Jak uczestnicy ustalają, co podpisać? Prosty CoinJoin może przygotować koordynator, ale każdy najpierw sprawdza swoje wyjście: dokąd trafiają jego środki i w jakiej wysokości. Dopiero potem podpisuje swoje wejścia. Nie daje to koordynatorowi swobody wydawania monet. W prostym wariancie może on jednak znać powiązania wejść z wyjściami. Uczestnik odmawiający podpisu może też zatrzymać całą rundę. Ochrona przed kradzieżą, dostępność i prywatność to różne właściwości. [2]

Zwykłe transakcje Bitcoin ujawniają kwoty. Confidential Transactions rozwiązują inny problem niż łączenie płatności: ukrywają kwoty w zobowiązaniach kryptograficznych. Te ustalają wartość bez jej ujawniania, a jednocześnie pozwalają sprawdzać sumy. Wyjaśnienie Maxwella w Elements rozwija propozycję Adama Backa z 2013. Użycie w Elements nie oznacza wdrożenia tej funkcji w podstawowej sieci Bitcoin. Ukrycie kwot samo nie ukrywa też całego grafu transakcji, czyli powiązań między płatnościami. [3]

Arytmetycznie 10 = 11 + (-1). Jako model przelewu bez opłat pokazuje to problem: suma się zgadza, ale dodatnie wyjście przekracza wartość początkową, równoważone przez bezsensowne wyjście ujemne. W Confidential Transactions podobny efekt może dać przepełnienie modularne, gdy obliczenie zawija się na granicy systemu liczbowego. Potrzebny jest więc dowód zakresu: potwierdza, że ukryta kwota mieści się w dozwolonym przedziale, nie ujawniając jej dokładnej wartości. Prywatność nie może umożliwiać tworzenia dodatkowych pieniędzy. [3]

Po co publikować zapasowe warunki wydania środków, jeśli wszyscy się zgodzili i nie trzeba było z nich korzystać? Propozycja Taproot Maxwella z 23 stycznia 2018 pokazywała, jak wspólny podpis może ukryć istnienie innych warunków. Gdy strony współpracują, bardziej złożone porozumienie może wyglądać jak zwykła płatność autoryzowana kluczem. Data wpisu nie jest jednak datą aktywacji w sieci. Od pomysłu do przyjęcia potrzebne są dyskusja, precyzyjne zasady i ich akceptacja. [4]

Końcowa specyfikacja BIP 341, publiczny dokument techniczny opisujący reguły Taproot, wymienia autorów: Pieter Wuille, Jonas Nick i Anthony Towns. Ścieżka klucza może wykorzystywać podpis bez ujawniania istnienia alternatywnego skryptu. Skrypt to program wyrażający warunki wydania środków; przy użyciu tej ścieżki ujawnia się wybrany program i dowód jego uwzględnienia. Nie umniejsza to pierwotnego pomysłu Maxwella, ale nie pozwala przypisać mu wyłącznego autorstwa końcowych reguł. [5]

Wysyłanie pieniędzy wymaga też poprawnie zapisanego adresu. Pieter Wuille i Greg Maxwell są autorami BIP 173 opisującego Bech32 dla natywnych adresów SegWit. Suma kontrolna zawiera znaki pomagające wykryć błąd kodowania. Nie potwierdza tożsamości odbiorcy ani tego, kto ma klucz prywatny. Poprawny, lecz podmieniony adres może przejść kontrolę. Bech32 rozwiązuje zatem inny problem niż CoinJoin lub ukryte kwoty; tych korzyści nie należy utożsamiać. [6]