I'm not sure what you're talking about precisely— obviously double spends will never confirm, so thats not going to be "resolved".

I'm not sure why you think this would be all that advantageous.

You still cannot accept&connect the block without the whole thing, and you cannot verify the later parts of the block without the earlier parts (as blocks very often spend txouts created in the same block)— if you want instead to forward blocks without verifying them, you can do that without any chunking.  This was implemented some time back for the reference software in a pull req by luke but it turned out to not really improve performance much (esp after the ecdsa caching went in).

Yes, but G is security irrelevant for our normal usage in Bitcoin (and generally, except for some contrived examples— e.g. where I need to convince you that I don't know the discrete log of some nothing up my sleeve point X (X!=G), and I picked X long in advance and selected G so that I knew the discrete log of X, but this is contrived and isn't something that I can think of any reason we'd do in Bitcoin.

The term 'fully rigid' comes from safer curves and I complained to DJB that his own curves had no obvious specification for their generator on the site, and (after some back and forth there I gave him a sage implementation of an 'attack' in a contrived protocol) the page was revised to include an argument why the base point selection is irrelevant "What about rigid choices of base points? For each curve considered by SafeCurves, the specified base point is a generator of the specified subgroup. SafeCurves does not place restrictions on the choice of this base point [...]".

You absolutely can. First: whats hackable to _you_ is not whats hackable to some guy with powerful statistical analysis and a fpga cracking farm who, with one unit of effort, simultaneously attacks all users. Secondly, what I was more expressing was an OR case,  that frequently you secrets are either crackable OR they are likely to be lost.  Both of those possible outcomes result in you losing your funds.

A challenge there is that it may be quite hard to get users to understand that your collection of personal information there isn't to send it off to some server or put it someplace public... in querying around I got the impression that lots of people would put random things in those fields, defeating the protection.  It would probably be better than what people are actually doing.

There is another weird consequence is that you lose denyablity when using such a scheme. E.g. if someone does obtain your secrets then your address is effectively a cryptographic commitment to that personal info, it's harder to say "those transactions weren't mine". Thats a little bit into the realm of movie plot threats, but at least some of the people working on encrypted wallets have insisted on "denyability" as a feature, and people have used it as selling point for "brainwallets" (and also as an argument against writing down the key, which is probably the most prudent think you should do— considering the forgetting risk).

Unfortunately ripple is a federated/centralized system that requires opencoin to select a consistent set of trusted signers and for those signers to behave honestly. You can get a lot of scaling advantages if you're willing to trust.

That said— what they're doing doesn't reduce the operating storage requirements for nodes relative to pruned (section 7) Bitcoin... which, fortunately, doesn't change the security assumptions. (it does change the initialization bandwidth, though that didn't appear to be what the thread was asking about)

The inhibition of valid and interesting unusual use cases is enough that those protections had to eventually go in any case. See also: https://github.com/bitcoin/bitcoin/pull/4365

A lot of people have screwed themselves badly this way— you are not a unique and special snowflake, the ways and manipluation people will come up with when they are trying to be "random" is fairly predictable, and that the same properties which make keys easy to remember make them more predictable. Studies of have shown people picking _more_ predictable passwords when explicitly instructed to be unpredictable. Modern password cracking is a statistical study of psychology, powered by "big data" analysis on information culled from huge leaked plaintext password databases and sources like twitter and the forums.

Using a fancy technique may really only be adding a few extra bits of entropy, and worse it's very hard for you to reason about how much entropy you have and an attacker with more powerful statistical tools than your intuition may find your key with only moderate effort.  For this reason it is far better to use a random technique (e.g. dice or a computer CSPRNG) and just add a couple bits directly, then there is no ambiguity.

(Though this is all without regarding the very real risk of forgetting— almost no one is prepared to deal with cryptographic secrets which _cannot_ be recovered if lost, and most people drastically overestimate the strength of their memory)

Whenever a website turns up having a security breach and we find it was using unsalted passwords everyone cries out claiming that the operators are incompetent fools (perhaps even criminally so) and yet thats exactly what a human generated "brainwallet" is— an unsalted hashed password, but worse: they're publicly visible to everyone so someone doesn't even have to compromise a system before they start cracking.

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.