Well, the problem with that is that transmission of power over a grid over long distances is typically inefficient.  It may be more cost-efficient to simply convert the energy to cryptocoins which are used later to offset the cost of fuel.  Also, what if there is a mismatch between renewable power production and demand over a large region (e.g. on a day that is particularly sunny or windy over much of the country).  Then, who do you sell the excess power to?  It still has to be stored somewhere, or used.  Currently, this is not as big of a problem, since renewable production is still only a small fraction of demand in most countries, but we can anticipate that this will not always remain the case.

I disagree.  The cost of photovoltaic panels has come down dramatically in recent years, to the point where in many places, PV is now cheaper per watt than grid power, with only a low payback period (few years) for capital cost recovery.  I know a miner who is building a complete solar-powered mining installation.  His operating costs are extremely low, and so his profit margins are much better than other miners'.  As other miners realize the feasibility of this approach, and the cost/watt of PV panels continues to come down, I predict that PV-powered mining will become more and more popular, and eventually will drive all traditional grid-powered mining out of the market due to the cost differential, also helping to drive widespread adoption of distributed solar power worldwide (at least in high-insolation areas).

Cheers...

During some discussions at our local meetup group last night (http://www.meetup.com/Bitcoin-Tallahassee/), I realized that there is a use case for cryptocurrency mining as a load-balancing mechanism for renewable power utilities, in effect, using mined coins as a form of "stored energy."

The argument goes like this:  Suppose you have an installation of renewable power generation (solar, wind) whose production varies throughout the day, and is not necessarily well-matched to demand.

Currently, either the surplus energy needs to be stored (using expensive battery systems) or exported via inefficient long-distance transmission lines to other markets.

As an alternative:  Renewable power utilities could use their excess power (when available) to drive mining hardware, and collect the (approximate) value of the energy consumed in the process as cryptocurrency.

Then, later, when production is lower (at night, or on a cloudy/calm day), and falls below power demand, the saved coins can be used to buy back surplus energy from nearby partners on the grid, or alternatively, to pay for or offset the cost of fuel (coal/oil/gas/biofuels) to produce it locally.

By proposing this scenario to energy companies and co-ops, one could sell them on the idea of purchasing cryptocurrency mining hardware and doing mining and trading as a more economical means of load balancing, which will help make the adoption of renewables more profitable.  And, as the utilities accumulate cryptocurrency reserves, they will pressure more and more of their fuel suppliers to accept it as payment directly, thereby driving broader adoption of cryptocurrencies within the energy industry.  As renewables become more competitive, and more and more utilities try this approach, it could drive a fairly rapid shift from the "petrodollar" to bitcoin, or whatever.

Load balancing is already a pretty major issue even within traditional fossil-fuel-driven power markets, and with renewables being added to the mix, the problem will only get worse...  So this presents a big growth opportunity for cryptos.

I have contacts at our university's campus utility as well as with a regional co-op, and I'm planning to talk with them about this idea and see if I can get it adopted locally.

Cheers, -Mike

Personally I think Dorian=Satoshi and he is just having a little fun before the FULL story comes out on AP newswire tomorrow.   

Then how did they back-date it on the SKS keyserver?

Doesn't that look mighty suspicious?  They are in cahoots, or the man is trolling us...

http://sks.pkqs.net/pks/lookup?op=vindex&fingerprint=on&search=0x18C09E865EC948A1

Search results for '0x18c09e865ec948a1'

Type bits/keyID     cr. time   exp time   key expir
pub  1024D/5EC948A1 2008-10-30           
    Fingerprint=DE4E FCA3 E1AB 9E41 CE96  CECB 18C0 9E86 5EC9 48A1

uid Satoshi Nakamoto <satoshin@gmx.com>
sig  sig3  5EC948A1 2008-10-30 __________ __________ [selfsig]
sig  sig   E2513C30 2009-01-03 __________ __________ Bitcoin Jesus
sig  sig   04143362 2011-11-01 __________ __________ lzsaver <lzsaver@gmail.com>
sig  sig   DAB591E7 2013-03-27 __________ __________ theymos
sig  sig   7480B161 2013-04-01 __________ __________ Dorian S Nakamoto <mtn_sssh@hotmail.com>
sig  sig   F2E50027 2013-04-19 __________ __________ Antony Bailey <support@antonybailey.net>
sig  sig   2346C9A6 2013-05-10 __________ __________ Wladimir J. van der Laan <laanwj@gmail.com>
sig  sig   FFDB1CCC 2013-07-01 __________ __________ []
sig  sig   F91975FE 2013-09-20 __________ __________ Cubaguy <cubaguy@gmail.com>
sig  sig   7471C2D0 2013-09-21 __________ __________ Harald Schilly <harald.schilly@gmail.com>
sig  sig1  67E4FA04 2013-10-12 __________ __________ Peter Todd <pete@petertodd.org>
sig  sig   7B536415 2014-03-06 __________ __________ Satoshi Nakamoto (Resident of California) <satoshin@gmx.com>

sub  2048g/D6AAA69F 2008-10-30           
sig sbind  5EC948A1 2008-10-30 __________ __________ []

Perhaps related to this (if true)?

http://two-bit-idiot.tumblr.com/post/77745633839/bitcoins-apocalyptic-moment-mt-gox-may-have-lost

It's not clear from those sites if Karpales was the original creator of the domain, or if his contact info is only on there as a result of his having purchased the domain in 2013 (those records say "updated 2013").  I'd say the latter is much more likely.

I don't understand what you're proposing exactly.  Can you explain?

Public keys do not have to be hidden at all.  That is why they are called 'public.'  As long as the account's keypair is generated and stored in a secure way, it is not risky at all to leave your public key out in the open.  Anyway, any address with bitcoins in it is already public  (visible in the blockchain) regardless of whether any coins have been sent from it yet or not.

How about some warnings about the U.S. dollar:

1.) WARNING: Your dollar has a serial number which can be used to track marked bills.
2.) WARNING: Your money in exchanges, banks, annuities, etc. could be stolen or hacked or not easily withdrawable.
3.) WARNING: The U.S. dollar is not government-proof and could be easily debased by the government.  It is not backed by anything.
4.) WARNING: The concept of fiat sovereign currency is not protected by any non-expired patents and can be easily imitated by any third-world banana republic.
5.) WARNING: A developing country's currency might gain prominence and severely impact the U.S. dollar's value.
6.) WARNING: A better currency has already been developed (namely, Bitcoin).
7.) WARNING: Your entire retirement savings might be eradicated in case of bank error, user error (you forget where you put it), your company going bankrupt and defaulting on its pension fund, or politicians changing the terms of your social security program.
8.) WARNING: You are highly likely to be scammed at some point using U.S. dollars in cyberspace or meatspace and often there is nothing that can be done about it.
9.) WARNING: Too-big-to-fail banks and central banks can compromise the financial system's integrity, lead to financial crises and bailouts.  Quantum computers could crack systems used to secure legacy financial networks.
10.) WARNING: No one knows what the U.S. dollar is really worth since it is no longer backed by gold or anything else tangible and its price is purely being driven by Ponzi-natured speculation on the sustainability of the traditional financial/political system.

Yeah Cas, why not just sell coins with BIP38 encrypted keys and no value loaded, for the cost of manufacture + profit, and let the customer send BTC to their coin's address themselves.  I don't see how anyone could accuse you of being a money transmitter in that case.

I don't see it as fraudulent, as long as the person receiving it understands the caveats.  The way I see it, it is the responsibility of each individual seller or reseller of physical bitcoins to make sure the buyer understands the relevant security limitations.  If this isn't done, that's not the fault of the original manufacturer of the coins.

No one should really trust large amounts of money in physical coins manufactured by others containing plaintext keys, but ones with BIP38-encrypted keys are fine if generated using an intermediate code, or where an already-encrypted key is supplied by the user, since in that case even the manufacturer can't decrypt them.  I have seen some physical coin manufacturers that offer such options.

(Note that Casascius is the one who developed this standard, why would he have done this if his business model was to keep the private keys?)

BTW I recently posted a fork of the BtcAddress reference implementation that adds support for BIP38-encrypting existing private keys...
https://bitcointalk.org/index.php?topic=355471.msg3802614

Cheers to all... And Mike, I hope you work things out so you can continue operating.

FYI, I just updated the BtcAddress utility to add the capability to BIP38-encrypt an already-existing private key and then print it as a banknote.

https://bitcointalk.org/index.php?topic=355471.msg3802614

One of the modes of Casascius' BIP-0038 key encryption standard is the non-EC-multiply mode, which can be used to encrypt an existing private key with a passphrase.

Unfortunately, if you would like to use this mode to generate nice printed bank notes with an encrypted version of the private key of one of your existing cold-storage accounts, the BtcAddress app reference implementation does not support this - it only supports creating notes containing brand-new encrypted keys.  The underlying code is already there, but the GUI does not support it.

Therefore, I have made enhancements to the BtcAddress app to provide GUI support for printing banknotes of encrypted keys generated using this mode.

Some links:

• Original Casascius utility:  https://en.bitcoin.it/wiki/BIP_0038#Reference_implementation
• My fork: https://github.com/mikepfrank/Bitcoin-Address-Utility (see cleanmod branch for minimal diffs)
• Precompiled Windows executable: https://dl.dropboxusercontent.com/u/3133557/BtcAddress_mod.zip

Some screenshots:

(New menu item.)


(New dialog box.)

Caveat: The "compress public address" option does not work yet.

(Some data filled in.)


(Resulting encrypted key in collection.)


(Example of a bill that can then be printed - not the same example.)


Obviously, this capability ought really to be included in the master branch of the reference client for better trustability, and hopefully Mr. Caldwell will honor that pull request.  First, the diffs need to be cleaned up a bit - there are a few accidental/unnecessary/inconsequential changes in several files (line-end changes, commented-out code that wasn't used) that are unrelated to the new feature.  The only actual important changes are in the new form AddEncryptedKey and the corresponding changes in the top-level form to add the new menu items.

UPDATE 12/3/13: In the below branch, I have now cleaned up the diffs (reverted inconsequential changes) and submitted it as a pull request.

• https://github.com/mikepfrank/Bitcoin-Address-Utility/tree/cleanmod
  

Comments/tips are welcome...

Thanks, that is helpful.  -Mike

Perhaps people are fleeing Bitstamp because of this:

http://www.washingtonpost.com/blogs/the-switch/wp/2013/11/23/heres-who-probably-did-that-massive-150000000-bitcoin-transaction/

The average transaction time has increased significantly in the last week:

https://blockchain.info/charts/avg-confirmation-time?timespan=30days&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

On this other thread, people were pointing out that some miners were mining unusually small blocks (not including all the pending transactions).  Perhaps we are starting to see the emergence of malicious mining.

https://bitcointalk.org/index.php?topic=328563.0

Here, I compiled v2 of the paper from its TeX source.  There's some error producing the citations but you can still read the text.

https://dl.dropboxusercontent.com/u/3133557/Bitcoin/btcProc.pdf

I thought difficulty related to the number of LEADING zeros, not trailing zeros...