Labākais soli pa solim Bitcoin Script Guide 2. daļa

Šī ir mūsu labākā Bitcoin skripta rokasgrāmatas 2. daļa. Pirms turpināt darbu, ir ļoti ieteicams izlasīt 1. daļu.

Labākais Bitcoin Script Guide 2. daļa

1. daļā mēs apskatījām sekojošo:

  • Ievads bitcoin skriptā.
  • Kā darbojas darījumi ar Bitcoin?
  • Kā darbojas skripti?
  • Skriptu bloķēšanas un atbloķēšanas spēle.
  • ECDSA kriptogrāfija Bitcoin skriptā.

PIEZĪME. Turpmāk komandu “OP_” neizmantosim tik bieži, jo ir jāsaprot, ka “OP_” vienmēr tiks pievienota prefiksam katram opkodam. Lūdzu, paturiet to prātā. Mēs neizmantojām “OP_”, lai uzlabotu lasāmību. Kad izpildāt skriptu, lūdzu, atcerieties izmantot “OP_”.

Daudzparakstu darījumi

Darījumi, kurus mēs esam redzējuši līdz šim, visi ir ļoti vienkārši (viens pret vienu pēc būtības). Tomēr darījumi var kļūt daudz sarežģītāki un daudzslāņu.

Vispirms mēs pārbaudīsim vairāku parakstu darījumus. Vairāku parakstu darījumā vienīgais veids, kā var atbloķēt bitcoin izvadus, ir tas, ja darījumu pārbauda vairāki cilvēki.

Tātad, kur tas ir noderīgi?

Iedomājieties, ka ir milzīgs daudznacionāls uzņēmums. Acīmredzot viņi neļaus vienai personai kontrolēt visus tās līdzekļus, vai ne? Viņiem būs cilvēku padome, kas atbildēs par līdzekļiem.

Tagad, kā tas darbosies Bitcoin skriptu darījumu kontekstā?

Vairāku parakstu skripti nosaka nosacījumu, ka skriptā tiek ierakstītas N publiskās atslēgas, un vismaz M no tām jāsniedz paraksti, lai atbrīvotu līdzekļus. To sauc arī par M-of-N shēmu, kur N ir kopējais atslēgu skaits un M ir mazākais parakstu skaits, kas nepieciešams validācijai. Darījumu sauc arī par M-of-N multisig.

Multisig izejas skripta formāts izskatās šādi:

M… N PĀRBAUDIET MULTISIG

Apskatīsim, kā tas darbojas piemērā.

Pieņemsim, ka mēs sūtām naudu uzņēmumam, kuru vada 3 cilvēki (Alise, Bobs un Čārlijs), un diviem no šiem trim cilvēkiem ir jāpārbauda darījums, lai tas notiktu. Šo darījumu sauc arī par 2 no 3 multisig.

Kā izeja izskatīsies?

2 3 PĀRBAUDES MULTISIG

Labi, tāpēc šī ir izeja. Kā uzņēmums atraisīs produkciju un piekļūs fondiem? Atcerieties, ka šī ir 2 no 3 multisig nozīme, 2 no 3 iesaistītajām personām jāuzrāda paraksti.

Tātad izmantotā parakstu kombinācija var būt jebkura no šīm:

Pieņemsim, ka Bobs un Čārlijs ir tie, kas pārbauda darījumu. Pēc tam pilns validācijas skripts tiks lasīts šādi:

2 3 PĀRBAUDES MULTISIG

Ja iepriekš minētie nosacījumi atbilst patiesībai un paraksti ir pareizi, tad darījums būs PATIESA un tā notiks cauri. Tomēr, ja paraksti ir nepareizi, darījums neizdosies.

Tomēr, ja pārbaudīsit vairāku sigu transakcijas piemērus, pamanīsit, ka mūsu izmantotais formāts:

2 3 PĀRBAUDES MULTISIG

… ir nepareiza.

Iemesls, kāpēc tas tā ir, ir tāds, ka CHECKMULTISIG opkodā ir kļūda.

Kļūda CHECKMULTISIG opkodā

Ideālā gadījumā CHECKMULTISIG opkodam vajadzētu iziet M + N + 2 elementus no kaudzes. Ņemsim piemēru, ar kuru līdz šim esam strādājuši:

2 3 PĀRBAUDES MULTISIG

Pirms CHECKMULTISIG tiek izpildīts, kaudze izskatīsies šādi:

Labākais Bitcoin Script Guide 2. daļa

Būtībā CHECKMULTISIG izceļ visus steka elementus.

Šajā piemērā M = 3 un N = 2.

CHECKMULTISIG tiek parādīti šādi vienumi: 3 (M) publiskās atslēgas, 2 (N) paraksti un divas konstantes, kas būtībā nozīmē, ka kopējais to priekšmetu daudzums, kuriem ideālā gadījumā vajadzētu iziet, ir (M + N + 2 =) 3 + 2 + 2 = 7 vienumi.

Tomēr CHECKMULTISIG opkodā ir kļūda, kas padara to par vienu vienumu vairāk nekā tie ir pieejami kaudzē. Tas acīmredzami izraisa kaudzes kļūdu.

Lai izvairītos no šīs kļūdas, tās novēršanai tiek izmantots risinājums. Ikreiz, kad mums ir apvienots validācijas skripts, mēs vienmēr sākam ar “0”. Tas nozīmē, ka skripts tagad izskatīsies šādi:

0 2 3 PĀRBAUDEMULTISIG

Pēc tam mūsu kaudze tagad izskatās šādi:

Labākais Bitcoin Script Guide 2. daļa

Sākumā pievienojot vienu papildu elementu “0”, mēs pārliecināmies, ka mums nav kļūdu.

Tas arī nozīmē, ka tā vietā, lai izmantotu šo atbloķēšanas skriptu:

Mēs galu galā izmantojam šo:

0

Kas ir Pay-to-Script-Hash vai P2SH?

Kaut arī daudzparakstu darījumi jūsu darījumiem piešķir daudz elastības, tie var kļūt sarežģīti. Iedomājieties uzņēmumu, kura darbībā ir iesaistīti 5 partneri. Ja Alise nosūtīja šim uzņēmumam dažus bitkoīnus, viņas izejas skripts izskatīsies šādi (pieņemot, ka 2 no 5 iesaistītajām personām ir jāpārbauda darījums):

2 5 PĀRBAUDES MULTISIG

Kā redzat, tas kļūst ļoti apgrūtinošs un tam ir daudz trūkumu:

  • Pirmkārt, uzņēmumam šī informācija un skripts faktiski būs jānosūta klientiem.
  • Pēc tam klientiem būs jāizmanto īpaša bitcoin maku programmatūra ar iespēju izveidot pielāgotu darījumu skriptu.
  • Iegūtais darījums būtu piecas reizes lielāks nekā parasts darījums, un tam būtu vajadzīgas lielākas maksas.

Bija nepieciešams risinājums, lai padarītu šo bitcoin skriptu nedaudz mazāk sarežģītu. Tika nolemts, ka sarežģītais multisig skripts tiks jaukts, un bloķēšanas skriptā cilvēki skripta vietā iekļaus hash.

Lai atbloķētu un izpirktu darījumu, saņēmējam būs jāuzrāda oriģināls skripts kopā ar parakstiem. Tā kā sūtītājs sūta naudu uz jaucienu, nevis publisku adresi, šāda veida darījumus sauc par Pay to Public Script Hash vai P2SH.

Tātad, kā P2SH mainīja darījumus (iepriekš sniegtajā piemērā)?

Pirms P2SH

Bloķēšanas skripts: 2 5 CHECKMULTISIG

Skripta atbloķēšana:

Pēc P2SH

Izpirkt skriptu: 2 5 CHECKMULTISIG

Bloķēšanas skripts: HASH160 EQUAL

Skripta atbloķēšana:

Kā redzams, atbildība par darījuma izpirkšanas nosacījumu nodrošināšanu tiek pārsūtīta no sūtītāja uz izpircēju, kurš uzrāda izpirkšanas skriptu.

Tātad, kāds būtu mūsu uzņēmuma skripts, ja P2SH netiktu izmantots? Sans P2SH Bitcoin skripts, ko viņi būtu izmantojuši, būtu šāds:

2 5 PĀRBAUDES MULTISIG

Kas tulkotu kaut ko līdzīgu šim:

2 04C16B8698A9ABF84250A7C3EA7EEDEF9897D1C8C6ADF47F06CF73370D74DCCA01CDCA79DCC5C395D7EEC6984D83F1F50C900A24DD47F569FD4193AF5DE762C58704A2192968D8655D6A935BEAF2CA23E3FB87A3495E7AF308EDF08DAC3C1FCBFC2C75B4B0F4D0B1B70CD2423657738C0C2B1D5CE65C97D78D0E34224858008E8B49047E63248B75DB7379BE9CDA8CE5751D16485F431E46117B9D0C1837C9D5737812F393DA7D4420D7E1A9162F0279CFC10F1E8E8F3020DECDBC3C0DD389D99779650421D65CBD7149B255382ED7F78E946580657EE6FDA162A187543A9D85BAAA93A4AB3A8F044DADA618D087227440645ABE8A35DA8C5B73997AD343BE5C2AFD94A5043752580AFA1ECED3C68D446BCAB69AC0BA7DF50D56231BE0AABF1FDEEC78A6A45E394BA29A1EDF518C022DD618DA774D207D137AAB59E0B000EB7ED238F4D800 5 CHECKMULTISIG

Nē, kāds neizcēla šos ciparus un burtus, tā izskatās 5 publiskās atslēgas kopā!

Iedomājieties, ka klienti sūta šo Bitcoin skriptu, lai nosūtītu savus Bitcoin UTXO.

Ja tas pats heksadecimālais bloks tiktu parsēts caur SHA 256, kam seko RIPEMD160, tas izskatās apmēram šādi:

54c557e07dde5bb6cb791c7a540e0a4796f5e97e

Tik daudz kārtīgāk un vadāmāk, pareizi?

Bloķēšanas skripta P2SH versija tagad izskatās šādi:

HASH160 54c557e07dde5bb6cb791c7a540e0a4796f5e97e EQUAL

Lai atbloķētu, atbloķēšanas skripts tagad izskatīsies šādi:

: <2 Publiskā atslēga 1 Publiskā atslēga 2 Publiskā atslēga 3 Publiskā atslēga 4 Publiskā atslēga 5 5 MULTISIG>

Šo divu bitcoin skriptu apvienošana notiek divos posmos.

Pirmkārt, izpirkšanas skripts tiek salīdzināts ar hash, lai redzētu, vai tas atbilst:

<2 Publiskā atslēga 1 Publiskā atslēga 2 Publiskā atslēga 3 Publiskā atslēga 4 Publiskā atslēga 5 5 MULTISIG> HASH160 EQUAL.

Ja šis bitcoin skripts atgriež TRUE, tad otrā atbloķēšanas daļa notiek, izmantojot šo koda daļu, kas notiek automātiski. Šis ir mūsu tradicionālais multisig atbloķēšanas veids:

 2 Publiskā atslēga 1 Publiskā atslēga 2 Publiskā atslēga 3 Publiskā atslēga 4 Publiskā atslēga 5 5 CHECKMULTISIG

P2SH adreses vienmēr sākas ar 3, nevis 1.

3KP3okFKoGs53JqgyGB27pqaum8tCz2BvW <- P2sh adrese.

Kas ir plūsmas kontrole?

Viens no interesantākajiem programmēšanas aspektiem ir Flow Control. Izmantojot noteiktus nosacījumus, var noteikt, kuras komandas tiek izpildītas un kad. Ikviens, kam ir kāda programmēšanas bāze, ir iepazinies ar IF-ELSE programmēšanas jēdzienu.

Šī ir vienkāršākā un elementārākā plūsmas vadības forma.

Bitcoin skriptā valsts kontrolei tiek izmantoti šādi:

  • JA
  • ELSEIF
  • ENDIF
  • NOTIF

Parastā programmā IF-ELSE nosacījums izskatās šādi:

Ja (nosacījums)

{

PAZIŅOJUMS A

}

cits

{

PAZIŅOJUMS B

}

C PAZIŅOJUMS

Tātad, kas šeit notiek?

  • Ja nosacījums ir patiess, izpildiet PAZIŅOJUMU A.
  • Pretējā gadījumā izpildiet PAZIŅOJUMU B.
  • Pēc tam STATEMENT C tiek izpildīts neatkarīgi no tā, kuru nosacījumu kāds izmanto.

Tomēr Bitcoin skriptā tam ir atšķirīgs izskats. Atcerieties, ka Bitcoin skripta galvenā iezīme ir tā, ka tā ir uz steku balstīta valoda. Tāpēc šajā gadījumā nosacījums rodas PIRMS IF paziņojuma.

Tātad, tas izskatās apmēram šādi:

NOSACĪJUMS

JA

PAZIŅOJUMS A

CITI

PAZIŅOJUMS B

BEIGT, JA

C PAZIŅOJUMS

Kā izskatīsies šī skripta bloka izpilde?

1. solis: Stāvoklis tiek parādīts kaudzē:

2. solis: IF opkods izlec no nosacījuma un pārbauda, ​​vai tas ir PATIESA vai nē.

3. solis: Ja tā ir patiesība, STATEMENT A tiek izpildīts, un Bitcoin skripts izlaiž ELSE paziņojumu, lai pārietu uz ENDIF un virzītu STATEMENT C uz kaudzīti.

4. solis: Ja IF ​​opkods atgriež FALSE, tad ELSE bloks tiek izpildīts un STATEMENT B tiek virzīts uz kaudzes.

5. solis: Pēc tam, kad STATEMENT B tiek nospiests uz kaudzes, ENDIF nosacījums tiek aktivizēts un STATEMENT C turpina virzīties uz kaudzi.

Sidenote:

Kā mēs redzējām iepriekš, plūsmas kontroli var izveidot, pievienojot VERIFY paziņojumu noteiktiem nosacījumiem.

2 4 IZLĪDZINĀT 3

Šajā gadījumā, tā kā 2 nav vienāds ar 4, skripts pārtrauks izpildīt to un to, pat nepārejot uz 3.

Plūsmas kontroles izmantošana Bitcoin skriptā

Viena no izplatītākajām plūsmas kontroles lietojumprogrammām ir tādu skriptu izveide, kuriem ir vairāki izpildes ceļi.

Mēs jau esam redzējuši daudzlīmeņu izpildījumu piemērus ar Multisignatures. Tagad aplūkosim, kā tos pašus daudzzīmju darījumus var rakstīt, izmantojot plūsmas kontroles paziņojumus.

Pieņemsim, ka mēs izpildīsim 1 no 2 Multisig. Divas multisig iesaistītās personas ir Alise un Bobs, un tikai šiem diviem ir jāpārbauda darījums, lai tas notiktu.

Tātad, kā tiks izveidots bloķēšanas skripts šim multisig, izmantojot plūsmas vadīklas?

Bitcoin Script bloķēšana

JA

PĀRBAUDE

CITI

PĀRBAUDE

ENDIF

Kā redzat, tā ir vienkārša vienkārša ja-cits cilpa. Tomēr šeit kaut kas nav kārtībā.

Kas, jūsuprāt, pietrūkst?

Tas ir pareizi …. Stāvoklis!

Trūkst paša nosacījuma … vai tā ir kļūda? Patiešām padomājiet par to tieši tagad … kāpēc mēs šo nosacījumu neiekļāvām bloķēšanas skriptā?

Nosacījuma esamība atbloķēs skriptu IF-ELSE un ļaus jums piekļūt paziņojumiem, NESniedzot verifikāciju. Atcerieties, ka IF-ELSE skriptu var atbloķēt tikai tad, ja ir izpildīti noteikti nosacījumi.

Tāpēc bloķēšanas skriptā mēs sniedzam IF-ELSE kodu bez nosacījuma.

Bitcoin skripta atbloķēšana

Atbloķēšanas skriptā Bobs vai Alise norāda parakstu un nosacījumus, kas nepieciešami skripta atbloķēšanai.

Saskaņā ar skriptu Alises kods tiek atbloķēts, ja nosacījums ir PATIESA, un Boba kods tiek atbloķēts, ja nosacījums ir FALSE. Mēs izmantojam “1”, lai apzīmētu TRUE, un “0”, lai apzīmētu FALSE.

Paturot prātā visu šo informāciju, Alises atbloķēšanas skripts būtu:

1

Boba atbloķēšanas skripts ir:

0

Skripta izpilde

Pieņemsim, ka Bobs vēlas atbloķēt UTXO, šādi izskatās kombinētais validācijas skripts (lai uzlabotu izpratni, mēs šajā piemērā izmantosim visu IF-ELSE kodu.):

0

1. darbība: Boba paraksts tiks virzīts uz kaudzes.

Labākais Bitcoin Script Guide 2. daļa

3. solis: Tagad sākas jautrā daļa.

Ir pienācis laiks izpildīt, kas notiek šādi:

JA

PĀRBAUDE

CITI

PĀRBAUDE

ENDIF

Pirmkārt, IF nosacījums no kaudzes izlec “0”.

Labākais Bitcoin Script Guide 2. daļa

5. solis: CHECKSIG tiek izpildīts, kurš no kaudzes ir gan paraksts, gan publiskā atslēga, un ar tiem tiek izpildīta darbība CHECKSIG.

Labi, tāpēc šis bija vienkāršs 1 no 2 multisig.

Tomēr nedaudz palielināsim ante un redzēsim, kas notiek, palielinot plūsmas kontroli skriptā.

JA

PAZIŅOJUMS A

CITI

JA

PAZIŅOJUMS B

CITI

C PAZIŅOJUMS

ENDIF

ENDIF

Labi, tāpēc mums ir trīs paziņojumi, kurus mēs vēlamies izpildīt. Lai izpildītu konkrētu paziņojumu, mums būs jāievada noteikti nosacījumi, lai tos sasniegtu.

Kādi nosacījumi jāievada, lai izpildītu PAZIŅOJUMU B? Nosacījumi būs: 1, 0 VAI {TRUE, FALSE}.

Bet pagaidiet, paziņojums B, nāk pēc viena CITA un viena, ja labi? Vai nosacījumu secībai nevajadzētu būt 0,1 VAI {FALSE, TRUE}?

Nu … atcerieties, ka skripts ir uz Stack balstīta programmēšanas valoda. Tātad kaudzē parādīsies šāds ievads: {TRUE, FALSE}:

Labākais Bitcoin Script Guide 2. daļa

Tātad, kas ir pirmais, kas parādīsies?

FALSE pareizi?

Šis FALSE nosacījums liks skriptam izlaist IF un pāriet tieši uz ELSE.

Tāpēc atcerieties, kā darbojas kaudze, vienmēr, kad mums ir jāpieņem nosacījumi.

Kas ir Timelock?

Laika bloķēšana ir primitīvs viedais līgums, kas nosaka laika ierobežojumus Bitcoin izdevumiem. Trīs Bitcoin bloķēšanai izmantotie laika bloķētāji:

  • Darījuma bloķēšanas laiks (nLocktime).
  • CHECKLOCKTIMERERY vai CLTV.
  • CHECKSEQUENCEVERIFY vai CSV

nBloķēšanas laiks

“NLocktime” būtībā ir parametrs, kas nosaka laiku, līdz kuram darījumu nevarēja pieņemt blokā. Katrā darījumu komplektā ietilpst nLocktime. NLocktime var veikt trīs iespējamos maršrutus:

  • Ja nLocktime ir iestatīts uz 0, darījums tiek nekavējoties izplatīts.
  • Ja 0
  • Ja nLocktime> 500 miljoni, tad to interpretē kā Unix Epoch laika zīmogu, un darījums nav derīgs, kamēr nav pagājis norādītais laiks.

Lai gan nLocktime labi izskatās uz papīra, ir ļoti acīmredzams vājums.

Pieņemsim, ka Alise vēlas nosūtīt Bobam kādu BTC ar bloķēšanas laiku 1 nedēļa. Pastāv iespēja, ka Alise var izmantot tos pašus UTXO, lai izveidotu citu darījumu, pirms ir pagājusi 1 nedēļa ar 0 bloķēšanas laiku.

Tātad uztvērējs ir pilnībā atkarīgs no sūtītāja ētikas.

CLTV

NLocktime problēma bija tāda, ka darījumam tika piemērota laika bloķēšana, kas padarīja to neaizsargātu pret ļaunprātīgiem lietotājiem. Tātad, CLTV vai CHECKLOCKTIMEVERIFY padarīja bloķēšanu piemērojamu atsevišķām izejām. Tātad, vienkāršoti izsakoties, CLTV padarīja atsevišķus darījuma rezultātus atbildīgus par laika bloķēšanu.

CLTV ir ieviests primitīvā ārpus ķēdes norēķinu kanālā, kas nodrošina pretestību iespējamai kaļamībai. CLTV stila maksājumu kanāli tika ieviesti pēc 65. BIP. Apskatīsim, kā tas darbojas:

  • Alise (tirgotājs) piešķir savu publisko atslēgu Bobam (klientam).
  • Bobs izmanto savu publisko atslēgu un Alisi, lai izveidotu P2SH adresi, izmantojot šādus nosacījumus: 1. nosacījums: gan Alise, gan Bobs paraksta jebkuru darījumu, kas notiek caur šo adresi. bloķēšanas laikam jābūt lielākam par atmaksas depozītu.
  • Bobs nekavējoties izveido depozīta darījumu un pārraida to blokķēdē. Iepriekš minētā 2. nosacījuma dēļ viņš ir pārliecināts par to, ka viņš pēc pieprasījuma var samaksāt atmaksu.
  • Atcerieties, ka pirmais nosacījums nosaka, ka Alisei un Bobam abiem jāpierakstās uz jebkuru darījumu, kas notiek P2SH adresē. Tātad, Bobs (klients) var parakstīt savu darījuma daļu, bet Alise – parakstīt savu daļu, neatklājot Bobam savus paraksta datus. To darot, Alise var pārraidīt gala maksājumu blokķēdē, pirms kompensācija var tikt pārraidīta.

CSV

Pirms mēs saprotam, kā darbojas CHECKSEQUENCEVERIFY vai CSV, jums jāzina atšķirība starp absolūto laika un relatīvo laika bloķēšanu.

Kaut arī nLocktime un CLTV ir absolūti laika bloķētāji, kas nozīmē, ka tie īpaši piemin absolūtu laika punktu, relatīvie laika bloķētāji norāda pagājušo laiku no produkcijas apstiprināšanas blokķēdē.

CSV vai CHECKSEQUENCEVERIFY ir relatīvs laika bloķētājs. CSV opkods norāda mainīgo “nSequence”.

Kad izsaukts, CSV opkods pārtrauks skripta izpildi, ja vien nSequence nenorāda, ka ir pagājis vienāds vai lielāks relatīvā bloķēšanas laika daudzums, nekā norādīts CSV opkodā.

Labi, tāpēc tagad izklaidēsimies. Izmantosim skriptu, izmantojot plūsmas kontroli un CSV!

Iedomājieties, ka mums ir uzņēmums, kas pieder 3 cilvēkiem: B, C un D. Uzņēmums darbojas ar 2 no 3 Multisig nozīmi, uzņēmuma līdzekļus var izmantot tikai tad, ja vismaz 2 no 3 cilvēkiem uzrāda savu taustiņus.

Tomēr, ja cilvēki zaudē atslēgas, viņiem ir jāpadara drošs, lai pārliecinātos, ka līdzekļus joprojām var aktivizēt 2 no 3 multisig. Šajā gadījumā viņi izveido rezerves atslēgu un nodod savam advokātam A.

Tātad, kā tas izskatīsies scenārijā?

JA

JA

2

CITI

<30 dienas> PĀRBAUDIET PĀRBAUDIET PILIENU <A’s Pubkey> PĀRBAUDE

1

ENDIF

<B’s Pubkey> 3 PĀRBAUDES MULTISIG

CITI

<90 dienas> PĀRBAUDIET PĀRBAUDIET PILIENU <A’s Pubkey> PĀRBAUDE

ENDIF

Kā redzat, plūsmai var būt trīs veidi:

  • Ja viss ir labi un labi, tad tas darbojas kā vienkāršs 2 no 3 multisig.
  • Ja kāds no īpašniekiem zaudē atslēgu un nevar to uzrādīt 30 dienu laikā, nosacījumi, kas nepieciešami, lai piekļūtu fondiem, ir jurista atslēga UN 1 no 3 multisig ar 3 īpašniekiem.
  • Ja visi 3 īpašnieki zaudē atslēgas, advokāts piekļūst fondiem pēc 90 dienām.

1. nosacījums: viss ir labi

Ja viss ir labi un neviens nav pazaudējis nevienu atslēgu, tad 2 no 3 īpašniekiem darījumus pārbaudīs ar saviem parakstiem, tāpat kā jebkurā parastā multisig.

Atbloķēšanas skripts: 0

Piezīme. Neaizmirstiet, ka visi multisig darījumi sākas ar “0”, lai apietu kļūdu CHECKMULTISIG.

Pilnīgs validācijas skripts: 0

Tātad, kā izskatās izpilde?

1. solis: Atbloķēšanas skripts tiek solīts pa solim

Labākais Bitcoin Script Guide 2. daļa

Vai tas izskatās pazīstams?

Jā … tas ir 2 no 3 multisig un Bitcoin skripts tiek izpildīts normāli.

Nosacījums Nr. 2: viena persona zaudē atslēgas

Šajā gadījumā spēlē advokāts A.

Atbloķēšanas skripts: 0

Pilnīgs validācijas skripts: 0

Tātad, kā izskatās izpilde?

1. solis: atbloķēšanas skripts tiek virzīts uz kaudzīti.

Labākais Bitcoin Script Guide 2. daļa

3. solis: Gaidāmās sekvences ir:

<30 dienas> PĀRBAUDIET PĀRBAUDIET PILNU PĀRBAUDI

“<30 dienas> CHECKSEQUENCEVERIFY DROP ”būtībā aktivizē 30 dienu laika bloķēšanu. Ja laika joslā īpašnieks, kurš zaudējis atslēgu, to nevar izgūt, skripts pāriet uz nākamo kaudzes elementu.

Tomēr, ja viņi var izgūt atslēgu un parādīt pierādījumu, skripts nekavējoties pārtrauc izpildi (jo tiek pievienots kods VERIFY).

Piezīme: Tātad, kas ir DROP? Pieņemsim, ka ir iesniegts parametrs, kas nepieciešams, lai izpildītu CHECKSEQUENCEVERIFY, laika parametrs, kas bija pirms tā, t.i.<30 dienas>”Joprojām atrodas uz steka. Funkcija DROP šajā gadījumā izlaiž pēdējo steka elementu, <30 dienas>.

Labākais Bitcoin Script Guide 2. daļa

Tagad tas kļūst par vienu no 3 multisig. Ja B paraksts tiek pārbaudīts, skripts tiek izpildīts pareizi.

Nosacījums Nr. 3: visi trīs īpašnieki nepareizi ievieto atslēgas

Šajā gadījumā skripts pat neizpilda pirmo IF, tas pāriet tieši uz ELSE paziņojumu.

Skripta atbloķēšana:

Pilnīgs validācijas skripts:

Tātad, kā izskatās izpilde?

1. solis: atbloķēšanas skripts tiek virzīts uz kaudzi.

Labākais Bitcoin Script Guide 2. daļa

Secinājums

Šīs rokasgrāmatas mērķis bija likt jums saprast dažādu Bitcoin Script darījumu scenāriju loģiku. Maigi izsakoties, ir intriģējoši redzēt šo darījumu mehānismu. Ja neesat izlasījis Bitcoin Script Guide 1. daļu, noteikti pārbaudiet to!

Mike Owergreen Administrator
Sorry! The Author has not filled his profile.
follow me
Like this post? Please share to your friends:
map