Not that I know of, as of the current release, but I could provide a quick/unofficial patch that automatically copies the signed message to the clipboard, if you're interested.

There is a new patch that adds support for importing compressed key pairs into electrum. However it hasn't been fully reviewed yet. See here: https://github.com/spesmilo/electrum/pull/28

I'm not sure, but I think you need to wait for a couple of confirmations for the rest to become available.

Hmmm... Got some reports that it's still running slower than it should on Vista/7 (even though it's no longer freezing).

Running it on an XP system results in significantly faster response times.
Not sure why that is - still investigating.

[EDIT]

Version 1.43 is ready!

Fixed a few GUI bugs, and it should be noticeably faster on Vista and 7.

@samr7:

when searching for a vanity pattern, it occured to me that you could match the compressed keys for each generated secret as well. That would double the efficiency/expected ETA of pretty much every query, wouldn't it? Well, perhaps not double, but at least greatly speed it up...

Or am I just saying nonsense again?

Even a non-connecting physical device doesn't offer more security per se.
If it's a physical device, it's usually closed source software, which means
a malicious vendor could program it to "generate" keys that are not really random, and that could be harvested at later time...

I suppose you could easily use my little "Deep Space Vagabond" application on an offline, freshly installed computer, to generate new addresses at the click of a button. See link in my signature. Source code to the very first version (which was a command-line Python script) is freely available to all, while source code for later versions is available to donators.

Alternatively if you're comfortable running Python command-line scripts, someone (I need to remember their name) made a wonderful little script doing just what you want. You could set up a Python environment on an offline computer, and then generate your keys using that script. If you're interested I can you look it up and post it here for you.

One last option is to use the fantastic vanitygen command-line tool directly. It is actually what my app relies on for generating addresses.

EDIT: at first, I didn't realize you were looking to build such a device yourself - sp my post is mostly irrelevant

Animated or not?

Also why did you delete your post immediately?

Thanks Pieter. Is it easy to compute the uncompressed equivalent public address from:

- the compressed public address
+ the private key expressed in WIF compressed format

- the compressed public address alone?

Sure, here's a step-by-step guide I once compiled for this:


A. To sign a message:

1. Hold SHIFT down while launching Electrum
2. (Only if the address is external and must be imported)
    Import your address by typing:
    e -o import 1YourBitcoinAddress:5YourPrivateKey
3. In the virtual console that has appeared, type:
    e signmessage 1YourBitcoinAddress "MessageLine1\nMessageLine2\nMessageLine3"
  
    This should output the base64-encoded cryptographic signature.    


B. To verify a signed message:

1. Hold SHIFT down while launching Electrum
2. In the virtual console that has appeared, type:
    e verifymessage 1YourBitcoinAddress "TheSignature" "MessageLine1\nMessageLine2\nMessageLine3"    
     (Be sure to include the quotes.)

   If successful, this must return True.  


Note that all of the above can be performed on a non-networked computer, if preferred.

PS: hopefully in a future release, these commands will be accessible from the graphical interface. For now, they are only available through the advanced (text-based) console.

TIL that one private key corresponds to more than one public (base58) address.
(Yeah, I admit I'm still a newbie for these things...)


The question is, how many of those public base58 addresses exist for one given private key?

Is the answer 2 (one "regular" and one "compressed") ?

[EDIT] By private key, I mean "32-byte secret', in case that matters.

Is genjix still involved? I haven't heard from him since the conference. I hope he's OK and will be back to lead this project soon!

Version 1.42 has been released!

- Windows Vista/7 startup freeze fixed
- faster address generation
- Now autoconnects to local ABE server if detected!  (thanks, grimd34th)

Nvm, it was actually just a misunderstanding on my part.

EDIT: wasn't easy, but I found the answer I was looking for here:
 http://sourceforge.net/mailarchive/forum.php?thread_name=CAPg%2BsBhDFCjAn1tRRQhaudtqwsh4vcVbxzm%2BAA2OuFxN71fwUA%40mail.gmail.com&forum_name=bitcoin-development

Sorry to insist, but are you sure? How do compressed private keys (introduced in bitcoind/bitcoin-qt 0.6.0) fit in there? From what I've been able to read, vanitygen doesn't support them and they are actually separate from noncompressed keys (ie, can't be expressed as normal uncompressed base58 keys) - so what proportion of the 2^256 search range do they represent? Or am I totally misunderstanding compressed keys?

Hmm perhaps my question wasn't very clear. I'm aware of what you said, what I meant to ask is, does it search within the full (2^256) range of possible private keys or a subset of it. I would have checked the source myself but my C/C++ is a little too rusty...

Thanks for clarifying that.
As for BitcoinJ, I thought I read somewhere that it wasn't a full node at this time but might become one in the future. Can't find that post right now, though...

Interesting development on the bitcoinJ front... I'm not qualified to comment on it from a technical point
of view, so I would really like to hear any comments from the experts

Not sure how technically feasible it is (it would perhaps require some protocol changes and cooperation with bitcoinJ devs), but perhaps it would be nice if Electrum (the client) could eventually get the ability to directly connect to BitcoinJ nodes (in addition to Electrum servers)?

If this is possible, I think it could actually be a good thing for Electrum in the long run, as it would bring a nice solution to the issue of having potentially malicious servers.

I guess it depends what you mean by "depends on"

Their code doesn't depend on bitcoind in the classical sense, but as far as I know, they do still depend on
it because they are not full-verifying nodes, so a network without bitcoind nodes to connect to can't operate properly (correct me if I'm wrong).

 

Which gets me wondering, does Vanitygen search the entire keyspace? (*)
If not, what proportion of the entire keyspace does it search?

(*) What about addresses associated with compressed keys?