Bitcoin 2022 elleni támadási módok, a floridai Miamiban, április 6-9-én , a „A Bitcoin elleni támadások megelőzése” című panelt három Bitcoin Core fejlesztők: Luke Dashjr, Bryan Bishop és Jameson Lopp (Peter Todd helyett). A panelt Shinobi moderálta.
A panel résztvevői a technikai és társadalmi támadási vektorokról vitatkoznak, elsősorban a Bitcoin Core fejlesztési folyamata, amely akadályozhatja vagy teljesen kisiklathatja a Bitcoin megváltoztathatatlan pénzként való egyetlen küldetését. A támadási vektorok nyílt eszmefuttatásának célja a megfelelő védekezési intézkedések megfogalmazása, és Sun Tzu „A háború művészete” stratégiája szerint:
„Ne bízz abban, hogy az ellenség nem jön. Bízzon benne, hogy készen áll találkozni vele. Ne bízz abban, hogy az ellenség nem támad. Csak arra hagyatkozzon, hogy olyan helyet válasszon ki, amelyet az ellenség nem tud megtámadni.”
Az alábbiakban az említett panel összefoglalója található, amely egy gyors áttekintést nyújt a Bitcoin Core fejlesztési folyamatáról.
p>
Rövid Bitcoin Core áttekintés
ABitcoin Core fejlesztői dolgoznak egy fejlesztési folyamaton keresztül, amely a Bitcoin protokoll hibajavításait, szoftveroptimalizálását és továbbfejlesztett funkciókat kínálja; majd a közösség konszenzusát követően közzéteszik ezeket a frissítéseket a Bitcoin Improvement Proposals (BIP-ek) útján. A fejlesztési folyamat elleni támadás sikeres megtervezése, akár technikai, akár társadalmi szinten, potenciálisan akadályozná (néha kritikus) a protokollfrissítéseket, és bizalmatlanságot kelt a fejlesztők között.
Egyértelművé téve, hogy a Bitcoin Core egy ingyenes és nyílt forráskódú szoftveres implementáció a Bitcoin teljes verziójához. csomópont, amelyet ügyfélnek neveznek. Bár név szerint félrevezető, a Bitcoin Core nem rendelkezik központosított vagy „mag” ellenőrzéssel a Bitcoin hálózat felett, hanem csak egy lehetséges ügyfélként szolgál, amelyet az emberek szabadon használhatnak saját belátásuk szerint. Ezenkívül a Bitcoin protokoll konszenzusos szabályai megkövetelik, hogy minden bitcoin teljes csomópont és gazdasági szereplő feltétlenül betartsa ezeket a szabályokat egy blokk érvényességének mérlegelésekor.
Emellett a Bitcoin Core frissítései nem automatikusan, hanem manuálisan töltődnek le, mivel Az automatikus szoftverfrissítések támadási vektort biztosítanak egy huncut szereplőnek, hogy egyetlen mozdulattal kompromittálja az összes csomópontot és bányászt.
A Bitcoin Core fejlesztőcsapata nem állít egyetlen vezetőt vagy szóvivőt sem – így eltávolítja az ügyfelet és a bányászokat. fejlődési folyamat a személyes jellem-kizsákmányolásból eredő hibák miatt, amelyek minden földi vezetővel eredendően rendelkeznek. Például a nárcisztikus vezetők gyengülhetnek, ha nyugtalanságot keltenek a rajongótáborukon belül, vagy a szűkszavú vezetők irracionálisan viselkedhetnek, ha sértésekkel provokálják őket. Egy feltörekvő mozgalom megdöntéséhez ügyesen kell megszabadulni vezetőjétől, vagy meg kell törni a követőiket.
Mégis egyetlen vezető nélkül hogyan jutnak a független Bitcoin Core fejlesztők megegyezésre a bonyolult tervezési döntésekben vagy a vészhelyzeti hibajavításokban? A fent említett BIP-eket a Bitcoin Core fejlesztési folyamatában használják a funkciók vagy információk Bitcoin-protokollba való implementálására, de a BIP-ek az új ötletek kommunikációjának szabványosítására is szolgálnak, amint az alább vázlatosan látható és a BIP 2:
Hogyan lehet csavarkulcsot dobni ebbe a folyamatba? Annak ellenére, hogy a BIP 2-n keresztül bizonyos formalitásokat bevezetünk egy egyébként strukturálatlan hálózatba, lehetőség nyílik rosszindulatú vagy egyszerűen félrevezetett szereplők számára, hogy technikai és társadalmi eszközökkel felforgatják a fejlesztési folyamatot. Ennek a „csavarkulcsnak” a felismerése azonban gyakran csak utólag lehetséges – így bizonyos támadási vektorok különösen nehezen észlelhetők és elkerülhetők. Ha ki tudja kerülni a csavarkulcsot, kikerülhet egy deviáns fejlesztőt is, aki a Bitcoin rovására törekszik az öncélú napirendjére.
A gyakorlatban a tényleges BIP-megvalósítások nem olyan ügyesek, mint egy munkafolyamat-diagram és a a fenti magyarázatot lerövidítettük. Mindazonáltal elkezdhetünk olyan aljas módszerek elméleti kidolgozásában, amelyek felforgatják a decentralizált fejlesztési folyamatot.
Megjegyzés: A „konszenzus” egy kétértelmű szó, amely a Bitcoin szabályain túlmenően több különböző dologra utal. Jellemzően azt jelzik, hogy „alapvetően mindenki egyetért” egy döntéssel, míg a valóságban vannak pontosabb, egyértelműbb szavak, amelyek jobban meghatározzák a döntéssel kapcsolatos egyetértés különböző szintjeit, mint a „konszenzus” kifejezés. Az egyszerűség kedvéért ez a cikk a szinte egyhangú és általános egyetértésre hivatkozik, mint „konszenzus” elérésére.
Korábbi támadások a Bitcoin ellen
A Bitcoin-hálózatot 2009-ben telepítették számos kritikus hibák és hiányosságok, amelyek komoly technikai támadási vektorokat eredményezhettek volna, de a nyilvánosan ismert sebezhetőségeket már régen orvosolták. Általánosságban elmondható, hogy ezeket a hibákat és hiányosságokat nehéz megtalálni, mivel a kódban nincs semmi, ami feltűnően vagy fájdalmasan nyilvánvaló. A kódbázishoz önkéntesen hozzájáruló nyílt forráskódú fejlesztői közösség szakadatlanul dolgozott a protokoll fejlesztésén. integritása az elmúlt évtizedben, majd néhány. A múltbeli sebezhetőségek és megoldásaik megértésével éberek maradhatunk a jövőbeli hibák enyhítésében, és alapot biztosíthatunk a legrosszabb forgatókönyvek generálásához a lehetséges védekezési mechanizmusok felkutatásához.
Minden bizonnyal ez a legjelentősebb társadalmi támadás a Bitcoin közösség ellen. és a fejlesztési folyamat 2015-ben ment végbe, amikor két akkoriban köztiszteletben álló és veterán Bitcoin-fejlesztő,Gavin Andresen és Mike Hearn egy új, inkompatibilis Bitcoin-klienst hozott létre és hirdetett Bitcoin XT. A Bitcoin XT a blokkonkénti lehetséges tranzakciók számának növelését javasolta, amely blokkméretként ismert versenyeznek a hagyományos fizetési rendszerekkel, mint például a MasterCard vagy a Visa. A Bitcoin ezen inkompatibilis verziójának elfogadásával a felhasználók hatékonyanhardforkát vagy érvényes, korábban érvénytelen blokkokat és tranzakciók, amelyek végső soron mindenkit arra kényszerítenek, hogy hasonló módon frissítse ügyfeleit – különben kockáztatja a hálózati stabilitást és visszajátszási támadások.
A Bitcoin megalkotója, a névtelen Satoshi Nakamoto már régen kilépett távol a Bitcointól, amikor bejelentették ezt az ellentmondásos projektet, és a közösségnek kellett megfejteni Satoshi megjegyzéseit útmutatásért, mintha szent írások lennének. A Bitcoin XT-nek nem sikerült konszenzust elérnie, mivel naivan a maximális blokkméret növelését javasolta, és támogatói arra törekedtek aláássák a felhasználói konszenzustzárt ajtók, fejlesztő-bányász-vállalat összejátszásával. Anélkül, hogy belemennénk a hírhedt „tömbméretű háború minden apró részletébe, és egy a teljes könyvet, egyértelműen megfigyelhetjük az intenzívkét éven át tartó veszekedés a teljes csomópontok (felhasználók) kritikus funkcióinak végrehajtása érdekében. új szabályok a bányászok támogatása nélkül a felhasználó által aktivált softforkon (UASF) keresztül.
Ha a Bitcoin beleesett volna a nagy blokkcsapdába, a hálózat decentralizációja és a Bitcoin apolitikus jellege ennek megfelelően szenvedett volna. Ahhoz, hogy megértsük egy látszólag egyszerű változó megváltoztatásának következményeit, ami a blokkméret korlátja, nemcsak a kódbázis integritására gyakorolt technikai hatás megértését igényli, hanem rejtettkövetkezmények, amelyek további támadási vektorokat hívnak meg a születőben lévő hálózati ökoszisztéma ellen. Ezt a gondolatmenetet ki lehet terjeszteni a mai őszinte javaslatokra, amelyek szerint a Bitcoint a tétigazolás a munkaigazolás. Annak ellenére, hogy a blokkméret-háború megoldását technikailag az UASF-en keresztül oldották meg, a kialakult társadalmi dráma olyan nem technikai megoldásokat követelt meg, hogy egyszerűen szilárdan meg kell maradni, és nem szabad megmozdulni a káros szoftvermegvalósítástól, függetlenül a vállalati vagy híresség fejlesztői támogatásától.
Támadások BIP-aktiválási módszerrel
A Dashjr a Bitcoin Core fejlesztése elleni támadással küzd folyamat éppen tavaly történt: a „Speedy Trial” a régóta várt „Taproot aktiválási módszere softfork frissítés (BIP 343). A Speedy Trial logika úgy működik, hogy aktiválja a BIP-megvalósítást anélkül, hogy fennállna a nemkívánatos láncszakadás kockázata azáltal, hogy három hónapos időkereten belül gyorsan sikerül vagy gyorsan meghiúsul. Miután a Taproot felépítésére irányuló munka befejeződött, a fejlesztők nem tudtak általános egyetértésre jutni az aktiválási módszerrel kapcsolatban, és lényegében figyelmen kívül hagyták azt a döntő lépést, hogy először megérkezzen a kétségtelen közösségi konszenzus.
Bár a Taproot sikeresen aktiválódott, és az azt követő funkciók biztosítottak vitathatatlanul előnyösek voltak a felhasználók számára, aktiválási módszerét ellentmondásosnak tartották, és potenciális támadási vektorokat jelentett, miközben rossz prioritást adott a jövőbeni BIP-aktiválásoknak. A Speedy Trial aktiválási mechanizmust a Bitcoin Core fejlesztési folyamat elleni támadásnak tekintették, mivel egyes fejlesztők eltávolodtak a vélt közösségi konszenzustól, miközben megtagadták aBIP 8 mint aktiválási módszer, más néven „Lássuk, mi történik” javaslat a Taproot telepítésében.
A Speedy Trial módszer ellentétes volt a a blokkméretű háború kimenetele, ahol a viszály arra a következtetésre jutott, hogy a szinte egyhangú megállapodást koordináló felhasználóknak a hálózati konszenzus szabályait kell ellenőrizniük, nem a bányászokat. A Speedy Trial és a BIP 8 nélkül a döntés, hogy aktiválják-e (vagy nem aktiválják-e, ha nem jeleztek, amikor telepítették) teljes mértékben a bányászoktól függött, függetlenül a felhasználói konszenzustól. A vitathatatlanul vakmerő Speedy Trial bevetési módszer ellentmond a vélt közösségi konszenzusnak, és ennek a jövőbeni enyhítése érdekében potenciálisan szükség lenne egy UASF koordinációjára, amely elegendő életképes örökbefogadást biztosít néhány érintett személyen kívül a szoba sarkában ahhoz, hogy megakadályozza a határállomás aktiválását. p>
A „Preventing Attacks On Bitcoin” panel tagjai azt fontolgatták, hogyan értékeljék ezeket a történelmi támadásokat, és hogyan kerüljék el a hasonló támadásokat a jövőben. A Bitcoin XT-t vagy a Speedy Trial-t szorgalmazó „támadók” javaslataikkal nem biztos, hogy rosszindulatúak voltak, de módszereik nyilvánvalóan ellentmondanak bizonyos elveknek, amelyeket a közösség egy része határozottan véd – vagyis a felhasználóknak kizárólagos joguk van jóváhagyni, ill. megvétózza a konszenzusos szabályok módosítását. Utólag visszagondolva, a támadók egyszerűen nem követték ugyanazokat a Bitcoin elveit, mint a közösség, ami azt eredményezte, hogy ezek a támadások szubjektív értelmezési háborúvá váltak arról, hogy mi a „legjobb” a Bitcoin számára.
A fent említett Bitcoin XT és A Speedy Trial forgatókönyvek bemutatják azokat a módszereket, amelyek során a Bitcoin Core fejlesztési folyamata ellentmondásossá tehető, hangsúlyozva annak szükségességét, hogy minden BIP-megvalósítást óvatosan és átgondoltan kell megközelíteni. A következő szakaszokban a panel résztvevői további valószínű támadási vektorokat dolgoznak ki.
Bitcoin szoftverellenőrző támadások
Bishop érdekei a fejlesztési folyamatban a determinisztikus buildek és build aláírások, amelyek kihasználhatók bizonyos támadások megelőzésére. támadások a Bitcoin-felhasználók ellen, nevezetesen olyan támadások, amelyek megtévesztik a felhasználót, hogy elhiggyék, jóhiszemű Bitcoin Core klienst töltöttek le.
Aki Bitcoin-kliens felhasználója, annak le kell töltenie azt valahonnan a spamből.-hajtott internet. Ha a letöltött fájlt tároló weboldalt feltörik vagy lehallgatják a letöltés során, akkor lehet, hogy magát a fájlt rosszindulatúan módosították. Hogyan tudja a felhasználó bizonyítani, hogy az általa letöltött verzió valóban a tervezett Bitcoin-kliens?
A közös módszer anem tagadása, vagy az adatok integritásának és eredetének igazolása a/a>. A digitális aláírás, a hamisításbiztos viaszpecsét elektronikus és matematikailag hajlamos rokona, a legtöbb aszimmetrikus (nyilvános és privát) kulcsok, amelyek lehetővé teszik a hitelesítést két idegen között – de várjon! Ez nem garantálja az aláírás hitelességét. Végső soron az aláírás ellenőrzéséhez használt kulcsokba vetett bizalom nélküli hitelesítés értelmetlen, mivel a címzettnek meg kell bizonyosodnia arról, hogy az ellenőrző kulcs valóban a feladóé.
Ekkor van egy másik ravasz támadási vektor, ha maga az ellenőrző szoftver veszélyeztetett. Egy okos bûnözõ, aki azt állítja magáról, aki nem õ, de állítását digitális aláírással is igazolnia kell, a gyanútlan felhasználónak letöltheti a feltört kulcsellenõrzõ szoftvert, és ennek következtében hamis hitelesítési eredményt mutathat be. A feltört szoftver egy nagyon finom hibát tartalmaz, amely a kód gyors pillantásával arra készteti a felhasználót, hogy érveljen, az ellenőrző szoftver pontos eredményt adott.
Míg a determinisztikus buildek nem oldják meg a digitális aláírás birtoklásának hitelesítését , működik annak érdekében, hogy csökkentse az egyetlen forrásba vagy a felhasználó által letöltött szoftverbe vetett igényt. A determinisztikus építmények megvédik a szoftver implementációját néhány szélhámos fejlesztővel vagy egy kompromittált fejlesztői kulcsokkal szemben a fejlesztési folyamat során. Ez a védelem a szoftver kriptográfiai kivonataival érhető el, amelyeket a fejlesztők digitálisan aláírnak a szoftver felépítése során a felépítési folyamat lépése – hatékonyan biztosítja, hogy a végső szoftver bináris fájlok megegyezzenek a bináris fájlokkal amelyet a becsületes fejlesztők építettek, és ezért semmilyen formában vagy módon nem került veszélybe.
Összességében a determinisztikus buildekkel és build aláírással alapvetően nyomon követhető a szoftverbe vetett bizalom a binárisoktól a forráskódig. a különböző fejlesztők által végrehajtott git-commit, és azonosítja, hogy ki milyen változtatásokat vezetett be. A szoftver legitimitását ezután tovább lehet vizsgálni olyan technikák segítségével, mint amegbízhatósági web ahol a felhasználók dönthetnek arról, hogy az ellenőrzött kulcsok hitelesek-e vagy sem, és a tervezett Bitcoin klienst működtetik-e. Ezért a felhasználó a determinisztikus buildek és build-aláírások előnyeinek kihasználása nélkül számtalan támadási vektorra érzékeny.
Egy ilyen példa: ha a felhasználó letölt egy Bitcoin klienst aHTTPS helyett HTTP nyilvános Wi-Fi kapcsolattal, esetleg egy külföldi kávézóban vagy szállodában, miközben nem ellenőrzi a buildet aláírásával, akkor a támadók elfoghatják a felhasználó letöltési kapcsolatát, és lecserélhetik a letöltött fájlt a Bitcoin gonosz verziójára, amely érméket lophat, a felhasználók után kémkedhet, vagy más káros funkciókat hajthat végre.
Bishop úgy találja, hogy a „ fun” része a szoftverépítési folyamatnak a konzisztens fejlesztési környezeti változók fenntartása, amelyek a nem-determinizmus forrásainak kiküszöbölésére törekszenek. A nem determinisztikus források nemkívánatos eltéréseket eredményezhetnek a build aláírásában, mivel a fejlesztők természetesen nyitott környezetre építenek. A variabilitás, akárcsak az egyes fejlesztők eltérő operációs rendszerei, teljesen más hash-t generál a fejlesztési folyamat végén. Ideális esetben a változatosság minden forrásának eltávolítása az építési környezetből javítaná a determinisztikus építményeket, és ezt követően javulna az integritásukba vetett bizalom.
Bitcoinfejlesztés szándékos megcsontosodása
Lopp, belső Sun Tzu-ját irányítva, egy különösen ravasz módszert dolgoz ki a Bitcoin Core felosztására és manipulálására à la aljas fejlesztő(k) elégedetlenséget keltenek a közösségben és a GitHub adattáraiban. Ha egy köztiszteletben álló fejlesztő rendkívüli ingerültséget és haragot sugározna a protokoll bármely fejlesztése, javítása vagy módosítása iránt, akkor a növekvő általános konszenzus a protokoll érintésétől való félelem lesz. A fejlesztési folyamat ezen „lefagyása” csontosodás néven ismert, és gyakorlatilag folyamatos protokolljavítást jelentene. lehetetlen.
Talán a csontosodás elérése végső soron előnyös a protokoll számára, mivel ez a Bitcoin széles körben elterjedt, kialakult dominanciáját jelentené, Lopp azonban éppen az ellenkezőjét állítja, mivel a csontosodás egy kihasználható támadási vektor, nem pedig hatékony védekezés. Míg a csontosodás megvédi a Bitcoin-protokoll káros változásait, például a Bitcoin XT-t, megakadályozhatja a hasznos vagy szükséges frissítéseket, amelyek megnövelik a peer-to-peer adatvédelmet és a kódbázis erőteljesebb fejlesztéseit.
A Lopp által leírt támadási vektort rendkívül nehéz lenne a helyszínen felmérni, hogy a fejlesztési folyamatban zajló aktív konfrontáció a protokoll elleni támadás vagy jogos konstruktív nézeteltérés. Ez az előző pontról szól, ahol utólag visszagondolva a támadás utólag sokkal jobban látható. Az egyes fejlesztők valódi szándékának teljes mindentudása nélkül a fejlesztési folyamat egy szikla és egy kemény hely között rekedne.
A technikai támadások elleni védekezés, mint például a fent említett korai hibák és tévedések, viszonylag egyszerű, és logikus a megoldásukban. Az ingadozó, emberi elem bevezetésekor azonban veszélyes játékot kezdünk játszani, sokkal kevésbé kiszámítható. A társadalmilag megtervezett támadások gyakran homályos megoldásokat tartalmaznak, és valószínűleg azonnal kezelni kell őket. Egy célzott memetikus vagy mainstream narratív támadás teljesen feltűnő lehet, és az ellenük való védekezés meghatározása nagyrészt szürke terület.
A hadviselés a megtévesztés filozófiája. Vitathatatlanul a leglogikusabb támadási vektor a leendő ellenfelek számára a társadalmi elégedetlenség és mémháború szítása. Lopp kifejti, hogy a csontosodás szándékos kikényszerítése a tökéletes támadás, mert sok felhasználó védekezésnek tartaná.
Igazságügyi támadások a Bitcoin központi fejlesztői ellen
A Craig Wright, egy magánszemély, aki azt állítja magáról, hogy ő a névtelen Satoshi Nakamoto, és az ő kriptográfiai bohóckodások pluszA Bitcoin Core fejlesztőinek bírósági megfélemlítése a Bitcoin Core fejlesztési folyamata elleni közvetlen támadást jelenti. Annak ellenére, hogy egyre több bizonyíték van arra vonatkozóan, hogy Craig Wright nem Satoshi Nakamoto, folytatja a pusztítást azáltal, hogy több millió dollárnyi ügyvédi költséget halmozott fel, és gyakorlatilag túllicitálja a védelmet a csillagászati – pénzügyi és személyi – költségek miatt, amelyeket Craig Wright ró az önkéntes fejlesztőkre és közreműködőkre a Stratégiai perek a nyilvános részvétel ellen (SLAPP-perek). Emlékezzünk vissza az okos bûnözõre, aki azt állítja magáról, hogy nem õ, de digitális aláírással is igazolnia kell állítását; pontosan ez a forgatókönyv játszódott le de az aszimmetrikus kriptográfia elgondolatlan természete miatt nem volt hatékony az igazságszolgáltatási rendszer meggyőzésében.
Ennek következtében a Bitcoin Core fejlesztőinek névtelen hozzájárulási módszereket kell alkalmazniuk, különben fennáll annak a kockázata, hogy költséges és megterhelő peres eljárás célpontja lesz. Az anonimitás ezen módszerei végső soron az egyén adatvédelmi gyakorlatától függenek, például a Bitcoin 2022 és a konferenciák teljes elkerülése érdekében az anonimitás megőrzése érdekében. Ennek ellenére egy állítólagos névtelen személy elleni peres eljárás továbbra is lehetséges, ha van IRL név vagy személyazonosításra alkalmas az adott fejlesztő álnevéhez kötődő elem. A privát hozzájárulás szükségessége azonban önmagában is jelenlegi és jövőbeli teher a fejlesztők és családjaik számára.
Végül, ha ezek a Bitcoin Core közreműködői elleni jogi támadások továbbra is fennállnak, vagy Jack Dorsey A Bitcoin Legal Defense Fund kimerül, a fejlesztők kiszorulnak az űrből, és tovább fokozzák a protokollok csontosodását, mivel a véget nem érő peres eljárásokban való pénzégetés nem túl vonzó; „ezernyi haláleset”, ahogyan Shinobi ékesszólóan összefoglalta.
Jövő támadásai és szövődményei a Bitcoin fejlesztésében
Ha a Bitcoin túlélése és virágzása nem csak ebben a században várható, de sok évszázadon keresztül és így tovább, akkor óvatos lépéseket kell tenni a Bitcoin Core és a Bitcoin ökoszisztéma elleni várt és váratlan támadások elleni védekezési mechanizmusok kialakításában. Nem lehet több generációs vagyoneszközöd, ha az értéktelenné válik, mielőtt meghalsz.
Bár a panel résztvevőinek eltérő volt a véleménye arról, hogy a Bitcoin-felhasználók megtámadása egyenértékű-e a Bitcoin-protokoll támadásával, továbbra is léteznek vektorok. a felhasználók elleni támadások, például a fent említett csaló digitális aláírások és a folyamatban lévő Craig Wright jogi saga. Más vektorok közé tartozik a rossz pénztárcaépítési gyakorlat vagy a rosszindulatú mainstream narratívák, amelyek átmossák a felhasználók agyát, amelyek jelentősen károsak lehetnek a Bitcoin bizonyos alapelvei szempontjából.
A Bitcoin privát kulcsok kezelésében elért előrelépések ellenére, amelyet pénztárcák, továbbra is fennáll annak a lehetősége, hogy a rossz színészek szándékosan olyan pénztárcákat építsenek, amelyek nem követik a legújabb és nem ideálisbiztonsági gyakorlatok, amelyek a rendelkezésükre állnak. Például még mindig vannak olyan pénztárca-megvalósítások, amelyekegyetlen címet használnak a bitcoin küldésére és fogadására – így felfedve Bármely adatvédelmi felhasználó rendelkezhet.
Valamint, bár nem feltétlenül szándékosan, inkább korlátaiból adódóan, minden könnyű pénztárcának (amelyik nem is működik teljes csomópontként) csatlakozni kell egy teljes csomópont a tranzakciók kommunikálásához. A könnyű pénztárcák, amelyek különösen népszerűek az alkalmi felhasználók körében, az egyszerű, könnyen használható interfész kettősségét képviselik, ugyanakkor biztonsági hiányosságokat is mutatnak a támadási vektorok számára. E pénztárcák felhasználói hajlamosak arra, hogy tranzakciós kommunikációjukat potenciálisan aljas szereplők elfogják. Egy egyszerű – de egyesek számára nem praktikus – megoldás erre a vektorra az lenne, ha lemondanánk a könnyű pénztárcák használatáról a teljes csomóponti pénztárcák javára.
A Shinobi alternatív támadási vektorokat képzel el, amelyek a Bitcoin elleni sima dezinformációs kampányokból fakadnak, majd gyorsan átterjednek a kormány lobbitevékenysége jogi lépésekért és szigorú szabályozásokért. Az egyik ilyen nyilvánvaló félretájékoztatási kampány az az alaptalan elképzelés, hogy a tét bizonyítása a munka igazolásának életképes alternatívája. Ha minden joghatóság – elsősorban az olcsó és bőséges energiainfrastruktúrával rendelkezők – dominóhatásba kerülne a hatalomrabló kétségbeesés következtében, hogy megfékezzék a Bitcoint a bitcoinbányászat teljes kitiltása révén, amelyet talán az egyedülálló energiahálózati teljesítménymodulációk vizsgálata, amelyek képesek azonosítani a bitcoin bányásztornyokat, majd az összes meglévő hash-kikapcsolás áthelyezése-grid elég nagy kihívást jelentene.
A hálózaton kívüli energiamennyiség cseréje és beszerzése – különösen titokban – nem könnyű feladat. Például a napelemek és a szélturbinák túlságosan korlátozóak ahhoz, hogy egyenértékű helyettesítőként működjenek, és teljes mértékben vállalják a hálózaton kívüli bitcoinbányászatra való átállást a hálózaton belül, a nap-és szélenergia változó és időszakos energiatermelése miatt. Dashjr egy lehetséges megoldást javasolt azzal, hogy csak akkor tér el a jelenlegi munkabizonyítási szabványtól, ha a helyzet elég súlyos. Ha a blokkláncot valamilyen elképzelhetetlen politikai diktálás vagy a kivonatoló algoritmus (SHA256) állította le A biztonságos Bitcoin megszakadt, akkor lehetségessé válhat az összefogás a megoldás megtalálása érdekében, és ez a hálózat összes résztvevője számára előnyös lenne.
Ez a javaslat a munkabizonyítvány módosítására, ahogyan tudjuk, maga is egy eset.-pont a Bitcoin elleni váratlan támadásokra és az elkerülhetetlenül vitatott döntésekre, amelyek a Bitcoin Core fejlesztési folyamaton keresztül következnének ilyen szörnyű forgatókönyv esetén.
Folytatás a hipotetikus helyzetek útján, amelyek időigényesek-érzékeny BIP-megvalósítások esetén az elképzelhető legrosszabb forgatókönyv az lenne, ha az SHA256,RIPEMD-160 vagy ECDSA mechanizmusok kétségtelenül com megígérte – de még akkor is az a kérdés, hogy melyek lennének életképes alternatívák? Lopp azzal viccelődik, hogy egy kvantumbiztos algoritmus mindenkit boldoggá fog tenni, de ez a pofátlan válasz valószínűleg a távoli jövőben valamikor valósággá válik, és kellemetlen, kemény villás vitákat tesz szükségessé a gyakorlati védekezési mechanizmusokról a aszimmetrikus kriptográfiát kihasználó kvantumszámítás.
A Bitcoin apolitikus pénz és békés tiltakozás a hivatalban lévő és korrupt monetáris rezsim ellen. A Bitcoin ellenfél természetéből adódóan, azaz az amerikai dollár miatt valószínűleg technikai és társadalmi támadások szüntelen özöne fog bekövetkezni a Bitcoin ellen,ha még nincs folyamatban. Bishop a Bitcoin teljesen önkéntes közösségét, amely állhatatosan védi a Bitcoint készenlétben, egy saját fejlesztésű „immunrendszerhez” köti, amely a Bitcoin legnagyobb védekező és támadó mechanizmusa lehet.
Záró gondolatok
Összefoglalva: A Bitcoin semmiképpen sem legyőzhetetlen. Az összes lehetséges támadási vektor aktív mérlegelése és a megfelelő megoldások keresése nélkül a mindig várakozó ellenfelek gyengeségeket találhatnak a kódban vagy magában a közösségben. Whether the attack be from colluding parties, counterfeit Bitcoin software, deliberate ossification, targeted attacks through the judicial system or some unknown future disaster scenario, Bitcoiners must work together and unite to seal any gaps that could be the beginning of the end for Bitcoin.
The aim of this panel is not to instill in the audience doom nor gloom, but rather to prescribe a proper dose of reality with the very possible attacks Bitcoin development and the network could encounter moving forward. Ignoring this would be incredibly detrimental to the overall security of Bitcoin if we decide to live in blissful ignorance of these attack vectors. Should history have anything to teach us, it would be that all existing and previous monetary regimes — outside of Bitcoin — have succumbed to the fallibility of human institutions. Let’s work to not have Bitcoin experience a similar fate.
Humans are rationally driven by monetary incentives which has enabled the open source, pseudo anonymous, monetary nature of Bitcoin to harness a large, skilled group of hackers with opportunity for a reward of the scarce currency that is bitcoin. The discovery and exploitation of flaws that could compromise Bitcoin would paradoxically diminish the attacker’s newfound wealth — thereby, in theory, monetarily encouraging hackers to continually support the Bitcoin network and responsibly report bugs and exploits.
Despite discussions of ways to attack the Bitcoin Core development process and the wider ecosystem with little readily-available solutions of how to exactly ascertain and prevent these attacks, Bishop ended the panel with a poignant statement that spoke to the greatest incentive of all: money. He remarked, “Bitcoin is the greatest bug bounty program of all time … good luck.”
This is a guest post by Okada. Opinions expressed are entirely their own and do not necessarily reflect those of BTC, Inc. or Bitcoin Magazine.
