FWIW, I think the current bignum free code we have in the reference client, now is moderately more clear than whats in the wiki. https://github.com/bitcoin/bitcoin/blob/master/src/base58.cpp#L66

wtf, no. Of course they know and validate the genesis block, it's part of the definition of the coin. They would ignore a greater work chain that disagrees with the genesis block.

This is far from clear to me, the obvious formulations of that would seem to have infinite convergence time to me.

You've given a pretty clear explanation of one aspect of the problem— though another one with common causes is costless simulation: e.g. some early large number of stake holders can go fork it off and with no cost produce a simulated chain which a new node cannot distinguish from the original. They can do this at any point, even after exiting the system, years later— so it doesn't seem possible that any inside-system incentives can prevent them from doing so.

You've been told some pretty weird stuff then. Nothing has been taken down, and it's not that complicated a point.

In POW to contribute to a consensus you must burn a resource, which means you must make an exclusive choice among all the possible consensus you could contribute to, to the exclusion of all others... and for your effort to not be wasted you should be spending it on the chain you think most likely to survive.  In pure POS schemes, there is no such exclusivity created.  This leads to fun outcomes like old stake holders can exit the system (sell their coins) and then sell their old keys to people go fork off the chain at a point in the past, at no cost to themselves. Someone who is later handed two histories— the real one and the simulated one— cannot distinguish them, they can tell— perhaps— that someone was naughty, but that doesn't help them decide which chain is the good one.  There are a number of other related implications.  A number of different modifications have been proposed, but so far all of them seem to be obfuscation and not actually fix the underlying issue, which seems a bit fundamental.

You can read more about this in Section 5 of https://download.wpsoftware.net/bitcoin/asic-faq.pdf

PPC was attacked utilizing this fact the moment POS mining became possible on it— a savvy miner tried all possible forks finding a sequence of forks which selected their stake as the winning stake as much as possible. PPC prevented this with block signing and discouraged it by hard forking the protocol so that POW blocks were required.

GPS is unauthenticated. Any local-to-you jammer can spoof it with nothing more complex than a USRP and some software. It's also run by US space command, and the US has been quite up front that they are willing to manipulate or disrupt the signal to achieve military objectives, they're able to perform geo-targeted alterations of the signal too.  It's pretty useful on average, but it's not a secure solution by itself.

Yup. Some altcoins have made it worse with crazy rule changes but in bitcoin it's kinda boring. We could also close it with a soft forking change e.g. detect the median dodging and add a further time clamp, but its such an unimportant thing no one has given any real though to the safe and sufficient rule for it.  I went as far as adding an attack to testnet so there would be something to test against.

I'm familiar with that paper and have linked to it on the forum before. Note that Lamport is talking about a distributed system, not a decenteralized one.  As I recall process he describes is not byzantine robust, requires a jamming proof broadcast network, and does not have anonymous membership (the players must be selected in advance, so it cannot meet our definitions of decenteralized— in particular it needs a consensus arbitrary ordering of player identities to break ties).

As far as POS goes, I've not seen anyone tender a solution to the nothing at stake problem, and so I still consider it non-viable for a decentralized consensus. PPC makes it work by requiring POW and using centralized block signatures. NXT was previously making it 'work' by not releasing the complete source to their software, I haven't checked lately.  So far POS schemes all suffer from attacks like former quorums (e.g. people who held coins at some point in the past) can costlessly replace the history by forking off from a point where they did have a quorum after they no longer do, and from things like the optimal income producing mining strategy is to mine all forks (because there is ~0 marginal cost in mining a fork) instead of a single one. Schemes like honesty bonds do not help a node decide between two different networks— the real one and a simulated one, and cannot punish someone if they perform the attack after exiting the network completely.

Using hash-chain mediated common view time transfer, as I wrote in 2011: https://people.xiph.org/~greg/decentralized-time.txt

Your question stops being interesting when you start removing the only known solution for strong decentralized consensus— even in the proof of work model an effort to do consensus time probably fails for incentive reasons, but no one knows how to do decenteralized consensus absent the expenditure of work.

You cannot get nodes to accept such a chain, you're confused about what people are talking about with timewarps; or confused because this is really an altcoin question and some altcoins have further broken things. Bitcoin won't switch to a chain with less apparent work.

No competent wallet software would recognize a payment to an scriptPubKey of a kind they wouldn't have created as theirs, and no wallet programs that I'm aware of do.  The model used in Bitcoin is that the receiver specifies the address they'll accept for a transaction. You can make up random stuff that, in theory, someone else could spend ("It's just one greater than some other private key of yours!", or some script) but they're not going to notice it.

Non-standardness has nothing to do with it— a 1 of 2 multisig is perfectly standard. The reason wallets will not report payments to such a thing is that they didn't author it.   A scriptPubKey _is_ a public key.  Expecting a wallet to magically notice a random unsolicited 1 of 2 scriptpubkey that contains a EC point they happen know the discrete log of is just like expecting them to notice a payment governed by a private key one greater than one that they know.

Right, yes. You'll know about that when it's available.

It won't be noticeable at all except during initial sync, and even there only after a number of other improvements which make a much bigger difference. I only brought it up to further emphasize that computation isn't a major issue.

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.