Friday, December 25, 2015

Vremenski zaključane transakcije: Primjeri

Zajamčeni polog (escrow)


Ako Alice i Bob žele zajedno upravljati poslom, zajednička sredtva mogu držati u 2-od-2 višepotpisnoj transakciji. No u slučaju smrti jedne strane, druga strana neće imati pristup zajedničkim sredstvima. Zato bi mogli zaposili odvjetnika Lennyja da bude treća strana u slučaju nezgode. No kod 2-od-3 višepotpisne transakcije, odvjetnik se može urotit s bilokojom stranom te ukrasti zajednička sredstva. U ovakvom se slučaju može iskoristiti operator CHECKLOCKTIMEVERIFY u scriptSig dijelu transakcije:

IF
    <sad + 3 mjeseca> CHECKLOCKTIMEVERIFY DROP
    <Lennyjev pubkey> CHECKSIGVERIFY
    1
ELSE
    2
ENDIF


<Alicin pubkey> <Bobov pubkey> 2 CHECKMULTISIG

Ovakva se transakcija može potrošiti u bilokojem trenutku ovako:

0 <Alicin potpis> <Bobov potpis> 0
Postupak trošenja je sljedeći:
 
0
Bobov potpis
Alicin potpis
0
 
 
Ovako izgleda stog nakon pokušaja trošenja gornje vremenski zaključane transakcije prije isteka roka valjanosti. Naredba IF provjerava prvi element na stogu te se izvršavanje dalje nastavlja ovisno o tom elementu. Na vrhu stoga je 0 koja se tretira kao neistina te se prelazi na ELSE dio naredbe koja na stog stavlja 2.

2
Bobov potpis
Alicin potpis
0

 
Izgled stoga nakon izvršavanja naredbe IF. Ovo je sada normalna 2-od-2 višepotpisna transakcija
0 <Bobov potpis> <Alicin potpis> 2 <Alicin pubkey> <Bobov pubkey> 2 CHECKMULTISIG
Zbog buga u naredbu CHECKMULTISIG, m-od-n višepotpisna transakcija uzima jedan više potpis nego je zapravo potrebno.

Nakon isteka roka valjanosti ovu je transakciju moguće potrošiti na sljedeći način:
0 <Alicin/Bobov potpis> <Lennyjev potpis> 1

1
Lennyje potpis
Alicin/Bobov potpis
0

 
Ovako izgleda stog nakon pokušaja trošenja gornje vremenski zaključane transakcije nakon isteka roka valjanosti. Na stogu je 1 koji se tretira kao istina te se prelazi na provjeru roka valjanosti. Rok valjanosti ističe tri mjeseca nakon nastanka transakcije.

sad + 3 mjeseca
Lennyjev potpis
Alicin/Bobov potpis
0

 
Na stog se stavlja rok valjanosti te se uspoređuje s poljem nLockTime transakcije koja taj izlaz želi potrošiti. Budući da je rok istekao, izlaz se smije potrošiti. Naredba DROP odbacuje gornji element stoga (u ovom slučaju rok valjanosti).

Zatim se uzima Lennyjev javni ključ s kojim naredba CHECKSIGVERIFY provjerava Lennyjev potpis na stogu. Ako je potpis ispravan na stog se na kraju stavlja 1.

1
Alicin/Bobov potpis
0

Sada je ovo 1-od-2 višepotpisna transakcija koja se može potrošiti pomoću Alicinog ili pomoću Bobovog potpisa
0 Alicin/Bobov potpis 1 <Alicin pubkey> <Bobov pubkey> 2 CHECKMULTISIG

Neinteraktivna vremenski zaključana nadoknada


U nekim je protokolima potrebna suradnja dvije strane da bi se potrošila neka transakcija. U slučaju nedostupnosti jedne strane, povrat novca (nadoknada) se vremenski zaključati kako bi se nakon isteka roka valjanosti vratio pošiljatelju. Takva transakcija u kojoj Alice šalje Bobu sredstva može izgledati ovako
 
IF
     <rok_valjanosti> CHECKLOCKTIMEVERIFY DROP
    1
ELSE
     2
ENDIF
<Alicin pubkey> <Bobov pubkey> 2 CHECKMULTISIG

Slično kao i u prethodnom primjeru, ovakva se transakcija može prije isteka roka potrošiti s

0 <Alicin potpis> <Bobov potpis> 0

U slučaju nedostupnosti jedne strane i nakon isteka roka valjanosti, transakcija se može potrošiti s

0 <Alicin/Bobov potpis> 1

Plaćanje za objavljivanje podataka


Postoje usluge koje omogućuju plaćanje za objavljivanje informacija. Osoba koja objavljuje informaciju prvo mora dokazati da kriptirani dokument sadrži tražene podatke, a zatim konstruirati transakciju koja će otkriti ključ za dekripciju podataka. Trenutačne implementacije takvih sustava omogućuju osobi koja objavljuje informaciju da nikad ne otkrije tajni ključ. Taj se nedostatak može riješiti korištenjem naredbe CHECKLOCKTIMEVERIFY:

IF
    HASH160 <hash160(tajni_ključ)> EQUALVERIFY
    <pubkey objavljivača> CHECKSIG
ELSE
     <rok valjanosti> CHECKLOCKTIMEVERIFY DROP
     <pubkey platitelja> CHECKSIG
ENDIF

Objavljivač informacije transakciju može potrošiti ovako:
<potpis objavljivača> <tajni ključ> 1
 
1
Tajni ključ
Pubkey objavljivača

Ovako izgleda stog nakon pokušaja trošenja transakcije. 1 se smatra istinom te se prelazi na verifikaciju tajnog ključa.
 
Tajni ključ
Pubkey objavljivača

Gornji element stoga se hashira funkcijom HASH160 te uspoređuje s hashem podatka u transakciji. U slučaju da su identični (objavljen je pravi tajni ključ), verificira se potpis objavljivača te je tajna otkrivena onome tko je platio za nju.

U slučaju da objavljivač ne objavi tajni ključ, platitelj može dobit povrat novca nakon isteka roka valjanosti:
 
0 <potpis platitelja>
 
0
potpis platitelja

Zbog 0 se pralazi u ELSE dio transakcije koji na stog stavlja rok valjanosti i uspoređuje ga s poljem nLockTime:
 
Rok valjanosti
Potpis platitelja

Ako je rok prošao, odbacuje se sa stoga te se verificira potpis platitelja te on dobiva uplaćeni novac natrag.

Friday, December 18, 2015

Vremenski zaključane transakcije (BIP 65)


Svaka bitcoin transakcija ima polje nLockTime. Zamišljeno je da sadrži vrijednost koja govori kada se transakcija može potrošiti u budućnosti. Vrijednost polja može se interpertirati na dva načina: ako je vrijednost manja od 500.000.000 tretira se kao visina bloka u kojem transakcija postane validna, a ako je vrijednost veća od toga, tretira se kao datum kada transakcija postaje validna (broj sekundi od 1. siječnja 1970.).

Takva se transakcija može uključiti u blok koji je na zadanoj ili većoj visini, odnosno čije je vrijeme pronalaska veće ili jednako onome u polju nLockTime. Problem je što se ne može garantirati da izlazi koje koristi transakcija s popunjem nLockTime poljem neće prije potrošiti neka druga transakcija.

Zato je definirana naredba CHECKLOCKTIMEVERIFY (odnosno redefinirana je naredba NOP2). Ona služi tome da se zaključaju pojedini izlazi iz transakcija koji će se potrošiti u budućnosti te prima jedan parametar: rok valjanosti. Kada se tako zaključani izlaz želi potrošiti, njegov se rok valjanosti uspoređuje s poljem nLockTime transakcije koja ga troši. Izlaz će se potrošiti samo ako je rok valjanosti manji od nLockTime. Transakcije zaključane s CHECKLOCKTIMEVERIFY mogu se normalno uvrstiti u blok.

Primjer zamrzavanja sredstava


Slijedi primjer skripte u skriptnom jeziku Bitcoina kojom je moguće zamrznuti sredstva sve dok ne istekne zadani rok valjanosti:


<rok valjanosti> CHECKLOCKTIMEVERIFY DROP DUP HASH160 <pubKeyHash> EQUALVERIFY CHECKSIG


Transakcija koja će potrošiti ovaj izlaz mora imati nLockTime veći od roka valjanosti. Budući da se transakcija s takvim poljem može tek uključiti u blok čija je visina ili vrijeme veće od vrijednosti nLockTime, originalna će transakcija ostati nepotrošena do zadanog vremena. Nakon isteka roka valjanosti, transakcija se dalje normalno validira.

Zaobilaženje roka valjanosti


Rok valjanosti moguće je zaobići ako transakcija koja troši vremenski zaključani izlaz redne brojeve svojih izlaza postavi na maksimum (0xffffffff). To je zaostatak iz starih verzija protokola Bitcoin te operacija CHECKLOCKTIMEVERIFY provjerava vrijednosti rednih brojeva ulaza. Ako redni broj nije maksimum transakcija će moći normalno potrošiti izlaz ako je prošao rok valjanosti. U suprotnom, transakcija ne može potrošiti izlaz.

Sunday, December 6, 2015

Detalji coinbase transakcije


Na početku svakog bloka transakcija nalazi se tzv. coinbase transakcija. Ona donosi nagradu onome tko je uspješno izrudario blok. Sama nagrada sastoji se od subvencije za blok (trenutačno 25 BTC) te od naknada za sve transakcije u bloku.

Primjer strukture coinbase transakcije je
Version
1
Inputs
Prevoius hash
0
Index
0xFFFFFFFF
ScriptSig
03dae7052f4249503130302f040e7164560902c8108999000000d3072f425443432f20
Sequence
0
Outputs
Value
2510629190
ScriptPubKey
76a9142c30a6aaac6d96687291475d7d52f4b469f665a688ac
Locktime
0

U odnosu na ostale transakcije, coinbase transakcija je pojednostavljena. Nema referencu na prethodnu transakciju jer stvara nove bitcoine, a ne preuzima već postojeće. Budući da se ne referira na prethodnu transakciju, nema niti indeks prethodnog izlaza.

Coinbase transakcija nije niti potpisana digitalnim potpisom nego se polje ScriptSig koristi kao tzv. extra nonce polje. Često polje nonce u zaglavlju transakcije nije dovoljno veliko da bi se moglo samo koristiti za pretraživanje svih mogućih vrijednosti noncea. Zato se ono dopunjava poljem ScriptSig u koje se upisuje dio noncea koji nije stao u zaglavlje. Na taj način rudari dobivaju više mogućnosti za kombiniranje.

BIP34

Osim što služi kao extra nonce, u prvi bajt polja ScriptSig zapisuje se i visina bloka u kojem se nalazi coinbase transakcija. To osigurava da je hash svakog idućeg bloka i transakcije jedinstven. Format zapisa je broj bajtova u visini te sama visina zapisana u little endian formatu. U gornjem primjeru to je "03dae705", odnosno "03" bajta za visinu te visina u little endian formatu "dae705", odnosno u big endianu 05e7da te u decimalnom formatu 387034. Blok 227835 je prvi blok takvog formata te on i svi sljedeći imaju verziju 2.