Because, it's lunacy:  The allegation being made (which was after I initially removed the posts, FWIW, when I started removing them there wasn't even that much) is that some decades ago some BFL person ran a BBS in one state, and some BCT user ran some BBS(es) in another state, an activity tens of thousands of people engaged in. And somehow this makes them connected. This just seems like a desperate attempt to draw any connection at all; and it makes the forum dumber for it, because some people have no clue what the words mean, and act like its significant (and as a result makes everyone there look like fools).

I administered BBSes (in Florida, in my case) in the mid 90s. Am I suddenly Josh?!

Sbogovac, you've drank water before, haven't you?!?!?  We all know that Sonny Vleisides was seen drinking water in court.  The connection is CLEAR (I suppose I should go full gauge here and use red text?)!!!!

Witches also drink water. Clearly you are both Sonny _and_ a witch!   Everyone, grab the torches!

If your signing RNG is sufficiently bad your funds can be stolen even if you only ever sign once: If your k some value they've got precomputed in a rainbow table of bad rng outputs they can race you in flight. If your key creation RNG is bad, of course you don't ever have to spend to lose your funds.

Reuse makes it worse-- an RNG with only a couple bits of bias (e.g. using RC4 to generate them) will screw you with enough signatures. And this is indeed a reason "paper wallets" aren't great.  I just wanted to comment to correct the impression that reuse is needed for sufficiently poor rng output to matter. The broken RNG's we've seen (so far!) have mostly been pretty much complete breaks.

As you yourself admitted, the posts had nothing to do with BFL other than by virtue of being posted in that thread.  I did also invite any complaints to come here, rather than to continue offtopic on that thread.

Generally when a thread is going offtopic we'll do a cleanup on the last couple pages to push it back onto the rails. There is no use in cleaning up hundreds of pages of past topic transgressions which no one is reading anymore. Many of the points I removed also had no connection to the (also offtopic) doxing posts.

SaltySpitoon, with due respect: Thanks for your support, but you're also confused. The posts in question were not related to BFL except by virtue of having been (_incorrectly_) posted in a BFL thread, and none of the posts themselves claimed to be related to BFL.  By defending my (very much real) non-connection to and non-motivation to help BFL you're just making it sound like I removed something to the betterment of BFL, which I think cannot be sanely alleged. (Quite the contrary: The mass of inscrutable, unprofessional, and irrelevant rubbish on that thread makes BFL's angry customers look bad and separates them from actual information which could be used to improve their situation).

It's quite likely that I deleted plenty of more borderline material (like the posts with nothing but pictures of chickens) that I might not have deleted as single isolated posts. This is the norm for pushing a thread back on topic. I used a similar approach (periodic aggressive removals) with reasonable success in some of the prior KNC threads.

I agree. But this has nothing to do with the discussion at hand. Cryptic pages of picture of chickens doesn't aid people in recovering their losses, ten pages about people who have nothing to do with BFL beyond having posted in that particular thread, do nothing to aid people recover their losses-- in fact, it does precisely (and I think, intentionally) the opposite.

Thanks for confirming.

Nope.

So your argument here is someone that has, as far as anyone can tell or has alleged, absolutely nothing to do with BFL being harassed with ten pages of nonsense posts is ontopic in a BFL thread because Josh-- a third party-- treated you like shit in the past?  Just making sure I'm clear about your line of thinking, because it doesn't make a lot of sense to me.

Because it had, as far as I can tell or anyone alleged, _NOTHING_ to do with BFL.

How so? None of those posts of ten pages of animated chicken gifs and what not, appeared to make any claim to relevance.  "It's relevant because I harassed someone and had a fun time" is not an argument.

As far as I can tell 90% of this is intentional, controlled topic derailment.  Y'all should be more critical about who you believe is on "your" side and who's been paying them to do what, I would be very surprised if some of the "BFL critics" hadn't been paid off by BFL; their constant lack of ability to conduct themselves professionally only makes everyone whos critical of BFL look stupider by association and the constant noise prevents finding any actual information.

Regardless, keep to the freeking topic. I am tired of the bad behaviour and I am tired of people ignoring requests to cut it out.

(Xian01 tells me that this thread was created because of messages I removed in a thread about BFL)

I don't know and don't care about "dox".  I removed a ton of posts that have absolutely nothing, not even any claim, of having to do with BFL, that were basically making it impossible to find the one in ten posts that were actually about BFL.

For the abstract question ... harassing people is not okay, but there are limits to what can be done about it.

Lambda (mod N) has multiplicative order three, the other value is just lambda applied twice. Unfortunately, it appears is no way to use that for additional speedups because the is no small orthogonal basis that cam be formed from a reduction on [n, lambda, lambda^2].

Absolutely not. The changes in 0.10 you're referring to are exclusively related to signing, as the release notes say, and do not change verification.

Verification in libsecp256k1 on x86_64 is now probably closer to ten times faster than OpenSSL's implementation, but the software is very much still under development. This is without batch validation. True batch validation requires additional side information to have any hope of being faster, and even with it the speed increase is not that enormous due to the additional blinding required to preserve security.

Adding to the excellent points DannyHamilton made,  you're completely ignoring the problem of introducing a new node to the network. If the "genesis block" is rewritten and the history forgotten by everyone-- what basis do they have to judge the new system? You haven't provided a security objective/argument at all for that case. (Fortunately, as DannyHamilton points out, the original Bitcoin whitepaper addresses storage and does so in a way that doesn't make it unclear how a new node can be initialized. And Bitcoin core did 99% of the work to implement that storage reduction a couple years ago, in 0.8, it-- as mentioned-- just hasn't been a priority, due to the -- as mentioned-- linear growth maximum).

If you're feeling that the response here is a bit to blunt you should realize that this proposal (and it's ilk) has been repeated here many times since 2011, seemingly by people who missed section 7 of the white paper and seldom proposing something even as good as the design Bitcoin already has. While it's great that you're enthusiastic and have ideas, when you make a public post you're consuming the time of all the readers and people who respond to you. It's helpful if you describe the research you already did when you first propose something in a community that you're new to, since when someone seems to have missed something obvious (like the whole section on the subject in the project's whitepaper) it gives an impression that the poster didn't care for the costs they imposed on others.

I'm not sure that people actually have much to learn from it; or at least the lesson most learn isn't the lesson they need to learn.

The problem is that the security of cryptosystems can't be assured by following a checklist. Do this. Don't do that.  Do this.  No finite set of instructions is necessary or sufficient for security.

The real lesson is the serious hard work, challenge, public review, testing, and residual risk there is with writing cryptographic software.  When you fixate on the list you feel like you have control of the security.

There is far too much adhoc cryptographic code being written in this community (and beyond) by people who are not putting in the serious effort to make sure it's done right. No matter how awesome a coder you are, no matter how many lists of things to avoid, if you're going it alone your code will not be secure, if you're just following instructions from the forum your code is not going to be secure, etc. Maybe it will be _mostly_ secure, but mostly isn't really good enough.

Put another way, if this thread is alerting you to the concern here then it's very likely that you are not yet prepared to be writing cryptographic software for large numbers of people.

BIP32 hardened is perfectly acceptable to release private keys.  They're indistinguishable from random keys to anyone who doesn't know the master secret.  Fore BIP32 _non-hardened_ IT IS ABSOLUTELY NOT ACCEPTABLE TO PUBLISH THE PRIVATE KEYS. PUBLISHING ONE PRIVATE KEY IS EQUIVALENT TO PUBLISHING ALL OF THEM TO ANYONE WHO CAN GENERATE KEYS.

R.x == 0 is not a point on the curve; but R.x congruent to 0 (mod order) _is_ on the curve, and so r can be zero because r is the x value of R mod the curve order.

(And likewise, s can be zero; e.g. I have a test in libsecp256k1 for s==0:
https://github.com/bitcoin/secp256k1/commit/8d11164bc0e03024d38d5694e81f334ea31ec238#diff-4655d106bf03045a3a50beefc800db21R1210)

What risks are you concerned about?

Just incorrect key generation? Attempt signing with all the keys and verify the results. (Bitcoin core does this internally. And I strongly recommend it, it's a little terrifying that nothing else does. It's too easy to have a bitflip cause the creation of an invalid key, and too easy to defend against)

Poor RNG quality?  Thats harder. Vanitygen allows seperated (point addition) key generation, so you could e.g. generate one key another way and generate all additional ones as that key plus some new random value, in order to have a baseline expectation of security.

Concerned about side-channel (timing, emi, etc.) leakage?

Why is speed a concern? I can understand applications for generating some large number and putting them away... but if the keys are going into a safe what do you care if it takes an hour? How fast does it need to be?

It does not.  In RFCs, requirements are usually specified using all-caps (though not strictly required), and special keywords. See RFC 2119.  It does make a suggestion to do so, but there are often good reasons not to do so; e.g. becuase of application layering, code availability, etc. (also RFC6979 is kind of embarrassingly slow already, mandating it be half again slower in our case would just encourage more people to do ill-formed adhoc things). In this case the suggestion doesn't even appear to be SHOULD level.

It's common for found-on-the-internet ECC crypto-implementations to be pedantically incorrect, and in worse ways than this. Caveat emptor. Virtually none of them that I've seen have evidence of strong peer review, or evidence that their authors have an especially detailed understanding of what they're doing. (Turns out you can implement working, or at least mostly working ECC just by aping some tutorials, which were themselves often written by people new to the subject).

I think being correct in this respect is important, not just in case someone manages to find the p=2^-256 inputs that expose misbehaviour, but also because the same code may later be reused for future curves where the field isn't so insanely close to 2^256, and a failure to implement this correctly can turn into a serious security vulnerability. It's also important to do right because it simplifies review: one can mechanically check each step and not resort to time consuming (and risky!) cryptographic reasoning about the implication of any particular change, the bug (or backdoor) that kills you is the one that looked harmless on the surface.

It's fine, yes. I mean a relay without a blockchain at all.  I think I misread your post as saying you had 1GB storage, but I'm guessing now that you have 1GB ram.

Soon-ish (probably in 0.11) we'll support running pruned nodes which could fully verify things but won't need the whole blockchain. They'll still require a couple gigs of storage and that amount will grow (but much slower, unless things that spam the utxo set become popular)... which might fit better on a small device like that, though it would be useful it wouldn't be as useful as something with the whole history.

That you could do. Though right now you'll need, say, 60 gigs of storage though better if you have more since you'd be able to keep serving old blocks long into the future.  (Actual usage is more like 32GB at the moment, but since it can grow at a rate of about 25-50GB/yr, it's best to have plenty of headroom if you're going to store a full chain.

USB flash sticks often wear out quickly when there are many writes, so you'd want an actual SSD or spinning hard drive. On newegg it looks like one can get a 500GB usb external drive for under $50.

Absolutely. One thing that would be pretty useful is to run a hidden service bitcoin node,  we're rather short on HS nodes and you can use tor to limit the bandwidth. ("BandwidthRate" in torrc).

The maximum long term average data rate for the blockchain is about 14kbit/sec. So even just a few megabits can do a lot to help keep more peers connected.

A relay node that doesn't filter for validity is not very useful for Bitcoin (and can easily be caused to get banned by all its other peers) and at worst is an attack amplifier.

It's great that you want to support the network, but running another node on that host is probably not the best way that you can do so right now.

Ah, it's the standard game of trying to con the Bitcoin technical community into doing the engineering work for some competing altcoin which doesn't actually have any technical backing.

Thanks Shorena.

Of course, otherwise it would risk triggerable (or even spontaneous) convergence failures which could be exploited to cause loss of funds.

This does fit within the model of "address as an invoice number", and it's strictly less harmful than other kinds of reuse. Though it would certainly be possible to provide multiple addresses for this purpose (the payment protocol accommodates this, IIRC). There may be reasons why the receiver cannot handle funds split up, and so the willingness to accept multiple payments really should be established up front or no payment should be made.

This application was my primary inspiration for the type-2 deterministic wallet proposal, which became BIP32: The FSF started accepting Bitcoin donations and they asked about being able to issue receipts for donation in order to comply with IRS requirements for 501(c)(3) chartable contributions over $250 in value. Doing so required they use one address per contribution but they did not want to generate private keys on an exposed web server which could be hacked.

Using an extended pubkey to receive funds allows the sender to verify the correct receiver statically without reusing addresses. Though this is not yet common.

Considering that the donor's ability to deduct donations is lost completely for donations over $250 if the recipient cannot issue receipts, and in the US an organization accepting quid-pro-quo donations without issuing receipts (which they cannot do if they're reusing addresses) is in violation of the tax code and could be subject to fines, I question your cost/benefit analysis in that context.