Default
Door Remote - 07 Jul 2026
Dit is deel 3 in de serie technische artikelen over Bitcoin-convenanten van Cointelegraph Research. Om het vorige artikel te lezen, klik hier.
SIGHASH_ANYPREVOUT, zoals voorgesteld in BIP 118, bouwt voort op het eerdere SIGHASH_NOINPUT-concept dat werd genoemd in de Lightning Network-paper uit 2015 van Joseph Poon en Thaddeus Dryja, en later formeel werd voorgesteld door Joseph Poon op de bitcoin-dev-mailinglijst in februari 2016.
SIGHASH_ANYPREVOUT is geen nieuwe opcode, maar een voorgestelde nieuwe waarde voor de SIGHASH-vlag, ontworpen om te worden ingezet als een soft-fork-upgrade naar Bitcoin. De SIGHASH-vlag wordt aan een handtekening toegevoegd en bepaalt welke delen van een transactie worden ondertekend en worden gecontroleerd door de CHECKSIG-opcode. De geselecteerde vlag wordt gekozen door de ondertekenaar en niet afgedwongen door de scriptPubKey. Vanwege de technische details met betrekking tot de upgradebaarheid in een softfork, geldt het SIGHASH_ANYPREVOUT-voorstel alleen voor uitgaven van taproot-adressen.
Er bestaat al een verscheidenheid aan standaard SIGHASH-modi, zoals geïllustreerd in figuur 1. Als de vlag is ingesteld op SIGHASH_ALL, moet de handtekening alle inputs, alle outputs en het specifieke outpoint dat wordt uitgegeven omvatten, waardoor de autorisatie cryptografisch aan die exacte UTXO wordt gebonden. Een outpoint is de combinatie van een transactie-ID en een outputindex die samen op unieke wijze identificeren welke UTXO een transactie verbruikt. Met SIGHASH_NONE hoeven alleen de ingangen te worden ondertekend, waardoor de uitgangen onbeperkt blijven. De variant SIGHASH_SINGLE ondertekent alle invoer, maar alleen de uitvoer op dezelfde index als de invoer die wordt ondertekend. De ANYONECANPAY-modifier introduceert verdere flexibiliteit doordat een enkele invoer onafhankelijk van de andere kan worden ondertekend. Cruciaal is dat geen van deze bestaande modi toestaat dat een handtekening de betrokkenheid bij het uitpunt weglaat. Deze beperking is wat SIGHASH_ANYPREVOUT verwijdert.
BIP-118 definieert twee ANYPREVOUT-varianten die verschillen in hoeveel van de vorige uitvoer ze weglaten uit de samenvatting, samengevat in Figuur 2. Onder SIGHASH_ANYPREVOUT wordt het outpoint uitgesloten van de samenvatting, maar de handtekening houdt nog steeds rekening met de hoeveelheid en scriptPubKey van de vorige uitvoer, evenals met de nSequence van de invoer. Onder SIGHASH_ANYPREVOUTANYSCRIPT worden het bedrag en de scriptPubKey ook uitgesloten, wat betekent dat de handtekening helemaal niet gebonden is aan het vergrendelingsscript van de uitgegeven uitvoer. Alle andere verplichtingen volgen de standaard Taproot-handtekeningberichtconstructie en zijn afhankelijk van de geselecteerde basisvlag, zoals SIGHASH_ALL of SIGHASH_SINGLE.
Omdat het outpoint wordt weggelaten uit de samenvatting, kan dezelfde handtekening toestemming geven voor het uitgeven van elke compatibele UTXO die voldoet aan de resterende vastgelegde velden. Bijvoorbeeld een transactie die vooraf is ondertekend met ANYPREVOUT | ALL om een uitvoer van 0,5 BTC te produceren, kan worden hergebruikt als hetzelfde adres later nog een UTXO van 0,5 BTC ontvangt, zelfs als de privésleutel die is gebruikt om de originele handtekening te maken niet langer beschikbaar is. Als de nieuwe UTXO echter meer dan 0,5 BTC bevat, gaat het overschot verloren voor mijnwerkers, tenzij de originele handtekening een wijzigingsuitvoer bevatte. Deze rebindingseigenschap maakt ANYPREVOUT nuttig voor laag-2-protocollen, waarbij dezelfde vooraf ondertekende transactie van toepassing moet zijn op meerdere mogelijke on-chain UTXO's zonder dat voor elke transactie nieuwe handtekeningen nodig zijn.
Voor convenantachtige toepassingen behouden de ANYPREVOUT-varianten de toewijding aan de scriptPubKey van de vorige uitvoer, en zijn deze doorgaans het meest relevant. Ze maken het mogelijk dat handtekeningen worden hergebruikt in compatibele UTXO's, terwijl ervoor wordt gezorgd dat fondsen aan hetzelfde vergrendelingsscript blijven gebonden. ANYPREVOUTANYSCRIPT verwijdert deze binding volledig en is daarom minder geschikt voor toepassingen in convenantstijl.
Net als OP_CTV verbetert SIGHASH_ANYPREVOUT de logica die al haalbaar is met vooraf ondertekende transacties, maar maakt op zichzelf geen recursieve convenanten of transactie-introspectie mogelijk. In plaats daarvan versoepelt het de binding tussen een handtekening en een specifieke UTXO, waardoor een handtekening kan worden hergebruikt in meerdere compatibele UTXO's.
Uit enig onderzoek is ook gebleken dat het verwijderen van de outpoint-verplichting constructies van herstelde sleutels mogelijk maakt - dat wil zeggen dat een publieke sleutel kan worden afgeleid van een vast paar van handtekening en bericht, zodat de corresponderende privésleutel voor iedereen aantoonbaar onbekend is, waardoor het sleutelpad van de UTXO aantoonbaar onbruikbaar wordt en elke uitgave via het scriptpad wordt gedwongen. Het zou de behoefte aan tijdelijke sleutels vermijden, die anders nodig zijn om het sleutelpad onbruikbaar te maken in constructies die afhankelijk zijn van het afdwingen van alleen scriptpaden. Deze observatie komt voor in Bitcoin Covenants: Three Ways to Control the Future van Jacob Swambo et al. (2020), hoewel het eerder een theoretische constructie blijft dan een ontwerp voorgesteld in BIP-118.
Het belangrijkste risico dat gepaard gaat met SIGHASH_ANYPREVOUT-handtekeningen is het opnieuw afspelen van handtekeningen. Omdat deze handtekeningen zich niet verbinden aan een specifiek outpoint, kan dezelfde handtekening worden gebruikt om een andere UTXO uit te geven dan oorspronkelijk bedoeld, op voorwaarde dat de nieuwe UTXO voldoet aan de overige vastgelegde velden. Dit risico wordt groter in specifieke configuraties: wanneer ANYPREVOUT | SINGLE wordt gebruikt en de uitvoerhoeveelheden kunnen opnieuw worden gerangschikt; wanneer er een afzonderlijke UTXO bestaat met dezelfde scriptPubKey en hetzelfde bedrag, in het geval van ANYPREVOUT; wanneer dezelfde publieke sleutel voorkomt in een compatibel script, in het geval van ANYPREVOUTANYSCRIPT; of wanneer een mijnwerker de bestelling en opname van transacties kan beïnvloeden om van deze voorwaarden gebruik te maken. Deze scenario's vereisen echter opzettelijk misbruik of het onvermogen van de gebruiker of ontwikkelaar om tijdens het protocolontwerp rekening te houden met de omstandigheden voor opnieuw afspelen.
In ons volgende artikel zullen we beginnen met onze bespreking van Opcodes die dienen als ondersteunende hulpmiddelen. Deze breiden de expressiviteit van het Bitcoin-script of de gegevensverwerking uit, maar implementeren geen convenantfunctionaliteit tenzij gecombineerd met andere opcodes. In deze volgende categorie bespreken we OP_CHECKSIGFROMSTACK en OP_CAT.
SIGHASH_ANYPREVOUT, zoals voorgesteld in BIP 118, bouwt voort op het eerdere SIGHASH_NOINPUT-concept dat werd genoemd in de Lightning Network-paper uit 2015 van Joseph Poon en Thaddeus Dryja, en later formeel werd voorgesteld door Joseph Poon op de bitcoin-dev-mailinglijst in februari 2016.
SIGHASH_ANYPREVOUT is geen nieuwe opcode, maar een voorgestelde nieuwe waarde voor de SIGHASH-vlag, ontworpen om te worden ingezet als een soft-fork-upgrade naar Bitcoin. De SIGHASH-vlag wordt aan een handtekening toegevoegd en bepaalt welke delen van een transactie worden ondertekend en worden gecontroleerd door de CHECKSIG-opcode. De geselecteerde vlag wordt gekozen door de ondertekenaar en niet afgedwongen door de scriptPubKey. Vanwege de technische details met betrekking tot de upgradebaarheid in een softfork, geldt het SIGHASH_ANYPREVOUT-voorstel alleen voor uitgaven van taproot-adressen.
Er bestaat al een verscheidenheid aan standaard SIGHASH-modi, zoals geïllustreerd in figuur 1. Als de vlag is ingesteld op SIGHASH_ALL, moet de handtekening alle inputs, alle outputs en het specifieke outpoint dat wordt uitgegeven omvatten, waardoor de autorisatie cryptografisch aan die exacte UTXO wordt gebonden. Een outpoint is de combinatie van een transactie-ID en een outputindex die samen op unieke wijze identificeren welke UTXO een transactie verbruikt. Met SIGHASH_NONE hoeven alleen de ingangen te worden ondertekend, waardoor de uitgangen onbeperkt blijven. De variant SIGHASH_SINGLE ondertekent alle invoer, maar alleen de uitvoer op dezelfde index als de invoer die wordt ondertekend. De ANYONECANPAY-modifier introduceert verdere flexibiliteit doordat een enkele invoer onafhankelijk van de andere kan worden ondertekend. Cruciaal is dat geen van deze bestaande modi toestaat dat een handtekening de betrokkenheid bij het uitpunt weglaat. Deze beperking is wat SIGHASH_ANYPREVOUT verwijdert.
BIP-118 definieert twee ANYPREVOUT-varianten die verschillen in hoeveel van de vorige uitvoer ze weglaten uit de samenvatting, samengevat in Figuur 2. Onder SIGHASH_ANYPREVOUT wordt het outpoint uitgesloten van de samenvatting, maar de handtekening houdt nog steeds rekening met de hoeveelheid en scriptPubKey van de vorige uitvoer, evenals met de nSequence van de invoer. Onder SIGHASH_ANYPREVOUTANYSCRIPT worden het bedrag en de scriptPubKey ook uitgesloten, wat betekent dat de handtekening helemaal niet gebonden is aan het vergrendelingsscript van de uitgegeven uitvoer. Alle andere verplichtingen volgen de standaard Taproot-handtekeningberichtconstructie en zijn afhankelijk van de geselecteerde basisvlag, zoals SIGHASH_ALL of SIGHASH_SINGLE.
Omdat het outpoint wordt weggelaten uit de samenvatting, kan dezelfde handtekening toestemming geven voor het uitgeven van elke compatibele UTXO die voldoet aan de resterende vastgelegde velden. Bijvoorbeeld een transactie die vooraf is ondertekend met ANYPREVOUT | ALL om een uitvoer van 0,5 BTC te produceren, kan worden hergebruikt als hetzelfde adres later nog een UTXO van 0,5 BTC ontvangt, zelfs als de privésleutel die is gebruikt om de originele handtekening te maken niet langer beschikbaar is. Als de nieuwe UTXO echter meer dan 0,5 BTC bevat, gaat het overschot verloren voor mijnwerkers, tenzij de originele handtekening een wijzigingsuitvoer bevatte. Deze rebindingseigenschap maakt ANYPREVOUT nuttig voor laag-2-protocollen, waarbij dezelfde vooraf ondertekende transactie van toepassing moet zijn op meerdere mogelijke on-chain UTXO's zonder dat voor elke transactie nieuwe handtekeningen nodig zijn.
Voor convenantachtige toepassingen behouden de ANYPREVOUT-varianten de toewijding aan de scriptPubKey van de vorige uitvoer, en zijn deze doorgaans het meest relevant. Ze maken het mogelijk dat handtekeningen worden hergebruikt in compatibele UTXO's, terwijl ervoor wordt gezorgd dat fondsen aan hetzelfde vergrendelingsscript blijven gebonden. ANYPREVOUTANYSCRIPT verwijdert deze binding volledig en is daarom minder geschikt voor toepassingen in convenantstijl.
Net als OP_CTV verbetert SIGHASH_ANYPREVOUT de logica die al haalbaar is met vooraf ondertekende transacties, maar maakt op zichzelf geen recursieve convenanten of transactie-introspectie mogelijk. In plaats daarvan versoepelt het de binding tussen een handtekening en een specifieke UTXO, waardoor een handtekening kan worden hergebruikt in meerdere compatibele UTXO's.
Uit enig onderzoek is ook gebleken dat het verwijderen van de outpoint-verplichting constructies van herstelde sleutels mogelijk maakt - dat wil zeggen dat een publieke sleutel kan worden afgeleid van een vast paar van handtekening en bericht, zodat de corresponderende privésleutel voor iedereen aantoonbaar onbekend is, waardoor het sleutelpad van de UTXO aantoonbaar onbruikbaar wordt en elke uitgave via het scriptpad wordt gedwongen. Het zou de behoefte aan tijdelijke sleutels vermijden, die anders nodig zijn om het sleutelpad onbruikbaar te maken in constructies die afhankelijk zijn van het afdwingen van alleen scriptpaden. Deze observatie komt voor in Bitcoin Covenants: Three Ways to Control the Future van Jacob Swambo et al. (2020), hoewel het eerder een theoretische constructie blijft dan een ontwerp voorgesteld in BIP-118.
Het belangrijkste risico dat gepaard gaat met SIGHASH_ANYPREVOUT-handtekeningen is het opnieuw afspelen van handtekeningen. Omdat deze handtekeningen zich niet verbinden aan een specifiek outpoint, kan dezelfde handtekening worden gebruikt om een andere UTXO uit te geven dan oorspronkelijk bedoeld, op voorwaarde dat de nieuwe UTXO voldoet aan de overige vastgelegde velden. Dit risico wordt groter in specifieke configuraties: wanneer ANYPREVOUT | SINGLE wordt gebruikt en de uitvoerhoeveelheden kunnen opnieuw worden gerangschikt; wanneer er een afzonderlijke UTXO bestaat met dezelfde scriptPubKey en hetzelfde bedrag, in het geval van ANYPREVOUT; wanneer dezelfde publieke sleutel voorkomt in een compatibel script, in het geval van ANYPREVOUTANYSCRIPT; of wanneer een mijnwerker de bestelling en opname van transacties kan beïnvloeden om van deze voorwaarden gebruik te maken. Deze scenario's vereisen echter opzettelijk misbruik of het onvermogen van de gebruiker of ontwikkelaar om tijdens het protocolontwerp rekening te houden met de omstandigheden voor opnieuw afspelen.
In ons volgende artikel zullen we beginnen met onze bespreking van Opcodes die dienen als ondersteunende hulpmiddelen. Deze breiden de expressiviteit van het Bitcoin-script of de gegevensverwerking uit, maar implementeren geen convenantfunctionaliteit tenzij gecombineerd met andere opcodes. In deze volgende categorie bespreken we OP_CHECKSIGFROMSTACK en OP_CAT.