delete

[TotalPanda]

simply a new light

while {
         loop
        }
and BCX is disarmed/will help to secure   

[sonysasankan]

Hi BCX!

You seem to be quite open at your evilness ;-)

Would you tell the truth, if I asked would this protect against the attack you are planning?:

https://bitcointalk.org/index.php?topic=505243.0

....the plot thickens 

[HCLivess]

I had my doubts towards you and I was wrong! Thank you for the analysis, please proceed with destruction.

[Lordoftherigs]

Hi BCX!

You seem to be quite open at your evilness ;-)

Would you tell the truth, if I asked would this protect against the attack you are planning?:

https://bitcointalk.org/index.php?topic=505243.0

....the plot thickens 

This remains me of the silly movie villains that tells their evil plan before actually executing it.... We all knows how they all end....



''Yippee ki-yay, motherfucker! ''

John Mcclane

[Nite69]

Hi BCX!

You seem to be quite open at your evilness ;-)

Would you tell the truth, if I asked would this protect against the attack you are planning?:

https://bitcointalk.org/index.php?topic=505243.0

While this is an improvement in the efficiency of KGW, it is still KGW.

Short answer is  I don't think so, but I will drop it in and see.


~BCX~

Actually, I guess it won't help. The problem might be not the adjustment algorithm itself, but the speed of it. Too quick adjustment while allowing large timestamp windows on the blocks allows you to adjust diff for you only. It allows you to generate a secret blockchain with timestamps that will give you a lot smaller diff than the outside word. Of course, you publish it only after you got several blocks with your lower difficulty. Am I right, wrong or even close?

[BohemianStalker]

AUR will survive this. It was I who predicted on this whole shitty forum that it will go 400M+ on coinmarketcap and nowI have info about it's defenses against this kind of shit. GL with the live chain haha.

[TotalPanda]

+1

I'am a C# dev, I have read the white paper
and I'am pretty sure they can't exploit the KWG.

I was in [panic sell mode] 

[LTEX]

Yes, a new one.. holy mother of god.. say it ain't so!

Well.. welcome to this wonderful cesspool where every other post is a scam, troll or insult about your mother's above average weight

Grab some popcorn because BitcoinEXpress is giving us a show.

Aaahhhhh I was already wondering why it was so quiet, peaceful, calm and decent in the other threads. You guys have found something better to waste your time on and, of course, eat popcorn  

Have fun guys, hope you enjoy!!!

Really, I mean it!!!

[1369]

Mr. BCX, seeing the fear you have struck into the hearts of AUR holders, what is to prevent a curious cryptonoob from assuming you're simply out to plummet AUR price & buy in? No man is above greed, yet those perceived as powerful tend to fool us into assuming otherwise.

[TotalPanda]

+1

I'am a C# dev, I have read the white paper
and I'am pretty sure they can't exploit the KWG.

I was in [panic sell mode]  

Bad news, the exploit is not enabled by a code issue in KGW, it is enabled by what KGW does. KGW functioning as intended is critical to this exploit. Without KGW, there is no exploit.


~BCX~

Bad news == Good news  


using System.Fair;

private static bool BCX = false;
public long AUR = 1;
//public long BTC = 1;  

class NoWorry
{
    public static void IDontWant2SellCheapAUR()
    {
     while
         {BCX == false
            {
            AUR++;
            }
         }
     }  
}

NO DECIMAL HERE

[bushstar]

Some of us are still waiting on that 51% attack BitcoinEXpress promised us a long time ago. That never happened but the threat scared the market into making some very cheap coins available.

BitcoinEXpress, are you looking for some cheap coins again

Now you have our attention how about some evidence to back up your claim?

[embicoin]

If you don't give any technical details more than "I tested this shit premine scam", you have 0% credentials.

________ END OF TOPIC __________

[LTEX]

If you don't give any technical details more than "I tested this shit premine scam", you have 0% credentials.

________ END OF TOPIC __________

I Agree, by the way, he's acting like some kind of wizard, but guess what? This is how he plans to do it (without meaningful result btw)...:

By exploiting the fact that retargeting ignores one block interval every period, it's possible for an attackers' fork chain to "jump backwards in time" and create lots of blocks at low difficulty without running nTime off into the far future.

Bitcoin (and most *coin) rules re. block timestamps:
nTime has to be > median of prev 11 blocks.
nTime has to be < now() + some buffer.

let's say we have a chain with 4-block interval and 10 sec/block.
Official chain, currect diff for hashrate, blocks found at nominal time:

Code:
blk#  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
time  0  10  20  30  40  50  60  70  80  90 100 110 120 130 140 150

Now here's the weird part, we retarget after blocks 3, 7, 11, 15, and for block 3 we use 0 as first and 3 as last, for 7 we use 4 as first and 7 as last, ...
so what happens if an attackers chain has blk timestamps like this:

Code:
blk#  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
time  0   1   2  30   4   5   6  70   8   9  10 110  12  13  14 150

?
first period (#3 - #0) is 30s as before
2nd period is (#7 - #4) ... 66s
3rd period is (#11 - #8) ... 104s

Whoops.
Obviously this ignores the "problem" of the attackers chain having way lower sum-of-difficulty
but thats easy to fix:

Code:
blk# 16 17 18 19 20 21 22 23 ...
time 16 17 18 19 20 21 22 23 ...

just keep driving diff up at maximum speed until you have the same total work as the real chain.
result-> the attackers chain does not violate the block timestamp rules, finishes at a *earlier* block timestamp than the real chain, ends up at a higher total work as the real chain, but contains way more blocks.

[ghur]

If you don't give any technical details more than "I tested this shit premine scam", you have 0% credentials.

________ END OF TOPIC __________

You're gonna regret not buying popcorn now while it's low.
It's gonna pump hard!

[embicoin]

If you don't give any technical details more than "I tested this shit premine scam", you have 0% credentials.

________ END OF TOPIC __________

I Agree, by the way, he's acting like some kind of wizard, but guess what? This is how he plans to do it (without meaningful result btw)...:

By exploiting the fact that retargeting ignores one block interval every period, it's possible for an attackers' fork chain to "jump backwards in time" and create lots of blocks at low difficulty without running nTime off into the far future.

Bitcoin (and most *coin) rules re. block timestamps:
nTime has to be > median of prev 11 blocks.
nTime has to be < now() + some buffer.

let's say we have a chain with 4-block interval and 10 sec/block.
Official chain, currect diff for hashrate, blocks found at nominal time:

Code:
blk#  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
time  0  10  20  30  40  50  60  70  80  90 100 110 120 130 140 150

Now here's the weird part, we retarget after blocks 3, 7, 11, 15, and for block 3 we use 0 as first and 3 as last, for 7 we use 4 as first and 7 as last, ...
so what happens if an attackers chain has blk timestamps like this:

Code:
blk#  0   1   2   3   4   5   6   7   8   9  10  11  12  13  14  15
time  0   1   2  30   4   5   6  70   8   9  10 110  12  13  14 150

?
first period (#3 - #0) is 30s as before
2nd period is (#7 - #4) ... 66s
3rd period is (#11 - #8) ... 104s

Whoops.
Obviously this ignores the "problem" of the attackers chain having way lower sum-of-difficulty
but thats easy to fix:

Code:
blk# 16 17 18 19 20 21 22 23 ...
time 16 17 18 19 20 21 22 23 ...

just keep driving diff up at maximum speed until you have the same total work as the real chain.
result-> the attackers chain does not violate the block timestamp rules, finishes at a *earlier* block timestamp than the real chain, ends up at a higher total work as the real chain, but contains way more blocks.

The only accepted blockchain would be the longer one, so your nice explanation involves the attackers generating a longer alternative blockchain at a higher speedrate than the real network does, If I understand well this is almost impossible, specially with such beast difficulty present on AUR.

The cost of performing that kind of attack would be so high so it will divert attackers to actually mine the coin in an "honorable" way to obtain more profit in AUR coins for the same hashrate.

[Nite69]

This might be just a story, but a nice one so I write it, wheather it is true or not.

First you generate a block in the future, so it's KGW difficulty calculation just hits the event horizon. After you have that block, you generate another one, the same time ahead to the future. With each block you generate, KGW generously offers you a smaller difficulty for your own secret blockchain. You go to the future, so far that you'll get the lowest possible diff. (Edit: Actually could you occasionally step backwards in time so eventually do not end in the future at all? You might use one block (and get higher diff) to get back in time worth 5 blocks (which give you 5x lower diff you payed when going back))

After that the join begins! You have the lowest difficulty and you happily generate blocks with timestamp exactly 5 minutes. Since you are floating out of the real time, you can generate them at any speed you wish, as far as you keep the timestamps at 5 min interval.

Now you have a long, secret blockchain. But bummer, it is in the future! No pain.. you start climbing back to the real time. But unfortunately, each block is more difficult.. this time KGW demands its reward...  "A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours." You hit the time warp wall and then you can only wait. (Edit: you can do more: build blocks, use one of 5 to get halfway back..repeat) However, when real blockchain reaches you.. you might be lucky enought to have a higher blockchain. And when you announce this to the other clients, in the correct time window.. the chain is all yours!

And then they revert back to the block 5400 and you lose everything.

Nice story, isn't it?


Edit: when you are inside your own blockchain, you can actually generate blocks faster than outside word. Generate 11 blocks at 5 min interval, get halfway back in time with one block, generate next 11 blocks etc.

[TotalPanda]

Alice in Wonderland with a dark horse 51% HASHRATE

[LTEX]

you happily generate blocks with timestamp 
YOU NEED 51% HASHRATE

And thus that resolves the FUD that started these 7 pages, because when block 5400 arrives, most miners in real dedicated pools will happily jump back in, scaring the shit out of the hacking hobbyists....

Please keep this threa(t)d open though, it keeps the popcorn eating nono's off the really serious ones!

TNX!

[TotalPanda]

Fix zeitgeist2 attack

return pindexLast->nBits;

etc.

[mcg]

thanks for mentioning this.