Network Attack on XVG / VERGE

[phm87]

nice a new version of the famed timewarp attack.. very interesting.

yep.. we pushed a quick fix and most pools have already updated.. we're already working on a whole new block verification process.

we're kinda glad this happened and that it wasn't as bad as it could have been.

Hmm, you guys are aware that the "fix" you pushed actually IS a hardfork ? So your blockchain snapshot is not valid anymore, the wallet's won't sync up from scratch anymore and the current chain is simply not usable anymore with that new "fix" ?

Your change simply disagrees with the attackers blocks, the first block I see from the attacker was 2007365 - so the wallets will stop syncing there and simply not progress any further.

I remember your first forking dramas when trying to fork into Tor which failed 2 times IIRC.

You should immediately refrain from that "fix" and set a proper fork-height (at least 48h) and the chain up until the fork block MUST accept blocks with the old timestamps and blocks after that fork block then only with the new timestamp.

bumping this for awareness

Thank you ocminer, I hope that dev coin team will fix this problem and warn pools in a timely manner if a fork should be done. i'd be happy that we revert the coins mined by the attacker.

[1660428886]

1660428886

[1660428886]

1660428886

[1660428886]

1660428886

[ocminer]

nice a new version of the famed timewarp attack.. very interesting.

yep.. we pushed a quick fix and most pools have already updated.. we're already working on a whole new block verification process.

we're kinda glad this happened and that it wasn't as bad as it could have been.

Hmm, you guys are aware that the "fix" you pushed actually IS a hardfork ? So your blockchain snapshot is not valid anymore, the wallet's won't sync up from scratch anymore and the current chain is simply not usable anymore with that new "fix" ?

Your change simply disagrees with the attackers blocks, the first block I see from the attacker was 2007365 - so the wallets will stop syncing there and simply not progress any further.

I remember your first forking dramas when trying to fork into Tor which failed 2 times IIRC.

You should immediately refrain from that "fix" and set a proper fork-height (at least 48h) and the chain up until the fork block MUST accept blocks with the old timestamps and blocks after that fork block then only with the new timestamp.

bumping this for awareness

Thank you ocminer, I hope that dev coin team will fix this problem and warn pools in a timely manner if a fork should be done. i'd be happy that we revert the coins mined by the attacker.

From what I know they won't roll back and just move on.. However, they still must do the hardfork in a proper way

[BitPotus]

When Ocminer tells you that Shit hit the Fan, Shit hit the fucking fan.

Verge fanbois better listen the fuck up.

[cchub]

if im not wrong they fixed it bug could be happen on any coin even bitcoin so lets  not blame them for bug lets blame them for not fixing it so fast

It cannot happen in bitcoin because bitcoin doesn't have such a system. Instead, bitcoin relies on proof-of-work only.

[aciddude]

nice a new version of the famed timewarp attack.. very interesting.

yep.. we pushed a quick fix and most pools have already updated.. we're already working on a whole new block verification process.

we're kinda glad this happened and that it wasn't as bad as it could have been.

Hmm, you guys are aware that the "fix" you pushed actually IS a hardfork ? So your blockchain snapshot is not valid anymore, the wallet's won't sync up from scratch anymore and the current chain is simply not usable anymore with that new "fix" ?

Your change simply disagrees with the attackers blocks, the first block I see from the attacker was 2007365 - so the wallets will stop syncing there and simply not progress any further.

I remember your first forking dramas when trying to fork into Tor which failed 2 times IIRC.

You should immediately refrain from that "fix" and set a proper fork-height (at least 48h) and the chain up until the fork block MUST accept blocks with the old timestamps and blocks after that fork block then only with the new timestamp.

bumping this for awareness

how can we verify the hardfork ?

just download an updated wallet which includes the "fix" - then download the blockchain snapshot and try to sync up to the latest block...it will get stuck at 2007364

heh Yeah I'm building their wallet with the fix now.

[ChekaZ]

Great post ocminer, thanks for this valuable information & awesome to see the newbie accounts pop up and say its fake and fud

[Polonex]

How can one initiate an attack such as this?

Do you need step by step instructions?

Yes

[IDCToken]

Can confirm it is still exploitable, will not abuse it futher myself but fix this problem immediately I'll give Verge some hours to solve this otherwise I'll make this public and another unpatchable problem.

[ico_fond]

So if I transfer XVG from exchange to my wallet there's the risk that my coins will be lost due hardfork?

[ChekaZ]

Github XVG:

"justinvforvendetta replied 2 hours ago
i'm glad this happened now. it's got us working on a whole new method for block and transaction verification =]"

Yeah, maybe work on a new verification method for blocks if he dev doesnt even know that nMaxClockDrift is in seconds..

static const int64 nMaxClockDrift = 2 * 15;        // fifteen minutes

[bitcoinwallet1972]

i,m just a little seed and dont have any tech skills,verge is really a sollid part of my portfolio.
i have a question if the buck stops @ block  2007365 and will stop syncing there and not progress any further.
then the blockchain will stop and payments will stop with it so wouldend there be a lot of spam in the telegram and discord from people who are not getting there transactions thrue?
i hope i can get a anwser to my question because FUD is the right statement of my state of being right now and asking these questions in discord or telegram is like putting your head in a sling right about now....
i just want to protect my investment and really believe in what verge represents but my $$$ are more important

greetings from a little seedling  

[OiMonetka]

U can't fix it through time... Why wouldn't u fix it through the prefix of current readable algorythm? I don't know how hard is it to realise, but (1) u may call each reachable algorythm with the new block with the prefix. Like for the SHA-256 - 00A-, DH - 00B-, Crypt - 00C-, NightCrypt - 01N-, Keccak - 01K-, Lyra - 012-,  X11 - 00D-, X15 - 01D-, Blake - 01B-, Quibit - 00Q-, Quark - 01Q-... etc
(2) Randomise it. (3) Implement Not-in-a-row accessable algorythm. Done. Too hard? - skip (1)

[boxalex]

Great post ocminer, thanks for this valuable information

Totally agree. ocminer should get rewarded with some bigger amount of XVG from Verge for showing them a lot of their problems.
GJ ocminer. Rarely seen such informative and excelent described problems on a forum. Hope you keep up the good work.

[IDCToken]

Hey Verge Team,
get some real developers and fix your code.
We have found another 2 exploits which can make quick hashes aswell.

The (soon) Bits Team.

[phm87]

nice a new version of the famed timewarp attack.. very interesting.

yep.. we pushed a quick fix and most pools have already updated.. we're already working on a whole new block verification process.

we're kinda glad this happened and that it wasn't as bad as it could have been.

Hmm, you guys are aware that the "fix" you pushed actually IS a hardfork ? So your blockchain snapshot is not valid anymore, the wallet's won't sync up from scratch anymore and the current chain is simply not usable anymore with that new "fix" ?

Your change simply disagrees with the attackers blocks, the first block I see from the attacker was 2007365 - so the wallets will stop syncing there and simply not progress any further.

I remember your first forking dramas when trying to fork into Tor which failed 2 times IIRC.

You should immediately refrain from that "fix" and set a proper fork-height (at least 48h) and the chain up until the fork block MUST accept blocks with the old timestamps and blocks after that fork block then only with the new timestamp.

bumping this for awareness

Thank you ocminer, I hope that dev coin team will fix this problem and warn pools in a timely manner if a fork should be done. i'd be happy that we revert the coins mined by the attacker.

From what I know they won't roll back and just move on.. However, they still must do the hardfork in a proper way

I'd prefer that XVG coin dev team decide to roll back to cancel the coins mined during the hack, it is better I think.


What do you think guys ?

[SacredRonin]

@OP

As an avid Verge supporter I'm actually glad you did what you did. Thanks for helping.

Don't listen to the radicals on both sides.

Seems the issue is fixed, let's all move on and be happy this happened now and not later.

Finally! A VALID response from VergeFam! Thanks Ragnarok for posting something of value!

[OneNattyLitecoin]

nice a new version of the famed timewarp attack.. very interesting.

yep.. we pushed a quick fix and most pools have already updated.. we're already working on a whole new block verification process.

we're kinda glad this happened and that it wasn't as bad as it could have been.

Hmm, you guys are aware that the "fix" you pushed actually IS a hardfork ? So your blockchain snapshot is not valid anymore, the wallet's won't sync up from scratch anymore and the current chain is simply not usable anymore with that new "fix" ?

Your change simply disagrees with the attackers blocks, the first block I see from the attacker was 2007365 - so the wallets will stop syncing there and simply not progress any further.

I remember your first forking dramas when trying to fork into Tor which failed 2 times IIRC.

You should immediately refrain from that "fix" and set a proper fork-height (at least 48h) and the chain up until the fork block MUST accept blocks with the old timestamps and blocks after that fork block then only with the new timestamp.

bumping this for awareness

Thank you ocminer, I hope that dev coin team will fix this problem and warn pools in a timely manner if a fork should be done. i'd be happy that we revert the coins mined by the attacker.

From what I know they won't roll back and just move on.. However, they still must do the hardfork in a proper way

I'd prefer that XVG coin dev team decide to roll back to cancel the coins mined during the hack, it is better I think.


What do you think guys ?

A rollback?

XVG will be judged accordingly.

[Dogedarkdev]

we are not doing a rollback and we are preparing a fork to patch this up.

[bitcoinwallet1972]

sorry tryd to make a quote from my last post.... but made a qoute from some one else here

i just made a paymen from Binance : Completed XVG9.9 2018-04-04 23:20:54 Address:   DLv25ww5CipJngsKMYemBTBWH14CUpucxX

to the verge fundraise adress : 4th Apr 2018 23:23:52   d9480b0f0b95bb5ec8a066d93b54fcd8b97c7b7c0ee83effe4ad95b80f004a83   + 9.90000000

so i think my investment is safe for now,i was really hoping to get a fair reaction from one of you

thanks anyway for making a contribution in making the verge blockchain more reliable

good luck and happy trading(mining) to you

[aciddude]

nice a new version of the famed timewarp attack.. very interesting.

yep.. we pushed a quick fix and most pools have already updated.. we're already working on a whole new block verification process.

we're kinda glad this happened and that it wasn't as bad as it could have been.

Hmm, you guys are aware that the "fix" you pushed actually IS a hardfork ? So your blockchain snapshot is not valid anymore, the wallet's won't sync up from scratch anymore and the current chain is simply not usable anymore with that new "fix" ?

Your change simply disagrees with the attackers blocks, the first block I see from the attacker was 2007365 - so the wallets will stop syncing there and simply not progress any further.

I remember your first forking dramas when trying to fork into Tor which failed 2 times IIRC.

You should immediately refrain from that "fix" and set a proper fork-height (at least 48h) and the chain up until the fork block MUST accept blocks with the old timestamps and blocks after that fork block then only with the new timestamp.

bumping this for awareness

how can we verify the hardfork ?

just download an updated wallet which includes the "fix" - then download the blockchain snapshot and try to sync up to the latest block...it will get stuck at 2007364

Confirmed.    client stalls at block 2007364