This is why the code wasn't deployed a year ago. (even though alt implementations have been rushing it out...)

Just about any change to consensus code has consistency risks, due care is being taken.

DHT is precisely the wrong technology for this, they generally have fairly poor security properties (or at least require a lot of complexity to make sibyl resistant) and don't solve the of the problems we need solving here.

If you're looking to reduce storage, this is explained in section seven of the Bitcoin whitepaper. The system was designed from the beginning so that nodes do not need to store all the data in order to validate new blocks.  Bitcoin Core v0.8 reorganized the system to facilitate supporting this, but completing the pruning requires first improving the synchronization behavior, second making sure all the database corruption bugs are gone (since corruption will mean a re download instead of just a reindex), and some P2P enhancements so that nodes which can serve new blocks but not old ones can be distinguished.
 
As far as computation goes, at runtime the computation load of Bitcoin is very low already and sipa has written faster ecdsa code that can do over 40k verifies per second on a quad core 3.2GHz i7 desktop (about 6x faster than openssl). It's not needed at runtime but it will be nice for the initial sync.

If you search around the forum you'll see these things have been discussed many times before.

An uncharitable interpretation would be so they could be "delayed" and leave customers in a lurch where they would feel grateful to accept apparently used hardware, allowing KNC to cycle out their inventory so that their own facility can run on the latest gear.  But what do you expect from a company who flagrantly violated their self-mining promises pretty much as rapidly as they good, using their customers payments to go into competition with them and making their own products into an assured bitcoin for bitcoin loss?

Funny how they're playing so humble we're-victims-too after months of treating customers like crap— not just ignoring them, but truly excellent stunts like claiming here that they owed me nothing because I declined their crazy settlement and gag agreement.

And, of course, — like many other batch 1 customers, no product no refund and no communication since the last time I commented.

Back in October when apparently they knew they were going to miss on the basis of having no board, they were still telling the public that they were on track. How many people placed orders on the basis of those claims?

check multsig is already designed that way. But even ignoring that I think a hardfork to increase some speculative flexibility against speculative attacks would be a very poorly justified risk. New signature algorithms can happily be deployed in soft forks (e.g. how P2SH effectively replaced the scripting system in a soft fork).

No, if you'd bothered to do some research you'd find out that checkpoints solve a number of boring DOS attack weaknesses which are better— though less simply— solved with a more intelligent fetching architecture. They also solve some initialization isolation attacks, which are better solved with threshold difficulty. I expect that once we've merged headers first we'll drastically reduce or eliminate the role they play in the reference software.

Bitcoin core wallet encryption uses a salted KDF and 100ms (on your computer) worth of SHA512, with a hard minimum of 25,000 iterations (though on normal computers its well in excess of 100k iterations). There is only so much you can do for a really bad key, but Bitcoin core does the prudent thing and makes very fast searches infeasible.

No, he had another paper where he 'invented' a number of long used mining optimizations like elimiating the final three rounds, mining from a midstate, and merging adder carries, and then spent the last half ranting about how the geometric subsidy decline doomed Bitcoin to failure with strange all-caps bold words mixed in, and saying that we must adopt his proposal to adjust the subsidy every 600 blocks, while simultaneously ignoring that we made it through one subsidy halving without incident.  On the basis of the prior paper and some comments from people who's opinions I trust who read this one, I've pretty much given this one a pass myself.

His work on the mining optimization stuff, though— I recall it being largely redundant with work already deployed out there— was not unintelligent. The conclusions he was drawing—  well, I think everyone who wanders into Bitcoin experiences at least 20 instances of "Ah ha! it cannot work, I've found the flaw!", some of us just go through it a little more privately than others.

Rather than focusing on what the paper has wrong, it might be more useful to ask what it got right or what interesting questions it poses. Even a completely confused paper can sometimes inspire some interesting questions or approaches. I understand that it makes some pretty concrete fairly near term predictions about dogecoin which will be falsifiable, — and hey, making a falsifiable prediction would put it ahead of a lot of things.

You have to keep in mind that publications (esp pre-prints) are just another communications channel for people. By themselves they don't automatically mean the work is of cosmic importance or even that its intended to be. So if it helps you extract something useful from it you can think of it as a expanded forum post. One virtue of that form is that often forum posts are so incomplete that it's hard to even tell if you can tell what there idea is from the post.  In this case, where the author seems to have some misunderstandings about the non-existence of globally consistent time in a decentralized system, and he failed to actually describe his solution— well at least you could tell what was missing.  Don't let the bombastic language get to you, it's a cultural norm in some places to make every thought sound like some major revelation. Annoying at times, but you do yourself a disservice if you can't learn to ignore it and sieve out the good ideas that might be hiding behind the noise.

Rodeoclownicp, okay, message received— you don't need to repeat it a zillion times.

No, the idea is that they keep trying to mine blocks, each time specifying times needed to get the maximum possible ramp— mining 2016 blocks between each 4x difficulty change. The first are easy, obviously, but eventually they become very unlikely to ever get a block. The key point is that the last couple of their lucky steps are more apparent work than all the history, if you assume exponential growth. The key points that makes this unreal is that while the probablity tends to one— assuming the attacker keeps a fixed arbitrary ratio the the network and the network grows exponentially, its negligible over sane timeframes.

When talking about the compact SPV proofs for total chain work the same kind of variance problem arises, that is to say that while the _expected_ work to produce a compact SPV proof is the same as the expected work for the long sequence of normal difficulty blocks it replaces, the reduced sample count means that the probability of 'getting lucky' and being able to mine a compact proof with less work than it would have taken you to do regular blocks of the same difficulty is much higher.

It occurred to me that by requiring additional edges in the proof you can ask about the work over alternative confidence intervals (bounded by base difficulty), and not just the expected work. E.g. "I am 50% confident that this chain had at least work X". In effect you can trade off proof size for decreased variance. But for most of the interesting applications of compact SPV proofs variance 'attacks' were really only interesting right at the tip of the chain (e.g. making a lucky bogus block that has a skip 6 blocks back to where a transaction question was committed), and so it would be easy enough to just demand that your last couple links in the proof be regular difficulty.

I suspect there may actually be an improvement possible to this variance game by having miners commit to lower difficulty solutions and provide them according to some cut-and-choose, and allow for a test of two chains against each other not just in terms of expected work, but according (e.g. to x-percentile work). It would probably take a lot of work to figure out the details here, and maybe in the exponential growth forever assumption it still doesn't work out unless you toss scalability out the window by having to exponentially increase the data disclose along with the exponential increases in hashrate.

I want to transition to a blacklist instead: inhibit the no-op opcodes, non-canonical pushes/signatures, oddball versions, and enforce sanity limits on size and checksig count... everything else relayed (assuming it's valid and meets whatever fee criteria is in use). I think this is also the goal of everyone else working on core in some timeframe or another: No one has any great affection for the whitelist approach afaik, it's just expedient and changing this is not a top priority compared to all the things which have a more urgent need.

The possibility of malicious use is a bug. A script isn't something only the users system validates, the whole network must run it... they can't even just ignore scripts they don't like. So any possibility of malicious use is a severe bug.

Most of the changes in 0.9 related to malleability, and 100% of the changes in responses to the attacksattacks, were changes to the wallet behavior.  The wallet will not become confused now if change is mutated.  There is now a switch to disable spending unconfirmed change, but by default it still does. But, for example, it will notice as soon as change is conflicted in the chain and not try to spend it, greatly decreasing the potential disruption.

(0.9 also included the fix from last September that expanded the definition of non-canoical, but thats not really important to changing the behavior here)

Thats pure hyperbole. The worst case consequence there was that you get transactions stuck which require technical intervention to unstick in your wallet. An annoying DOS attack but hardly "catastrophic to business".

It's not weird, you asked in the wrong subform and no one who cared to answer it noticed. This should have been posted in technical support.

If you'd prefer transactions to fail when you run out of confirmed inputs instead of creating a risk of getting stuck you should set spendzeroconfchange=0 in your configuration.

There are a lot more uses than you've listed there. For example lottery transactions, and those puzzles you dismiss as "stupid" enable secure atomic cross chain trades, making payments that securely depend on an external zero knoweldge proof, and making highly private coin trades.

Because multiplication increases the size of the data. Load a 510 byte number, then keep DUPing and multiplying. Each operation doubles the storage, in relatively few operations all nodes are crashing because they've run out of memory. Your dismissive response shows an extreme carelessness which would virtually ensure the existence of vulnerabilities. Even the simplest operation is easy to make mistakes in. Fortunately the people working on the software are more considerate than that.

Because you can go and put new things to use without first requiring a risky network upgrade for everyone. Some of the non-standardness is also required to preserve forward compatibility so that new things can be safely and non-disruptively added in the future.

And seriously disrupt all the kinds of clever derivation schemes that now exist, e.g. blinding for reality keys, etc. I'm glad Bitcoin was not hyperoptimized in that particular way.

But if the hashrate will not be increasing exponentially, you can prohibit difficulty adjustment patterns that do. Though practical fixes aren't needed against something whos probability becomes non-trivial only after life-of-the-solar-system timeframes, which was what I was going for when talking about working out the distribution and not just the asymptotic behavior.

Indeed, while I was well aware of growth making the historical hashing inconsequential (http://bitcoin.sipa.be/powdays-50k.png) and playing the reorg lottery I hadn't considered that particular possibility before reading that paper (thanks for the link). Though it does require also exponential growth, which is physically senseless in some sufficiently long run. It would probably be interesting to explore the probability distribution with a relaxed form of that assumption.

Well, take care there— lots of things are busted without ever being noticed.
This from the guy who was going around claiming to sell a bogus magical ECDSA cracker. I guess the deadline has passed for my challenge, no keys broken? So sad for you.

In any case, no this isn't actually interesting either— because you have to do as much work as the whole network to get ahead of it in terms of expectation. So you might as well say "you could go mine as much as the network until you get ahead of it"— something you can't do without more computing power than it (much more, in the case that you start far behind it) since the expected required computing power would be equal. The only change is the variance. (and indeed, you can construct some kind of not very interesting very low probability example out of the difference in variance, but like your fraudulent ECDSA cracker, its not very interesting in practice)

(And— since you don't seem to understand any of the technical details about the system at all— I guess I also need to point out that the difficulty can only increase by a factor of four per retarget, though thats not really necessary for what what you're talking about to not bay a concern, though it does frustrate an attempt at a lucky roll).

I can't figure out how that was supposed to be an improvement to the "status quo" (presumably in Bitcoin). Truly decentralized mining works fine today though its not currently very popular, that text is talking about a world where it isn't economically possible.

Moreover, even accepting the motivation the solution sounds like a handwave in other ways as well: Pooling allows work delegation because of the huge ratio of work for solving vs verifying.  Script work is all verification, barring complex and insanely expensive things like proofs of computation the best I think you can do there is farm the work out to N miners and ask for the hash of the execution transcript, and if there are disagreements verify for yourself... but even that fails if the N miners are sibyls and it has N fold overhead. What am I missing here?

Have nothing to do with this.  A general tip: if you are commenting on the security of Bitcoin and the word "checkpoint" comes to mind, you are probably confused.

This thread was answered completely and correctly in the very first response. This attack does not exist because Bitcoin chooses the chain with the most work, not the most blocks.