Artikkeli · r6-network-003
Bitcoinin SIGHASH: mitä tapahtuman allekirjoitus sitoo?
Bitcoin-tapahtuman allekirjoitus ei aina sido kaikkia tapahtuman osia samalla tavalla. SIGHASH-tyyppi määrää, mitä tietoja allekirjoitusta varten otetaan mukaan. Jos tietty osa ei kuulu tämän allekirjoituksen suojaamiin tietoihin, sen muuttaminen ei välttämättä riko juuri tätä allekirjoitusta. Muut allekirjoitukset ja tapahtuman kelpoisuussäännöt voivat silti rajoittaa muutosta.[4]
Tämä ei ole sama kysymys kuin se, kuka omistaa yksityisen avaimen tai kuinka suuri siirtomaksu on. Kyse on yhden allekirjoituksen sitovuuden rajasta tapahtumassa, jossa on syötteitä ja tulosteita. Eri skripti- ja allekirjoitusversioiden yksityiskohdat eroavat: legacy käyttää muunneltua tapahtumaserialisointia, SegWit v0 BIP-143:n mukaista esikuvaa ja Taproot BIP-341:n viestiä. Niitä ei pidä käsitellä yhtenä hash-algoritmina.[4], [5], [6]
ALL, NONE ja SINGLE vastaavat eri kysymyksiin
SIGHASH_ALL sitoo kaikki tulosteet. Ilman ANYONECANPAY-määrettä se sitoo myös kaikkien syötteiden viitteet aiempiin tulosteisiin eli outpointit. Tämä ei tarkoita sitoutumista kaikkien syötteiden kaikkiin kenttiin tai tapahtuman kaikkiin tavuihin; tarkat tiedot riippuvat allekirjoitusversiosta.[4], [5], [6]
SIGHASH_NONE ei sido tulosteita kyseisen allekirjoituksen osalta; ilman ANYONECANPAY-määrettä se sitoo syötteiden outpoint-viitteet. Siksi yksin tällainen allekirjoitus ei määritä, mihin tulosteisiin arvo päätyy. Jos tapahtumassa on muita allekirjoituksia, niiden ehdot voivat kuitenkin sitoa tulosteita ja rajoittaa muutoksia.[4]
SIGHASH_SINGLE sitoo kyseistä syötettä vastaavan tulosteen, jos se on olemassa: parin ratkaisee syötteen ja tulosteen sama järjestysnumero. Se ei sellaisenaan sido kaikkien muiden tulosteiden sisältöä. Ilman ANYONECANPAY-määrettä myös syötteiden outpoint-viitteet sitoutuvat, paitsi alla kuvatussa legacy-poikkeuksessa, jossa vastaavaa tulostetta ei ole.[4], [5], [6]
Pelkkä kaikkien outpointien sitominen ei tarkoita kaikkien muiden syötekenttien sitomista. Legacyssä ja SegWit v0:ssa NONE ja SINGLE eivät sido muiden syötteiden sequence-arvoja samalla tavalla kuin ALL; BIP-143:ssa näissä tapauksissa hashSequence on nolla. Taprootissa ilman ANYONECANPAYta sitoutuvat myös kaikkien syötteiden sequence-arvot sekä käytettävien aiempien tulosteiden määrät ja scriptPubKeyt. Muiden syötteiden scriptSig- tai witness-sisältöjä ei voi olettaa kokonaisuudessaan allekirjoitetuiksi.[4], [5], [6]
Ajatuskokeessa tapahtumalla on kaksi syötettä ja kaksi tulostetta. Jos tarkastellaan vain ensimmäisen syötteen SINGLE-allekirjoitusta, sen vastaava tuloste on ensimmäinen tuloste. Tästä ei voi päätellä, että toisen syötteen allekirjoitus antaisi luvan muuttaa toista tulostetta: se on tarkastettava erikseen.[4]
Mikä muuttuu, kun mukana on ANYONECANPAY?
ANYONECANPAY on lisämääre, joka yhdistetään perustyyppiin. Oppaan esimerkissä ALL yhdessä ANYONECANPAY-määreen kanssa sitoo kaikki tulosteet, mutta ei muiden syötteiden viitteitä; syötetietojen osalta mukana on allekirjoitusta vastaava syöte soveltuvan version sääntöjen mukaan. Muita syötteitä voidaan tällöin lisätä tai poistaa rikkomatta juuri tätä allekirjoitusta, jos muut soveltuvat ehdot sen sallivat.[4]
Kuvitellaan keskeneräinen tapahtuma, jossa yhden syötteen allekirjoittaja sitoo kaikki tulosteet mutta jättää muiden syötteiden kokoonpanon avoimeksi. Toinen osapuoli voi ehdottaa lisäsyötettä. Se ei silti tarkoita, että uusi kokonaisuus olisi automaattisesti kelvollinen tai että jokainen muu allekirjoittaja olisi hyväksynyt muutoksen. Esimerkki kertoo vain yhden allekirjoituksen rajauksesta.[4]
Versio ratkaisee myös SINGLE-poikkeuksen
Jos vastaavaa tulostetta ei ole, legacy-mallissa allekirjoitushash on historiallinen vakio 1. SegWit v0:ssa BIP-143:n hashOutputs on tällöin nolla, mutta muu allekirjoitusviesti edelleen hashataan: tulos ei ole sama vakio-1-poikkeus. Taprootissa vastaavan tulosteen puuttuminen aiheuttaa SINGLE-allekirjoituksen kelpoisuustarkistuksen epäonnistumisen. Nämä erot eivät ole kehotus allekirjoittaa puutteellista tapahtumaa.[4], [5], [6]
Taprootin BIP-341 määrittelee SIGHASH_DEFAULT-tyypin, joka sitoo samat transaktiotiedot kuin ALL kyseisen allekirjoitusversion sääntöjen mukaan. Tämä ei tarkoita kaikkien serialisoidun tapahtuman tavujen tai kaikkien muiden allekirjoitusten ja witness-pinojen sitomista. DEFAULT ja ALL eivät myöskään ole sama tyyppiarvo.[6]
Taprootin määrittelyssä allekirjoitettava tietosisältö riippuu tyypistä: esimerkiksi ilman ANYONECANPAY-määrettä mukana on kaikkien syötteiden viitteitä, kun taas määreen kanssa kuvataan kyseisen syötteen tietoja. Yleistys ”SIGHASH allekirjoittaa aina täsmälleen samat kentät” peittäisi juuri ne erot, joita tyyppi on tarkoitettu ilmaisemaan.[6]
Jos lompakko tai keskeneräisen tapahtuman työkalu näyttää SIGHASH-arvon, nimen tunnistaminen on vasta alku. Selvitä myös allekirjoitusversio, kyseinen syöte ja mahdolliset muut allekirjoitukset. Jos lompakko ei näytä riittäviä tietoja tai et ymmärrä tyyppiä tai versiota, älä allekirjoita ennen asian selvittämistä. Yksittäisen lipun nimi ei todista pyynnön turvallisuutta. Tämä artikkeli ei ole ohje muokata tapahtumia eikä arvio yksittäisen allekirjoituspyynnön turvallisuudesta.