‘Selfish mining’ elv a gyakorlatban

A tegnapi cikk kapcsán előkerült a 51% attack és a double spending gyakorlati kérdésköre. Ennek kapcsán gondoltam edukációs célzattal bemutatom az egyik legismertebb módszer lényegét, amit anno 2013-ban még Emin Gun Sirer és Ittay Eyal publikált “Majority is not Enough: Bitcoin Mining is Vulnerable” címmel.

Nézzük az egész témát a gyakorlatban. Ugye így épülnek szépen sorjában a blokkok:

A blokkokat különböző minerek/poolok hozzák létre, majd egyszer csak az egyik pool úgy dönt, hogy double spendelni akar. Ekkor az egyik pool úgy dönt, hogy végrehajt egy 51% attackot. Ehhez persze nem árt, ha az összes hashing power jóval több mint 50%-ával rendelkeznek, de szigorúan matematikai alapon erre úgy egyébként 33,3% is elég, ha a difficulty adjustment nem azonnal reagálja le a fő láncon történő hash elvonódást.

A “Selfish miner” (pirossal jelölt blokkok) elkezd gyártani egy blokkot (piros #1-es), miközben a többi miner gyárt egy blokkot az eredeti #0-ás után. A Selfish miner blokkja persze hamarabb készül el, hiszen több hashing powerrel rendelkezik. Ennek okán a selfish miner lánca lenne a hosszabb lánc, ami miatt a kék #1-es el sem készülhetne, azonban:

A Selfish miner NEM propagálja a blokkot, hanem megtartja azt magának. Így az összes többi miner valójában azt hiszi, hogy az eredeti (kék) lánc a leghosszabb.

Ezt követően a Selfish miner elkészít még egy blokkot (piros #2), mire a többi bányász is propagálja az elkészült (kék #1) blokkját. Itt a támadó már pontosan tudja, hogy olyan mennyiségű hashing power van a kezében, amivel stabilan meg tudja csinálni a támadást. Ekkor:

A támadó előveszi a meglévő – a támadásra félrerakott – coinjait és a főláncon beküldi azt az egyik tőzsdére, majd a továbbra is rejtve bányászott láncon (piros) ugyanazt elküldi egy másik tőzsdére. A rejtett (piros) láncról továbbra sem tud senki a Selfish mineren kívül, mivel ezek a blokkok nem kerülnek propagálásra a hálózat felé!

Ezen a ponton a Selfish minernek tovább kell gyártania a blokkokat a piros láncon, míg a főláncon (kék) megvárja, hogy megtörténjen a 20 confirmation, amíg az exchange elkölthetővé teszi a beküldött coinokat. Amikor ez megtörténik, akkor azonnal eladja a coinokat és az ellenértéket valamilyen gyorsan kiküldhető formában, lehetőleg privacy coinok (zcash, monero, stb.) formájában kimenti a tőzsdéről. Megvárja, amíg a kiküldés is confirmálódik, majd fogja magát és elkezdi szépen lassan propagálni a piros lánc blokkjait:

A propagálás végére a nodeok azt fogják látni, hogy megjelent egy újabb lánc, ami sokkal hosszabb, tehát ezt követően mindenki dropolja az eredeti kék láncot és folytatják a felfedett selfish miner által gyártott láncot. Amint a második láncot elkezdik folytatni a rendes bányászok is valójában nem csak, hogy megtörténik ugyanannak a coin mennyiségnek az elküldése egy másik exchangere (xchg#2), de egyből meg is kapja a 20 confirmation-t, tehát azonnal el is költhető lesz a másik láncon és másik exchangen ugyanaz a coin, ami alig néhány blokkal korábban egyszer már elköltöttek a korábbi (kék) láncon. Természetesen ezt a támadó azonnal el is költi/átváltja.

Hogy ki járt rosszul az egésszel? Természetesen az első exchange (XCHG#1), hiszen a longest chainen valójában meg sem történt az az esemény, amikor beküldésre került hozzá egy adat coin és mégis el lett adva az. Tehát összességében  olyan coinokat adott el, ami valójában sosem kerül az exchangere. Itt nyilván az exchange a lehető leggyorsabban megpróbálja értesíteni a fejlesztőcsapatot és a többi exchanget is. Ám ennek reakcióideje akár extrém hosszú is lehet, így szinte biztos, hogy a támadó minden gond nélkül véghez tudja vinni a támadást és az eladásokat, hiszen valójában a második exchange (XCHG#2) jogosan birtokolta az eladásra került coinokat, mivel az ő általa ismert leghosszabb chainen tényleg hozzá kerültek a coinok.

Persze az exchangek több módon is próbálkoznak védekezni ezen támadás ellen. Pl többször is elfordult már, hogy ha egy kriptopénzből hirtelen tűnik el nagy mennyiségű hashing power, akkor az adott algo összes coinjánál felemelik a confirmation-t. Legutóbb pont a héten bekövetkezett zencash támadásnál emelték fel a tőzsdék 20-ról 120-ra a minimum confirmationt. Hogy mit érnek el ezzel? Nyilván időt nyernek, mely idő alatt esetleg ki tudják hámozni, hogy melyik addressen történt double spending, ehhez persze nagyon hatékony együttműködés szükséges az exchangek között, ami centralizált exchangek esetén még talán létezhet is, de az egyre inkább erősödő decentralizált exchange és atomic swap megoldások tükrében ezen támadások valószínűsége sokkal inkább fog növekedni.

Hogy mi erre a megoldás és ‘ha ennyire bugos, akkor egyáltalán miért nem javítják meg…’ típusú kérdésekre az egyezményes válasz: Nem minden arany ami fénylik. Aki minority hash powerrel rendelkező crypto-t bányászik vagy akár csak tart az legyen felkészülve arra, hogy ilyen támadások bármikor bekövetkezhetnek. Aki pedig szeretné magát ettől megóvni, annak:

  • csak majority hash powerrel bányászott PoW coinokat használj. (Bitcoin, Ethereum, LTC, Zcash, Monero, stb.)
  • vagy használj olyan altcoinokat, amikben a konszenzus egyéb módon (pl. PoS, DPoS) van elérve és van is mögötte akkora mennyiségű validity stake, ami alapján feltételezhető, hogy mindenki tisztességes.

 

 

Cseperedő hazai Bitcoin (mainnet) Lightning Network konglomerátum

Napról napra egyre több hozzám hasonló vakmerő (#reckless) őrült dönt úgy, hogy a deszkamodell LN implementációkra idejét és vagyonát rábízva vág bele az éles tesztelésbe. Legjobb tudomásom szerint nem kevesebb mint négy hazai lightning network node üzemel már. Ebből biztosan kettő lnd (Lightning Lab) és egy c-lightning (Blockstream), a negyedikről (COINMINER.SPACE) nincs implementáció-információm. A csatornák kapcsán igen vadnyugati módszerekkel biztosítunk folyamatos likviditást, de ezek ellenére sem tudunk komolyabb fennakadásokról eddig (egyedül Krisznek sikerült egyszer valami nagyon fura állapotba hoznia egy csatornát, ami miatt néhány óra kellett, mire újra visszakapta a pénze feletti kontrollt).

Az egész hálózat egyébként igen komoly ütemben növekedik. Ma már átlépte az összes csatornában lockolt vagyon mennyisége a 3BTC-t és a 200 aktív node határ átlépése kapcsán is.

Bár én a magam részéről továbbra sem javaslom, hogy bárki is mainneten funoljon, de ha valaki olthatatlan vágyat érez erre, az a következő connection stringgel tud kapcsolódni az ln.variance.hu hub-hoz:

033abe908878ac00c1e916face972331b3a6e3ba4e587c95efec3c76e3ee339c82@34.242.65.85:9735e

Néhány praktikus tanács azoknak akiknek vakmerősködni támad kedvük:

  • Az elmúlt napokban drasztikusan esett a mempool terheltsége, ezt azonban még nem tudták lekövetni a fee estimation algoritmusok. Éppen ezért erősen javaslom az openchannel és a closechannel parancsoknál (lnd impl) a –sat_per_byte paraméter kézi beállítását. Nekem enélkül 30k sat körül akar miner fee-t fizetni, kézzel beállítva pedig 2400 sat (19 sat/b) körül boldogan nyitja/zárja a csatornákat max 2-3 blokkon belül.
  • A nagy csomópontok igen terheltek. Eleve nincs sok értelme ezekhez kapcsolódni, ha már 30-an vannak oda kapcsolódva. Ezt külön alátámasztja, hogy nekem pl rendszeresen kerülnek a nagy hubos csatornáim false státuszba a kapcsolatok lebontása miatt. Ha false statusban lévő csatornát akarsz lebontani (close channel), akkor előbb mindképp kapcsolódj újra (connect), ellenkező esetben végig kell várnod a forced close penality-t.
  • A c-lightning implementáció esetén (feltehetően biztonsági okokból) alapértelmezetten a base_fee értéke 546.000 sat. Ennek megfelelően az ilyen csatornákon kb sosem fog routeolódni semmi, ráadásul ez a basefee a saját vásárlásaidhoz is hozzáadódna, ergo amíg ezt nem állítod át, addig nem nagyon fogsz tudni tranzaktálni. Eddigi visszajelzések alapján ezt az értéket csak parancssori beállítással lehet átállítani a c-lightning implementációban.
  • Nem úgy az lnd-ben, ahol könnyedén tudod átállítani a következő paranccsal: (itt az alapértelmezett base_fee 1000 sat, amit szintén érdemes mérsékelni)
    lncli updatechanpolicy –base_fee_msat 1 –fee_rate 0.000001  –time_lock_delta 144 ch_point

Eddig a tech rovat… Akkor, most térjünk át a konspirációs rovatra… Fura konstellációt vélnek sokan felfedezni a mempool terhelétségének csökkenése és a Lightning Network mainnet megjelenése között.

Persze nem feltétlenül érdemes démonokat kergetni, nyilvánvalóan azért történt itt más is a Lightning Network megjelenése mellett. Pl alig egy hónap alatt megfeleződött az egy érmére jutó Bitcoin árfolyam, ami minden bizonnyal sokaknál beindította a HODL faktort. Az alacsony árak ellenére inkább pihennek a Bitcoin érmék a cold walletekben, mintsem hogy pörögnének a tőzsdéken. Ezen feltételezésnek persze ellentmond az a tény, hogy a tőzsdék összesített napi volumenadataiban ezen visszaesésnek nyoma sincs. A decemberi átlag 15 milliárd dolláros napi forgalomról igaz visszacsorogtunk 10-11 milliárdra az elmúlt néhány napban, de vegyük figyelembe, hogy mindezen idő alatt az árfolyam is megfeleződött, tehát a fajlagos hálózati terhelésben ennek nem kellene megnyugvásként megjelennie.

Folytatás…

Békaemberek támadása a BCash ellen!

Kezd körvonalazódni, hogy mi is folyik a BCash block generálási drámája körül. Papírforma szerint csak az első 6 blockot kellett volna kiszenvednie a ViaBTC-nek és a BTC.com-nak ahhoz, hogy életbe lépjen az automatikusan 20%-os difficulty adjustment. Ez azonban nem tudott megtörténni, mert valaki jófejségből és saját bevallása alapján “just for fun” levillantott akkora számítási kapacitást ami megfelel a BTC hálózat 8%-ának. Ezzel a lendülettel ez a bizonyos idegen ki is bányászott 9 blockot, majd úgy döntött, hogy ebből elég is volt. Azóta állítólag visszatér a bitcoin mainnetre bányászni.

Az ügy pikantériája, hogy ezzel sikeresen megakadályozta a BCC hálózat automatikus hashing power nehézség finomhangolását. Jelen esetben ráadásul a ‘békaemberünk’, egymagában képviseli a BCC hálózat hashing powerének több mint 51%-át, tehát a titokzatos ‘jótevő’, az eddig kiállított 9 blockjában akár nyugodtan tudott double spendingelni. (ez természetesen csak egy lehetőség, semmi bizonyítés nincs arra, hogy a Honkongi illetékességű bányász rosszhiszemű lenne) Tekintettel arra, hogy jelenleg egy 2016 blockos difficulty period totális közepén vagyunk, és mivel a ‘jótevő’ megakadályozta a difficulty adjustmentet, így a legközelebbi adjustment (a jelenlegi sebességet figyelembe véve), nagyjából 6 hónap múlva lesz esedékes, hacsak nem tereli át a teljes hashing power készletét a teljes kínai bányász konglomeráció. Ha ezt esetleg mégis megtenné, azzal kivégzik a bitcoint, hiszen a BCash-sel ellentétben a bitcoin hálózatán valós ügyletek is folynak, nem csak dumpolgatják le a vagyont.

(Apró megjegyzés: Nem vagyok teljesen tisztában a bitcoin hashing power kalkulációs mechanizmusával. Nem szeretnék szükségtelen para helyzetet kelteni, de mindenesetre, az gyanús, hogy kerek fél napja egyetlen block sem készült el. Ha a fentebbi ‘idegen’ valóban csak jóhiszeműen funnolt be bányászni BCH-ba és a ViaBTC továbbra is csökkenti a hasing powerét a BCH hálózatba, amihez senki nem csatlakozik, akkor is legalább egy hét mire el tud kezdődni újra bármilyen adjustment.)

Szép kilátások…