I agree that the proposals for carbon reduction so far publicly floated are fails. 

There are geo-engineering proposals that people aren't convinced are necessary yet. They are regarded as too desperate and extreme. 

They will seem less desperate and extreme as the failure to apply them becomes more desperate and extreme.

But I suspect the decision to use them will not be made until far too late. 

Yeah, I bet a panel of geophysicists wouldn't want to hear from someone claiming the earth's core is made of  cheese, either.

You know, people being dismissive of your opinions and denying you the right to speak at conferences, isn't necessarily evidence of a goddamn conspiracy.  You have to consider the idea that maybe you're just plain wrong and they already know it and they don't want to waste any more of  their valuable time on you.

Wat?  Just because I'm a pessimist about the rest of you clowns and the probable results given how many people just refuse to admit there's a problem, does that mean I'm not allowed to take a little comfort in the thought that our species probably STILL won't go entirely extinct?

Hell, probably even the survivors after 90% of us die off will still be arguing about whether climate disruption  is our own fault or not and whether we need to change our lifestyle to avoid a disaster.

Eh. 

Yeah, there'll be some depopulation and tough stuff going on.  The Easter Island thing is actually pretty likely.

But one thing to remember.  The people of Easter Island?  Didn't quite go extinct.  Some of them survived, and their descendants are alive today.

So, sure, maybe 90% of everybody will die.  It doesn't mean things are hopeless.   

Today is an awesome day to own Bitcoins.   

This time next week will be even awesomer.   

And yet those ice sheets that we count on for the regulatory effect, are getting smaller and smaller.....  We have less ice at the poles now than we've had at any time in the last half-million years, and if that regulatory effect goes, we're leaving Icehouse Earth.

Yeah, the issue requiring an extra bit for rounding accuracy happens when you multiply or divide by by an imprecisely represented decimal fraction, or add or subtract an imprecisely represented decimal fraction, and want to be sure that the answer comes out to the closest value.  

And it's 52 bits of mantissa, not 53.  The last one is a sign bit, and while there's no such thing as negative bitcoins you can't use it for positive amounts because of partial results and subtractions having negative values you must represent.

This discussion got stupid a long time ago so I really shouldn't be replying, but I'm doing it anyway....

There are three different main "chaotic attractors" in the state space of earth's climate.  They are called Greenhouse Earth, Icehouse Earth, and Snowball Earth, and under normal circumstances they last for at least millions of years each.  Usually Greenhouse and Icehouse earth alternate with each other; the conditions that lead to a Snowball Earth are not well understood although the geological record shows evidence of them and we have solid modeling that indicates why they have to end.  The Eocene period, ending about 50 million years ago, was a Greenhouse Earth that was followed by an Icehouse Earth;  And during the Permian period, about 300 Million years ago, an Icehouse period was followed by a Greenhouse period.

Snowball Earth is HORRIBLE for survival prospects; it involves the whole planet being covered with ice and snow, forming a reflective surface that sends most solar energy back into space instead of keeping enough of it around to warm up and start melting.  Snowball Earth phases last tens of millions of years, until volcanism builds up enough CO₂ in the atmosphere for the greenhouse effect to trigger melting - but the melting leads to a relatively abrupt switch from reflecting to absorbing solar energy, without removing the greenhouse gases, and that usually sends Earth abruptly into a Hothouse period.  We haven't had a Snowball Earth phase for the last 650 Million years.

Right now we're in an "Icehouse Earth" state, and have been for several million years.  During an Icehouse Earth period, we get "Glacials" or Ice ages, interrupted at 50k-100k year intervals by an "Interglacial" lasting 10K to 20K years.  For the last 11K years or so we've been in an Interglacial period (the Holocene), so the ice sheets that characterize an Icehouse Earth have been small and mostly limited to the polar regions.  Icehouse Earth tends to last until earth's orbital precession and chaotic factors cause the ice sheets to entirely melt, which destroys a regulatory mechanism by which coriolis-driven ocean currents act to regulate earth's temperature by moving heat energy back and forth from the poles to the equator. The end of this regulation usually results in a Greenhouse Earth, but, according to some theories, can also result in a Snowball earth state.

A Greenhouse Earth state would also be bad for our survival prospects, as it is something our species has no evolutionary experience with.  Greenhouse Earth is described as dry, windy, and unstable, with winters just as cold or barely colder, but summers considerably hotter than Icehouse Earth.  Like Icehouse Earths, Greenhouse Earths tend to last for millions of years, until orbital precession and random chaotic processes result in the formation of polar ice sheets at both poles that last for more than a century or two and start the regulatory process of Icehouse Earth back up.

So those are basically the three choices.  Some people are worried about transitioning out of an interglacial into a glacial phase but still within the Icehouse regime (the people talking about a new ice age).  But we can survive an ice age; it would suck but we've done it before.  Other people who are scared are envisioning the complete end of the current Icehouse era and wondering what our odds of survival in a Greenhouse Earth would be like.  That would suck too, and probably harder since we've never evolutionarily adapted to it.  People like me though, are pessimists and harbor dark suspicions and worry that we don't actually know what causes Snowball Earth eras to start. I wonder whether the end of Icehouse-style global temperature regulation will result in a bunch of wild oscillations settling on the near-certain death of our species in a Snowball Earth. I hope not, but I can't help wondering.

Actually yes, Satoshi was very much aware of numeric representation issues.  And the fact is that you can't actually get 100% accurate rounding on basic-4 operations (addition/subtraction/multiplication/division) if you use more than *HALF* of the number of distinct values available.  So the actual limit on the number of divisions for accounting without "gotcha" rounding errors is 2^51, not 2^52.

Satoshi cared that people using Javascript (?) or other languages which encode all numbers as 'double' (64-bit floats) would not have to jump through hoops to avoid stupid accounting mistakes. 

Your 64-bit float has 52 bits of mantissa, so, in order to avoid rounding errors ever going the wrong way, the number of units involved in bitcoin-related math must never be more than 2⁵¹, which is 2251799813685248 units.  21 million coins times 10⁸ divisions (Satoshis as they are now called) is 2100000000000000 units - comfortably just below the limit allowing "simple" accounting implementations in such languages to be accurate.

And as Hal Finney pointed out in 2008, even if the entire M1 money supply of the world as of that time were expressed in Bitcoins, the smallest division would still be worth less than 1 USAmerican penny, so there is no need for more than that many units.

Hi. 

I'm forming a moderated mailing list for the purpose of designing security systems -- and then breaking each other's designs.  On-topic will be pretty much anything from hardcore cryptographic design and implementation to general design of systems to achieve particular security goals to protocols and key management problems. 

The purpose is to get better as designers and understand what kind of attacks people mount against security systems.  If you are interested in joining such a list, please respond.  If you know others who might be interested in joining such a list, I encourage you to forward this message to them. 

Thanks,

Cryddit (aka, Ray Dillinger, bear@sonic.net)

Yah, they overrode SecureRandom with their own service.  But on platforms without enough memory their own service didn't get registered, and instead of detecting the error they wound up calling the parent class's method.

And this is important because their service, LinuxSecureRandom, initially uses state from /dev/urandom - same as the parent class but had a 'setSeed' method that mixed its input with the RNG state. 

The parent class, SecureRandom, is automatically initialized with bits from the native RNG if you DON'T initialize it - but if you call 'SetSeed' it uses your seed instead. 

So, yah, while not noticing the difference between '200 OK' and '301 service permanently moved' is awe-inspiring, so is failing to notice when their service overriding the native service failed to load. 

But geez, to list all the things that scream WAT here?  We'd have to add several more lines, including getting "random" numbers over HTTP in the first place, doing the initialization in an order that put the greatest reliance (ie, last update via 'setSeed' call) on the least secure source (ie, numbers retrieved over HTTP), and then .... Good grief.  It's a long list.

I never said that it was the best method for working around the problem, nor did I say that it was implemented competently.

What I think it was, was a "quick fix" that they could get out the door in 24 hours when the problem with the Android RNG was discovered, which they probably planned to get back to and fix "for real" with error checking and probably an onboard source of bits and so on....  

But such plans are hardly ever fulfilled.  Some security-ignorant beancounter goes, "We have a workaround?  Cool, now we need to work on this other thing instead."  And they never get back to it.

An interesting point here is that the mistake which led to the most recent problem may have been (in fact probably was) an attempt to work around the previous problem.  

IE, they probably overrode SecureRandom and were getting numbers from random.org to mix with the output of the parent class, specifically BECAUSE of the earlier issue with SecureRandom.  

One way of looking at this is that these fuckups are going to be made - and hopefully learned from - by people along the way.

With $27 million of money from vulture capitalists, bc.i will likely survive more "opportunities to learn" than most companies can afford.  

They may achieve security before their money runs out. Which, I guess, would put them ahead of the short-lived competition we've seen so far.

As part of my 'Cybernetic Entomology' posts I researched how and why this bug actually happened.

They derived a class with a 'SetSeed' method that _mixed_ input with the RNG state from a native class with a 'SetSeed' method that _replaced_ the RNG state with input.  But on low-memory Android devices that class didn't get registered.  Instead of failing because an important component did not load, they called the 'SetSeed' method of its parent class.

So, the procedure for initializing the RNG --->

whatever its current state is, use SetSeed() to mix it with bits from /dev/urandom (good)
make it "Better" by using SetSeed() to mix with bits from random.org (stupid but probably harmless)

But when you wind up calling the parent class's SetSeed method, instead, this turns into ---->

Replace current state using 'SetSeed' with bits from /dev/urandom (suboptimal but acceptable, except for what they do next)
make it "Better" by replacing that (acceptable) state using 'SetSeed' with bits from random.org (WRONG!)

After digging some more and understanding what actually went wrong (and discovering some of the decisions that led to the failure along the way)  I've updated the article at

http://dillingers.com/blog/2015/06/09/ce-random-numbers-and-response-parsing/

This "Cybernetic Entomology" series of articles is about breaking down bugs and showing how they came about - and after analysis, giving some basic observations about how not to get bitten by the same bad decisions that led to those bugs. 

Done.  I'm still boggling over this.

This required an UNBELIEVABLE level of ignorance or wilful stupidity to achieve. 

I mean, hell, the minute I hear "Random numbers over http" the deal is already broken.  HTTP is not private and has no message integrity.  Middleware intercepts and rewrites HTTP all the damn time.  Your message could be tampered anywhere along the way!

The http service shut down in January.  Blockchain noticed in June.  Wouldn't you think that if your security depends on a web service staying up, you'd at least write a script that would tell you within, say, 24 hours, if it went away?

What does it take to not notice the difference between '200 OK' and '301 Service Permanently Removed' responses?  Seriously!  How could you possibly write an app that wouldn't notice that!!

"PRNG initialized from only two sources" -- another deal-breaker.

And then, when it tries to read one of those sources and fails, it fails SILENTLY?  What the HELL?

I'm just ...  I can't.... wow.  I didn't think that level of ... whatever it is .... was even possible.

  http://www.theregister.co.uk/2015/06/01/blockchain_app_shows_how_not_to_code/
  http://arstechnica.com/security/2015/05/crypto-flaws-in-blockchain-android-app-sent-bitcoins-to-the-wrong-address/
  http://dillingers.com/blog/2015/06/09/ce-random-numbers-and-response-parsing/

Short version of the story:  They were getting "Random" numbers over HTTP (WRONG!) from a third-party (WRONG!) to initialize a PRNG and generate keys (WRONG!).  

The third party - random.org in this case - discontinued its HTTP service because, well, random numbers over HTTP is WRONG!

But the clients Blockchain.info had deployed for Android didn't parse the response to see whether it was an error message; they just read the "301 service permanently moved" error message and treated it as a "random" number.(WRONG!)

This left all those Android clients initializing their key generators with the same not-very-random number.   And for some of them, where the sole other source that they attempted to use failed, that was the ONLY initialization.  

The result was that all of those clients generated the private key corresponding to 1Bn9ReEocMG1WEW1qYjuDrdFzEFFDCq43F and sent bitcoins to it.

And somebody who noticed a whole lot of coins accumulating at "his" address, spent them.  

" There are more ways to get security wrong, Horatio, than dreamt of in your philosophy. "

Doesn't matter, really.  Knowingly profiting from illegal activities makes you guilty. Add facilitating them by providing a marketplace, and you get criminal conspiracy and accessory after the fact to thousands of things that went down. Under law he's considered worse than any of the individual sellers. 

And If I recall correctly, wasn't there a post on here from someone who said they had bought mushrooms or something from him?