Actually, I will mention that here in Ontario, larger organizations get their electricity on HOEP pricing (https://www.ieso.ca/imoweb/marketdata/hoep.asp). HOEP basically stays at a fixed market rate, provided that electricity demand is close to projected electricity demand. When demand differs from projections, the price fluctuates. You can get the current price off their website, updated in realtime.

If demand is too high, the price goes up, and if demand is lower than expected, the price goes down (because they have extra capacity, possibly from nuclear sources that can't easily be spun down, that they need to bleed off somewhere.) Sometimes, the price actually goes substantially negative, but usually only for a few hours a few times a year.

So, if you're on your local supplier's equivalent of HOEP, you might review your historical pricing, and see if it's worth your time an effort to build a system that starts furiously mining when the price goes low/negative.

The one thing that jumps out at me immediately is that, for almost any modern computer, a computer which is powered up but otherwise idle is going to draw less power than a computer which is mining bitcoins. If you want to use GPU mining (and, realistically, if you don't, this is probably a waste of time since you'll probably never mine any bitcoins) then I think you'll find the power draw from a mining machine is substantially higher than that of an idle machine.

So, what you need to do is work out your idle power consumption (with, say, a Kill-A-Watt meter), then work our your fully-loaded power consumption (preferably by trying to mine some bitcoins, but you could get a reasonable quick estimate by firing up a modern 3D game), work out the delta, which is your effective power consumption for mining, and then use one of the various calculators out there (e.g. http://www.bitcoinx.com/profit/) to decide if this is a profitable venture for you or not.

For every four Americans working a 50-hour week, every week, there's one American who should have a full-time job, but doesn't.

That's very much like saying "For every copy of Photoshop that is pirated, Adobe looses $1000." And it's wrong, for very much the same reasons.

I have certainly worked on projects where if we'd hired enough people to make everyone work 40 hour weeks, the project would have been horribly over budget and would have been canceled. Of course, those projects are usually unsustainable anyways (mine was - it was canceled. :)

I'm not arguing with the basic premise that the 40 hour work week is a good thing, keep in mind.

Expect it to get muddy quickly, even if Natco Pharma is not allowed to export the medication. I suspect we will quickly see the Natco version smuggled out for sale on foreign shores, and I also expect we will see counterfeit versions claiming to be smuggled Natco which may or may not even come out of India (and may or may not contain cancer fighting drugs.)

So... a wheel?

For one, there's the second hand game market. DRM does a good job of killing it. Even with Steam, there's no way to sell your old games.

It's a stupid argument too, though; you have to be willing to suffer all of this bad press and associated lost sales in the hopes that you will get extra sales in the tail end of your product's life-cycle.

It also fails to take into account that most people have a certain finite amount of disposable income they're willing to spend on games. I suppose the studio would rather see you spend money on one new game instead of one two used games, but on the other hand the guy who sold those two used games is probably going to take the money and spend it on a new game.

CIRA (the ".ca" registry) has a feature called "whois privacy" which hides the information of individuals who register domains by default. Only businesses get their information published in the whois database (by default - individuals and businesses can turn this on or off, although businesses need to provide CIRA with a good reason why they want their whois info hidden).

But, you get yummy imu roast pig at the end! You don't get that with a PERL script.

So, 10^80 atoms in the universe, which is around 2^265, so 2^768/2^265 = 2^503, or a universe 2.6x10^151 times larger than ours (with all of the caveats I've pointed out elsewhere in this thread about how that's a very rough guesstimate.)

Thanks for pointing out my craziness. :)

nm

Unfortunately, no. We're only trying to factor composite numbers. Prime numbers are easy to factor; they only have two factors, themselves and 1.

Each and every non-prime, or "composite" number is a product of two or more prime numbers. For example, 28 is the product of 2, 2, and 7.

So, we can actually eliminate all the prime numbers from the chart. You also can eliminate all the composite numbers with more than two prime factors, if your objective is only to break RSA.

But using current technology we also need a lot more than just one atom to store each record of the table in. Even using holographic storage you'd need around 10 atoms, and using a traditional hard drive you'd need around 12x10^18 atoms.

It's true, and you'd also have a hard time encoding two primes on a single atom. But the current estimates on the number of atoms in the universe vary pretty wildly, so it's not a bad guess.

If you really want a more accurate estimate of how much larger a universe we need, you first need to compute the number of composite numbers which are the product of two primes and are less than 2^768. Let K be the number of primes less than the square root of 2^768:

K = PI(root(2^768))

(where PI is the prime-counting function)

The number of composites, N, is "K choose 2", plus all the square numbers:

N = K!/2*(K-2)! + K

So that's the size of the number of values we actually want to store. Storage wise, assume we can store these all in a table sorted by the composite number, and then use a binary search to find the number we're looking for. (This is of course completely preposterous; while you'd only need to access lg(N) records to do a binary search, which is going to be way less than 768, your hard drive is going to take on the order of 10^230 square inches of space to store all this data, so it's going to take your read head a LONG time to do 768 reads all over the disk).

For the naive storage scheme, you'd need 3*768 bits to store each composite and it's two primes. The actual number of atoms you need is dependent on your storage medium. The average storage today for hard drives is around 250GBit/in^2. Stanford has managed a bit density of 35bit/electron with holographic storage technology, which is mighty impressive; you'd only need around 5 atoms per entry.

Then you need to pick which estimate of the number of atoms which exist in our observable universe you like best. :)

10^80 is less than 2^84.

2^4 is 16, so 2^84 == 16^80, which is obviously larger than 10^80.

Other people have explained factorization in this thread (finding the prime factors that make up a composite number), but I just wanted to point out why making a "nice big chart" won't work.

The "nice big chart" would have to be very big. If you wanted to factor all the numbers from 1 to 2^768, you'd need a chart with 2^768 entries on it. This chart would need to be made of something, or stored on a disk that was made of something. Made of something means it needs to be made of matter, which means it needs to be made of atoms. In the observable universe, there are about 2^84 atoms, so you'd need a universe around 8x10^205 times larger than ours to store the chart in.

The original "God Mode" one isn't in that list. And, this doesn't say anything about creating folders with the canonical name as the extension. It's an interesting hack.