159 / 736LABEL

Transaction Labeling

Notatki, dzięki którym później rozumiesz płatności

Kwota i data nie zawsze wystarczą, by po miesiącach przypomnieć sobie cel płatności. Etykiety dodają własny kontekst do historii portfela. Warto wiedzieć, co opisują, czego nie gwarantują i jak zachować je przy odtwarzaniu.

Portfel to aplikacja lub urządzenie do odbierania i wysyłania bitcoinów. Transaction Labeling oznacza dodawanie opisów i notatek do transakcji, adresów lub innych zapisów portfela. Mogą wskazywać cel płatności albo pochodzenie otrzymanych środków. Te metadane pozostają w aplikacji poza transakcją Bitcoin i same nie dowodzą tożsamości drugiej strony.

Otwierasz historię portfela i widzisz dawną płatność. Była zaliczką, prezentem czy przelewem na twoje inne konto? Etykieta „zaliczka na naprawę roweru” może wyjaśnić zapis nawet po długim czasie. Jej zmiana modyfikuje notatkę aplikacji, nie transakcję ani jej identyfikator txid. Nie trzeba niczego nowego zapisywać w blockchainie, publicznej historii potwierdzonych transakcji. To samo ma znaczenie przy odzyskiwaniu: Seed Phrase, słowa odtwarzające klucze portfela, nie zawiera twoich notatek. Odzyskać możliwość wydawania i odzyskać kontekst płatności to różne zadania. [1] [3] [5]

Przydatna notatka opisuje to, co wiesz: numer faktury, cel lub źródło pieniędzy. Własny zapis różni się jednak od automatycznego powiązania aplikacji czy twierdzenia przejętego od analityka. BTCPay Server używa na przykład invoice dla płatności przez fakturę oraz payout dla wypłat lub zwrotów; pozwala też tworzyć własne etykiety. Kontekst pomaga w Coin Control, ręcznym wyborze UTXO, czyli niewydanych wyjść. Każde takie wyjście zapisuje kwotę i warunki jej wydania. Sam napis „nie łączyć” niczego jednak nie zatrzyma. O tym, które wpływy połączy kolejna płatność, decyduje faktyczny wybór wejść. [1] [2]

Niektóre portfele potrafią zamrozić wyjście, aby aplikacja nie wybierała go do wydania. BIP 329 przenosi ten lokalny stan przez spendable, wyłącznie dla typu output. spendable:false używa wartości logicznej false; tekst "false" jest czymś innym. W praktyce zamrożenie chroni przed przypadkowym wyborem w tej aplikacji, a nie przed każdym możliwym wydaniem. Nie jest to Timelock, warunek czasowy egzekwowany przez Bitcoin. Inny portfel z odpowiednimi kluczami może wydać wyjście, jeśli spełni jego rzeczywiste warunki. [1] [3]

Przy zmianie aplikacji pomyśl więc o osobnym eksporcie notatek. Plik może powiązać nazwiska, faktury i historię z adresami lub XPUB, rozszerzonym kluczem publicznym. Pozwala on obliczyć kolejne adresy odpowiedniej części portfela, ale sam XPUB nie pozwala podpisywać płatności. Jeżeli eksport zawiera rekord typu spscan, ten rekord zawiera prywatny klucz skanowania służący do odnajdywania przychodzących Silent Payments. Sam nie pozwala wydawać, ale ujawnienie go szkodzi prywatności. Brak prywatnego klucza wydawania nie oznacza więc, że plik można swobodnie udostępniać. Szyfruj przechowywane kopie i przesyłanie, a odtworzenie sprawdzaj na właściwym koncie. [1] [4] [5]

BIP 329 rozróżnia tx, addr, pubkey, input, output, xpub i spscan: transakcję, adres, klucz publiczny, wejście, wyjście, rozszerzony klucz publiczny i wyrażenie skanowania Silent Payments. Typ wyznacza znaczenie ref. Dla input jest to identyfikator transakcji i indeks jej wejścia; dla output identyfikator transakcji tworzącej wyjście i jego indeks. Zapis txid:1 bez typu nie wystarcza. Może oznaczać wejście lub wyjście, czyli różne obiekty. Uznawanie każdego takiego odwołania za „adres płatności” nie jest bezpieczne. [1] [4]

BIP 329 stosuje JSON Lines: tekstowy plik UTF-8 zawierający jeden uporządkowany rekord w każdym wierszu. Nie musisz pisać go ręcznie; obie aplikacje muszą go rozumieć. Wymagane type i ref wskazują obiekt. label, origin i spendable są opcjonalne. Brak label lub spendable nie powinien nadpisywać istniejącej wartości podczas importu. Zgodny importer powinien ignorować nieznane typy. Poprawne otwarcie pliku nie oznacza więc zachowania wszystkich notatek i ustawień. [1]

Transakcja może występować na kilku kontach lub w portfelach z różnymi opisami. origin pomaga odróżnić te perspektywy. Zawiera skrócony Output Descriptor, maszynowy opis portfela, z informacją o pochodzeniu kluczy, lecz bez samych kluczy, potomnych ścieżek wyprowadzania i sumy kontrolnej. Określa portfel, którego dotyczy etykieta. Nie podpisuje jednak pliku ani nie potwierdza prawdziwości wpisanego celu płatności. Rozpoznanie właściwego konta i zaufanie do treści są różnymi sprawami. [1]

Zanim porzucisz starą aplikację, wypróbuj przenoszenie na oddzielnej kopii testowej. Porównaj znane płatności: obiekt i ref, tekst oraz ewentualne zamrożenie spendable. Sprawdź polskie znaki, wiele kont, nieznany typ i brak opcjonalnych pól. Importer może pominąć nieobsługiwane rekordy lub skrócić etykiety. Zalecane 255 znaków to limit domyślny, nie gwarancja każdej aplikacji. Zachowaj pierwotną kopię, dopóki nie potwierdzisz ważnego kontekstu. Sam komunikat „import zakończony” tego nie dowodzi. [1]

Pełniejszy obraz uzyskasz, czytając to hasło razem z Coin Control, UTXO, Prywatność w Bitcoinie, Address Clustering, Seed Phrase, Output Descriptor. Do tego hasła prowadzą również odsyłacze z Chain Surveillance.

DOC · 001BIP 329 — Wallet Labels Export FormatSpecyfikacja DOC · 002BTCPay Server — WalletDokumentacja DOC · 003Bitcoin Developer Guide — TransactionsDokumentacja DOC · 004BIP 392 — Silent Payment Output Script DescriptorsSpecyfikacja DOC · 005Bitcoin Developer Guide — WalletsDokumentacja
Zaktualizowano: Najpierw źródła · To nie jest porada inwestycyjna