Er VERGE fast? Eller hvordan man hacker VERGE igen og får kun mere end $ 2M USD med CPU.

Ansvarsfraskrivelse: Et groft udkast til denne artikel blev skrevet lige efter, at det andet angreb på Verge-netværket er blevet udført, og i løbet af hele denne tid er jeg i tvivl om at offentliggøre den. Men da problemet beskrevet i denne artikel i stigende grad begyndte at blive rejst offentligt, besluttede jeg endelig at offentliggøre det, kun tilføje nogle opdaterede oplysninger og bringe dem til den læsbare form.

Opd. 06/06/18: Verge-teamet kom hurtigt i kontakt med mig for at informere om, at de arbejder på at flytte til den nye codebase, og de problemer, der er beskrevet i artiklen, er blevet overvejet og helt sikkert vil blive løst. Håber, at det bliver frigivet ASAP.

Introduktion

Sidste to måneder var Verge blevet et emne for meget opmærksomhed fra mange medlemmer af cryptocurrency-samfundet. Dog og desværre er det forårsaget af nogle besværlige begivenheder - Verge-netværket er blevet angrebet mere end én gang i intervaller på mindre end to måneder. Så hvad skete der, og hvordan er det, at en cryptocurrency, der er i Top 50 med 24 timers handelsvolumen (ca. 10 mio. $), Er blevet angrebet to gange og næsten identisk? Og det vigtigste spørgsmål, om Verge-udviklerne beskyttede deres netværk og løste problemet, eller et tredje angreb er stadig muligt?

Tidslinje

Lad os gå gennem de vigtigste tidsstempler og gendanne kronologien over angrebene på Verge.

Det første angreb er blevet registreret den 4. april. Omstændighederne ved dette angreb er velkendte og tilstrækkeligt detaljerede i mange kilder (først og fremmest på Bitcointalk forum af ocminer, ejeren af ​​Suprnova pool). Attacker var i stand til at miner en enorm mængde blokke inden for en kort periode ved at udnytte en række sårbarheder i Verge-kode. Blokke blev udvindet med intervaller på kun et sekund pr. Blok, sammen med det, vanskeligheden ved hver blok var så minimal som muligt.

Der var faktisk to angreb. Det første angreb startede ved blok 2.007.364, og det lignede mere som et prøvekørsel, da det blev afbrudt i blok 2.009.911, og derefter blev angriberen stadig fortsat med at udnytte blokke, men uden udnyttelse. Naturligvis sluttede andre minearbejdere sig med det samme, og vanskelighederne blev hurtigt øget. Men angrebet er fortsat med at starte igen fra blok 2.011.409, og denne gang varede det meget længere, indtil blok 2.026.085.

Et samlet beløb på mere end 26 millioner XVG-mønter blev udvundet af angriberen, og til deres nuværende pris fra skrivningen af ​​dette var det over $ 1 mio. USD.

Verge-udviklere reagerede på dette angreb med kaotiske forsøg på hurtigt at løse problemet, men det forårsagede en utilsigtet gaffel af kæden.

https://github.com/Vergecurrency/Verge/commit/7294e062a61f78ffb05689b562f90985463d1179https://github.com/Vergecurrency/Verge/commit/b6c380727ebe285538b9e5ac330176d9e8983f87

Her skal vi tage en side og påpege, at Verge bruger en multi-algo PoW. Dens minecyklusser gennemgår algoritmerne Scrypt, Lyra2Rev2, Blake2s, Groestl og X17. Ved design skulle en multi-algoritme PoW garantere decentraliseringen af ​​blockchain og undgå en monopolisering af en mønt ved minepooler og derved reducere muligheden for at udføre 51% -angrebet betydeligt.

Der er dog ingen kontrol i kantkoden, der tvinger brugen af ​​alle de 5 algoritmer. Desuden kan en og samme algo anvendes, og angriberen udnyttede derfor denne fejl for at gøre et angreb meget lettere.

I deres næste løsning lukkede Verge-udviklere denne kritiske sårbarhed ved at sætte grænsen for en maksimal mængde blokke, der er udvindet med den samme algoritme, til 6 blokke.

https://github.com/Vergecurrency/Verge/commit/80c81aef63272231fc39c2af4b8db9f3f2e9d328

For øvrig er grænseværdien faktisk ikke 5, som den er defineret i SAME_ALGO_MAX_COUNT konstant, men 6, da kontrollen starter fra en tidligere blok og ignorerer den aktuelle. Svært at sige, hvis det er en forsætlig opførsel, men alligevel er det ikke så kritisk.

Mere vigtigt er, at denne løsning, selvom den er ganske vigtig, ikke løser overhovedet årsagen til angrebsspørgsmålet.

Med det næste trin er ClockDrift-konstanten vendt tilbage til dens oprindelige værdi, sandsynligvis med det formål at løse problemet med en kædegaffel.

https://github.com/Vergecurrency/Verge/commit/2b6faff66ecfd8b9361aa5db14ffa5019b784f4f

På trods af al denne tvetydighed i denne parameter såvel som kaotiske forsøg på at justere den, var beslutningen om at vende tilbage til den oprindelige værdi dødelig sammen med det faktum, at grundlæggende sag om angrebsspørgsmålet ikke blev bestemt. Inden for mindre end to måneder blev angrebet gentaget igen.

Den 22. maj ved blok 2.155.843 begyndte det andet angreb og fortsatte indtil blok 2.205.870 i løbet af en 5 timers varighed. Dette angreb var meget mere forberedt og omfattende, i hvilket et beløb på 50.000 blokke og 36,5 millioner XVG-mønter blev udvindet. Det var over $ 1,5 mio. USD til den aktuelle pris og næsten $ 2 mio. USD på angrebsøjeblikket.

Det er bemærkelsesværdigt, at dette angreb var næsten identisk med det foregående, med den eneste forskel - i stedet for en algoritme (Scrypt) brugte angriberen to (Scrypt og Lyra2Rev2) algoritmer og roterede dem en efter en. Således gjorde den sidste løsning netop angrebet lidt mere kompliceret, men alligevel fikste den ikke grunden.

Denne gang indledte udviklere en planlagt hard gaffel af kæden i blok 2.158.500 for at begrænse en ClockDrift-værdi til 10 minutter.

https://github.com/Vergecurrency/Verge/commit/f8ca082646f9d98f5856e341097807ba06268464

Som udviklerne erklærede, er fejlen rettet, og netværket er ikke mere sårbart. Men er det sandt? Lad os se…

Sværhedsindstilling i Verge

En lille smule teori nu.

Verge er en PoW-mønt, der bruger DGW-vanskeligheder med at retargete algoritmer. Hvad er DGW?

DGW (Dark Gravity Wave) blev for første gang annonceret i 2014 af den vigtigste Dash-udvikler Evan Duffield, og det blev erklæret som en forbedret version af KGW (Kimoto Gravity Well) algoritme. I konceptet ligner DGW det samme som KGW, og justerer vanskelighedsniveauerne hver blok ved hjælp af statistiske data for de sidst fundne blokke. På denne måde kan blokudstedelsestider forblive konsistente på trods af store udsving i hashpower. Ifølge udvikleren bruger “DGW flere eksponentielle glidende gennemsnit og et simpelt glidende gennemsnit for at justere vanskeligheden jævnt. Denne implementering er langt mere forenklet og bedre egnet til at justere vanskeligheder end KGW og løser også alle kendte udnyttelser. ”

Grundlæggende kan DGW-formlen repræsenteres som:

hvor:
Dnext - påkrævet næste mål
Dk - vanskeligheder ved forrige k-blok
Tk - tidsstempel for sidste k-blok
N - blokering
n - forbi blokke tæller (12 i Verge, 24 i Dash)

I det første trin beregnes den gennemsnitlige vanskelighed for de sidste 12 blokke, derefter på det andet trin multipliceres det med andelen af ​​en faktisk tidsperiode (som er begrænset af minimal værdi for måltidspan / 3 og maksimal værdi af måltidstid * 3 ) og måltid.

Implementeringen af ​​denne algoritme i Verge er næsten den samme som den originale. Der er en forskel i mængden af ​​tidligere blokke, og minealgoritmen i den aktuelle blok overvejer også.

DGW-algoritme erklæres som modstandsdygtig over for tidsvarpeangreb. Desværre er en sådan påstand nu blevet modbevist om dette angreb.

Starten

Lad os se på starten af ​​angrebet.
Det blev startet fra to blokke, 2.155.843 og 2.155.844.
Vi bør tage et særligt kig på tidsstemplerne for disse blokke.

Som vi kan se, går en blok «til fremtiden» i 90 minutter.

Intervallet på 90 minutter er ikke tilfældigt.

I Verge er blocktime for hver algoritme 150 sekunder. Når vanskeligheder er at målrette igen, tages 12 sidste blokke i betragtning, og værdien af ​​måltid er således lig med:

90 minutter er de samme som 5400 sekunder, hvilket igen svarer til måltidstid * 3. Hvis vi kigger ovenfor, ved beskrivelsen af ​​DGW, kan vi se, at denne nøjagtige værdi er den øvre grænse for den aktuelle tidsvarverdi, og at nøjagtigt interval forårsager et højst vanskelighedsfald. Derudover overstiger denne værdi ikke ClockDrift-værdien, der er indstillet til 2 timer.

Lad os se på de næste tidsstempler.

Det er let at bemærke en række sekvenser, som gentager hver 11 blokke, og kan betinget beskrives som:

hvor B = A + 5400, og hvor hver næste værdi af A og B øges med en.

Denne sekvens er påkrævet for at videregive kontrollen for MTP (Median Time Past). Denne check sammenligner en median af de sidste 11 blokke med en aktuel tidsstempel. Det er vigtigt, at tidsstempel for gruppe B aldrig vælges som median, når man sammenligner med det aktuelle tidsstempel i gruppe A (naturligvis er A mindre end B, og kontrollen vil mislykkes). Men det er med en sådan rækkefølge, at en stak af tidsstempler af de sidste 11 blokke altid indeholder mere end 6 tidsstempler i gruppe A, således at medianen altid er en tidsstempel fra gruppe A.

Lad os se på grafen over tidsstempler og medianer af de første 400 blokke siden angrebets begyndelse:

Som vi kan se, på trods af udsving på op til 5400 sekunder, overskrider blokering af tidsstempel aldrig værdien af ​​median timepast.

(Nogle små huller og afbrydelser er sandsynligvis årsagen til test og justering af nogle parametre af angriberen. Opfølgningsændringen af ​​tidsstemplets rækkefølge peger også på det. Det ser ud til, at angriberen matchede de bedste parametre direkte i processen med minedrift.)

Det bemærkes, at de forskellige sekvenser bruges på forskellige tidspunkter. En sådan sekvens er således blevet brugt under det første angreb:

Og det er ændret til enkleste (og hurtigste) under det andet angreb, der starter fra blok 2.156.223:

Men det samme resultat opnås altid.

Graf over tidsstempler og medianer for

Lad os vende tilbage til intervallet mellem tidsstempler for A- og B-grupper. Som det er nævnt ovenfor, forårsager et interval på 5400 sekunder et højst fald i vanskeligheden.

Logaritmisk sværhedsgrad

Selvom dette interval ikke blev set på hvert trin, og vanskelighederne med jævne mellemrum søges til den højeste værdi (hvilket er forårsaget af den negative værdi af Timespan), er den laveste vanskelighed nået ved blok 1467 indtil videre bare i 75 betingede minutter for Lyra2Rev2-algoritmen og ved blok 1785 på 77 minutter for Scrypt-algoritme.

Opfølgningsblokkene blev udvindet med den samme tidsstempel-sekvens, men allerede på den laveste vanskelighed med nogle små udsving.

Hvad angår den tvungne rotation af algoritmer, brugte angriberen en ganske enkel løsning. Justeringen blev foretaget fra den første blok, det vil sige algoritmenes rækkefølge var sådan, indtil blok 2.155.560:

Den næste sekvens er ganske åbenlyst - en maksimal mængde blokke for den samme algoritme følger bare hinanden:

Det centrale problem

Det er åbenlyst, at den tvungne ændring af mining-algoritmer slet ikke løser problemet for angrebet. Så årsagen ligger i vanskelighederne med at målrette algoritmen? Og enhver mønt, der bruger denne algoritme, kan blive et offer for det samme angreb? Ikke så let!

Bestemt er DGW uforenelig med deklarerede specifikationer, da det ikke beskytter mod et tidsvarpeangreb. Det er et ret alvorligt problem, men stadig er dette ikke den eneste nøgle til det succesrige angreb.

Lad os vende tilbage til nogle teorier for at forstå grundårsagen.

Lad os forestille os en situation. Der er to betingede dele af verden, der i fællesskab mines Bitcoin. Men pludselig, uanset af hvilken grund, fjerner den første del forbindelsen til det offentlige netværk, mister forbindelsen med den anden del, og begge bliver isoleret fra hinanden. Som et resultat har hver del af verden nu sin egen gaffel af kæden. Efter nogen tid opretter den første del forbindelse til det offentlige netværk og bliver tilgængelig. Knudepunkterne begynder at synkronisere, og konflikten mellem kæderne opstår. Begge disse kæder er naturligvis gyldige og opfylder konsensusreglerne. Så hvordan løses denne konflikt?

I de meget tidlige versioner af Bitcoin blev en sådan konflikt løst gennem en sammenligning af højden på kæder. Netværket skifter til den kæde, der har den højeste højde, og den anden kæde er markeret som en gaffel, og alle dens blokke bliver forældreløse. Det er helt åbenlyst, at denne metode er meget usikker, sårbar og let at udnyttes uretfærdigt.

Pludselig efter at have fundet problemet blev den nye procedure til valg af den bedste kæde udviklet. Det bruger et såkaldt Chainwork - en værdi, der svarer til summen af ​​hashværker for alle blokke i kæden. Således er den bedste kæde nu en kæde, der har det højeste samlede hasharbejde, uanset dens højde. Denne metode, som den mest korrekte og sikre, accepteres som standard og bruges i alle PoW-netværk.

I 2012 blev der udviklet en mønt med et særpræg i den nye type opnåelse af konsensus. Dets navn er Peercoin og den nye type kaldes Proof-of-Stake.

I Proof-of-Stake-baserede netværk vælges skaberen af ​​den næste blok via forskellige kombinationer af tilfældig markering og rigdom eller alder (dvs. indsatsen), og i modsætning til PoW-mønter er de mere energieffektive.

Som en løsning på problemet med at vælge den bedste kæde blev ChainTrust-parameteren implementeret, som også indeholder summen af ​​vanskeligheder for alle blokke i kæden, men her betyder vanskeligheden ikke mængden af ​​hasharbejde, skønt den tænder på grundlaget for et udtryk, hvor en blokfalser lagrer mønterne i aktiv fase for at modtage stavbelønning.

Verge blev startet til at blive udviklet i 2014, og en af ​​kodebaser, der blev brugt som basis, er Peercoin. Trods Verge er erklæret som PoW-mønt, har det et integreret PoS-system, selvom det er deaktiveret i øjeblikket.

Men der er en virkelig vigtig ting, som udviklere ikke har overvejet, mens de portede en Peercoin-kodebase. Selv hvis PoS er deaktiveret i dette øjeblik, anvendes PoS-proceduren til valg af den bedste kæde, så kæder sammenlignes med deres ChainTrust-værdier.

https://github.com/Vergecurrency/Verge/blob/f8ca082646f9d98f5856e341097807ba06268464/src/main.cpp#L1973https://github.com/Vergecurrency/Verge/blob/f8ca082646f9d98f5856e341097807ba06268464/src/main.cpp#L2145https://github.com/Vergecurrency/Verge/blob/f8ca082646f9d98f5856e341097807ba06268464/src/main.h#L1389

Det store problem er, at Verge er en fuld PoW-mønt, og ChainTrust-parameteren er meningsløs. I Verge-implementeringen svarer ChainTrust kun til højden-1, da BlockTrust-værdien for hver blok altid indstiller til 1! Derfor er den bedste kæde altid kæden med den højeste højde!

Og dette er et hovedproblem i Verge-netværket!

Ingen anden PoW-mønt med ChainWork-check kan påvirkes af denne form for angreb.

Hvis vi antager, at den nuværende netværksvanskelighed kun er 250 (BTW Verge-netværksvanskelighed for hver algoritme er ti gange højere nu), skal vi kun afbryde mere end 1.000.000 blokke med den laveste gruppe, der er udtjent med denne vanskelighed mulig vanskelighed!

Ja, problem med tidskrængning er stadig det vigtige problem, da det giver mulighed for at tjene mere end 100x fortjeneste, selv hvis kædearbejde beregnes. Men så skal en angriberen stadig konkurrere med den samlede hashhastighed for netværket, så dette ville være et rent 51% angreb.

Men fraværet af Chainwork-kontrol er nøjagtigt det, der gjorde angrebet på Verge så stor og let at blive gennemført.

Er det et angreb på 51%?

Nej, dette er ikke 51% angreb.
I det mindste kræver det ikke at have sådan magt.

Det skal forstås, at alle tidsstemplerne i de blokke, der er udvindt af angriberen, er falske og falske og er totalt ikke forbundet med den reelle tid for opdagelse af blok. Da der ikke er nogen tidsbegrænsning, når en gaffel kunne imødekommes, kan en angriberen mine sin private gaffel, så længe det er nødvendigt. Med andre ord er det ikke nødvendigt at have en magt, der kan sammenlignes med det samlede hashrat i netværket for at finde de første blokke i bloktidsperiode, når vanskeligheden stadig er stor. Hvis en angriber kun har 10% af netværket, betyder det, at en blok udvindes ikke om 150 sekunder i gennemsnit, men om 1500 sekunder. Og ved at have en fordel ved at udnytte sårbarhed overfor tidsvarp og derfor have mere end to uger til rådighed (for 50.000 blokke), tillader det at have 1% af det samlede netværks hashrat til at finde en lille mængde blokke med stor vanskelighed på kort tid .

Derefter skal en angriber bare forbinde sin node til det offentlige netværk og begynde at se, hvordan alle noder skifter til den nye ondsindede kæde.

Men det, der er interessant, er, at angriberen endda ikke forsøgte at skjule kæden og havde nok strøm til at starte angrebet i realtid.

Og det er meget muligt, at de første blokke oprindeligt blev udvindet med en vis forsinkelse, derfor blev de markeret som forældreløse af andre minearbejdere. Men angriberen fortsatte med at udnytte sin kæde, og da vanskeligheden var faldende, blev hastigheden for minedrift markant øget, kæden blev længere, derfor blev den valgt som den bedste.

Og i dette var angriberen ikke ligeglad med en anden minearbejdere, der kunne konkurrere i blokminedrift med så lave vanskeligheder, og det er ganske let at forklare hvorfor. Der er begge sårbarheder, der gjorde det muligt at ignorere andre minearbejdere - også muligheden for et tidsvarpeangreb og fraværet af kædeledskontrol.

Naturligvis forsøgte ærlige minearbejdere at oprette forbindelse til kæden og fortsætte med at mines, men med hver nye temmelig udvindede blok voksede vanskeligheden, derfor blev blokeringstiden også stigende, og efter et stykke tid blev kæden mindre længere end angriberen kæde, der fortsatte med at have en laveste vanskelighed. Efter at have modtaget en ny del af blokke, der blev udtjent af angriberen, koblede en minedrift poolen af ​​sin kortere kæde og begyndte at mines fra det nye punkt, og denne proces blev gentaget gang på gang og producerede mange forældreløse blokke, der blev udvindet af bassinerne.

Dette ville naturligvis ikke være muligt, hvis kæderarbejdscheck er integreret. Bare en lille mængde af ret udvindede blokke ville have et kæde, der er større end hundreder og tusinder af blokke, der er udvindt af angriberen, så alle disse blokke ville blive forældreløse, og angrebet ville blive afbrudt.

Så når alt kommer til alt er Verge stadig sårbar eller ikke?

Ja! Og det er ekstremt nemt at hacke det igen!

Lad os se på nogle få måder, hvordan det kunne laves.

CPU-minedrift (undskyld ven, du er sent)

Faktisk den nemmeste måde at hacke Verge igen bliver utilgængelig for næsten en uge siden. Men det skal stadig beskrives.

Så vi har en mulighed for at starte minedrift af vores private kæde fra enhver blok i Verge-blockchain (indtil det sidste kontrolpunkt).

Så lad os drage fordel af det, der blev gjort før af den forrige angriber, og tage for eksempel en blok 2.158.500. Det er bare en tilfældig blok i området af udvindede blokke under det andet angreb. Dets vanskelighed er mindst, ligesom dens forgængere har. Alt, hvad vi har brug for nu, er bare at starte en CPU-mining fra denne blok og gentage den samme sekvens, der blev brugt under det sidste angreb. Derfor når vi hårdgaffelblokken temmelig hurtigt, hvor ClockDrift-værdien, der er indstillet til 10 minutter, og ikke tillader os at fortsætte den aktuelle sekvens af tidsstempler (da 600 sek er mindre end en minimal værdi af den faktiske tidsperiode, der kræves for at sænke vanskeligheden).

Hvis vi ikke kan fortsætte med at udnytte blokke med lave vanskeligheder på den høje hastighed, kan vi stadig prøve at bare gemme den nuværende laveste vanskelighed. Vi er allerede foran den offentlige kæde, så vi har en ledetid for et spillerum.

Baseret på beskrivelsen af ​​DGW er det indlysende, at andelen af ​​faktisk tid og måltid skal være lig med eller være mere end 1 for at gemme den mindste vanskelighed.

En konvolutberegning viser, at vi har brug for intervallet på 164 sekunder.

Eftersom de blokke, der er udvindet med forskellige algoritmer, ikke overlapper hinanden, kan de smedes på samme tid.

Men for at gøre det har vi brug for en rækkefølge sådan:

Så vi er nødt til at justere det ved hjælp af den næste rækkefølge:

Og det er alt! På trods af at vores kæde er meget langsommere end den offentlige kæde (2 blokke på 164 sekunder i stedet for 5 blok på 150 sekunder), har vi stadig en tid opnået i resultatet af muligheden for at udføre tidsvarpeangrebet indtil den hårde gaffelblok.

Den mulige bivirkning af dette angreb er en ret lang synkronisering og langsom proces med at skifte til den nye kæde, da alle forældreløse blokke skal kobles fra og transaktioner skal returneres til hukommelsespuljen.

Konsekvenserne af dette angreb er faktisk meget fatale, da hele den ugentlige historie med blockchain ville blive omskrevet i modsætning til tidligere angreb, hvor de fleste af udvindede blokke var helt nye.

Men alligevel, på tidspunktet for offentliggørelsen af ​​denne artikel, er tiden forbi, og sidste chance for at udføre dette angreb var omkring midnat den 31. maj.

Men lad os tilføje endnu en algoritme.

Det er umuligt at udføre angrebet beskrevet ovenfor, men vi kan stadig tilføje en tredje algoritme i sekvensen og sænke dens vanskelighed. Som nævnt ovenfor, for at nå den laveste vanskelighed så hurtigt som muligt, skal den næste betingelse være opfyldt:

Det er let at opnå det ved at indstille tidsintervallet til 491 sekunder:

Så nu er vi bare nødt til at indsætte de ekstra blokke med den tredje algoritme til vores rækkefølge og overholde intervallet på 491 sekunder.

Logaritmisk sværhedsgrad

Som vi kan se, sænkes vanskeligheden meget hurtigt, og kun 70–100 blokke er tilstrækkelige til at nå den laveste værdi.

Nu har vi mere føringstid, indtil kæderne ikke er lige høje, men stadig sker det kritiske punkt i morgen (den 6. juni) omkring kl. 06:00 UTC.

Faktisk kræver dette angreb stadig ikke at have egne rigge, en lejet magt kunne bruges, når tidspunktet for vanskelig blokering var kommet, og CPU-mining er stadig kan bruges resten af ​​tiden.

Vi har flere algoritmer, lad os tilføje en anden.

Det er det samme som tidligere, forskellen er, at det kritiske punkt opstår den 25. juni, så der er en stor risiko for dette angreb.

Og til sidst bruges alle algoritmer.

Da den gennemsnitlige reelle blokeringstid er inden for intervallet 33–35 sekunder, og blokeringstiden i den private kæde er 33 sekunder, er det en meget lille chance for, at den offentlige kæde kan blive længere end den private kæde. Så der er ingen grænser for, hvornår angrebet kan udføres.

Dobbelt forbrug angreb

Alle angribende vektorer beskrevet ovenfor kunne suppleres med dobbelt forbrugsangreb, da alle blokke, der er berørt af angrebet, vil blive "omskrevet". Så vi kan stadig med vilje inkludere / ekskludere nogle transaktioner.

Desuden, da det er nok bare at gå foran den offentlige kæde, kan angreb med dobbelt forbrug udføres på ethvert sted af blockchain (indtil checkpoint), og det er stadig nok at kun bruge to af mine-algoritmerne.

Konklusion

Randen er ekstremt sårbar, og der kræves øjeblikkelige rettelser!

Hvad skal rettes først:

1) Som bare en hurtig “fix”, tilføjelse af et checkpoint på hard-fork-blokken, så vil de første 4 angrebsmetoder blive irrelevante.
2) En hårdgaffel med implementering af Chainwork-check.
3) Skift til en mere sikker vanskelighedsjusteringsalgoritme, som ikke er sårbar over for tidsvarpeangreb. Faktisk er det lige nok at bruge MTP i stedet for rene bloktidsstempler, når man beregner den faktiske tidsperiode.
4) Til sidst skal du lade uret glide værdien tilbage.

Bare et par ting, der er de grundlæggende principper i ethvert blockchain-netværk, er nødvendige for at sikre netværkets sikkerhed. Indtil det er risikoen for et nyt angreb ekstremt høj, og virkningen vil være meget alvorlig end den var ved to tidligere angreb.

LINC-ligevægt

Vi, LINC-team, tager vores ansvar for at beskytte vores netværk og for at sikre blockchains integritet meget alvorligt. Derfor er vores mål og den nuværende hovedopgave en implementering af Aequilibrium-konceptet, der er forpligtet til at reducere muligheden for at udføre 51% -angrebet og alle de relevante angreb betydeligt.

Vi arbejder stadig på forbedring og justering, men nu er vi klar til at præsentere dens vejledende principper:

- Verifikation af minearbejdere. En forfalskning kan indgive en anmodning til validatoren og / eller styringssystemet om at blive en bekræftet forfalskning. Derfor, under visse tekniske betingelser og for en vellykket afstemning gennem det decentraliserede regeringssystem, kunne en falske tilføjes hvidlisten og undgå nogle begrænsninger og sanktioner i minedrift.

- Samme forfalskningsstraf sammen med det foregående punkt udelukker næsten muligheden for at udnytte den private kæde med intention om at erstatte den offentlige. Derudover tvinger det mineressourcerne til at blive jævnt fordelt mellem forskellige puljer, hvorved man undgår en koncentration af en enorm mængde hasjkraft i en pulje.

- Da LINC også bruger den samme algo som Dash og Verge (DGW), planlægges det at skifte til en anden algoritme med vanskelighedssignal. Vi overvejer stadig og tester nogle af open source-algoritmer samt arbejder på vores egne løsninger.

Hvis du ikke allerede har gjort det, tilmeld dig vores community i Discord, hvor du får opdateringer om projektets udvikling.

Bob,
LINC Executive