Yes, you are wrong— if all you are doing is verifying new blocks and not initializing new peers there is no reason to store the historical data, you need only store the list of currently spendable coins (this owing to the fact that the bitcoin system tracks atomic coins, and not 'balances'.). This is what section 7 is about, and I thought it was rather clear— so you're going to have to ask some questions if there is to be any hope of someone figuring out where your misunderstanding is coming from.

Certainly you're not likely to get far by insulting the people who you'd hope to educate you about the matters you're asking about.

It's a slippery slope, perhaps— "don't @#$@ with the behavior" is a clear position... but not really viable with the current state of the art in software engineering— otherwise bitcoin would have been dead with the integer overflow bug back in 2010.  I think the next reasonable compromise is "don't @#$@ with the behavior unless ~everyone agrees".  Sometimes its hard to tell what everyone would agree with, however.  Fixing obvious software bugs in the system itself seems to have gone without issue so far.

They were all within a couple hours of each other AFAIK and all by MTGOX.  Am I incorrect?

I see you've still not read section 7.

This was MTGOX it made a bit of news back when it happened.

Like most epic failures it took a complex series of events to happen— that transaction was non-standard and wouldn't have been mined by normal nodes... but mtgox had an API to ask eligius to mine transactions of interest to it which bypassed all non-standardness checks and their system flagged those transactions for prioritization.

I'm sort of surprised that no one has even proposed a hardfork to recover those coins— esp. in light of mtgox somehow losing most of their customer's coins.

It sounds like you haven't read the original bitcoin whitepaper? See section 7.

Incorrect. The parameters _are_ minimal, there is a script to reproduce them from first principles _in this very thread_.

There is nothing arbitrary about it, with use of the efficient endomorphism enabled libsecp256k1 is (AFAIK) the fastest implementation of ECDSA verification on general purpose hardware in existence, obviously if it contained an implementation of schnorr signatures over this group they'd be even faster due to being able to skip the modular inversion too, but as far as I know it is unparalleled by any other actual ECDSA implementation with comparable security...

Nor are there any obviously strictly superior alternatives, _even today_ much less several years ago, the best contenders have a cofactor greater than one— allowing a non-prime group at a minimum costs several bits of security (e.g. equal or worse to the rho improvement from the efficient endomorphism), and depend on implementation hacks that require private keys to be in a particular sub-group, making things like multiparty key derivation (e.g. BIP32) incompatible with those implementations.

You can mine on P2Pool and turn your share difficulty way up— there is a maximum, but it's pretty high. Or you can solo mine.

Yep.

There was another thread in this subform where we showed that all of the secp256k1 parameters can be deterministically derived from reasonable first principles— even ones simpler than the ones we know where actually used (e.g. you don't have to require that the curve have the efficient endomorphism, a practical increment from zero search still finds ours first), except for the generator point— whos value is irrelevant for security assumptions except in somewhat contrived situations (basically if someone from cetricom or the NSA shows up and tries to convince you that they don't know the discrete log of to_point(H(pi)) on our curve, you might not want to believe them because G could have been selected in such a way as to make the discrete log of a chosen in advance but seemingly nothing up my sleeve point known).

Sorry, the criteria also required that x < 1024, the performance speed-up requires x to be a small integer.

It's not used for a cryptographic purpose.

See BIP0037 (or grep the code base for where it is used!).

It's a system parameter, it must be a finite field which has size near 2^256 to achieve ~128 bit security, but less than 2^256 to avoid needing more space, to make the modular reductions faster the number selected is a generalized mersenne number. In the case of secp256k1 was selected by picking the largest x such that 2^256 - 2^32 - x is prime. You can search for "generalized mersenne number" to find the Solinas paper about how fields of sizes with special form yield more efficient computation.

Very neat.  Perhaps to go with the bandwidth stats some mempool stats and a time since last received block?— for the latter we might need to adds something to the rpc, I don't think we expose what time we received a block.

Its unfortunate— more than anything else patents slayed ecash the first time around... they substantially hamper the deployment of cryptographic tech on the internet, — even when they're not actually applicable getting people to deploy cryptographic technology is uphill enough that the small amount of uncertainty from patents completely tips the balance.

Before getting too worried by DeathAndTaxes reasonable suggestion,— you really shouldn't attempt it without first taking some time to learn about how to read patents, any of that reading should also be read along side RFC 6090 which firmly establishes the unpatentable prior art basis for elliptic curve technology.

Thats also outrageously incorrect, it's the kind of misinformation repeated by idiots who have no idea how patents works, usually thinking the title of the patent or abstract text specifies what the patent covers (when really the scope is established by the independent claims).

All "compression" means is sending only the X corrd plus one bit of the Y it should hardly be called "compression" as much has omitting redundant data.

The observation that only the X coordinate was needed was made in the earliest of ECC papers— including, Miller, V., "Use of elliptic curves in cryptography" from 1985: "Finally, it should be remarked, that even though we have phrased everything in terms of points on en elliptic curve, that, for the key exchange protocol (and other uses as one-way functions), the only the x-coordinate needs to be transmitted."

If anyone were to have obtained a patent as broad as that it would be invalid, trivially so due to the Miller cite above and many other prior descriptions of the techniques.

That site is backdoored, the <random> button bypasses window.crypto and directly uses math.random. Math.random() is typically a 32-bit LCG, practically no entropy at all.

Your proposals are not very clear on the technical details. I can interpret what you're saying in multiple ways. If the work you're describing must be cumulative e.g. one building off another to ensure publication than what you're describing is basically what P2Pool already does (though it doesn't impose anything on transaction selection).  If the work is independant but a block must have a total of it, then that isn't progress free— the hypothetical 40% miner could listen to everyone elses announced shares, but horde its own jealously until it finds a block and thus have a significant advantage.

It might help to describe how you think what you're suggesting is different from what P2Pool already does.

The best of intentions… but really, thats less of my point than the rest— the sluthing creates an impression that it actually matters, as you can see in TooDumbForBitcoin's response. Thats unfortunate.

It is— e.g. you can follow the p2pool sharechain and reconize blocks consistent with it, but the soft (non-hardforking) incentivizaiton approaches require the cooperation of miners.