Bitcoin-adrestypen uitgelegd

Direct antwoord

Vergelijk legacy-, geneste SegWit-, native SegWit- en Taproot-adresformaten, voorvoegsels, compatibiliteit en veiligheidslimieten.

Twee Bitcoin-adressen kunnen beide BTC ontvangen en toch onderliggend verschillende transactiestructuren creëren. Een mainnet-adres dat begint met 1, een dat begint met 3, een bc1q -adres en een bc1p -adres kunnen allemaal geldige bestemmingen zijn, maar ze vertegenwoordigen niet noodzakelijkerwijs hetzelfde script, dezelfde codering of dezelfde toekomstige bestedingsvoorwaarde.

Dat verschil is gemakkelijk te missen omdat de wallet een adres als een enkele tekenreeks presenteert. Daaronder vertelt het adres software hoe een transactie-uitvoer moet worden geconstrueerd. Zodra die uitvoer is bevestigd, wordt het een UTXO die later moet worden besteed volgens de scriptregels die door die uitvoer zijn gecodeerd.

De praktische vraag is dus niet simpelweg “Welk voorvoegsel is nieuwer?” Het is of het adres tot het beoogde Bitcoin-netwerk behoort, welk uitvoertype het vertegenwoordigt, of de verzendsoftware dat formaat ondersteunt, en wat het adres u wel—en niet—kan vertellen voordat u een betaling autoriseert.

Wat een Bitcoin-adres vertegenwoordigt

Een Bitcoin-adres is geen account in de bankzin. Het bevat geen bitcoin, houdt geen privésleutel vast en biedt geen volledig beeld van een wallet-saldo. Het is een mensleesbare codering die een wallet helpt een specifieke transactie-uitvoer te construeren.

De vereenvoudigde relatie is:

Bitcoin-adres
        ↓
Adresdecodering
        ↓
scriptPubKey
        ↓
Transactie-uitvoer
        ↓
Bevestigde UTXO
        ↓
Toekomstige bestedingsvoorwaarde

Wanneer u bitcoin verzendt, verplaatst de wallet geen object van de ene adrestekenreeks naar de andere. Het verbruikt bestaande UTXO's als transactie-ingangen en creëert nieuwe uitvoeren. Het bestemmingsadres levert de informatie die nodig is om een van die uitvoeren te bouwen.

Dit is waarom een adresformaat technisch gezien ertoe doet. Een P2PKH-adres leidt tot een ander outputscript dan een P2WPKH-adres. Een Taproot P2TR-output is weer anders. Die outputs kunnen allemaal besteedbare bitcoin vertegenwoordigen, maar de voorwaarden en serialisatie die worden gebruikt wanneer ze worden besteed, zijn niet identiek.

Het adres is niet de privésleutel

De privésleutel blijft gescheiden van het adres. Een wallet gebruikt privésleutelmateriaal om de handtekening of witness-data te creëren die vereist is door de bestedingsvoorwaarde. Het publiceren van een ontvangstadres publiceert niet de privésleutel.

Het omgekeerde is ook belangrijk: het zien van een adres bewijst niet dat een bepaalde persoon de bijbehorende sleutel beheert. Blockchain-analyse kan transacties en outputs observeren, maar een adresstring alleen is geen identiteitsbewijs.

Waarom er verschillende formaten bestaan

Bitcoin heeft meerdere adresformaten omdat het transactiesysteem evolueerde terwijl het compatibiliteit met oudere outputs behield. Nieuwe formaten vervingen geen oude outputs op de blockchain. In plaats daarvan introduceerden ze extra manieren om bestedingsvoorwaarden uit te drukken.

De vier formaten die de meeste gebruikers op het Bitcoin-mainnet tegenkomen zijn:

• Legacy P2PKH, meestal weergegeven met een adres dat begint met 1.
• P2SH, meestal beginnend met 3; geneste SegWit is een belangrijk gebruik van P2SH, maar niet het enige.
• Native SegWit, gecodeerd met Bech32 en meestal beginnend met bc1q voor witness-versie 0.
• Taproot, gecodeerd met Bech32m en beginnend met bc1p voor witness-versie 1 P2TR-outputs.

De belangrijke verandering is niet het uiterlijk van de string. Het is wat het gedecodeerde bestemmingsadres de wallet vertelt om in de nieuwe output te plaatsen.

Bitcoin-adrestypen vergeleken

Algemene naam	Mainnet-prefix	Codering	Typische uitvoer	Wat het prefix je vertelt
Legacy	1	Base58Check	P2PKH	Versie-bytefamilie voor een mainnet public-key-hash adres
P2SH (inclusief genest SegWit)	3	Base58Check	P2SH; geneste SegWit is een mogelijke redeem-scriptconstructie	De bestemming is P2SH, niet het exacte redeem-script erin
Native SegWit	bc1q	Bech32	Witness v0, meestal P2WPKH of P2WSH	Mainnet Bech32 witness-versie-0 bestemming
Taproot	bc1p	Bech32m	P2TR	Mainnet witness-versie-1 Taproot bestemming

Deze tabel is nuttig voor identificatie, maar het voorvoegsel is geen volledige beschrijving van toekomstig bestedingsgedrag. Het duidelijkste voorbeeld is een 3... adres: het identificeert P2SH, maar P2SH kan zich vastleggen op veel redeem-scripts. Geneste SegWit is slechts één mogelijkheid.

Legacy P2PKH-adressen

Legacy pay-to-public-key-hash, of P2PKH, is het adresformaat dat het meest wordt geassocieerd met vroege Bitcoin-walletsoftware. Op mainnet beginnen deze Base58Check-adressen normaal gesproken met 1.

Het adres vertegenwoordigt een hash van een openbare sleutel. Wanneer een wallet naar die bestemming betaalt, creëert het een P2PKH-vergrendelingsscript dat een geldige handtekening en de bijbehorende openbare sleutel vereist wanneer de uitvoer wordt besteed.

OP_DUP
OP_HASH160

OP_EQUALVERIFY
OP_CHECKSIG

Het zichtbare adres is dus niet het script zelf. De wallet decodeert het Base58Check-adres, haalt de versie en payload eruit en construeert het juiste scriptPubKey.

P2PKH-outputs blijven geldige Bitcoin-outputs. “Legacy” betekent niet ongeldig of automatisch onveilig. Het onderscheid wordt relevant bij het vergelijken van transactiestructuren: het besteden van een traditionele P2PKH-output plaatst de ontgrendelingsgegevens in het inputscript in plaats van gebruik te maken van SegWit-witness-serialisatie.

Dat verschil kan het transactiegewicht verhogen in vergelijking met veelvoorkomende SegWit-sleutelbestedingen. Het betekent niet dat een P2PKH-betaling automatisch een bepaald bedrag aan kosten heeft. Aantal invoeren, aantal uitvoeren, geselecteerd kostenpercentage en de rest van de ondertekende transactie bepalen nog steeds de uiteindelijke kosten.

P2SH en geneste SegWit

Pay-to-script-hash, of P2SH, verplaatste een deel van de bestedingslogica achter een hash. Mainnet P2SH-adressen gebruiken Base58Check en beginnen normaal gesproken met 3.

Een standaard P2SH-output plaatst de redeem-script-hash in het vergrendelingsscript:

OP_HASH160
<20-byte script hash>
OP_EQUAL

Het volledige redeem-script wordt alleen geleverd wanneer de output wordt besteed. Dit creëerde een belangrijke compatibiliteitstool toen SegWit werd geïntroduceerd: een SegWit-witnessprogramma kon in een P2SH-redeem-script worden geplaatst, waardoor een afzender die gewone P2SH-adressen begreep, een output kon betalen die later zou worden besteed volgens SegWit-regels.

Een veelvoorkomende constructie met één sleutel wordt P2SH-P2WPKH genoemd:

P2SH-adres
    ↓
hash van redeemScript
    ↓
redeemScript bevat een P2WPKH-witnessprogramma
    ↓
handtekening en openbare sleutel worden via witnessdata geleverd bij besteding

Een 3-voorvoegsel bewijst geen SegWit

Dit is een van de belangrijkste beperkingen van visuele adresidentificatie. Een adres dat begint met 3 vertelt je dat de bestemming de mainnet P2SH-adresversie gebruikt. Het onthult niet het volledige redeem-script voordat de output wordt besteed.

P2SH bestond vóór SegWit en kan andere scripts omwikkelen. Het behandelen van elk 3... adres als “een SegWit-adres” is daarom te breed.

Technische grens: het voorvoegsel identificeert het externe adresformaat. Het bewijst niet het exacte script dat verborgen is achter een P2SH-hash.

Native SegWit en bc1q

Native SegWit verwijdert de P2SH-compatibiliteitswrapper en vertegenwoordigt het witnessprogramma direct. BIP 173 introduceerde Bech32-codering voor native SegWit-adressen.

Op Bitcoin-mainnet is het menselijk leesbare deel bc. Witnessversie 0 produceert adressen die algemeen herkenbaar zijn aan het begin bc1q.

Twee veelvoorkomende witness-versie-0-outputs zijn:

• P2WPKH: een 20-byte witnessprogramma dat vaak wordt gebruikt voor betalingen met één sleutel naar een wallet.
• P2WSH: een 32-byte witness-programma dat zich vastlegt op een witness-script.

Het adres zelf geeft de wallet de witness-versie en het programma. Voor witness-versie 0 hebben veelvoorkomende output-scripts deze vormen:

P2WPKH: OP_0 <20-byte key hash>
P2WSH:  OP_0 <32-byte script hash>

De output bevat direct het witness-programma in plaats van een P2SH-wrapper. Wanneer de UTXO wordt uitgegeven, wordt de handtekening of scriptgegevens die vereist zijn door het witness-programma geleverd in de transactie-witness in plaats van in een traditionele P2PKH-stijl scriptSig.

Bech32 verandert ook de foutdetectie

Bech32 is niet alleen een ander alfabet. Het bevat een checksum die is ontworpen voor deze adresfamilie en scheidt het leesbare netwerkgedeelte van de gecodeerde witness-gegevens.

Bech32-strings mogen geen hoofdletters en kleine letters mengen. Wallets tonen normaal gesproken Bitcoin-mainnet-Bech32-adressen in kleine letters. Een volledig in hoofdletters gecodeerde versie kan geldig zijn volgens de specificatie, maar gemengd hoofd- en kleinletters is ongeldig.

Taproot en bc1p

Taproot introduceerde pay-to-Taproot, of P2TR, uitvoeren. P2TR gebruikt witness-versie 1 met een 32-byte witness-programma. Op het Bitcoin-mainnet begint het resulterende adres met bc1p.

Witness-versie 1 en later gebruiken Bech32m in plaats van de oorspronkelijke Bech32-checksom. BIP 350 introduceerde deze wijziging nadat een zwakte was geïdentificeerd in het gebruik van het oorspronkelijke Bech32-checksomgedrag voor nieuwere witness-versies.

Dit geeft een praktische identificatieregel:

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

Het bijbehorende P2TR-vergrendelingsscript gebruikt witness-versie 1 en een 32-byte Taproot-uitvoersleutel:

OP_1 <32-byte Taproot output key>

Een P2TR-uitvoer verbindt zich aan die Taproot-uitvoersleutel. Het kan later worden besteed via het sleutelpad of, als een scriptboom is vastgelegd, via een geldig onthuld scriptpad.

Het adres onthult niet welk pad uiteindelijk zal worden gebruikt. Het zien van bc1p vertelt je dat de uitvoer P2TR is. Het vertelt je niet of de toekomstige besteder een sleutelpad-handtekening zal gebruiken of een scriptpad zal onthullen.

Wat Bitcoin-voorvoegsels je echt vertellen

Voorvoegsels zijn nuttig omdat ze een mens in staat stellen snel de waarschijnlijke adresfamilie en het netwerk te identificeren. Ze moeten worden behandeld als een eerste controle, niet als volledige validatie.

Voorbeeldbegin	Waarschijnlijke mainnet-betekenis	Wat het niet bewijst
1...	P2PKH-mainnetadres	Eigenaar, saldo of identiteit van de ontvanger
3...	P2SH-mainnetadres	Dat het inlosserscript genest SegWit is
bc1q...	Native witness-versie-0-adres	Of het P2WPKH of P2WSH is op basis van alleen het voorvoegsel
bc1p...	P2TR witness-versie-1-adres	Welk Taproot-bestedingspad later zal worden gebruikt

Het voorvoegsel kan ook niet de persoon authenticeren die je het adres heeft gegeven. Een perfect gecodeerd, checksum-geldig adres kan nog steeds toebehoren aan de verkeerde ontvanger.

Netwerk komt vóór adrestype

Voordat je kiest tussen Legacy, SegWit of Taproot, bevestig dat het adres behoort tot het Bitcoin-netwerk dat je van plan bent te gebruiken.

Bech32-familieadressen maken dit zichtbaar via hun leesbare deel. BIP 173 definieert bc voor Bitcoin-mainnet en tb voor Bitcoin-testnetadressen. Het leesbare deel is daarom onderdeel van netwerkvalidatie, niet decoratie.

Base58Check-adresfamilies gebruiken ook verschillende versiebytes tussen mainnet en testnetwerken, ook al is het verschil minder duidelijk voor een gebruiker die alleen naar de string kijkt.

Een wallet moet een niet-ondersteunde netwerk/adrescombinatie afwijzen, maar de uiteindelijke verantwoordelijkheid blijft om het netwerk te bevestigen dat door de verzendende applicatie wordt getoond. Adresformaat-herkenning is geen vervanging voor netwerkverificatie.

Voor de bredere transactiecontext—inputs, outputs, bevestigingen en de Bitcoin-basislaag—gebruik de Bitcoin-netwerkreferentie.

Adrestype en transactiekosten

Het is gebruikelijk om te horen dat een nieuwer Bitcoin-adres “goedkoper” is. Die uitspraak is in sommige vergelijkingen richtinggevend nuttig, maar te simpel om als kostenregel te gebruiken.

Het adres dat door een ontvanger wordt gekozen, beïnvloedt het type en de geserialiseerde grootte van de output die vandaag wordt gecreëerd. Belangrijker is dat wanneer die output later wordt besteed, het scripttype de structuur van de bijbehorende transactie-input beïnvloedt.

SegWit verandert ook de transactie-Weight-boekhouding omdat witness-bytes anders worden gewogen dan niet-witness-bytes. Een veelvoorkomende Native SegWit-sleutelbesteding heeft daarom een ander Weight-profiel dan een vergelijkbare Legacy P2PKH-besteding. Dat beïnvloedt de virtuele grootte wanneer de UTXO wordt besteed, maar het bepaalt nog steeds niet de totale kosten vooraf.

Hetzelfde BTC-bedrag kan leiden tot verschillende toekomstige kosten

Overweeg twee gebruikers die elk hetzelfde aantal bitcoin ontvangen. De ene ontvangt een P2PKH-uitvoer en de andere ontvangt een P2WPKH-uitvoer. De waarde is identiek. De toekomstige invoerstructuur is dat niet.

Wanneer die UTXOs later worden uitgegeven, wordt hun ontgrendelingsgegevens anders geserialiseerd. Dat verandert transactie Weight en daarmee de virtuele grootte. Bij hetzelfde sat/vB-tarief betekent een andere vSize een andere totale vergoeding.

Dit is een illustratief technisch scenario, geen gebruikers transactierecord of een claim over een specifieke portemonnee.

Het adrestype bepaalt nog steeds niet zelf de uiteindelijke vergoeding. Een transactie met veel efficiënte SegWit-inputs kan groter zijn dan een met een enkele Legacy-input. Het aantal outputs, handtekeningen, scriptpaden en het gekozen vergoedingstarief zijn ook van belang.

Voor de volledige relatie tussen Weight, virtuele grootte en sat/vB, lees hoe Bitcoin-transactiekosten werken. Wanneer u een transactiespecifieke schatting nodig heeft in plaats van een conceptuele vergelijking, gebruik dan de Bitcoin-transactiekostencalculator.

Compatibiliteit is een zendercontrole

Een geldig Bitcoin-adres is niet nuttig voor een betalingsworkflow als de verzendende portemonnee of opnameservice het formaat niet begrijpt.

Dit onderscheid was vooral belangrijk tijdens de adoptie van Native SegWit en later Taproot. Het Bitcoin-netwerk kon het outputtype herkennen terwijl oudere applicaties geen ondersteuning hadden voor het creëren van die bestemming.

Wanneer een service een bc1q of bc1p adres afwijst, wijzig het adres dan niet handmatig. Verwijder geen tekens, verander het voorvoegsel niet en converteer het niet via een willekeurige website. Gebruik een adresformaat dat uw ontvangende portemonnee daadwerkelijk heeft gegenereerd en dat de zender expliciet ondersteunt.

Verzenden tussen formaten is geen conversie

U heeft geen Legacy-portemonnee nodig om een Legacy-adres te betalen of een Taproot-portemonnee om een Taproot-adres te betalen in de zin van het matchen van de bron- en bestemmingsformaten. De verzendende transactie verbruikt welke ondersteunde UTXOs de portemonnee ook selecteert en creëert een nieuwe output voor het bestemmingsscript.

De relevante vraag is of de verzendende software het gevraagde bestemmingsoutput kan decoderen en construeren.

Een geldig adres kan nog steeds fout zijn

Checksums vangen bepaalde transcriptiefouten op. Ze authenticeren niet de beoogde ontvanger.

Als malware een gekopieerd adres vervangt door een ander geldig Bitcoin-adres, kan de vervanging perfect door checksumvalidatie komen. Het technische formaat is geldig; de bestemming is fout.

Dit is waarom “de portemonnee accepteerde het adres” niet de uiteindelijke veiligheidscontrole is. Acceptatie vertelt u dat de software een geldige of ondersteunde bestemming herkende. Het bewijst niet waar het adres vandaan kwam.

Verifieer voordat u verzendt

Een nuttig verificatieproces scheidt formaatvalidatie van ontvangervalidatie.

1. Bevestig het netwerk. Zorg ervoor dat de portemonnee of service Bitcoin verzendt op het beoogde Bitcoin-netwerk in plaats van een ander activum of testomgeving.
2. Lees de adresfamilie. A 1, 3, bc1q of bc1p voorvoegsel geeft u een eerste formaataanwijzing.
3. Bevestig zenderondersteuning. De opnameservice of portemonnee moet het bestemmingsformaat expliciet accepteren.
4. Verifieer de bestemming via een vertrouwd kanaal. Vergelijk het volledige adres op een vertrouwd display waar praktisch, in plaats van alleen te vertrouwen op een paar voorloop- en achterlooptekens.
5. Bekijk het uiteindelijke transactiescherm van de portemonnee. Bevestig de ontvanger, het bedrag, de netwerkvergoeding en eventueel wisselgeld voordat u ondertekent.
6. Bescherm privémateriaal. Ontvangstadresverificatie vereist nooit dat u een seedzin of privésleutel op een website invoert.

Voor grote of operationeel gevoelige overdrachten voegen organisaties vaak onafhankelijke bestemmingsverificatieprocedures toe. Die procedures zijn een operationele controle, geen eigenschap van een specifiek Bitcoin-adresformaat.

Adreshergebruik is een aparte kwestie

Een Bitcoin-adres verloopt niet op protocolniveau simpelweg omdat het een keer is gebruikt. Als de bijbehorende uitgavenvoorwaarde beheersbaar blijft, kunnen toekomstige betalingen aan hetzelfde adres nog steeds geldige outputs creëren.

Dat maakt adreshergebruik niet wenselijk. Het hergebruiken van een ontvangstadres kan transacties gemakkelijker associëren op de openbare blockchain en kan privacy verminderen.

Deze privacykwestie is apart van of het adres P2PKH, P2SH, P2WPKH of P2TR is. Een modern adresformaat maakt herhaald gebruik van dezelfde zichtbare bestemming niet privé.

De grenzen van adresvalidatie

Formaatvalidatie beantwoordt een beperkte vraag: of de string kan worden gedecodeerd als het verwachte soort Bitcoin-bestemming onder de relevante adresregels. Het authenticeert niet de persoon die het heeft verstrekt, bewijst geen eigendom van een privésleutel, bewijst niet het totale saldo van een wallet, garandeert niet dat een service het formaat ondersteunt, of bepaalt niet de uiteindelijke transactiekosten.

Het kan ook geen informatie onthullen die opzettelijk verborgen is door de outputconstructie. Een P2SH-adres onthult niet het volledige inwisselscript vóór uitgave, en een P2TR-adres vertelt u niet van tevoren of de toekomstige uitgave het sleutelpad zal gebruiken of een scriptpad zal onthullen. Behandel succesvol decoderen als één controle in het betalingsproces, niet als bewijs dat elke omringende aanname correct is.

Een ontvangstformaat kiezen

De veiligste standaard is om een adres te gebruiken dat is gegenereerd door de wallet die u daadwerkelijk beheert, in plaats van handmatig een adres te construeren of te converteren.

Als de ontvangende wallet meer dan één adrestype biedt, gebruik dan het type dat overeenkomt met het beoogde scriptbeleid van de wallet en dat de afzender kan decoderen. Een P2WPKH-adres is geschikt wanneer de wallet opzettelijk een witness-versie-0-sleutelhash-bestemming genereert. Een P2TR-adres is geschikt wanneer de wallet opzettelijk een Taproot-bestemming genereert en de afzender dit ondersteunt. Oudere P2PKH- of P2SH-bestemmingen blijven geldig wanneer een workflow deze formaten vereist.

Selecteer geen formaat uitsluitend omdat iemand beweert dat het “het goedkoopst” is. De output die u vandaag maakt, wordt pas een input wanneer deze later wordt uitgegeven, en de uiteindelijke kosten van die toekomstige transactie zijn afhankelijk van de volledige transactiestructuur en het vergoedingstarief.

Het adres moet afkomstig zijn van de ontvangende wallet. De afzender moet het ondersteunen. Het netwerk moet overeenkomen. Deze drie controles zijn belangrijker dan het najagen van een prefix op zichzelf.

Bitcoin-adres FAQ

Wat is het verschil tussen bc1q en bc1p?

bc1q is vaak het begin van een Bitcoin-mainnet-witness-versie-0-adres gecodeerd met Bech32, zoals P2WPKH of P2WSH. bc1p identificeert een mainnet-witness-versie-1 P2TR-adres gecodeerd met Bech32m.

Gebruikt elk Bitcoin-adres dat begint met 3 SegWit?

Nee. Een mainnet-adres dat begint met 3 is een P2SH-adres. Genest SegWit kan P2SH gebruiken, maar P2SH kan zich vastleggen op andere inwisselscripts, dus het prefix alleen bewijst niet dat de output genest SegWit is.

Zijn Bitcoin-adressen hoofdlettergevoelig?

Base58Check-adressen gebruiken een hoofdlettergevoelig alfabet. Bech32- en Bech32m-coderingen mogen geen hoofd- en kleine letters mengen; Bitcoin-wallets geven ze normaal gesproken in kleine letters weer. Verander niet handmatig het hoofdlettergebruik van een adres.

Kan ik Bitcoin van het ene adrestype naar het andere sturen?

Ja, wanneer de verzendende wallet het bestemmingsformaat ondersteunt. Een transactie kan één ondersteund invoertype uitgeven en een ander ondersteund uitvoertype creëren. Bron- en bestemmingsprefixen hoeven niet overeen te komen.

Verloopt een Bitcoin-adres?

Geen protocolregel zorgt ervoor dat een normaal Bitcoin-adres verloopt na een bepaalde datum of na één betaling. Wallets genereren vaak nieuwe ontvangstadressen omdat adreshergebruik de privacy kan verminderen, niet omdat eerder gegenereerde adressen automatisch ongeldig worden.

Welk Bitcoin-adrestype moet ik gebruiken?

Gebruik een adres dat is gegenereerd door de ontvangende wallet voor het Bitcoin-netwerk en scripttype dat u wilt gebruiken, en bevestig vervolgens dat de afzender dat formaat ondersteunt. Native SegWit is gebruikelijk voor moderne betalingen, terwijl Taproot geschikt is wanneer beide partijen P2TR ondersteunen. Transformeer niet handmatig het ene adresformaat naar het andere.

Technische bronnen

De bovenstaande beschrijvingen van adresformaten zijn gebaseerd op Bitcoin-verbeteringsvoorstellen en Bitcoin Core-documentatie. Deze referenties definiëren adrescoderingen, witness-programma's en scriptgedrag; ze bewijzen niet de identiteit of veiligheid van een specifiek ontvangstadres. De bredere bronbenadering van BitcoinToolkit wordt beschreven op de Gegevensbronnen page.

• BIP 13: Adresformaat voor pay-to-script-hash — specificeert het Base58Check P2SH-adresformaat.
• BIP 16: Betaal aan Script Hash — definieert het P2SH-uitgavemodel en de evaluatie van inwisselscripts.
• BIP 49: Afleidingsschema voor P2WPKH-genest-in-P2SH — documenteert de gangbare constructie met één sleutel genest-SegWit die in deze gids wordt besproken.
• BIP 141: Segregated Witness — definieert witness-programma's, transactie Weight en SegWit-outputsemantiek.
• BIP 173: Base32-adresformaat voor native v0-16 witness-outputs — introduceerde Bech32 native SegWit-adrescodering.
• BIP 350: Bech32m-formaat voor v1+ witness-adressen — definieert Bech32m en de controlesomregel voor nieuwere witness-versies.
• BIP 341: Taproot — definieert Taproot-output- en uitgifteregels, inclusief P2TR-witness-versie 1.
• Bitcoin Core-outputdescriptors — gestructureerde beschrijvingen van documenten van veelvoorkomende Bitcoin-uitvoerscripts en sleuteluitdrukkingen.

Bronnen

1. BIP 13: P2SH adresformaat
2. BIP 141: Segregated Witness
3. BIP 173: Bech32 native SegWit adressen
4. BIP 350: Bech32m
5. BIP 341: Taproot
6. Bitcoin Core uitvoerdescriptors

Een fout gevonden? Meld een inhoudsprobleem of lees onze Correctiebeleid.