Collaborative Custody to sposób zabezpieczania bitcoinów, w którym uczestniczą właściciel oraz inna osoba lub usługa. W popularnym modelu właściciel ma dość kluczy, aby zapłacić samodzielnie, a usługa pomaga w razie problemów. Ta niezależność musi wynikać z zasad portfela, nie tylko z nazwy produktu.
Piotr zarządza bitcoinami we własnym portfelu. Obawia się jednak utraty urządzenia lub kopii zapasowej. Portfel to aplikacja lub urządzenie do odbierania i wysyłania bitcoinów. Podpisanie oznacza tu użycie klucza prywatnego, czyli tajnej wartości liczbowej, do utworzenia sprawdzalnego dowodu autoryzacji płatności. Inni mogą zweryfikować podpis, nie znając tej tajnej wartości. Unchained opisuje model 2-of-3: płatność wymaga podpisów dwóch z trzech kluczy. Piotr ma A i B, usługa C. Działają więc A+B, A+C oraz B+C; samo C nie wystarcza. Wymóg kilku podpisów nazywa się Multisig. Piotr może płacić bez usługi i poprosić o pomoc po utracie klucza. Dwa urządzenia odtworzone z tej samej Seed Phrase, czyli tej samej kopii zapisanej słowami, nie są niezależne: ujawnienie wspólnego sekretu zagraża obu. [1] [4] [8]
Dopóki Piotr ma sprawne A+B i komplet informacji o portfelu, sama awaria usługi nie odbiera mu możliwości zapłaty. Jeśli pozostanie tylko A, do A+C potrzebuje usługi. Jej awaria lub odmowa podpisu może wtedy zablokować odzyskanie środków. Po utracie A i B samo C nie pomoże. Samodzielne odejście i odzyskiwanie z pomocą trzeba zatem sprawdzać osobno. Instrukcja Casa dotycząca odzyskania bez jej infrastruktury również wyraźnie zakłada niedostępność klucza usługi. Przebieg i sprzęt zależą od produktu; nie wynikają ze słowa „collaborative”. [1] [6]
Piotr ma kopie, ale inna aplikacja musi wiedzieć, jaki portfel odtworzyć. Typowy 2-of-3 wymaga kluczy publicznych wszystkich trzech uczestników, także dostawcy, oraz zasad ich użycia. Klucze publiczne sprawdzają podpisy, a prywatne je tworzą. Output Descriptor to opis konfiguracji zrozumiały dla programu, obejmujący wyprowadzanie adresów. Dwie własne kopie Seed Phrase nie odtworzą brakującego klucza publicznego dostawcy. Piotr zapisuje i sprawdza eksport, póki usługa działa. Przed przekazaniem go dalej sprawdza zawartość: ogólny format descriptor może zawierać także klucze prywatne. [4] [5]
Koordynator zbiera dane transakcji; podpisujący ma klucz, którym ją zatwierdza. PSBT, format opisany w BIP 174, przenosi niedokończoną transakcję i potrzebne informacje między programami oraz urządzeniami. Utworzenie pliku nie zastępuje brakującego podpisu. Koordynator bez klucza też może zaszkodzić, podsuwając innego odbiorcę. Przed podpisaniem trzeba sprawdzić adres, kwotę, opłatę i change, czyli resztę wracającą do własnego portfela. Hardware Wallet pomaga oddzielić klucz od komputera; nadal ważne jest to, co pozwala sprawdzić jej ekran i co Piotr faktycznie zatwierdza. [2] [3]
Błąd może powstać jeszcze przed pierwszą płatnością, przy zakładaniu wspólnego portfela. BIP 129 opisuje wymianę kluczy i konfiguracji tak, by uczestnicy porównali próg podpisów, zestaw kluczy oraz pierwszy adres. Obejmuje to typ skryptu, czyli zapisu warunków wydawania, i ścieżki wyprowadzania kolejnych kluczy. Podmienione ustawienia mogą skierować wpłaty gdzie indziej. Dokument nie obejmuje jednak odporności pamięci urządzenia ani późniejszej weryfikacji adresów odbiorczych i change. Obsługa standardu nie potwierdza bezpieczeństwa całego produktu. [2]
XPUB to rozszerzony klucz publiczny służący do wyprowadzania kluczy publicznych danej gałęzi portfela. Znajomość tych danych i konfiguracji może pozwolić dostawcy śledzić adresy oraz płatności, choć nie ma dość podpisów do wydania środków. Powiązanie ich z kontem na nazwisko klienta dodaje kolejny związek. Prywatność i prawo do wydawania to różne sprawy. Twierdzenie, że usługa nie zapłaci sama, też jest warunkowe: może zdobyć inny klucz Piotra lub podstępem skłonić go do szkodliwego podpisu. Mniejsze uprawnienia ograniczają część ryzyk, nie wszystkie. [2] [4]
Piotr traci klucz i tworzy nowy w aplikacji. To nie unieważnia starego dla wcześniejszych wpłat. Wyjście transakcji zapisuje kwotę i warunki, pod którymi można ją później wydać. Wcześniejsze wpłaty istnieją jako UTXO, niewydane wyjścia transakcji z własnymi warunkami wydawania. Przy zwykłym Multisig trzeba utworzyć nowe warunki i przenieść do nich odpowiednie środki potwierdzoną transakcją. Potem sprawdza się, co zostało na starych adresach. Zmiana hasła do konta lub etykiety klucza nie zastępuje przelewu. Trzeba też odświeżyć konfigurację i rodzinne instrukcje, inaczej spadkobiercy mogą skorzystać z nieaktualnego planu. [4] [9]
Przydatną próbę przeprowadza się na oddzielnym portfelu testowym. Piotr importuje zapisaną konfigurację do zgodnego programu, porównuje adresy i sprawdza podpisywanie własnymi kluczami bez pierwotnej usługi. Tryb watch-only pokazuje adresy i saldo, ale nie dowodzi zdolności do podpisania. Caravan to otwarty koordynator; trzeba sprawdzić obsługę konkretnego formatu i urządzeń. Próba obejmuje też odzyskiwanie z pomocą, niedostępny klucz, opłaty oraz change. Wynikiem powinna być zrozumiała, zapisana procedura z wersjami programów, a nie samo poczucie bezpieczeństwa na widok salda. [3] [6] [7]
Pełniejszy obraz uzyskasz, czytając to hasło razem z Multisig, Samodzielne przechowywanie bitcoinów, Output Descriptor, PSBT, Bitcoin Inheritance Plan, Counterparty risk. Do tego hasła prowadzą również odsyłacze z Bitcoin Inheritance Plan, Institutional custody.