Hi, Mike. I am still alive alive but greatly limited.

I looked at the first paper, which as you know is not about batch verification. It gives a speed up if you know R that we should already get with just r, with our pseudo Koblitz curve. But I discovered that I had missed an essential optimization in my Koblitz implementation, which is to split the G multiplication into two, with half size exponents. This should increase the speed-up from 20% to more like the 40% they claim. So thanks! (Not that I can do anything about it. Hopefully this hint will be sufficient.)

On batch verification, I had thought of a much kludgier approach. Bear in mind that in the current signature (r,s), r is just the x-coordinate of R. So we need to supply the y-coordinate. (Actually, that's not important, but it saves a little space.) So presently the scriptSig pushes the key and the signature on the stack. My idea was to first push a magic number and the y-coordinate of R. Hopefully, legacy code would ignore these two deeper stack values, and just verify the signature traditionally. But new code could check for the magic number, reconstruct R, and do batch verification. This way transactions could be broadcast that were backwards compatible.

Your idea is cleaner but I am concerned about transaction hash consistency between old and new nodes. Old nodes don't see R, so I think new nodes can't hash it. And it might have to be that way forever. On the plus side, this would let you go back and convert all existing transactions to the new format, giving benefit from batch verification immediately.

I'll try to look at the second link tomorrow and see if such dramatic speedups are possible. I did try an experiment where I patched out signature verification entirely, just had it return true. I didn't get all the speedup I was hoping for on initial blockchain download. Be interesting to repeat that now that it takes so much longer.

I got an M-disk drive from Amazon using spendbitcoins.com.This is supposed to use a high power laser to etch the data into special rock-like DVDs .It should last a long time. The DVDs are readable by any conventional drive.

http://www.amazon.com/LG-Electronics-WH12LS39K-Internal-Rewriter/dp/B00632U162/ref=pd_bxgy_e_text_b

I recently found the 0.1 source code on one of my computers. I can send it if you want it, but I'm pretty severely disabled these days, so it may take me a while to respond.

File this one under "you can't win."

I fired up the new client after several days, the progress bar immediately went to 99%, and stayed there for the next ten minutes. I guess some people found the old behavior confusing, but of what use is this behavior?

How much entropy does a live cd have after booting?

Do you have to convert your btc to USD to write a call?

Just noticed that we've reached "shave and a haircut" parity. The old secret knock is becoming true once again.

Research dollar cost averaging.

How about a limerick?

There once was a girl from Des Moines
Whose breasts were as fine as her loins.
"I'll do tricks for dollars,
Make all my guys holler,
But I save my best stuff for Bitcoins!"

(Probably should've posted anonymously...)

Every day that goes by and Bitcoin hasn't collapsed due to legal or technical problems, that brings new information to the market. It increases the chance of Bitcoin's eventual success and justifies a higher price.

This patch might work for the import
http://forum.bitcoin.org/index.php?topic=9046.0

Flipping a bit your way.

Any successful replacement of the Bitcoin block chain will forever undermine the credibility of any successor. How is an investor to know that it won't happen again?

Rebooting now may benefit a few thousand early adopters. What happens when hundreds of millions use Bitcoin 2? They'll be just as jealous and envious of you as you are of others. Given the precedent you want to set, how will you argue against yet another reboot?

I'm the author of this code. The main.cpp code sends a version message in response to receiving one, on inbound connections.

Sorry I haven't responded, communicating is hard for me these days. This seems to be a very good and sound approach. I would not bother to use longer keys for the master key, chances are the user passphrase will be the weakest part. Also I would stay away from point compression for patent reasons. 

Sent 1000 btc to a friend as a test transaction the first month. Luckily he sent it back. 

I started using Bitcoin the first day. Satoshi sent me 10 btc within a day or two, so he must have spent at least one of his early blocks.

Exactly what do you mean by money laundering?

One way to deal with the key-addition attack would be to store a MAC (keyed crypto checksum) with the encrypted data (priv keys). The MAC key could be either an alternate hash of the encryption passphrase, or a hash of a separate MAC passphrase. The MAC passphrase would have to be entered whenever the client started, and the MAC key would be stored in memory while running.

I agree, we should be very conservative about this part of Bitcoin. It is the foundation of value for the whole system.

Q on the video:

You received 1 btc, then before it was confirmed, made a payment of 0.1 btc. Was that payment real? When we cut to the future, the 1 btc tx had 2 confirmations, but the 0.1 had none. Both txns could have been confirmed in the same block. Do you know why that didn't happen?