Den bedste trin-for-trin Bitcoin Script Guide del 2

Dette er del 2 af vores bedste Bitcoin Script Guide. Det anbefales stærkt, at du læser del 1, før du fortsætter med dette.

Den bedste Bitcoin Script Guide del 2

I del 1 dækkede vi følgende:

  • Introduktion til bitcoin Script.
  • Hvordan fungerer transaktioner i Bitcoin?
  • Sådan fungerer scripts?
  • Spillet med at låse og låse op i scripts.
  • ECDSA-kryptografi i bitcoin-script.

BEMÆRK: Herfra og ud bruger vi ikke kommandoen “OP_” så ofte, fordi det skal forstås, at “OP_” altid vil være forud for hver opkode. Husk dette. Vi brugte ikke “OP_” til at forbedre læsbarheden. Når du udfører scriptet, skal du huske at bruge “OP_”.

Multisignaturtransaktioner

De transaktioner, vi hidtil har set, er alle meget enkle (en-til-en i sin natur). Transaktioner kan dog blive meget mere komplicerede og lagdelte end det.

Først vil vi tjekke transaktioner med flere signaturer. I en transaktion med flere signaturer er den eneste måde, bitcoin-output kan låses op, hvis flere personer bekræfter transaktionen.

Så hvor er dette nyttigt?

Forestil dig, at der er et stort multinationalt selskab. Det er klart, at de ikke vil lade en enkelt person kontrollere alle dets midler, ikke? De vil have en bestyrelse af mennesker, der har ansvaret for midlerne.

Hvordan fungerer det nu i forbindelse med bitcoin-script-transaktioner?

Multisignatur-scripts indstiller en betingelse, hvor N offentlige nøgler er optaget i scriptet, og mindst M af disse skal give underskrifter for at låse op for midlerne. Dette er også kendt som et M-of-N-skema, hvor N er det samlede antal nøgler, og M er det mindste antal signaturer, der kræves til validering. Transaktionen kaldes også M-of-N multisig.

Scriptformatet for en multisig-output ser sådan ud:

M… N CHECKMULTISIG

Lad os se, hvordan dette fungerer i et eksempel.

Antag, at vi sender penge til et selskab ledet af 3 personer (Alice, Bob og Charlie), og to ud af disse tre personer er nødt til at kontrollere transaktionen, før den kan gennemføres. Denne transaktion kaldes også en 2-af-3 multisig.

Hvordan vil output se ud?

2 3 CHECKMULTISIG

Okay, så dette er output. Hvordan vil virksomheden låse op for output og få adgang til midlerne? Husk at dette er en 2-af-3 multisig-betydning, 2 ud af de 3 involverede personer skal præsentere deres underskrifter.

Så den anvendte signaturkombination kan være en af ​​følgende:

Antag, at Bob og Charlie er dem, der bekræfter transaktionen. Det komplette valideringsscript vil så læse sådan:

2 3 CHECKMULTISIG

HVIS betingelserne ovenfor gælder, og underskrifterne er korrekte, så er transaktion vil være SAND, og ​​det vil gå igennem. Men hvis underskrifterne er forkerte, mislykkes transaktionen.

Men hvis du tjekker eksempler på en multi-sig-transaktion, vil du bemærke, at det format, vi har brugt:

2 3 CHECKMULTISIG

… Er forkert.

Årsagen til, at det er sådan, er, at der er en fejl i CHECKMULTISIG-opkoden.

Fejlen i CHECKMULTISIG opcode

Ideelt set skulle en CHECKMULTISIG opcode sprænge M + N + 2-elementer ud fra stakken. Lad os tage eksemplet, som vi hidtil har arbejdet med:

2 3 CHECKMULTISIG

Før CHECKMULTISIG bliver udført, vil stakken se sådan ud:

Den bedste Bitcoin Script Guide del 2

CHECKMULTISIG springer i bund og grund alle elementerne i stakken ud.

I dette eksempel er M = 3 og N = 2.

Varerne, som CHECKMULTISIG dukker op, er: De 3 (M) offentlige nøgler, 2 (N) signaturer og to konstanter, hvilket grundlæggende betyder, at den samlede mængde af emner, der ideelt set skal poppes ud, er (M + N + 2 =) 3 + 2 + 2 = 7 varer.

Der er dog en fejl i CHECKMULTISIG-opkoden, der får den til at poppe et mere element, end der er tilgængeligt i stakken. Dette ender naturligvis med at forårsage en stakfejl.

For at undgå denne fejl bruges en løsning til at imødegå den. Hver gang vi har et kombineret valideringsscript, begynder vi altid med et “0”. Dette betyder, at scriptet nu vil se ud:

0 2 3 CHECKMULTISIG

Efterfølgende ser vores stak nu sådan ud:

Den bedste Bitcoin Script Guide del 2

Ved at tilføje det ene ekstra element “0” i starten sørger vi for, at vi ikke møder nogen fejl.

Dette betyder også, at i stedet for at bruge dette oplåsningsscript:

Vi ender med at bruge dette:

0

Hvad er Pay-to-Script-Hash eller P2SH?

Mens multisignatur-transaktioner giver dine transaktioner stor fleksibilitet, kan de blive lidt komplicerede. Forestil dig et firma, der har 5 partnere involveret i operationen. Hvis Alice skulle sende nogle bitcoins til dette firma, vil hendes output-script se sådan ud (forudsat at 2 ud af de 5 involverede har brug for at kontrollere transaktionen):

2 5 CHECKMULTISIG

Som du kan se, bliver dette meget besværligt og har en hel række ulemper:

  • For det første skal virksomheden faktisk videresende disse oplysninger og script til deres kunder.

  • Kunderne skal derefter bruge en speciel bitcoin-pungesoftware med evnen til at oprette brugerdefineret transaktionsscript.

  • Den resulterende transaktion ville være fem gange større end en normal transaktion og ville have brug for flere gebyrer.

En løsning var nødvendig for at gøre dette bitcoin-script lidt mindre kompliceret. Det blev besluttet, at det komplekse multisig-script ville blive hashet, og folk vil inkludere hash i stedet for scriptet i låsescriptet.

For at låse op og indløse transaktionen skal modtageren præsentere det originale script sammen med underskrifterne. Da afsenderen sender penge til en hash i stedet for en offentlig adresse, kaldes denne type transaktion Pay to Public Script Hash eller P2SH.

Så hvordan ændrede P2SH transaktionerne (for eksemplet ovenfor)?

Før P2SH

Låseskript: 2 5 CHECKMULTISIG

Oplåsning af script:

Efter P2SH

Indløs script: 2 5 CHECKMULTISIG

Låseskript: HASH160 LIGE

Oplåsning af script:

Som det kan ses, overføres ansvaret for at levere betingelserne for at indløse en transaktion fra afsenderen til forløseren, der præsenterer indløsningsskriptet.

Så hvordan ville vores virksomheds script se ud, hvis P2SH ikke blev brugt? Sans P2SH bitcoin-scriptet, som de ville have brugt, ville være dette:

2 5 CHECKMULTISIG

Hvilket ville oversætte til noget som dette:

2 04C16B8698A9ABF84250A7C3EA7EEDEF9897D1C8C6ADF47F06CF73370D74DCCA01CDCA79DCC5C395D7EEC6984D83F1F50C900A24DD47F569FD4193AF5DE762C58704A2192968D8655D6A935BEAF2CA23E3FB87A3495E7AF308EDF08DAC3C1FCBFC2C75B4B0F4D0B1B70CD2423657738C0C2B1D5CE65C97D78D0E34224858008E8B49047E63248B75DB7379BE9CDA8CE5751D16485F431E46117B9D0C1837C9D5737812F393DA7D4420D7E1A9162F0279CFC10F1E8E8F3020DECDBC3C0DD389D99779650421D65CBD7149B255382ED7F78E946580657EE6FDA162A187543A9D85BAAA93A4AB3A8F044DADA618D087227440645ABE8A35DA8C5B73997AD343BE5C2AFD94A5043752580AFA1ECED3C68D446BCAB69AC0BA7DF50D56231BE0AABF1FDEEC78A6A45E394BA29A1EDF518C022DD618DA774D207D137AAB59E0B000EB7ED238F4D800 5 CHECKMULTISIG

Nej, nogen slog ikke disse tal og bogstaver ud, sådan ville de 5 offentlige nøgler tilsammen se ud!

Forestil dig, at kunder sender det bitcoin-script for at sende deres bitcoin UTXO’er.

Nu, hvis den samme hexadecimale blok blev analyseret gennem SHA 256 efterfulgt af RIPEMD160, ville det se sådan ud:

54c557e07dde5bb6cb791c7a540e0a4796f5e97e

Så meget pænere og håndterbar, ikke?

P2SH-versionen af ​​låsescriptet ser nu sådan ud:

HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e LIGE

For at låse op ville oplåsningsscriptet nu se ud:

: <2 Offentlig nøgle 1 Offentlig nøgle 2 Offentlig nøgle 3 Offentlig nøgle 4 Offentlig nøgle 5 5 MULTISIG>

Kombinationen af ​​disse to bitcoin-scripts finder sted i to faser.

For det første matches indløsningsskriptet op mod hash for at se, om det stemmer overens:

<2 Offentlig nøgle 1 Offentlig nøgle 2 Offentlig nøgle 3 Offentlig nøgle 4 Offentlig nøgle 5 5 MULTISIG> HASH160 LIGE.

Hvis dette bitcoin-script returnerer SAND, finder den anden del af oplåsning sted via dette stykke kode, der finder sted automatisk. Denne er vores traditionelle multisig-oplåsning:

 2 Offentlig nøgle 1 Offentlig nøgle 2 Offentlig nøgle 3 Offentlig nøgle 4 Offentlig nøgle 5 5 CHECKMULTISIG

P2SH-adresser starter altid med en 3 i stedet for 1.

3KP3okFKoGs53JqgyGB27pqaum8tCz2BvW <- En P2sh-adresse.

Hvad er flowkontrol?

Et af de mest interessante aspekter ved programmering er Flow Control. Ved at bruge visse betingelser kan man registrere, hvilke kommandoer der udføres, og hvornår. Enhver, der har en eller anden programmeringsbase, er bekendt med konceptet IF-ELSE-programmering.

Dette er den enkleste og mest basale form for flowkontrol.

I bitcoin-script bruges følgende til statskontrol:

  • HVIS
  • ELSEIF
  • AFSLUT HVIS
  • NOTIF

I et normalt program ser IF-ELSE-tilstand sådan ud:

Hvis (betingelse)

{

ERKLÆRING A

}

andet

{

UDTALELSE B

}

ERKLÆRING C

Så hvad sker der her?

  • Hvis betingelsen er sand, skal du udføre ERKLÆRING A.
  • Ellers udfør ERKLÆRING B.
  • Derefter bliver STATEMENT C udført uanset hvilken tilstand man bruger.

Men i bitcoin-script har det et andet udseende. Husk, at hovedfunktionen i bitcoin script er, at det er et stakbaseret sprog. Derfor kommer betingelsen i dette tilfælde FØR IF-udsagnet.

Så det ser sådan ud:

TILSTAND

HVIS

ERKLÆRING A

ANDET

UDTALELSE B

AFSLUT HVIS

ERKLÆRING C

Hvordan vil udførelsen af ​​denne blok af script se ud?

Trin 1: Tilstand sprænges på stakken:

Trin 2: IF-opoden springer ud af betingelsen og kontrollerer, om den er SAND eller ej.

Trin 3: HVIS sandt, ERKLÆRING A bliver udført, og bitcoin-scriptet springer ELSE-udsagnet over for at hoppe til ENDIF og skubbe UDTALELSE C på stakken.

Trin 4: Hvis IF-opkoden returnerer FALSE, bliver ELSE-blokken udført, og UDTALELSE B bliver skubbet på stakken.

Trin 5: Når STATEMENT B bliver skubbet på stakken, bliver ENDIF-tilstanden aktiveret, og STATEMENT C fortsætter med at blive skubbet på stakken.

Sidenote:

Som vi har set før, kunne flowregulering oprettes ved at tilføje VERIFY-erklæringen til visse betingelser.

2 4 EQUALVERIFY 3

I dette tilfælde, da 2 ikke er lig med 4, stopper scriptet med at køre der og da uden engang at gå til 3.

Brug af flowkontrol i Bitcoin Script

En af de mest almindelige applikationer af Flow Control er at oprette indløsningsskripter, der har flere stier til udførelse.

Vi har allerede set eksempler på eksekveringer på flere niveauer med multisignaturer. Lad os nu se, hvordan de samme multisig-transaktioner kan skrives via Flow Control-udsagn.

Antag, at vi vil udføre en 1-af-2 Multisig. De 2 personer, der er involveret i multisig er Alice og Bob, og kun af disse to har brug for at kontrollere transaktionen for at den kan gennemføres.

Så for denne multisig, hvordan bliver låseskriptet designet ved hjælp af flowkontroller?

Låsning af Bitcoin Script

HVIS

CHECKSIG

ANDET

CHECKSIG

AFSLUT HVIS

Som du kan se, er det en simpel ligefrem if-else-løkke. Der er dog noget galt her.

Hvad tror du mangler?

Det er korrekt … tilstanden!

Selve tilstanden mangler … så er det en fejl? Tænk virkelig på dette lige nu … hvorfor satte vi ikke betingelsen i låsescriptet?

At have en betingelse vil låse IF-ELSE-scriptet op og lade dig få adgang til udsagnene, UDEN at give en verifikation. Husk, at IF-ELSE-scriptet kun kan låses op, hvis visse betingelser er opfyldt.

Dette er grunden til, at vi i låseskriptet leverer IF-ELSE-koden uden betingelsen.

Låsning af Bitcoin Script

I oplåsningsscriptet giver Bob eller Alice deres underskrift og de betingelser, der kræves for at låse scriptet op.

Ifølge scriptet låses Alice op, hvis betingelsen er SAND, og ​​Bobs kode låses op, hvis betingelsen er FALSK. Vi bruger “1” til at betegne SAND og “0” til at betegne FALSK.

Så med al denne info i tankerne ville Alice’s oplåsningsscript være:

1

Bobs oplåsningsscript er:

0

Scriptudførelse

Antag, at Bob ønsker at låse UTXO op, sådan ser det kombinerede valideringsscript ud (vi skal bruge i dette eksempel i stedet for hele IF-ELSE-koden for at forbedre forståelsen):

0

Trin 1: Bobs signatur bliver skubbet på stakken.

Den bedste Bitcoin Script Guide del 2

Trin 3: Nu begynder den sjove del.

Det er tid til at blive henrettet, hvilket tilfældigvis ser sådan ud:

HVIS

CHECKSIG

ANDET

CHECKSIG

AFSLUT HVIS

For det første springer IF-tilstanden “0” ud af stakken.

Den bedste Bitcoin Script Guide del 2

Trin 5: CHECKSIG bliver udført, hvilken pop der er både signaturen og den offentlige nøgle fra stakken og kører CHECKSIG-operationen på dem.

Okay, så dette var en simpel 1-af-2 multisig.

Lad os dog ante lidt mere op og se, hvad der sker, når vi øger flowkontrollen i et script.

HVIS

ERKLÆRING A

ANDET

HVIS

UDTALELSE B

ANDET

ERKLÆRING C

AFSLUT HVIS

AFSLUT HVIS

Okay, så vi har tre udsagn, som vi vil udføre. For at udføre en bestemt erklæring er vi nødt til at indtaste visse betingelser for at nå dem.

Hvilke betingelser skal indtastes for at udføre STATEMENT B? Betingelserne vil være: 1, 0 ELLER {SAND, FALSK}.

Men vent, erklæring B, kommer efter en ELSE og en, hvis ikke? Så bør betingelsessekvensen ikke være 0,1 ELLER {FALSK, SAND}?

Nå … husk at Script er et stak-baseret programmeringssprog. Så et input på {TRUE, FALSE} ser sådan ud på stakken:

Den bedste Bitcoin Script Guide del 2

Så hvad er den første ting, der bliver poppet ud?

FALSK ret?

Denne FALSE-betingelse får scriptet til at springe IF over og hoppe lige til ELSE.

Derfor skal vi huske, hvordan en stak fungerer, når vi har brug for det.

Hvad er Timelock?

En timelock er en primitiv smart kontrakt, der opkræver tidsbaserede begrænsninger for Bitcoin-udgifter. De tre timelocks, der bruges i bitcoin:

  • Transaktionslåsetid (nLocktime).
  • CHECKLOCKTIMEVERIFY eller CLTV.
  • CHECKSEQUENCEVERIFY eller CSV

nLåsetid

“NLocktime” er grundlæggende den parameter, der definerer det tidspunkt, inden hvilket transaktionen ikke kunne accepteres i blokken. Hvert transaktionssæt inkluderer nLocktime. Der er tre mulige ruter, som nLocktime kan tage:

  • Hvis nLocktime er indstillet til 0, formeres transaktionen straks.

  • Hvis 0

  • Hvis nLocktime> 500 millioner, så fortolkes det som et Unix Epoch-tidsstempel, og transaktionen er ikke gyldig, før den angivne tid er gået.

Mens nLocktime ser godt ud på papir, er der en meget skarp svaghed.

Antag, at Alice vil sende Bob noget BTC med en låsetid på 1 uge. Der er en mulighed for, at Alice kan bruge de samme UTXO’er til at oprette en anden transaktion, før den 1 uge er gået med 0 låsetid.

Så modtageren er helt afhængig af afsenderens etik.

CLTV

Problemet med nLocktime var, at tidslåsen blev anvendt på transaktionen, som gjorde den sårbar over for ondsindede brugere. Så CLTV eller CHECKLOCKTIMEVERIFY gjorde låsning gældende på individuelle udgange. Så for at sige det enkelt, CLTV gjorde de enkelte output fra en transaktion ansvarlig for tidslåsning.

CLTV er implementeret i en primitiv off-chain betalingskanal, der giver modstand mod mulig smidighed. CLTV-stil betalingskanaler blev implementeret efter BIP 65. Lad os se, hvordan det fungerer:

  • Alice (købmanden) giver sin offentlige nøgle til Bob (kunden).

  • Bob bruger sin offentlige nøgle og Alice til at oprette en P2SH-adresse under følgende betingelser: Betingelse 1: Både Alice og Bob underskriver enhver transaktion, der sker gennem denne adresse. Betingelse 2: Kun Bob kan underskrive en transaktion alene, men den transaktion skal have en låsetid, der er større end depositummet.

  • Bob opretter straks en indbetalingstransaktion og sender den på blockchain. På grund af tilstand 2 ovenfor er han forsikret om, at han stort set kan generere en refusion efter anmodning.

  • Husk nu, den første betingelse siger, at Alice og Bob begge skal underskrive enhver transaktion, der sker i P2SH-adressen. Så Bob (kunden) kan underskrive sin del af transaktionen, og Alice kan underskrive hendes del uden at afsløre sine underskriftsoplysninger for Bob. Ved at gøre dette kan Alice sende den endelige betaling til blockchain, inden refusionen kan sendes.

CSV

Før vi forstår, hvordan CHECKSEQUENCEVERIFY eller CSV fungerer, skal du kende forskellen mellem absolut timelock og relativ timelock.

Mens nLocktime og CLTV er absolutte tidslåse, hvilket betyder, at de specifikt nævner et absolut tidspunkt, angiver relative tidslåse en forløbet tid fra bekræftelsen af ​​output i blockchain.

CSV eller CHECKSEQUENCEVERIFY er en relativ tidslås. CSV-opkoden specificerer en “nSequence” -variabel.

Når CSV kaldes, stopper scriptet fra at blive udført, medmindre nSequence indikerer, at en lige eller større mængde relativ låsetid er passeret end den, der er nævnt i CSV-opkoden.

Okay, så lad os have det sjovt nu. Lad os bruge et script ved hjælp af flowkontrol og CSV!

Forestil dig, at vi har et firma, der ejes af 3 personer: B, C og D. Virksomheden kører på en 2-af-3 Multisig-betydning, firmaets midler kan kun bruges, hvis mindst 2 ud af de 3 personer præsenterer deres nøgler.

I tilfælde af at folk ender med at miste deres nøgler, er de nødt til at lave en fail-safe for at sikre, at midlerne stadig kan aktiveres af 2-of-3 Multisig. I dette tilfælde laver de en backupnøgle og giver til deres advokat A.

Så hvordan vil det se ud i scriptet?

HVIS

HVIS

2

ANDET

<30 dage> CHECKSEQUENCEVERIFY DROP <A’s Pubkey> KONTROLLER

1

AFSLUT HVIS

<B’s Pubkey> 3 CHECKMULTISIG

ANDET

<90 dage> CHECKSEQUENCEVERIFY DROP <A’s Pubkey> CHECKSIG

AFSLUT HVIS

Som du kan se, er der tre måder, som strømmen kan gå på:

  • Hvis alt er godt og godt, fungerer det som en simpel 2-af-3 multisig.
  • Hvis en af ​​ejerne mister deres nøgle og ikke kan producere den på 30 dage, er betingelserne, der kræves for at få adgang til midlerne, advokatens nøgle OG en 1-af-3 multisig med de 3 ejere.
  • Hvis alle 3 ejere mister deres nøgler, får advokaten adgang til midlerne efter 90 dage.

Betingelse nr. 1: Alt er godt

Hvis alt er godt, og ingen har mistet nogen nøgler, vil 2 af de 3 ejere kontrollere transaktionerne med deres underskrifter som i enhver normal multisig.

Oplåsning af script: 0

Bemærk: Glem ikke, at alle multisig-transaktioner begynder med et “0” til løsning af CHECKMULTISIG-bug.

Komplet validerings script: 0

Så hvordan ser udførelsen ud?

Trin # 1: Unlocking-scriptet skubbes videre til stakken trin for trin

Den bedste Bitcoin Script Guide del 2

Ser det velkendt ud?

Yup … det er 2-af-3 multisig, og bitcoin-scriptet udføres normalt.

Betingelse nr. 2: En person mister sine nøgler

I dette tilfælde kommer advokaten A ind i billedet.

Oplåsning af script: 0

Komplet validerings script: 0

Så hvordan ser udførelsen ud?

Trin # 1: Oplåsningsscriptet skubbes videre til stakken.

Den bedste Bitcoin Script Guide del 2

Trin # 3: De kommende sekvenser er:

<30 dage> CHECKSEQUENCEVERIFY DROP CHECKSIGVERIFY

Det “<30 dage> CHECKSEQUENCEVERIFY DROP ”aktiverer grundlæggende en tidslås på 30 dage. Hvis ejeren, der har mistet deres nøgle, ikke kan hente den inden for tidslåsen, flyttes scriptet til det næste element i stakken.

Men hvis de kan hente nøglen og vise bevis, stopper scriptet straks med at udføre (da VERIFY-koden er tilføjet).

Bemærk: Så hvad er DROP? Antag, at den nødvendige parameter for at tilfredsstille CHECKSEQUENCEVERIFY er indsendt, den tidsparameter, der gik forud for den, dvs.<30 dage>”Er stadig på stakken. DROP-funktionen popper det sidste element på stakken, der tilfældigvis er, i dette tilfælde, <30 dage>.

Den bedste Bitcoin Script Guide del 2

Nu bliver dette en 1-af-3 multisig. Hvis B’s signatur tjekker ud, udføres scriptet korrekt.

Betingelse nr. 3: Alle tre ejere placerer deres nøgler forkert

I dette tilfælde udfører scriptet ikke engang den første IF, det springer direkte til ELSE-erklæringen.

Oplåsning af script:

Komplet validerings script:

Så hvordan ser udførelsen ud?

Trin # 1: Oplåsningsscriptet skubbes på stakken.

Den bedste Bitcoin Script Guide del 2

Konklusion

Målet med denne guide var at få dig til at forstå logikken bag forskellige bitcoin Script transaktionsscenarier. Det er spændende at se mekanismen bag disse transaktioner, for at sige det mildt. Hvis du ikke har læst del 1 af Bitcoin Script Guide, skal du kontrollere det!

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me