Wyjaśnienie typów adresów Bitcoin

Bezpośrednia odpowiedź

Porównaj formaty adresów legacy, nested SegWit, native SegWit i Taproot, prefiksy, kompatybilność i limity bezpieczeństwa.

Dwa adresy Bitcoin mogą oba otrzymywać BTC, a mimo to tworzyć różne struktury transakcji w tle. Adres mainnet zaczynający się od 1, jeden zaczynający się od 3, adres bc1q i adres bc1p mogą być prawidłowymi celami, ale niekoniecznie reprezentują ten sam skrypt, kodowanie lub przyszły warunek wydatkowania.

Ta różnica jest łatwa do przeoczenia, ponieważ portfel przedstawia adres jako pojedynczy ciąg znaków. Pod spodem adres mówi oprogramowaniu, jak skonstruować wyjście transakcji. Gdy to wyjście zostanie potwierdzone, staje się UTXO, które później musi zostać wydane zgodnie z regułami skryptu zakodowanymi w tym wyjściu.

Praktyczne pytanie nie brzmi więc po prostu “Który prefiks jest nowszy?”. Chodzi o to, czy adres należy do zamierzonej sieci Bitcoin, jaki typ wyjścia reprezentuje, czy oprogramowanie wysyłające obsługuje ten format oraz co adres może—i czego nie może—ci powiedzieć przed autoryzacją płatności.

Co reprezentuje adres Bitcoin

Adres Bitcoin nie jest kontem w sensie bankowym. Nie zawiera bitcoinów, nie przechowuje klucza prywatnego ani nie zapewnia pełnego obrazu salda portfela. Jest to czytelny dla człowieka kod, który pomaga portfelowi skonstruować konkretne wyjście transakcji.

Uproszczona zależność jest następująca:

Adres Bitcoin
        ↓
Dekodowanie adresu
        ↓
scriptPubKey
        ↓
Wyjście transakcji
        ↓
Potwierdzone UTXO
        ↓
Przyszły warunek wydatkowania

Kiedy wysyłasz bitcoiny, portfel nie przenosi obiektu z jednego ciągu adresu do drugiego. Konsumuje istniejące UTXO jako wejścia transakcji i tworzy nowe wyjścia. Adres docelowy dostarcza informacji potrzebnych do zbudowania jednego z tych wyjść.

To dlatego format adresu ma znaczenie techniczne. Adres P2PKH prowadzi do innego skryptu wyjściowego niż adres P2WPKH. Wyjście Taproot P2TR jest znowu inne. Te wyjścia mogą wszystkie reprezentować wydawalne bitcoiny, ale warunki i serializacja używane przy ich wydawaniu nie są identyczne.

Adres nie jest kluczem prywatnym

Klucz prywatny pozostaje oddzielony od adresu. Portfel używa materiału klucza prywatnego do utworzenia podpisu lub danych świadka wymaganych przez warunek wydawania. Opublikowanie adresu odbiorczego nie publikuje klucza prywatnego.

Odwrotność jest również ważna: zobaczenie adresu nie dowodzi, że konkretna osoba kontroluje odpowiadający mu klucz. Analiza blockchain może obserwować transakcje i wyjścia, ale sam ciąg adresu nie jest dowodem tożsamości.

Dlaczego istnieje kilka formatów

Bitcoin ma wiele formatów adresów, ponieważ system transakcyjny ewoluował, zachowując kompatybilność ze starszymi wyjściami. Nowe formaty nie zastąpiły starych wyjść w blockchainie. Zamiast tego wprowadziły dodatkowe sposoby wyrażania warunków wydawania.

Cztery formaty, które większość użytkowników spotyka w głównej sieci Bitcoin, to:

• Legacy P2PKH, zwykle wyświetlany z adresem zaczynającym się od 1.
• P2SH, zwykle zaczynający się od 3; nested SegWit jest jednym z ważnych zastosowań P2SH, ale nie jedynym.
• Native SegWit, kodowany za pomocą Bech32 i zwykle zaczynający się od bc1q dla wersji świadka 0.
• Taproot, kodowany za pomocą Bech32m i zaczynający się od bc1p dla wyjść P2TR w wersji świadka 1.

Ważną zmianą nie jest wygląd ciągu. To, co odszyfrowane miejsce docelowe mówi portfelowi, aby umieścił w nowym wyjściu.

Porównanie typów adresów Bitcoin

Nazwa zwyczajowa	Prefiks sieci głównej	Kodowanie	Typowy wynik	Co mówi ci prefiks
Legacy	1	Base58Check	P2PKH	Rodzina bajtów wersji dla adresu hasha klucza publicznego sieci głównej
P2SH (w tym zagnieżdżony SegWit)	3	Base58Check	P2SH; zagnieżdżony SegWit jest jedną z możliwych konstrukcji skryptu wykupu	Celem jest P2SH, a nie dokładny skrypt wykupu wewnątrz
Native SegWit	bc1q	Bech32	Witness v0, powszechnie P2WPKH lub P2WSH	Główny cel Bech32 witness-version-0 w sieci głównej
Taproot	bc1p	Bech32m	P2TR	Główny cel Taproot witness-version-1 w sieci głównej

Ta tabela jest przydatna do identyfikacji, ale prefiks nie jest pełnym opisem przyszłego zachowania przy wydawaniu. Najwyraźniejszym przykładem jest 3... adres: identyfikuje P2SH, ale P2SH może zobowiązywać się do wielu skryptów redeem. Nested SegWit to tylko jedna z możliwości.

Adresy Legacy P2PKH

Legacy pay-to-public-key-hash, lub P2PKH, to format adresu najbardziej kojarzony z wczesnym oprogramowaniem portfela Bitcoin. W sieci głównej te adresy Base58Check zwykle zaczynają się od 1.

Adres reprezentuje hash klucza publicznego. Gdy portfel płaci na ten cel, tworzy skrypt blokujący P2PKH, który wymaga ważnego podpisu i odpowiedniego klucza publicznego podczas wydawania środków.

OP_DUP
OP_HASH160

OP_EQUALVERIFY
OP_CHECKSIG

Widoczny adres nie jest więc samym skryptem. Portfel dekoduje adres Base58Check, wyodrębnia wersję i ładunek, a następnie konstruuje odpowiedni scriptPubKey.

Wyjścia P2PKH pozostają ważnymi wyjściami Bitcoin. “Legacy” nie oznacza nieprawidłowe lub automatycznie niebezpieczne. Różnica staje się istotna przy porównywaniu struktury transakcji: wydawanie tradycyjnego wyjścia P2PKH umieszcza dane odblokowujące w skrypcie wejścia, zamiast używać serializacji świadka SegWit.

Ta różnica może zwiększyć wagę transakcji w porównaniu z typowymi wydatkami klucza SegWit. Nie oznacza to, że płatność P2PKH automatycznie ma określoną opłatę. Liczba wejść, liczba wyjść, wybrana stawka opłaty i reszta podpisanej transakcji nadal określają ostateczny koszt.

P2SH i Nested SegWit

Pay-to-script-hash, lub P2SH, przeniósł część logiki wydawania za hash. Adresy P2SH w sieci głównej używają Base58Check i zwykle zaczynają się od 3.

Standardowe wyjście P2SH umieszcza hash skryptu redeem w skrypcie blokującym:

OP_HASH160

OP_EQUAL

Pełny skrypt redeem jest dostarczany tylko wtedy, gdy wyjście jest wydawane. Stworzyło to ważne narzędzie kompatybilności, gdy wprowadzono SegWit: program świadka SegWit mógł być umieszczony wewnątrz skryptu redeem P2SH, umożliwiając nadawcy, który rozumiał zwykłe adresy P2SH, zapłatę za wyjście, które później zostanie wydane przy użyciu zasad SegWit.

Typowa konstrukcja z jednym kluczem nazywa się P2SH-P2WPKH:

Adres P2SH
    ↓
hash skryptu redeem
    ↓
skrypt redeem zawiera program świadka P2WPKH
    ↓
podpis i klucz publiczny są dostarczane przez dane świadka podczas wydawania

Prefiks 3 nie dowodzi SegWit

To jedna z najważniejszych ograniczeń wizualnej identyfikacji adresu. Adres zaczynający się od 3 mówi ci, że miejsce docelowe używa wersji adresu P2SH dla sieci głównej. Nie ujawnia pełnego skryptu redeem przed wydaniem wyjścia.

P2SH istniało przed SegWit i może opakowywać inne skrypty. Traktowanie każdego 3... adresu jako “adresu SegWit” jest zatem zbyt szerokie.

Granica techniczna: prefiks identyfikuje zewnętrzny format adresu. Nie dowodzi dokładnego skryptu ukrytego za hashem P2SH.

Natywny SegWit i bc1q

Natywny SegWit usuwa warstwę kompatybilności P2SH i reprezentuje program świadka bezpośrednio. BIP 173 wprowadził kodowanie Bech32 dla natywnych adresów SegWit.

W sieci głównej Bitcoin, część czytelna dla człowieka to bc. Wersja świadka 0 tworzy adresy powszechnie rozpoznawalne po początku bc1q.

Dwa typowe wyjścia wersji świadka 0 to:

• P2WPKH: 20-bajtowy program świadka powszechnie używany do płatności z pojedynczym kluczem.
• P2WSH: 32-bajtowy program świadka, który zobowiązuje się do skryptu świadka.

Sam adres daje portfelowi wersję świadka i program. Dla wersji świadka 0, typowe skrypty wyjściowe mają następujące formy:

P2WPKH: OP_0 
P2WSH:  OP_0

Dane wyjściowe bezpośrednio zawierają program świadka zamiast otoczki P2SH. Gdy UTXO jest wydawany, dane podpisu lub skryptu wymagane przez program świadka są dostarczane w świadku transakcji, a nie w tradycyjnym scriptSig w stylu P2PKH.

Bech32 zmienia również wykrywanie błędów

Bech32 to nie tylko inny alfabet. Zawiera sumę kontrolną zaprojektowaną dla tej rodziny adresów i oddziela czytelną dla człowieka część sieciową od zakodowanych danych świadka.

Ciągi Bech32 nie mogą mieszać wielkich i małych liter. Portfele zwykle wyświetlają adresy Bech32 głównej sieci Bitcoin małymi literami. W pełni wielkie litery mogą być poprawne zgodnie ze specyfikacją, ale mieszana wielkość liter jest nieprawidłowa.

Taproot i bc1p

Taproot wprowadził wyjścia pay-to-Taproot, czyli P2TR. P2TR używa wersji świadka 1 z 32-bajtowym programem świadka. W głównej sieci Bitcoin wynikowy adres zaczyna się od bc1p.

Wersja świadka 1 i nowsze używają Bech32m zamiast oryginalnej sumy kontrolnej Bech32. BIP 350 wprowadził tę zmianę po zidentyfikowaniu słabości w użyciu oryginalnej sumy kontrolnej Bech32 dla nowszych wersji świadka.

To daje praktyczną zasadę identyfikacji:

bc1q... → wersja witness 0 → Bech32
bc1p... → wersja witness 1 P2TR → Bech32m

Odpowiadający P2TR skrypt blokujący używa wersji świadka 1 i 32-bajtowego Taproot klucza wyjścia:

OP_1

Wyjście P2TR zobowiązuje się do tego Taproot klucza wyjścia. Może być później wydane przez ścieżkę klucza lub, jeśli drzewo skryptów zostało zobowiązane, przez prawidłową ujawnioną ścieżkę skryptu.

Adres nie ujawnia, która ścieżka zostanie ostatecznie użyta. Widząc bc1p dowiadujesz się, że wyjście jest P2TR. Nie mówi ci, czy przyszły wydawca użyje podpisu ścieżki klucza, czy ujawni ścieżkę skryptu.

Co naprawdę mówią prefiksy Bitcoin

Prefiksy są przydatne, ponieważ pozwalają człowiekowi szybko zidentyfikować prawdopodobną rodzinę adresów i sieć. Należy je traktować jako wstępną kontrolę, a nie pełną walidację.

Przykładowy początek	Prawdopodobne znaczenie dla mainnetu	Czego nie dowodzi
1...	Adres mainnet P2PKH	Właściciel, saldo lub tożsamość odbiorcy
3...	Adres mainnet P2SH	Że skrypt redeem jest zagnieżdżony SegWit
bc1q...	Adres natywny wersji świadka 0	Czy jest P2WPKH czy P2WSH na podstawie samego prefiksu
bc1p...	Adres P2TR wersji świadka 1	Która ścieżka wydania Taproot zostanie użyta później

Prefiks nie może również uwierzytelnić osoby, która podała ci adres. Doskonale zakodowany adres z prawidłową sumą kontrolną może nadal należeć do niewłaściwego odbiorcy.

Sieć jest ważniejsza niż typ adresu

Zanim wybierzesz między Legacy, SegWit lub Taproot, potwierdź, że adres należy do sieci Bitcoin, której zamierzasz użyć.

Adresy z rodziny Bech32 czynią to widocznym dzięki swojej części czytelnej dla człowieka. BIP 173 definiuje bc dla mainnetu Bitcoin i tb dla adresów testnet Bitcoin. Część czytelna dla człowieka jest zatem częścią walidacji sieci, a nie ozdobnikiem.

Rodziny adresów Base58Check również używają różnych bajtów wersji między mainnetem a sieciami testowymi, chociaż różnica jest mniej oczywista dla użytkownika, który patrzy tylko na ciąg znaków.

Portfel powinien odrzucać nieobsługiwaną kombinację sieci/adresu, ale ostateczna odpowiedzialność nadal spoczywa na potwierdzeniu sieci pokazanej przez aplikację wysyłającą. Rozpoznawanie formatu adresu nie zastępuje weryfikacji sieci.

Dla szerszego kontekstu transakcji — wejść, wyjść, potwierdzeń i warstwy bazowej Bitcoin — użyj Referencja sieci Bitcoin.

Typ adresu i opłaty transakcyjne

Często słyszy się, że nowszy adres Bitcoin jest “tańszy”. To stwierdzenie jest kierunkowo przydatne w niektórych porównaniach, ale zbyt proste, aby używać go jako zasady opłat.

Adres wybrany przez odbiorcę wpływa na typ i rozmiar serializacji wyjścia utworzonego dzisiaj. Co ważniejsze, gdy to wyjście zostanie później wydane, jego typ skryptu wpływa na strukturę odpowiedniego wejścia transakcji.

SegWit zmienia również rozliczanie Weight transakcji, ponieważ bajty świadka są ważone inaczej niż bajty niebędące świadkiem. Typowe natywne wydanie klucza SegWit ma zatem inny profil Weight niż porównywalne wydanie Legacy P2PKH. Wpływa to na rozmiar wirtualny, gdy UTXO jest wydawany, ale nadal nie ustala z góry całkowitej opłaty.

Ta sama kwota BTC może prowadzić do różnych przyszłych kosztów

Rozważ dwóch użytkowników, którzy otrzymują tę samą ilość bitcoinów. Jeden otrzymuje wyjście P2PKH, a drugi wyjście P2WPKH. Wartość jest identyczna. Przyszła struktura wejścia nie jest.

Gdy te UTXO zostaną później wydane, ich dane odblokowujące są serializowane inaczej. To zmienia Weight transakcji, a tym samym rozmiar wirtualny. Przy tym samym wskaźniku sat/vB, różne vSize oznacza inną całkowitą opłatę.

To ilustracyjny scenariusz techniczny, a nie zapis transakcji użytkownika ani twierdzenie o konkretnym portfelu.

Typ adresu nadal nie określa ostatecznej opłaty sam w sobie. Transakcja z wieloma wydajnymi wejściami SegWit może być większa niż transakcja z pojedynczym wejściem Legacy. Liczba wyjść, podpisy, ścieżki skryptów i wybrany wskaźnik opłaty również mają znaczenie.

Aby uzyskać pełny związek między Weight, rozmiarem wirtualnym i sat/vB, przeczytaj jak działają opłaty transakcyjne Bitcoin. Gdy potrzebujesz oszacowania specyficznego dla transakcji, a nie porównania koncepcyjnego, użyj Kalkulator opłat transakcyjnych Bitcoin.

Zgodność to kontrola nadawcy

Prawidłowy adres Bitcoin nie jest przydatny w przepływie płatności, jeśli portfel wysyłający lub usługa wypłat nie rozumie formatu.

To rozróżnienie było szczególnie ważne podczas wdrażania natywnego SegWit, a później Taproot. Sieć Bitcoin mogła rozpoznać typ wyjścia, podczas gdy starsze aplikacje nie obsługiwały tworzenia takiego miejsca docelowego.

Gdy usługa odrzuca bc1q lub bc1p adres, nie zmieniaj adresu ręcznie. Nie usuwaj znaków, nie zmieniaj prefiksu ani nie konwertuj go przez przypadkową stronę internetową. Użyj formatu adresu, który faktycznie wygenerował Twój portfel odbierający i który nadawca wyraźnie obsługuje.

Wysyłanie między formatami to nie konwersja

Nie potrzebujesz portfela Legacy, aby płacić na adres Legacy, ani portfela Taproot, aby płacić na adres Taproot w sensie dopasowywania formatów źródłowych i docelowych. Transakcja wysyłająca konsumuje dowolne obsługiwane UTXO wybrane przez portfel i tworzy nowe wyjście dla skryptu docelowego.

Istotne pytanie brzmi, czy oprogramowanie wysyłające może zdekodować i skonstruować żądane wyjście docelowe.

Prawidłowy adres może być nadal błędny

Sumy kontrolne wychwytują pewne błędy transkrypcji. Nie uwierzytelniają zamierzonego odbiorcy.

Jeśli złośliwe oprogramowanie zastąpi skopiowany adres innym prawidłowym adresem Bitcoin, zamiennik może przejść walidację sumy kontrolnej doskonale. Format techniczny jest prawidłowy; miejsce docelowe jest błędne.

Dlatego “portfel zaakceptował adres” nie jest ostateczną kontrolą bezpieczeństwa. Akceptacja mówi Ci, że oprogramowanie rozpoznało prawidłowe lub obsługiwane miejsce docelowe. Nie dowodzi, skąd pochodzi adres.

Zweryfikuj przed wysłaniem

Przydatny proces weryfikacji oddziela walidację formatu od walidacji odbiorcy.

1. Potwierdź sieć. Upewnij się, że portfel lub usługa wysyła Bitcoin w zamierzonej sieci Bitcoin, a nie w innym aktywie lub środowisku testowym.
2. Przeczytaj rodzinę adresów. A 1, 3, bc1q lub bc1p prefiks daje początkową wskazówkę co do formatu.
3. Potwierdź wsparcie nadawcy. Usługa wypłat lub portfel musi wyraźnie akceptować format docelowy.
4. Zweryfikuj miejsce docelowe za pomocą zaufanego kanału. Porównaj pełny adres na zaufanym ekranie, gdy to praktyczne, zamiast polegać tylko na kilku pierwszych i ostatnich znakach.
5. Przejrzyj końcowy ekran transakcji w portfelu. Potwierdź odbiorcę, kwotę, opłatę sieciową i ewentualną resztę przed podpisaniem.
6. Chroń poufne materiały. Weryfikacja adresu odbiorczego nigdy nie wymaga wprowadzania frazy początkowej lub klucza prywatnego na stronie internetowej.

W przypadku dużych lub operacyjnie wrażliwych transferów organizacje często dodają niezależne procedury weryfikacji miejsca docelowego. Te procedury są kontrolą operacyjną, a nie właściwością konkretnego formatu adresu Bitcoin.

Ponowne użycie adresu to osobna kwestia

Adres Bitcoin nie wygasa na poziomie protokołu tylko dlatego, że został użyty raz. Jeśli odpowiadający warunek wydatkowania pozostaje pod kontrolą, przyszłe płatności na ten sam adres mogą nadal tworzyć prawidłowe wyjścia.

To nie czyni ponownego użycia adresu pożądanym. Ponowne użycie adresu odbiorczego może ułatwić powiązanie transakcji na publicznym blockchainie i może zmniejszyć prywatność.

Ta kwestia prywatności jest oddzielona od tego, czy adres jest P2PKH, P2SH, P2WPKH czy P2TR. Nowoczesny format adresu nie czyni wielokrotnego użycia tego samego widocznego miejsca docelowego prywatnym.

Ograniczenia walidacji adresów

Walidacja formatu odpowiada na wąskie pytanie: czy ciąg znaków może być zdekodowany jako oczekiwany rodzaj miejsca docelowego Bitcoin zgodnie z odpowiednimi zasadami adresów. Nie uwierzytelnia osoby, która go dostarczyła, nie dowodzi posiadania klucza prywatnego, nie dowodzi całkowitego salda portfela, nie gwarantuje, że usługa obsługuje format, ani nie określa ostatecznej opłaty transakcyjnej.

Nie może również ujawnić informacji celowo ukrytych przez konstrukcję wyjścia. Adres P2SH nie ujawnia pełnego skryptu odkupu przed wydatkowaniem, a adres P2TR nie mówi z góry, czy przyszłe wydatkowanie użyje ścieżki klucza, czy ujawni ścieżkę skryptu. Traktuj pomyślne zdekodowanie jako jedną kontrolę w procesie płatności, a nie jako dowód, że wszystkie otaczające założenia są poprawne.

Wybór formatu odbiorczego

Najbezpieczniejszą domyślną opcją jest użycie adresu wygenerowanego przez portfel, który faktycznie kontrolujesz, zamiast ręcznego konstruowania lub konwertowania adresu.

Jeśli portfel odbierający oferuje więcej niż jeden typ adresu, użyj typu, który odpowiada zamierzonej polityce skryptów portfela i który nadawca może zdekodować. Adres P2WPKH jest odpowiedni, gdy portfel celowo generuje miejsce docelowe skrótu klucza w wersji świadka 0. Adres P2TR jest odpowiedni, gdy portfel celowo generuje miejsce docelowe Taproot, a nadawca je obsługuje. Starsze miejsca docelowe P2PKH lub P2SH pozostają prawidłowe, gdy przepływ pracy wymaga tych formatów.

Nie wybieraj formatu wyłącznie dlatego, że ktoś twierdzi, że jest “najtańszy”. Wynik, który tworzysz dzisiaj, staje się danymi wejściowymi dopiero wtedy, gdy zostanie wydany później, a ostateczny koszt tej przyszłej transakcji zależy od pełnej struktury transakcji i stawki opłaty.

Adres powinien pochodzić z portfela odbiorcy. Nadawca powinien go obsługiwać. Sieć powinna się zgadzać. Te trzy kontrole są ważniejsze niż samo dążenie do prefiksu.

Adres Bitcoin FAQ

Jaka jest różnica między bc1q a bc1p?

bc1q jest zazwyczaj początkiem adresu Bitcoin mainnet witness-version-0 zakodowanego za pomocą Bech32, takiego jak P2WPKH lub P2WSH. bc1p identyfikuje adres P2TR mainnet witness-version-1 zakodowany za pomocą Bech32m.

Czy każdy adres Bitcoin zaczynający się od 3 używa SegWit?

Nie. Adres mainnet zaczynający się od 3 jest adresem P2SH. Zagnieżdżony SegWit może używać P2SH, ale P2SH może zobowiązywać się do innych skryptów redeem, więc sam prefiks nie dowodzi, że wynik jest zagnieżdżonym SegWit.

Czy adresy Bitcoin są wrażliwe na wielkość liter?

Adresy Base58Check używają alfabetu wrażliwego na wielkość liter. Kodowania Bech32 i Bech32m nie mogą mieszać wielkich i małych liter; portfele Bitcoin zwykle wyświetlają je małymi literami. Nie zmieniaj ręcznie wielkości liter w adresie.

Czy mogę wysłać Bitcoin z jednego typu adresu na inny?

Tak, jeśli portfel wysyłający obsługuje format docelowy. Transakcja może wydać jeden obsługiwany typ danych wejściowych i utworzyć inny obsługiwany typ danych wyjściowych. Prefiksy źródłowe i docelowe nie muszą się zgadzać.

Czy adres Bitcoin wygasa?

Żadna reguła protokołu nie sprawia, że normalny adres Bitcoin wygasa po określonej dacie lub po jednej płatności. Portfele często generują nowe adresy odbiorcze, ponieważ ponowne użycie adresu może zmniejszyć prywatność, a nie dlatego, że wcześniej wygenerowane adresy automatycznie stają się nieprawidłowe.

Którego typu adresu Bitcoin powinienem użyć?

Użyj adresu wygenerowanego przez portfel odbiorcy dla sieci Bitcoin i typu skryptu, który zamierzasz użyć, a następnie potwierdź, że nadawca obsługuje ten format. Natywny SegWit jest powszechny w nowoczesnych płatnościach, podczas gdy Taproot jest odpowiedni, gdy obie strony obsługują P2TR. Nie przekształcaj ręcznie jednego formatu adresu w inny.

Źródła techniczne

Opisy formatów adresów powyżej opierają się na Bitcoin Improvement Proposals i dokumentacji Bitcoin Core. Te odniesienia definiują kodowania adresów, programy witness i zachowanie skryptów; nie dowodzą tożsamości ani bezpieczeństwa konkretnego adresu odbiorczego. Szersze podejście do źródeł BitcoinToolkit jest opisane na Źródła danych page.

• BIP 13: Format adresu dla pay-to-script-hash — określa format adresu Base58Check P2SH.
• BIP 16: Płać do skrótu skryptu — definiuje model wydawania P2SH i ocenę skryptu redeem.
• BIP 49: Schemat wyprowadzania dla P2WPKH-zagnieżdżonego-w-P2SH — dokumentuje typową konstrukcję pojedynczego klucza zagnieżdżonego SegWit omawianą w tym przewodniku.
• BIP 141: Segregated Witness — definiuje programy witness, identyfikator transakcji Weight i semantykę danych wyjściowych SegWit.
• BIP 173: Format adresu Base32 dla natywnych wyjść witness v0-16 — wprowadził natywne kodowanie adresów Bech32 SegWit.
• BIP 350: Format Bech32m dla adresów witness v1+ — definiuje Bech32m i regułę sumy kontrolnej dla nowszych wersji witness.
• BIP 341: Taproot — definiuje zasady wydawania i danych wyjściowych Taproot, w tym P2TR witness version 1.
• Deskryptory wyjść Bitcoin Core — dokumentuje strukturalne opisy typowych skryptów wyjściowych Bitcoin i wyrażeń kluczy.

Źródła

1. BIP 13: Format adresu P2SH
2. BIP 141: Segregated Witness
3. BIP 173: Adresy Bech32 native SegWit
4. BIP 350: Bech32m
5. BIP 341: Taproot
6. Deskryptory wyjść Bitcoin Core

Znalazłeś błąd? Zgłoś problem z treścią lub przeczytaj nasz Polityka poprawek.