Az elosztott szerződések arra adnak lehetőséget, hogy a Bitcoin blokkláncába foglaljunk különböző megállapodásokat. A szerződések semmi olyasmit nem tesznek lehetővé, ami ne lett volna lehetséges eddig is, csupán a lehető legminimálisabb bizalomszükséglettel adnak lehetőséget bizonyos gyakori problémák megoldására.

A Bitcoinos szerződések alapjául szolgáló elképzelések egy jelentős hányadát Nick Szabó fejtette ki először a Nyilvános hálózati kapcsolatok formalizálása és biztosítása (Formalizing and Securing Relationships on Public Networks) c. szemináriumi dolgozatában.

Elmélet

Minden Bitcoinos tranzakció rendelkezik egy vagy több be- és kimenettel. Mindegyik be- és kimenethez kapcsolódik egy egyszerű funkció, egy úgynevezett szkript. A szkriptek a tranzakcióik egyszerűsített, aláírt változatát tartalmazhatják.

Mindegyik tranzakcióhoz csatolható egy záridő is. Ez egy előre meghatározott jövőbeli időpontig függőbe helyezi és cserélhetővé teszi a tranzakciót. Ezt az időtartamot blokkindexként vagy időbélyegzőként is meg lehet határozni. Mindkét esetben ugyanazt a mezőt használjuk, de az 500 millió alatti értékeket blokkindexként értelmezi a rendszer. A tranzakció akkor válik véglegessé, ha eléri a megszabott határidejét.

Mindegyik tranzakció-bemenetnek van egy sorszáma. Normál, csak értékeket mozgató tranzakciók esetében a sorszám mindig UINT_MAX, a záridő pedig nulla. A tranzakció akkor is véglegesnek számít, ha a záridejét ugyan még nem érte el, viszont minden sorszáma UINT_MAX. A sorszámok segítségével hozhatóak létre egy adott tranzakció újabb változatai a többi bemeneti aláírás érvénytelenítése nélkül. Olyan esetekben például, ahol a tranzakció minden egyes bemenete valaki mástól származik, mindegyik bemenet kezdődhet nullás sorszámmal, és mindegyik szám egymástól függetlenül növelhető.

Az aláírás-ellenőrzés rugalmas, mivel a tranzakció aláírt változata az aláírás végéhez fűzött SIGHASH flagekkel ellenőrizhető. Így olyan szerződéseket állíthatunk össze, amelynek minden érintett fél aláírhatja egy-egy részét. A SIGHASH-flagek két részből állnak, egy módból és egy ANYONECANPAY módosítóból:

1.) SIGHASH_ALL: Ez az alapbeállítás. Azt jelzi, hogy a bemeneti szkriptek kivételével a tranzakció minden más része megfelelően aláírt. Mivel a bemeneti szkriptek aláírása értelemszerűen ellehetetlenítené a tranzakció felépítését, ezért ezek mindig aláíratlanok. A bemenet egyéb tulajdonságai azonban – így például az összekapcsolt kimenet és a sorszámok mind aláírottak, csak a szkriptek nem. Ez tehát lényegében azt jelenti, hogy “Hajlandó vagyok beletenni a pénzemet ezzel és ezzel a kimenettel, ha mindenki más is beleteszi a magáét.”

2.) SIGHASH_NONE: A kimenetek nincsenek aláírva és bármit tartalmazhatnak. Ezzel azt jelezzük, hogy “Hajlandó vagyok beletenni a pénzemet, ha mindenki más is beleteszi a magáét, de nem érdekel, hogy mi lesz a kimenettel.” Ez lehetővé teszi mások számára, hogy a bemeneti sorszámaik megváltoztatásával frissíthessék a tranzakciót.

3.) SIGHASH_SINGLE: A SIGHASH_NONE-hoz hasonlóan a bemenetek itt is aláírottak, de a sorszámok üresek, hogy lehessen frissíteni a tranzakciót. A kimenetek közül egyedül a bemenettel megegyező pozícióban lévő van aláírva. Ezzel jelezzük azt, hogy “Amíg a kimenet az marad, amit én akarok, részemről rendben, és nem érdekelnek a többiek.”

A SIGHASH_ANYONECANPAY módosítót kombinálni is lehet az előbbi három móddal. Ez eseben csak az a bemenet lesz aláírva, a többi bármi lehet.

A szkriptek tartalmazhatják a CHECKMULTISIG opkódot. Ez az opkód n-of-m ellenőrzést végez: megadsz több nyilvános kulcsot és meghatározod a szükséges érvényes aláírások számát. Ez utóbbi lehet alacsonyabb is a megadott nyilvános kulcsok számánál. Ha például azt szeretnénk, hogy egy kimenet csak két érvényes aláríással legyen elkölthető, akkor azt valahogy így állíthatjuk be:

2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY

A szerződések biztonságosságát általában kétféleképpen szavatolhatjuk:

1. A tranzakciókat a P2P-hálózaton kívül adjuk körbe, részleges vagy érvénytelen formában.

2. Két tranzakciót használunk: létrehozzuk magának a szerződésnek a tranzakcióját és aláírjuk, de nem küldjük el azonnal. Helyette a másik, a fizetést tartalmazó tranzakciót küldjük el azután, hogy megkötöttük a pénzt lekötő szerződést, és csak eztán küldjük el magát a szerződést is.

Így mindig pontosan tudhatja mindenki, hogy mibe is egyezik bele épp. Ezen eszközök együttes használatával érdekes és hasznos új pénzügyi eszközöket építhetünk a blokkláncra.

1. példa: letét

Képzeld el, hogy beregisztrálsz egy weboldalra (például egy fórumra vagy wikire), és szeretnéd valamiféle bizonyságát adni a megbízhatóságodnak, viszont nincs semmiféle előzetesen meglévő hírneved, amit felhasználhatnál erre a célra. Alternatív lehetőségként befizethetsz valamennyi pénzt a weboldalnak – de ha akármikor is úgy döntesz, hogy otthagynád az egészet és törölnéd a regisztrációdat, akkor nyilván szeretnéd vissza is kapni a pénzedet. És talán te sem bízol meg annyira az oldalban, hogy rájuk bízd a pénzed, hogy aztán esetleg csak úgy elköltsék. Vagy hogy egy nap egyszerűen eltűnjön az egész oldal a pénzeddel együtt.

A cél tehát annak bizonyítása, hogy hoztál valamiféle áldozatot annak érdekében, hogy az oldal láthassa, hogy komolyak a szándékaid, viszont azt sem akarod, hogy eltapsolják a pénzedet. Ha pedig egyszerűen eltűnnének, akkor szeretnéd, ha nélkülük is visszaszerezhetnéd újra a pénzedet.

Mindez könnyen megoldható egy szerződéssel:

1.) Az oldal és a felhasználó egyaránt küldenek egymásnak egy-egy frissen generált nyilvános kulcsot.

2.) A felhasználó az oldaltól az előző lépésben kapott nyilvános kulccsal létrehozza a letétet tartalmazó Tx1 tranzakciót, 10 BTC-t helyezve el egy olyan kimenetben, amit neki és a weboldalnak is alá kell írnia, de nem küldi el azt.

3.) A felhasználó elküldi az oldalnak a Tx1 tranzakciót.

4.) A weboldal létrehozza a szerződést tartalmazó Tx2 tranzakciót. Ez elkölti a Tx1-et és visszafizeti azt a felhasználónak az általa az első lépésben megadott címre. Emlékezzünk rá, hogy a Tx1 két aláírást igényel, így ez a tranzakció nem lehet teljes. Az nLockTime-ot egy jövőbeli időpontra (mondjuk hat hónapra) állítjuk be, a bemenet sorszámát pedig nullára.

5.) Végül a weboldal visszaküldi a részleges (félig aláírt) tranzakciót a felhasználónak, aki így ellenőrizheti, hogy minden rendben van-e azzal, hogy a hat hónap lejártával valóban visszakerülnek-e hozzá az érmék, ha semmi nem változik. A nullás sorszámok miatt a felek közös megegyezéssel és egyetértéssel a későbbiekben még módosíthatják a szerződést (egyoldalú módosításra nincs lehetőség). Mivel azonban az input szkriptje még nem teljes (a felhasználó aláírásának helyén csak nullák vannak), ezért a a felhasználó aláírja a szerződést és beilleszti az új aláírást a megfelelő helyre.

6.) A felhasználó elküldi előbb a Tx1-et, majd a Tx2-t.

Ezen a ponton a 10 BTC olyan állapotba kerül, hogy azt sem az oldal, sem pedig a felhasználó nem tudja önállóan elkölteni. Hat hónap után a szerződés beteljesül, és a felhasználó akkor is visszakapja a pénzét, ha a weboldal időközben eltűnik.

És ha a felhasználó szeretné hamarabb elhagyni az oldalt, és törölni a regisztrációját? Akkor az oldal létrehozza a Tx2 egy új változatát, amelyben nullára állítja az nLockTime-ot, a bemenet sorszámát pedig UINT_MAX-ra, majd újra aláírja azt, és átadja a tranzakciót a felhasználónak, hogy ő is aláírhassa. Miután ő is aláírta, szét is küldi azt a hálózatban. Ezzel máris elintézték a szerződés idő előtti megszakítását, és a felhasználó is visszakapta a pénzét.

És ha rövidesen lejár a hat hónap, de a felhasználó továbbra is szeretné megtartani a tranzakcióját? Az alapelv akkoris ugyanez: újra aláírják a szerződést egy újabb nLockTime-idővel, valamint az előzőnél eggyel magasabb sorszámmal és 2^32 alkalommal küldik szét újra. Bármi is történjék azonban, a változtatás csakis akkor lép életbe, ha ahhoz minden érintett hozzájárul.

Értelemszerűen ha a felhasználó rosszindulatúnak bizonyul (például spamel), akkor a weboldal nem fogja engedélyezni a szerződés idő előtti megszakítását. Ha a felhasználó túl sokat rendetlenkedik, úgy emelhető a letét összege, vagy megnyújtható az időtartama.

2. példa: zálog és vitamediáció

Olyasvalakivel szeretnél kereskedni, akit vagy nem ismersz, vagy akiben nem bízol. Ha a tranzakciót bonyodalmak nélkül sikerül lefolytatni, úgy harmadik félre nincs is szükség. Ha azonban problémák adódnak akár eladói, akár vásárlói részről, úgy már jól jöhet egy harmadik fél – például egy profi mediációs szolgáltató. A mediátor pedig kérhet például bizonyítékot az áru leszállításáról a kereskedőtől.

Más szavakkal tehát szeretnél zárolni egy bizonyos összeget, hogy aztán két cím valamelyikére küldhesd el azt. Olyan kimeneti szkriptet nem lehet írni, ami ellenőrizhetné az elköltő tranzakció kimeneteit, mivel a szkripteknek nincs hozzáférésük ezekhez az adatokhoz. Szerencsére azonban ezt megoldhatjuk másképp is:

1.) Megegyezhetünk egy kereskedővel vagy mediátorral (pl. ClearCoin).

2.) Kérhetünk egy nyilvános kulcsot a kereskedőtől (K1) és a mediátortól (K2), plusz létrehozhatunk egyet saját magunknak is (K3).

3.) A kereskedőnek elküldjük a K2-t. A kereskedő ebben kicseréli a mediátort egy random nonce-ra, majd aláírja azt a K2 magánváltozatával, bizonyítva így, hogy az valóban az övé.

4.) Létrehozunk és szétküldünk egy tranzakciót (Tx1) a következő kimeneti szkripttel:

2 <K1> <k2> <K3> CHECKMULTISIGVERIFY

Ezzel máris zároltuk az érméket úgy, hogy csak a következő esetekben és a következő módokon válhassanak elkölthetővé:

1.) Teljes egyetértés: az üzlet sikeresen lebonyolításra került, vagy a kereskedő mediáció nélkül is hajlandó visszaadni a pénzedet.

2.) A mediátor veled ért egyet: sikertelen üzlet, visszakapod a pénzedet.

3.) a mediátor a kereskedővel ért egyet: az áru leszállításra került, így a kereskedő a tiltakozásod ellenére is megkapja a pénzedet.

A bemenet aláírásakor annak a tartalma a csatlakoztatott kimenetre állítódik, így a tranzakció úgy váltható vissza, ha létrehozunk egy, az aláírás helyén csak nullákat tartalmazó scriptSig-et, aláírjuk, majd az egyik rekeszt beállítjuk az új aláírásunkra. Ezt a részleges tranzakciót aztán elküldhetjük a kereskedőhöz vagy a mediátorhoz a második aláírásért.

3. példa: biztosítási szerződések

A biztosítási szerződés egy lehetésges mód egy közjó létrehozásának finanszírozására. Közjó az, ami ha egyszer elkészült, úgy mindenkinek ingyen a rendelkezésére áll. Ennek klasszikus példája a világítótorony: mindenki egyetérthet ugyan abban, hogy hasznos, de túlságosan is drága a megépítése ahhoz, hogy bármely tengerész egymaga vállalkozzon rá – annál is inkább, hogy aztán azzal a vetélytársai is jól járnának.

Ezt a helyzetet tehát például úgy lehelet megoldani, ha mindenki hozzájárul valamennyi pénzzel a közjó létrehozásához oly módon, hogy a hozzájárulás csak akkor lesz érvényes, ha az összegyűlt hozzájárulások összege már meghaladja a létrehozás költségeit. Ha nem gyűlik össze elegendő hozzájárulás, akkor senkinek sem kell fizetnie semmit.

A Bitcoinban ezt a következőképpen modellezhetjük le:

1.) Egy vállalkozó létrehoz egy új címet, és bejelenti, hogy létrehoz egy meghatározott közjót, amint összegyűlik az ehhez szükséges 1.000 BTC. Bárki hozzájárulhat a gyűjtéshez.

2.) Mindenki, aki szeretne hozzájárulni, létrehoz egy új tranzakciót, amelyben befizet valamennyi érmét a bejelentett címre, viszont nem küldi szét azt a hálózatba. A hagyományos tranzakcióktól ez három pontban különbözik: először is, semmi nem változhat meg benne. Ha nincs megfelelő méretű kimeneted, úgy előbb létre kell hoznod egyet az egyik saját címedre való elköltéssel. Másodszor, a bemeneti szkript SIGHASH_ALL | SIGHASH_ANYONECANPAY-jel van aláírva. Végül, a kimeneti érték 1.000 BTC. Ez azonban így még nem egy érvényes tranzakció, mivel a kimeneti értéke nagyobb, mint a bemeneti.

3.) A tranzakciót feltöltik a vállalkozó szerverére, ami elmenti azt és frissíti vele az eddig felajánlott érmék összegét.

4.) Amint összegyűlik a megfelelő mennyiségű pénz, a szerver egy új tranzakcióban egyesíti az eddig különálló tranzakciókat. Ennek az új tranzakciónak csak egyetlen, az összegyűjtött összeget a bejelentett címre elküldő kimenete van – ez tehát megegyezik a felajánló-tranzakciók kimeneteivel -, a bemeneteit pedig a felajánlásokból gyűjti össze.

5.) A befejezett tranzakció elküldésre kerül, így a felajánlott érmék is megérkezhetnek a bejelentett címre.

Ez a módszer a többszörösen is kiaknázza a protokoll lehetőségeit. Először is ott vannak a felhasznált SIGHASH flag-ek. Alapbeállítás a SIGHASH_ALL, és annyit tesz, hogy a bemeneti szkriptek kivételével a tranzakció teljes tartalma alá van írva. A SIGHASH_ANYONECANPAY pedig annyit, hogy az aláírás csak a saját bemenetére vonatkozik, a többire nem, így azok bármilyenek lehetnek.

E két flag kombinálásával tehát egy olyan aláírást hozhatunk létre, ami további bemenetekkel való bővítés esetén is érvényes marad, viszont a tranzakció kimenetének vagy egyéb tulajdonságainak megváltoztatása esetén azonnal megtörik.

Másodszor ott van az a tény is, hogy nyilvánvaló okok miatt önmagában is, eleve érvénytelen minden olyan tranzakció, amelynek a kimeneti értékei meghaladják a bemenetieket. Így tehát teljes nyugalommal elküldhetjük a tranzakciót a vállalkozónak, mivel csak és kizárólag akkor férhet hozzá az abban foglalt pénzhez, ha más bemenetekkel együtt ki tudja egészíteni annak az összegét a megcélzott végösszegre, vagy annál is többre.

De létre lehet hozni biztosítási szerződéseket SIGHASH_ANYONECANPAY nélkül is. Alkalmazhatunk ehelyett egy kétlépcsős folyamatot, amelyben a felajánlásokat tranzakciók nélkül gyűjtjük össze, és ha összejött a megfelelő összeg, úgy körbeadunk a felajánlók között egy olyan tranzakciót, amelyben mindannyiuknak van egy-egy bemenet, és így mindenki aláírhatja a magáét. A SIGHASH_ANYONECANPAY használata és az azt követő egyesítés azonban vélhetőleg egyszerűbb ennél.

Létre lehet hozni egy hálózatbiztonságot finanszírozó biztosítási szerződést is. Ez esetben ahelyett, hogy mindenki egyetlen bejelentett címre ajánlaná fel a hozzájárulását, a vállalkozó egy sor különböző kimenetet tesz közzé, a vállalkozásban érintett valamennyi fél által aláírva. A vállalkozó egyben előkészít a kimenetek számával megegyező mennyiségű tranzakciót is, amelyek mindegyike egyetlen szerződés-kimenetet költ egy nulla értékű és nulla kimenetre, valamint tartalmaz egy OP_FALSE szkriptet is. Így a teljes érték díjként emésztődik fel. Mindegyik tranzakció záridejét N+M-re állítja, ahol N a szerződés érvényessé válásának előre meghatározott, blokkszámokban mért időpontja, M pedig a szerződés-kimenet indexe. Így egy sor olyan tranzakciót készíthetünk elő, ami semmi egyebet nem tesz azon túl, hogy adott ideig fokozottan ösztönzi a bányászatot.

Ezt a koncepciót Tabarrok fejti ki bővebben “Közjavak magánfinanszírozása domináns biztosítási szerződések útján” c. dolgozatában (“The private provision of public goods via dominant assurance contracts”). Domináns biztosítási szerződések sikertelensége esetén (ha nem jön össze elegendő összegű felajánlás a meghatározott időkereten belül) a vállalkozó egy bizonyos összegű díjat fizet az addig felajánlást tevőknek. Ez a fajta szerződés azt próbálja kimódolni, hogy mindenki számára a hozzájárulás legyen a helyes stratégia, és így erre is ösztönözze az embereket. Ennek a Bitcoinba való átültetését meghagyjuk az olvasónak szellemi gyakorlat gyanánt.

4. példa: külső adatok

Természetüknél fogva a szkriptek csupán funkciót. Nem léphetnek kapcsolatba külső szerverekkel és nem is importálhatnak semmi olyasmit, ami később esetleg változhat, mivel egy ilyen lehetőséget könnyen ki lehetne használni a blokklánc megtámadására. Azonban más módszerekkel is teremthetünk kapcsolatot a tranzakcióink és a külvilág között.

Vegyük például az öregember esetét, aki az unokájára kívánja hagyni a vagyonát vagy a saját halálát, vagy pedig az unoka 18. születésnapját követően – amelyikre előbb kerül sor.

Az öregember ezért elküldi előbb az örökség összegét saját magának, hogy legyen egyetlen kimenete a megfelelő összeggel. Ezt követően létrehoz egy, az unoka 18. születésnapjára időzített záridejű tranzakciót, ami az unoka kulcsára fizeti ki az összeget, aláírja, majd átadja neki, de nem küldi szét a hálózatba. Ezzel el is van intézve a 18. születésnap, mint feltétel. Ha eljön az idő, az unoka szétküldi a tranzakciót a hálózatba, és begyűjti az örökséget. Ugyan szétküldheti a tranzakciót már hamarabb is, de az időzár miatt így sem fog előbb hozzájutni a pénzhez, egyes csomópontok pedig akár el is utasíthatják a túl messzi időpontokra kódolt tranzakciókat.

A haláleseti öröklés már keményebb dió. Mivel a Bitcoin-csomópontok külső körülményeket nem tudnak figyelembe venni, ezért egy orákulumra kell hagyatkoznunk. Az orákulum egy egy saját kulcspárral rendelkező szerver, ami kérésre ír alá tranzakciókat a felhasználók által meghatározott értékek igazzá válása esetén. Íme egy példa. Az öregember létrehozza a kimenetét elköltő tranzakciót, és a következőképpen állítja be a kimenetet:

<unoka nyilvános kulcsa> CHECKSIGVERIFY <orákulum nyilvános kulcsa> CHECKSIGVERIFY <hash> OP_TRUE

Ez egy szokványos orákulum-szkript. Az aláírás ellenőrzését követően visszadobja az adatot a halomba, és nem használja fel. A nyilvános kulcs felkerült az orákulum weboldalára. A hash a halálára vonatkozó, általa megadott kifejezés hashe olyan “megfogalmazásba” lefordítva, amit az orákulum is tud kezelni. Lehet például a következő sztring hashe:

if (has_died(‘john smith’, born_on=1950/01/02)) return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;

Ez a megfogalmazási nyelv hipotetikus; a megfogalmazás módját az orákulum határozza meg, az bármiféle lehet. A return-érték pedig az unoka (egyik) címe.

Összefoglalva: az öregember létrehozza a tranzakcióját, de ahelyett, hogy szétküldené a hálózatba, átadja azt az unokájának. Emellett megadja a tranzakcióba hashelendő kifejezést, valamint az annak az igazolására jogosult orákulum nevét.

Az orákulum a következőképpen dolgozik:

1.) Fogadja a mérési kérelmet. Ez tartalmazza a felhasználó által megadott kifejezést, a kimeneti szkript másolatát és egy, a felhasználó által megadott részleges tranzakciót, amelyben csak a scriptSig nincs befejezve. Ez utóbbi ugyanis csak egy aláírást tartalmaz (az unokáét), ami pedig önmagában még nem elég a kimenet aktiválására.

2.) Az orákulum ellenőrzi, hogy a felhasználó által megadott kifejezés hashe valóban megegyezik-e a megadott kimeneti szkriptben szereplő értékkel. Ha nem, akkor hibát jelez.

3.) Az orákulum kiértékeli a kifejezést. Ha nem a kimenetben szereplő célcímet kapja eredményül, szintén hibát jelez.

4.) Ha mindent rendben talál, az orákulum aláírja a tranzakciót és beilleszti az aláírását a scriptSig-be. Jusson eszünkbe, hogy egy Bitcoin-tranzakció aláírásánál a bemeneti szkript a csatlakoztatott kimeneti szkriptre állítódik. Ez azért van, mert az OP_CHECKSIG futásakor az opkódot tartalmazó szkript az éppen kiértékelt bemenetbe kerül, _nem_ pedig a magát az aláírást tartalmazó szkriptbe. Az orákulum soha nem látta az általa aláírandó kimenet teljes egészét, de erre nincs is szüksége. Ismeri a kimeneti szkriptet, a saját nyilvános kulcsát és a felhasználó által megadott kifejezés hashét – és ez minden is, amire szüksége van a kimeneti szkript ellenőrzéséhez és a tranzakció véglegesítéséhez.

5.) Az orákulum tálalja a felhasználónak a frissen aláírt, elküldésre váró tranzakciót.

Az unoka tehát csakis akkor küldheti el a két tranzakciót (a szerződést és az örökséget) és veheti át az összeget, ha az orákulum is igazolja, hogy a nagyapja valóban meghalt.

Az orákulumnak nem kell megbízhatónak lennie. Soha nem látta az unoka által aktiválni kívánt tranzakciót, mivel az soha nem is került elküldésre, és így nem is zsarolhatja meg az unokát, mivel azt sem tudja, hogy létezik-e egyáltalán az a tranzakció, amit alá kell írnia. Lehet és érdemes is időről-időre automatikus ellenőrzésnek alávetni az orákulumot, hogy meggyőződhessünk róla, hogy valóban a megfelelő értékeket adja-e vissza mindig. Ehhez semmit nem kell elkölteni, mivel az ellenőrzés céljából létrehozott tranzakció lehet érvénytelen is (csatlakozhat pl. soha nem létezett tranzakciókhoz); az orákulum ugyanis sehogyan sem tudja kideríteni az aláírandó kérelmekről, vagy azok valódiak-e vagy sem. Ha n-of-m orákulumra van szükség, úgy CHECKSIGVERIFY helyett alkalmazhatunk CHECKMULTISIGVERIFY-t is.

Az orákulumok gyakorlatilag bármit kiértékelhetnek, és a blokklánc kimeneti szkriptje mégis ugyanaz maradhat. Vegyük csak például a következő lehetőségeket:

// Ha azt akarjuk feltételül szabni, hogy az árfolyam az adott napon a meghatározott két érték között legyen.
today() == 2011/09/25 && exchange_rate(mtgoxUSD) >= 12.5 && exchange_rate(mtgoxUSD) <= 13.5

// Fogadás olyasvalamire, amit e sorok szerzője soha nem fog ténylegesen elérni.
google_results_count(site:www.google.com/hostednews ‘Mike Hearn’ olympic gold medal) > 0

// Választás az Eurovíziós Dalfesztivál végeredményére fogadó felek közül.
if (eurovision_winner() == ‘Azerbaijan’)
return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD;
else
return return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;

Az orákulum aláírását meghatározó feltételek tetszés szerinti bonyolultságúak lehetnek, mivel a blokkláncnak semmiféleképpen sem kell egyetlen hashnél több adatot eltárolnia.

5. példa: láncokon átívelő kereskedelem

A Bitcoin technológiájával több, egymástól független pénzrendszer is létrehozható. Jó példa erre a Bitcointól kissé eltérő szabályokkal működő Namecoin, melynek segítségével neveket bérelhet ki magának az ember a névtérben. A Bitcoin alapelveire épülő pénzek szabadon adhatóak-vehetőek egymásért, bármiféle bizalomszükséglet nélkül. Képzeljünk el például egy olyan vállalatkonzorciumot, ami a saját bankszámlájuk tartalmához 1:1 arányban kapcsolt EURcoinokat bocsát ki. Egy ilyen pénz más tulajdonságokkal rendelkezne, mint a Bitcoin: centralizáltabb lenne ugyan, de valutakockázatoktól mentes. Egyesek esetleg szeretnének EURcoint venni Bitcoinért vagy fordítva – ebben a folyamatban pedig a vállalatkonzorciumnak csak a hagyományos bankrendszerrel való kapcsolódási ponton kell részt vennie.

Ezt a luxgladius által javasolt protokollal valósíthatjuk meg:

1.) Mindkét fél generál egy új kulcsot és egy véletlen adathalmazt (a titkot).

2.) B fél elküldi a titka hashét A-nak a nyilvános kulcsával együtt.

3.) A fél létrehozza Tx1-et (a fizetést) a lánckereskedelmi szkriptet magában foglaló kimenettel. Ezt a szkriptet és a megvitatását lásd lejjebb. Ez egyaránt lehetővé teszi a két kulccsal (A és B) vagy a két titokkal (A és B) való aláírás útján történő érmekiadást. Ez a tranzakció nem kerül elküldésre. A lánckiadási szkript csak a hasheket tartalmazza, nem magukat a tényleges titkokat.

4.) A fél létrehozza a Tx1-et elköltő Tx2-t (a szerződést) az A kulcsra visszavezető kimenettel. A záridőt egy tetszőleges jövőbeli időpontra állítja be, a bemenet sorszáma pedig nulla, hogy lehessen változtatni rajta. A aláírja Tx2-t és elküldi B-nek, aki szintén aláírja, majd visszaküldi azt. Alternatívaként egyszerűen meg is egyezhetnek arról, hogy hogyan nézzen ki a szerződés, pl. egyazon szoftver használatával, majd A egyszerűen elküldheti B-nek a Tx1 hashét, válaszként pedig megkapja az aláírást.

5.) A elküldi a Tx1-et és a Tx2-t. B most már látja az érméket, de még nem költheti el őket, mivel nincs hozzá vezető kimenet, és különben sem lett még véglegesítve a tranzakció.

6.) B ugyanennek a fordítottját végzi el az alternatív láncon. Így most az adásvétel mindkét fele folyamatban van ugyan, de még egyik sem teljes.

7.) A elküldi a titkát (véletlen adat) B-nek, aki aztán azzal újra kiadja az immár véglegesített szerződést A és B titokkal, valamint B kulccsal, és egy általa válaszott kimenettel. B így már átveheti az érméit, viszont ezzel együtt felfedte a titkát, így A is átveheti a sajátjait.

Mivel a protokoll nem igényel bizalmat, ezért érdemes lenne az ilyesfajta kereskedelmet teljesen P2P-alapon automatizálni a fokozott likviditás biztosítása érdekében.

A lánckereskedelmi szkript kinézhetne például így:

IF

2 <key A> <key B> 2 CHECKMULTISIGVERIFY

ELSE

<key B> CHECKSIGVERIFY SHA256 <A titok hashe> EQUALVERIFY <B titok hashe> EQUALVERIFY

ENDIF

A szerződés szkriptje kinézhet így is:

<sig A> <sig B> 1

meg így is:

<secret B> <secret a> <sig B> 0

Az első adatelem határozza meg, hogy melyik fázist használjuk.

6. példa: okos tulajdon

Lehetőség van arra is, hogy olyan fizikai dolgokat, mint például házakat, autókat vagy telefonokat is eladhatóvá vagy kölcsönözhetővé tegyünk a blokkláncon keresztül. Ennek a témának saját szócikkje van, itt olvashatsz róla bővebben.

Forrás: Bitcoin Wiki

A lap szövege Creative Commons Nevezd meg! – Ne add el! – Így add tovább! 3.0 licenc alatt áll, felhasználni csak forrásmegjelöléssel, és ide mutató linkkel szabad.