Azonnali utalás Bitcoinnal harmadik felek nélkül

Szerző: Joannes Vermorel

A Bitcoin egy kriptopénz (bevezető gondolatok az előző posztomban), amely bár számos előnyös tulajdonsággal rendelkezik (így például decentralizált, nagyon alacsonyak a tranzakciós díjai, eleve digitális, stb.), a fizetések azonnali lebonyolítása legalábbis eledig nem tartozott kifejezetten az erényei közé. Igen feltűnő például, hogy e probléma orvoslására már egy külön, bizalmas harmadik felet is létrehoztak.

Jelen posztban tehát egy olyan konvenciót próbálok felvázolni, amely lehetőséget biztosítana az (1) azonnali, (2) biztonságos és (3) decentralizált tranzakció-lebonyolításra (4) a Bitcoin saját rendszerében.

Elöször is tisztázzuk jelen állítás pontjait:

1.) Azonnali. A valós idő a neten nem értelmezhető, mivel annál még a fénysebesség is lassabb. Jelen esetben az azonnali szót úgy értem, hogy 10 másodperc alatt, ami már bőven elfogadható időtartam lenne a hétköznapi pénzhasználati alkalmak elsöprő többségéhez, ide értve az egyszerű, hagyományos, fizikai bolti vásárlást is.

2.) Biztonságos. Bár a Bitcoin pillanatok alatt el tud terjeszteni egy tranzakciót a hálózatában, biztonságossá (vagyis a többszörös elköltés minden lehetőségét kizáróvá) az csak akkor válik, ha már a blokkláncba is bekerült; a hivatalos kliens alapbeállítás szerint legkevesebb 6 blokknyi megerősítést követel meg. Értelemszerűen ez a követelmény valamelyest ütközik az előzővel, mivel 6 blokk nagyjából 1 órát jelent, tekintve a Bitcoin rendszerének átlagosan 10 perces blokkonkénti célsebességét.

3.) Decentralizált. Régen rossz, ha már csak egy bizalmas harmadik fél közbeiktatásával tudjuk összebékíteni egymással az 1.) és a 2.) pontot. Nincs ugyan semmi bajom a BitInstanttal, de ha ugyanezt meg tudjuk oldani közvetítők nélkül is, akkor azt hiszem, azzal csak még erősebbé tesszük a Bitcoint.

4.) Bitcoin. Olyan megoldás kell tehát, amely a mai formájában őrzi meg a Bitcoin protokollját és nem kötelezi frissítésre a közösséget – kivéve annak azon tagjait, akik szeretnék kihasználni az azonnali fizetés lehetőségét. Egy olyan Bitcoin-használati konvencióról beszélek tehát, ami a jelenlegi protokoll-specifikációhoz illeszkedik. Így akik nem akarják követni a konvenciót, azok nyugodtan és biztonságosan figyelmen kívül hagyhatják az egészet.

Ezen a ponton ildomosnak tartom megjegyezni, hogy nem vagyok sem kriptográfus, sem pedig biztonsátechnikai szakértő, hanem csak egyszerűen egy lelkes Bitcoin-felhasználó.

Felvetésem arra az alapötletre épül, mely szerint érdemes lenne csavarnunk egyet a biztonság fogalmán: ahelyett, hogy a többszörös elköltés szigorú és minden körülmények között való megakadályozására törekednénk, tegyük inkább még sokkal drágábbá azt annál, mint amennyit nyerni lehetne általa. Ha ugyanis meghagyjuk ugyan a többszörös elköltés lehetőségét, viszont még sokkal költségesebbé tesszük azt (bitcoinok tekintetében is), akkor onnantól kezdve egyszerűen nem lesz többé érdemes ténylegesen és széleskörűen alkalmazni ezt a trükköt az azonnali fizetéseknél. Ezzel a csavarral ugyan elfogadjuk tehát a többszörös elköltések lehetőségét, de csak azért, mert azt bármilyen támadó csak rendkívül rossz hatásfokkal alkalmazhatná. Nem gátol meg tehát egy kellőképpen őrült támadót abban, hogy valamennyi kárt okozzon ily módon, de ezek a károk világviszonylatban így is jelentéktelenek maradnának (elvégre vannak sokkal hatékonyabb módjai is a rombolásnak, ha valaki hajlandó pénzt áldozni erre).

Az 1.), 2.), 3.) és 4.) pontokat összebékítő konvenció két összetevőt kombinál:

* egy bizonyíthatóan drága Bitcoin-címet; ennek a beállítási költsége legyen X BTC.

* egy olyan ellenőrző-mechanizmust, amely garantálja, hogy egyetlen többszörös elköltéses támadást sem hajtottak végre a múltban erről a címről (blokklánc).

Bár a szokványos Bitcoin-címek lényegében ingyenesek (a legenerálásukhoz szükséges árammennyiség elhanyagolható), mégsem nehéz előállítani egy bizonyíthatóan költséges címet. Ennek a legegyszerűbb módja a monetáris rombolás, egy /null-t célzó tranzakció útján. Azonban az érmepusztítás nem teljesen kielégítő.

AX cím értékének bizonyítására tehát egy egyetlen, 1A címből kiinduló (csak 1 bemenetes) tranzakciót javaslok, amely konvenció szerint 10 olyan egymást követő blokk coinbase címe (*) között osztja el az értékét, amelyek (a bizonyítás pillanatában) nem régebbiek 1 hónapnál.

(*) Ez a blokk első tranzakciójának a címe; ezt maga a bányász használja, ezen fogadja a blokk legenerálásáért járó jutalmát.

Nem hagyatkozhatunk tehát csak önmagában a tranzakciós díjra a cím költségének bizonyításánál, mivel egy bányász könnyen létrehozhat egy fiktív, magas díjas tranzakciót egy blokkban – fiktív abban az értelemben, hogy a díj neki semmibe nem kerülne, mivel a blokk tulajdonosaként azonnal vissza is kapná azt.

Ha azonban 10 egymást követő blokkot célzunk meg, úgy már egyetlen bányász sem jutalmazhatja meg kizárólagosan önmagát a tranzakcióval. Elvégre a blokkgenerálás végső soron egyfajta lottóhúzásként is felfogható, amelynél a nyerési esélyek a résztvevők rendelkezésére álló számítókapacitástól függenek. Egy “okos” bányász így legfeljebb egy (**) saját blokkját célozhatja meg, 10%-kal mérsékelve a költségeit a minta megtörése nélkül, de még így is kénytelen lesz számolni a maradék 90%-kal.

(**) Egy kellően fajsúlyos bányásztársulás, például a deepbit még akár ennél több saját blokkot is megcélozhatna, de mivel a Bitcoin rendszerének amúgyis a teljes bányászkapacitás több mint felének egy kézben való összpontosulása jelenti a sarkalatos pontját, így itt abból az alapfeltevésből indulok ki, hogy senki sem mondhat magáénak a rendelkezésre álló teljes számítókapacitás egy töredékénél többet.

Az egy hónapos korhatár-korlátozás egyetlen célja annak a biztosítása, hogy az érmék ne menjenek veszendőbe. Mivel a megcélzott címek gazdája további utalásokra már nem számít azután, hogy egyszer már kiürítette őket, így a későbbiekben már talán még csak nem is tartja szemmel őket, de a beérkező plusz összeget, amit a puszta szerencse folytán éppen ő kap meg, azért még így is észre fogja venni.

További érv a coinbase címek megcélzása mellett, hogy ez is plusz ösztönzést jelent a bányászok számára, tovább erősítve így a Bitcoin rendszerének teljes egészét.

Az itt vázolt konvenció útján tehát máris van egy lehetőségünk annak a bizonyítására, hogy egy adott Bitcoin-cím létrehozása legalább X BTC-be került a gazdájának. Meg kell bizonyosodnunk azonban még arról is, hogy valóban nem is követett el többszörös elköltéseket erről a címről.

Ennek kapcsán tehát abból indulunk ki, hogy azonnali fizetés esetén (blokkhitelesítés nélkül) nem előzhetjük meg ugyan a többszörös elköltést, viszont felfedhetjük azt utólag, teljesen lerombolva így a bizonyíthatóan költségesen létrehozott címbe vetett bizalmat.

Lássunk egy példát. Legyen Alice a tisztességes kereskedő, aki elfogad azonnali bitcoinos fizetéseket, Bob pedig a rosszfiú, aki többszörös elköltéssel akar próbálkozni ellene.

Bob a tranzakció pillanatában megadja Alice-nek a Tx1 tranzakció tartalmát, amelynek 1B a bemenete (Bob bizonyítottan költséges címe) és 1A (Alice címe) a kimenete. Ezzel egyidőben azonban Bob elindít még egy Tx2 tranzakciót is, amivel kiüríti az 1B címet. Ennek eredményeképp Alice egy idő után azt láthatja, hogy a Tx1 tranzakciót elutasította a rendszer.

Most Alice-en a sor: visszavág azzal, hogy felfedi Bobot. Teszi pedig ezt oly módon, hogy létrehoz magának egy kis “technikai” tranzakciót, amelybe az OP_DROPra alapozott konvenció útján rekurzívan beágyazza adatként a Tx1 tranzakciót. (***) Amint ily módon felfedte a Tx1 tranzakciót, a közösség hozzá (Alice-hez) hasonló, azonnali fizetéseket szintén elfogadó tagjai máris láthatják, hogy az 1B cím nem megbízható, mivel az abból kiinduló Tx2-es tranzakció valamint az imént felfedett, a blokkláncba azonban soha be nem került Tx1 tranzakció összesítése nyomán az 1B címen jegyzett érmék értéke már negatívba fut.

(***) Hogy tömören tartsuk a dolgokat, a rekurzív beágyazás részleteibe itt most nem megyek bele. Tudomásom szerint azonban ez az eljárás minden további nélkül kivitelezhető.

Ezen a ponton van tehát egy olyan rendszerünk, amelyben Bob, a rosszfiú nem árthat anélkül Alice-nek, a kereskedőnek (a címzettnek), hogy ezzel ne járna maga is rosszul. Mi történik azonban akkor, ha Alice, a kereskedő a rosszfiú (“rosszlány”), Bob pedig tisztességes vásárló? Árthat-e Alice Bobnak pusztán azért, hogy bomlassza a közösséget azáltal, hogy lerombolja a Bob bizonyíthatóan költséges 1B címébe fektetett bizalmat?

Kell még tehát egy olyan végső mozzanat is ebbe a konvencióba, amely megvédi Bobot, az érmék küldőjét Alice hamis vádaskodásaitól. Ennek érdekében Bobnak gondoskodnia kell róla, hogy a bizonyíthatóan költséges B1 címéről indított valamennyi Tx1 tranzakcióját valóban szét is küldje a hálózatba, és ne csak Alice-nek adja oda. Bob ily módon biztosíthatja a Tx1 tranzakció bekerülését a blokkláncba és meggátolhatja Alice-t az 1B cím besározásában (ha Bob még inkább biztosra akar menni, felajánlhat valamennyi tranzakciós díjat is a Tx1 tranzakcióhoz annak érdekében, hogy az a lehető leggyorsabban bekerüljön a blokkláncba).

A konvenció megvalósítása

Tudomásom szerint ehhez semmiféle igazán átütő módosításra nem lesz szükség. Ideális esetben elég mindössze három plusz funkciót beépíteni a hivatalos kliensbe (vagy egy kifejezetten erre tervezett másik változatba):

* a BTC-költés lehetőségét egy bizonyos Bitcoin-cím megbízhatóságának fokozására;

* a “költséges” Bitcoin-címen keresztüli tranzakciók azonnali lebonyolítását;

* a cím “költségének” jelentését a beérkező tranzakcióknál.

Vannak persze még olyan további csiszolandó részletek, mint az a késlekedés, amit az okoz, amíg a közösség eldönti egy adott bejelentés nyomán, hogy egy cím valóban megbízhatatlanná vált-e. És persze bizonyára lehet teljes egészében is tovább csiszolni még a konvenciót.

Névtelen fizetések

Persze e konvenció nyomán a Bitcoin a jelenleginél egy kissé kevésbé névtelenné válna. Az azonnali fizetések lehetséges alkalmazási területeinek palettáját tekintve azonban (számomra legalábbis) ez nem tűnik túl nagy problémának. Ha valóban névtelen akarsz maradni, akkor valószínűleg úgyse nagyon fogsz csak úgy beugrani egy boltba. E-kereskedelem esetén pedig az egy órás fizetési várakozási idő általában amúgy sem jelent gondot (kivéve legfeljebb a pizza-házhozszállítás esetét).

Gyakorlati alkalmazás

Azonnali fizetésre leginkább csak apróságok vásárlásánál van szükség: nagy összegeket általában nem kell gyorsan elutalnod. Vagy-vagy. Azt pedig már magának a kereskedőnek kell eldöntenie, hogy azonnal elfogad-e vagy sem egy bizonyított Y címről érkező X BTC-s fizetést.

Az ésszerűség azt diktálja, hogy legfeljebb akkora összegű fizetéseket fogadjunk el azonnal egy bizonyított címről, mint amekkora annak a költsége volt – vagyis egy 10 BTC-s címről legfeljebb 10 BTC-t (vagy egy kicsit kevesebbet, tekintve az önjutalmazó bányász esetét). A valóban többszöri (tehát három vagy több alkalommal való) elköltések koordinálása a gyakorlatban már rendkívül bonyolult (bár nem lehetetlen), de komolyan kétlem, hogy bárki is vállalkozna egy ilyen komplikált terv végrehajtására bármilyen egyéb céllal azon túl, hogy egyszerűen bizonyítsa, hogy az igenis kivitelezhető. A tétek pedig amúgyis erősen korlátozottak lennének, mivel a nagyobb összegű tranzakciók továbbra is a hagyományos, nem-azonnali csatornán keresztül kerülnének lebonyolításra.

Emellett pedig az egyazon címről egyre több tisztességes tranzakció lebonyolításával a visszatérő vásárlók is folyamatosan növelhetnék a megbízhatóságukat (a kereskedő szemszögéből) azonnali fizetéselfogadás terén a bizonyíték-értékük növelése nélkül is.

Érzésem szerint a bizonyíthatóan költséges cím heti rendszerességű vásárlások esetén kevesebb, mint egy éven belül leamortizálódna (a BitInstant 2%-os közvetítői díjából kiindulva, ahhoz viszonyítva). Ettől azonban nagy valószínűséggel még mindig megfontolásra érdemes ez az opció – főleg, ha figyelembe vesszük a bányászatra gyakorolt pozitív hatását is.

Forrás: Joannes Vermorel’s blog

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.