I just saw that Aphroditecoin was traded today. 

And that at the price it was traded, the market capitalization for it is standing at US$ SIXTEEN dollars.

That's kind of stunning.  People are still running a block chain that represents a currency ALL OF WHICH could now be bought  cheaper than a pizza.

Thanks for the info, on Silly Valley coin and Electriccoin.  Like I said, if I have to hunt all this stuff on my own I'll probably never catch up! 

Yes, in fact they are dead.  Or at least, no longer traded. Thanks for the headsup; they just hadn't popped up in any of the spots I found on my initial search.  So I added them today.

Added Rotocoin, Cryptographic Anomaly, and Electronic Gulden.

Hmmm.  That's a fine example of withdrawing your support from a blockchain (by creating an attack chain) without making the repudiation or withdrawal of support visible on that blockchain (because it hasn't happened yet). 

And you're right, the GHOST protocol doesn't address it.  Darn.

There are partial protections such as checkpoints in the downloaded wallet, but the most they can do is limit the length of the 'simulation' or attack chain.

No.

The hash power devoted to securing altcoin chains is orders of magnitude smaller than the hash power devoted to bitcoin, and the cost of an attack in general is therefore orders of magnitude smaller.  Doge got a special mention because it was used as an example recently of the economic effects of reward halving on hash power distribution - the author of that paper made the point that every time doge cuts their block subsidy in half the hashing power devoted to securing their blockchain will also be cut in half.  Doge was mined too quick; its block reward is cut in half many times more often than Bitcoin's.  But it isn't the quickest-mined coin out there by any means; just one that's a bit remarkable for the size of its current market cap.  All of the quick-mined coins have this problem, and many of them are already gone.  But that's only the technical side of blockchain safety, and unfortunately that isn't even the main type of risk.

Altcoins, in general, are a cesspool right now.  In fact it would not be too much to say that the *AVERAGE* altcoin is a scam.  Exchanges are openly taking bribes to list altcoins regardless of merit. Some of them are even developing their own altcoins in house for the sole purpose of trading fraud.  Other people are more or less openly accepting payments to hype coins on Reddit, Twitter, etc, then engaging in blatant price manipulation in order to drive prices up on a particular day so scammers can sell their premines at maximum profit. Several coins a week that are doing "crowdfunding" or "IPO" to sell their initial distribution of coins are simply scammers who then disappear with the money. 

If you even consider investing in altcoins, you should first have a definite reason to believe that the one you're investing in isn't a scam.  You should second have legal recourse (meaning, you know AND CAN PROVE exactly who the scammers are and where they live) if it does turn out to be a scam.  If you have trouble following that second rule, it's not because it's an unreasonable rule; it's because scams ARE THE NORM in the altcoin world and scammers will not give you enough information for legal recourse.  While some non-scam coins exist, they are rare exceptions.  Nobody in that business is entitled to the benefit of a doubt.

That's a completely separate issue from chain security w/r/t large (or small) transactions - but once again, if you don't fully understand why a blockchain is (or isn't) secure and what resources are required to attack it - then you don't know enough to even evaluate the security of an altcoin that's operating with different rules, and if you can't evaluate the security of its blockchain, then you shouldn't be investing in it even if it's a non scam.

The central issue with proof-of-stake is that when the chain forks, the stakeholders on the left side of the fork, with very few exceptions, are also stakeholders on the right side of the fork.  Whichever fork wins, they still have their stake.  In fact, they have an incentive to use it to mine both sides of the fork at once.  There's literally no rational reason for them not to; whichever fork eventually fails is eliminated from history, but until they know for sure which one that's going to be, why would they stop mining it?  And as a result of that dysfunction, why does a choice between forks ever get made at all?

Proof-of-work is the expenditure of a finite resource (hashing power) in real time.  You cannot use the same hashing power to support both sides of a fork; you are forced by physics to choose one side or the other, and therefore a decision on the local level perforce actually gets made - leading to a decision on the wider level.

The nothing-at-stake problem can be overcome by GHOST protocol or similar; it must not be possible to support one side of a fork without your repudiation or withdrawal of support being visible to the other. 

He's talking about a transaction that would justify the cost of making an attack. 

But having the money to pay the 'going rate' for hashing power doesn't mean there's that much hashing power available to lease.  You'd start buying hash power, then when the market started to run short the price would start going up.  You'd cost out long before you reached enough hashing power to actually make the 51% attack on the Bitcoin network.

I'm totally with you about Doge though.  Every time they cut their block reward in half (which is often) they'll be cutting their share of hashing power in half.  They'll wind up with not enough to secure the network, because all the miners will be off distributing their hashes up in proportion to the value production. 

Okay, I feel better now. 

It turns out that that description of time warp's effect was just plain wrong in the first place, and time warp is nothing but a subspecies of 51% attack.

So the boneheaded bug I was looking for does not in fact exist.  Nor have I (and many others) been just stupid for not being able to see it. 

Time warp amplifies the destructive power of a 51% attack drastically, but a 51% attack means you're kinda screwed anyway, doesn't it, so this is a more minor deal than I'd thought.

 

 

That's not the way it works.  The routine above estimates the amount of hashing required to solve the current difficulty, not the amount of hashing required to get the particular hash. 

IOW, if he gets a hash (any hash, no matter how low) for a block whose difficulty is 10B,  the chain including that block only gets credit for 10B hashes. 

I think the metaphor I'd have selected is that it's like trying to do surgery on an individual of an unknown species.  You can see what's in front of you, but you must understand what it does and why it's important (and therefore what aspects of its behavior must be preserved and what else must be adjusted if you change it) before you mess with it.

I'm an old crypto geek, but there is a LOT more to this code than crypto.  In fact, the crypto aspects of it are among the very smallest parts.  

It's good code, but frequently nonobvious, and commented even less than most opensource projects.  The 'nonobvious and uncommented' combination makes it hard to get full understanding.  'nonobvious and commented wrong' would be even worse, of course, and that's the most frequent alternative.

Finally I'm stunned to see how much it's using SSL and Boost, because SSL is a crawling horror, and Boost is too large and complex to be genuinely believed secure.  

some reading.... http://clearcrypt.org/tls/

When I went looking for the bug that allows time warp exploits, I found something related.  Not what I had been told the time warp exploit does, but something related to it.

If you can use timestamp lies in some way to trick or manipulate a difficulty adjustment algorithm,  an attack chain can arrive at the same timestamp as the main chain with many times more actual blocks, having used the same amount of hashing to get there. 

The result is that a 51% attack can use an attack chain with a STOOPID number of coins, rather than an attack chain that simply gets all the coins that the main chain issued to other miners while  the attack chain was built.

Bitcoin had an irregularity (really too slight to be called a bug) in its implementation of difficulty adjustment that allowed a certain type of fiddling, in that it adjusted difficulty every 2016 blocks, based on the 2015 intervals between those blocks; but once per difficulty adjustment, one interval between the end of one block and the beginning of the next was skipped by diff adjustment.  Thus, Bitcoin's difficulty adjustment algorithm could be manipulated by an attacker, but only by about a quarter of one percent per difficulty adjustment period, which is why it's an irregularity rather than a bug.  An attacker would do this by selecting that skipped interval to make a backward jump in time which difficulty adjustment wouldn't take into account.  This would be a 51% attack, in that he'd have to use hashing power equivalent to the hashing power of the entire legitimate network to form his attack chain.  In Bitcoin's case, the attacker would have to generate a chain that stretched through dozens of difficulty adjustment periods to have a really significant impact on Bitcoin's difficulty adjustment, and even if he had the multi-petahash infrastructure that would take, there'd be a checkpoint locking out his attack chain by the time he got the difficulty in his attack chain down significantly.

This irregularity became an outright bug in altcoins which shortened the adjustment interval to the point where this kind of manipulation could give an attacker nearly-arbitrary control over difficulty adjustments and block rates - in some cases even allowing the attacker to walk timestamps backward WHILE lowering difficulty, by making intervals shorter than 6 intervals (the 'median-of-last-11-blocks' rule guarantees nondecreasing timestamps only for adjustment periods longer than 6 intervals).  KGW and several other difficulty adjustment algorithms introduced new and different bugs that allowed the same kind of manipulation.  So this attack, applied to those alts, could instamine their entire remaining supply of coins in a 51% attack, and the very short difficulty adjustment periods made it feasible to form attack chains that invoked difficulty adjustment hundreds of times.

But none of these difficulty adjustment bugs would EVER have allowed an attack chain formed with less than 50% of hashing power to displace the main chain, assuming the routine I quoted above remained in place.  So the Time Warp attack as described to me is either not this attack, or the person who described it was simply wrong. 

Is that what the time warp has been all along?  Just a particular type of 51% attack?

The attack has been used on several alts, so I'm looking for the bug that allows it in the bitcoin code they have in common. You can claim it's an "altcoin question" if you want, but the bug that allows this is in the code they inherit, whether or not they aggravate it with difficulty adjustment algorithms that respond more quickly to changes in network hashing power. 

Okay, I do see one way for timewarps to work as an attack, but only as a way to leverage the profitability of a 51% attack.

If an attacker screws around with timestamp lies and exploits the block reward adjustment algorithm, he can use 51% of hashing power to generate a blockchain with ten or fifteen times as many blocks - thus he gets ten or fifteen times as many block subsidies. 

The attack chain will be accepted because it has more hashes, not because he found a tricky way to get something created with less hash power accepted. 

So now I need to think about what is the correct fix for that.

The Time Warp Exploit depends on the ability to get a block created by less hashing accepted as "longer" or having more work in it.  Ultimately, that determination is made by this routine.  The theory here is that this returns the number of hashes required, on average, to create this block. Thus the sum of it for each block from the root to the tip should equal the amount of hashing power required to create the chain.

It appears that this should do what it is intended to do.  And yet, Time Warp Exploits work.  Why?

EDITED:

Okay, I get why someone can game a difficulty adjustment algorithm and lie about block timestamps in order to create an attack chain which

a) has more blocks,
b) ends on or before the same timestamp as the main chain,
c) took less than the same amount of hash power to produce.

And so far we've focused on the difficulty adjustment algorithms to try to fix it.  But I have a different question. 

Why aren't these attack chains recognized as containing less work?  Regardless of length, timestamps, or whatever, shouldn't they simply be recognized as containing less hashes and never given the chance to displace the main chain?

The point about trying to track the expected block height for the timestamp is to try to control the coin supply. 

We've seen the exploits; we know that burst mining tactics can often result in blockchains running consistently faster than they are supposed to, and supplies of coins that were supposed to become available over the course of years being instamined in a few weeks instead - with difficulty ratcheting up and down wildly as burst miners jump on and off.

These coins then get dumped on the markets and the whole thing collapses (I know, that usually happens anyway, but sometimes the coin developer didn't mean for it to happen and might not even be the one doing it....)

From the POV of someone who is mining, or holding coins, it would be nice to know that there isn't an easy exploit that can make the blockchain run consistently fast, bringing more coins into existence faster than intended.  Having the blockchain detect when it's created more blocks than it's supposed to have, and slow down, or conversely detect that it hasn't been creating enough blocks, and speed up, is a way of committing to the 'nominal' coin creation rate that often gets left by the wayside in the interaction between adjustment algorithms and exploiters (or, indeed, between adjustment algorithms and random chance).

Oh, my god.  You're right.  That was boneheaded.  Thanks for pointing that one out.

Well, this is why we have code review.  Code that seems to work "well enough" may still not be doing exactly what we suppose it's doing, in a way that will become obvious only if we examine its behavior on a statistical basis. 

A correction then: Here's how that first function should have gone... 

[/code]

On the one hand, that's a good point and I haven't yet given it the amount of thought it deserves.  Good thinking!

On the other, that's a special case of the fact that generating a chain in an isolated environment using long block times is going to give you very low difficulty anyway.  You can generate more blocks than the regular blockchain, while going *much* further into the future per block.  

But in order for that to become an attack on the main chain, you have to bring your attack  chain's last timestamp into line with the main chain's last timestamp, and I don't think that you can.  

If you do nothing, then by the time the main chain catches up to the last timestamp of the attack chain, the main chain has more blocks (AND higher difficulty through those blocks).  

If you try to add blocks while not adding time to your attack chain, you need some form of the Time Warp exploit (which allows you to add short-time blocks without triggering difficulty adjustments, or allows you to trigger opposite-direction difficulty adjustments to compensate for them), or the difficulty will rapidly go so high that you cannot continue.  

And I had thought that I had designed this against the time warp exploit, but now I'm thinking of the implications of burst mining and the fact that you can get five rapid blocks without triggering emergency adjustments...  and repeat at intervals of 25 blocks ... and I believe the regular difficulty adjustments compensate, but I haven't proven it rigorously.  If the regular difficulty adjustments don't compensate, you could build a chain about 17% (1/6) longer in the same timestamped time, while keeping the same difficulty setting.   Meaning you'd need about 42% of hash power to build a chain equally long.  

So the question is now whether there's enough wiggle room to play the emergency adjustments against the regular adjustments.  Aww, crap, now I'm going to have to do real math.