Here is a simple fix for the exploit.

When a block has an earlier timestamp than the previous block, its difficulty adjustment needs to be based on the difficulty of the most recent block its timestamp is later than rather than on the block immediately prior in the block chain.

For example, if a block has a time earlier than the last four blocks then it should start its difficulty calculations with the difficulty as it was before those four blocks.

I think that this makes every instance of the time warp exploit impossible.

And it's a simple adjustment to whatever difficulty algorithm you're using. Kgw included.

The simplest way to protect against the time warp exploit, in all its forms, is with a simple rule about blocks whose timestamp is before the previous block.

Just make an adjustment to the difficulty baseline so they don't get the benefit of difficulty adjustments made after their own timestamp. 

In other words,  if a new block is timestamped prior to the previous four, you proceed as if the base difficulty were the same as it was prior to those four blocks.

poof, every time warp exploit in the world becomes impossible.

The question is not whether someone intends to take it down.  The question is whether it is constructed well enough to stay up anyway.  This is at least theoretically financial software here.  If someone's effort to take it down even matters, then it is worthless.

If someone can take it down then the stakeholders cannot rely on it being secure against thieves.  And more importantly, they NEVER could have relied on it being secure.

The kgw exploit is real.

The problem is that the software will accept blocks that are timestamped earlier than previous blocks, (for good reasons) up to the median timestamp of the previous 11.  

Kgw counts these as very fast blocks and adjusts the difficulty up by its 20% maximum.  Once.   But you can use that once to roll the timestamp back after five blocks that are long enough to drive the difficulty 20%lower each.  

So the exploit is to start mining your own block chain, time stamping several blocks into the future far enough to get the maximum downward adjustment of difficulty each time.  Then jump backwards in time getting the maximum upward difficulty once.  Rinse, repeat,  and your chain gets ridiculous low difficulty and you mine a whole lot of blocks while advancing your timestamp not much further than the main chain.

When the time in the main block chain catches up, you release your own chain and force a reorganization, which allocates to you all the coins mined for the last umpty ump blocks.

The problem with the idea that lost coins are a donation to everyone is when nobody knows which coins or how many are lost.

It creates uncertainty and worry when that's not clear.  Right now if Satoshi or one of the other huge entities whose keys appear to be lost were to start spending coins it would cause a panic.

What you have here is much easier to account for.  One lost wallet with a known amount in it.  Make it so that wallet can't be spent even if the keys are recovered, and you have the public donation scenario.   Actually you have the equivalent of a launch with a smaller coin count and an initial distribution to fewer people.

You're missing the point here.  If he can destroy a block chain or an exchange or a pool, then they were doing it wrong and deserved to be destroyed.

This is a service that good security pays handsomely for.  It's called testing.  People who are afraid of testing are just those who fear that they have failed.  Testing means you can't keep your failure a secret any more and when you're asking people to trust you with their money that is a good thing.

Oh hell no.  I just said, a BTC holder who wants to maximize his return on investment has a rational reason to attack all altcoins.  A large BTC holder could easily believe that he has a reason to do so.  I never said whether I think that's a good thing or not. 


Wow, that's a new record.  Zero to Godwin's Law in one post!  I need to take a bow now.    

I think maybe I see a flaw in the current implementation of Darksend.  

When someone attempts DoS by promising to spend a txin in the first round, but then does not authorize the spend in the second round, that txin is blacklisted from the current Darksend negotiation and rounds continue.  Presumably the darksend eventually goes through, minus the txins controlled by attackers.  You can't allow any new txins to be introduced in later rounds, or the attacker could just keep attacking that particular Darksend.

But the attacker can go on attacking forever - he can use a thousand txins over and over, in every Darksend transaction, forcing each of them to go a thousand rounds before it gets to any conclusion.  

About that "PWN ALL THE BLOCKCHAINS" meme.... 

As we all know, Altcoins are the number one reason proposed why Bitcoin is going to fail.  What economists who investigate the situation say is, "There is no barrier to entry, thus cryptocoins will never be scarce, thus  the price for all cryptocurrencies will be driven to zero."

Someone going around destroying altcoins would be demonstrating a barrier to entry, and probably doing the Bitcoin prospects a big favor.  So, yes, it's in the rational best interests of a large Bitcoin holder to organize a pool specificially to break altcoins. 

Also, altcoin bagholders who are PO'd at scummy altcoin developers might join in just out of spite. 

That's kind of meta.  Hope you didn't pay much in exchange fees. 

The other day I bought a bag, and the lady behind the counter put it in... a bag... 

Is there, in fact, any way to motivate people to mine individually, rather than as part of pools? 

I see pools as one of the biggest problems to overcome in an altcoin design.  Not the only big problem, but one of the biggest.  What I see though is that everybody wants to be part of a pool.  They don't even *know* how to mine solo, even though it's bog-simple compared to setting up a pool. 

"proper" and "analysis" don't usually go together in this context. 

No sober analysis ever really predicts a rate of more than a dozen percentage points up or down; outside of that is the field where pure speculation comes into play, because they are relatively rare cases and there isn't enough data to even build models for "proper" analysis.   

The circumstances and controlling factors on these more volatile issues are too individual and too rare for real analysis to have much of anything to work with.  Instead we tend to have speculators falling back on games a bit more sophisticated than mere numerology but not backed up by any serious theory. 

Once you're dealing with something that is outside the range where there's enough data to verify theories and do analysis, you either get the heck out or trust your gut instincts.  There will be a thousand people doing something they call analysis, but ask yourself how much data they can possibly have that addresses the unique aspects of the issue at hand and you will usually find that it is wiser to ignore them and just pay attention to literal on-the-street indications of public awareness and sentiment. 

Yesterday I was at a junk shop and I saw one of those hand-scribbled flyers about some garage sale, which said, "Bitcoin accepted!"  And that on-the-street indication, to me, was a heck of a lot more significant than anything someone pretending to be an "analyst" says.

I would cheerfully pay you $50 per coin today, for the option to buy bitcoins from you for $200 each on July 15.  If you're serious and willing to work with a lawyer etc to get the escrows sewn up, PM me.

+1, all three points.  Complexity and security are very hard to mix, and something as complex as the linkage to an external database is a well of impending disasters.  Embedding a particular version of SQlite would be acceptable - it would get all the necessary code into the project and under strict control at the very least - but I agree that the simpler the save format, the easier it is to audit and bugfix in the code that reads/writes it. And the Append-only Pattern is very simple and does achieve transactional integrity. 

Does nobody ever solo mine anymore?  It's even easier to set up than a pool, and brings the diff down just as well.  Plus, if you get a block you get all of it.  So why not just say "generate=true" when you start your wallet?  You need pool info like a fish needs a bicycle.

Well, let's consider it at the very least a valuable learning experience.  This worked better than I would have believed any all-comers giveaway possibly could.  Someone scripted a sybil attack and didn't dominate the whole proceedings.  

I think the crucial thing - the big learned lesson here - was the captchas.  As a (reasonably) script-resistant element, they dominated the work of the sybil attacker.  The lesson is that to make the whole thing fairer, we need captchas that take more human time to solve.  

Instead of "which of these three pictures is a duck?" we need a "game" captcha like "Can you solve this maze, avoid getting killed by the monsters, and bring your coins from the vault back to the palace?"  that has procedurally generated content, gives everybody a different random seed so no two mazes are alike, and takes a human an hour or so to play.  They send in a savefile that has all the movements recorded, the server runs it against the random seed it gave them and discovers whether they succeeded, and the server awards coins.

True, procedurally generated content being what it is, some folks would get tougher mazes than others.  Some might solve three or four, or even ten.  But nobody's going to solve 350 of them in a day, and if you're really stuck you can always get another captcha (making the one you downloaded to the same address earlier ineligible for the prize) and do a different maze.

I've been watching this rollout, and I think it's time for a hats-off to the developers. This is a successful experiment, and in rolling out a proof-of-stake altcoin it's very clearly the way to do it.

This actually worked really well, regardless of the fact that somebody got 350 shares.  I think this is, so far, the gold standard for a proof-of-stake rollout. 

Yes, it was possible to game it - but if the top gamester still wound up with less than 1% of the coins, after putting in 24 solid hours of human work, I'm considering this was in fact a nearly complete success.  Usually when somebody breaks something, they get half or more. 

There are 320,137 people in Iceland.  You're not going to get something to each and every one of them for less than the price of (paper) postage.  So unless somebody is coming forward with about $200K in actual cash for stamps, plus 640 reams of paper, 321 large boxes of envelopes, enough printers to push that many paper wallets through in a week, and a whole lot of volunteers to handle the operation and take that truckload of paper down to the local post office (where they will curse at you and delay it at least another week), this isn't going to happen.

I looked at KGW and aside from the code being very (alarmingly) complex it's got a mathematical property I don't like.

Depending on the timing of blocks, chain #1 can do less total hashing while getting more blocks and a supposedly higher proof of work than chain #2, and arrive at the same final hour.  This happens when chain #2 has blocks at even intervals, while chain #1 has long intervals punctuated by occasional backwards-in-time intervals.  Backwards-in-time blocks are allowed, up to the average time of the previous several blocks - and if they've got long intervals, you can get a long way backward in time with one jump.

Instead of tracing the ridiculously complex code, I actually tried testing it with random intervals, and within a few hours of testing chain splits (two chains from the same starting point) on a FakeCoin with 2-second target intervals, I saw a sequence that had more total hashes and less proof of work (and less blocks) than another sequence.  After a bunch more tests, it seems to happen whenever the backward-in-time jumps are more than 5 blocks apart and work less well the further apart they are than that. 

It looks like somebody with considerably less than half of the hashing power of the network could execute a 51% attack against a KGW blockchain.

The most reliable way to store Bitcoins is made less reliable by telling people what they are looking for if they'd like to steal them.  So I'm not going to say.

I can tell you however, that a so-called "Brainwallet" is one of the very WORST ways to store bitcoins.  In fact the longer it takes to generate a Brainwallet, the worse it is. 

Remember, everybody can see all the accounts.  They have your pubkey.  A brainwallet makes your privkey easy to guess, and they don't have to steal a thing from you.