You're probably getting little response here because this has been asked so many times over that a bit of searching would get you some answers. I know I've repeated my answer below in similar ad-hoc terms at least 5 times over the last year.

An Electrum seed is 128 bits so there are 2^128 possible seeds. Let's say there are 1 billion seeds in use by users which contain some balance.

2^128 = 3.402823669×10³⁸

1 billion = 1.0 x 10⁹

So you would have to search a space of 3.402823669×10³⁸ / 1.0 x 10⁹, or

3.402823669×10²⁹ seeds.

For each wallet check you need to generate the seed, and check a few addresses against the blockchain. If you used a local RAM copy of the blockchain and you were able to check 1000000 seeds / second then in one year you could check 60*60*24*365*1000000 seeds. Or about,

3.1536×10¹³

Leaving you with a task that would take 1.079028307×10¹⁶ years. But wait that's still too long so we better assign a cluster of a 1000000 computers to generating and checking seeds, because any tiny balance on any of a billion seeds may be worth it...

Now we're down to, 10,790,283,070 years.

We'd better get right on it.

This plugin was not intended for offline cold storage. Obviously the 12 word seed is the best way to do that.

This plugin was intended for cases where the intention is giving away small gift amounts in bulk but still maintaining the ability to clawback unclaimed balances. Several people have wanted such a thing in the past and had to resort to keeping lists of private keys, and then manually monitoring them. This way you can easily keep an eye on what gifts are claimed or left unused.

Do not use this plugin with a wallet intended to be secure offline storage.

@Yakov,
If you don't get the Tools, Papergen menu item then it is probably related to not having an open wallet. I couldn't find a generic start-up hook for plugins to trigger attaching a new menu item, so I do this on the wallet-open hook.

Can you add a Thai version? I can work on that with my wife (native speaker).

The easiest way to handle this is to boot off a clean OS install (or live cd), connect to the net, update your OS, install Electrum, and disconnect. If you never connect again it is close to impossible that, even if you did get a keylogger or infection during the brief install process, it would ever be able to send funds. The only way I can see if is the Electrum code itself was subverted such that it would alter transaction content during signing - which installing offline as you propose would not prevent anyway.

This has been an issue for me for a long time. It's quite annoying. A couple times I started looking at fixing it and doing a pull request but after exploring it seems to be more complicated than a simple fix. But one thing I was thinking is that if any address line is selected then the updated could be blocked, or less often. Right now it just becomes a real pain to do anything more than a quick glance at addresses. If you need to spend time checking some values or doing something then you are constantly having to re-scroll and re-open groups. A more comprehensive fix would update contents in some less destructive way than just reseting and refilling.

Update: I've added a Christmas themed layout as sample on github now.

This background image was designed by QuickBT.com and they indicated it was CC licensed with attribution. So with permission I've adapted it slightly, with Merry Christmas (and a little less conspicuous credit line).

Here's a screen grab from a PDF with a BIP38 encrypted key.

I placed it immediately before the seed version. eg.

'imported_keys': {}, 'seed_version': 6}

becomes,

'imported_keys': {}, 'gap_limit': 10, 'seed_version': 6}

There is a cmd line option but in my testing it made no difference. That is, starting with -G 10 still didn't behave as if gap limit is 10 and see new addresses used.

If this would work it would probably be good enough as users could simply alter the menu/icon start cmd to have this option set.

However, I did find that if your add a 'gap_limit': 10 at top level in the wallet file then it does behave correctly and respect new addresses. ie. red addresses become normal.

You should be able to use N number of 12 word seeds and combine them using the hex representations to give you a single 12 word actual wallet seed. The only thing you need for this is a way to generate 12 word seeds and sum them.

In my github misc repo I have a collection of seed utilities that allow you to do this and more.

Like this,

for x in 1 2; do ./seed; done | ./addseeds

seed is my util for generating a seed (it uses code extracted from Electrum)
addseeds will read stdin and sum the seeds (whether hex or 12-words) and output sum

The line above generates and prints 2 seeds and then the sum seed.

You can use the same addseeds to re-combine later like this,

echo -e "first 12 words\n2nd 12 words" | ./addseeds

or can read from a file,

cat myseeds.txt |./addseeds

(prints both inputs and output sum)

-----

I would also note I have a simple util there called b2b that converts bases using alphabets for each base. With this you can roll dice and output hex values to create seeds using hexseeds. eg. with dice rolls (need something like 99 rolls, not just a few as here), base 6 to hex,

./b2b 1624351  123456  0123456789abcdef

I've created a new plugin for Electrum that provides quite sophisticated Paper Wallet functions. I'd appreciate if users interested in this could have a look and test it. I've done a basic amount of testing on my own Ubuntu install but have not attempted to use it on other OS.

PaperGen allows users to easily:

- generate addresses in bulk (or use existing ones)
- print paper wallets to PDF using SVG templates (samples provided)
- fund those addresses with one multi-output transaction

For additional info see my new repo readme at,
https://github.com/bkkcoins/papergen

If you have the scrypt module available then BIP38 support is enabled. (sudo pip install scrypt).

You can tweak or create new SVG templates with Inkscape. I provided a few samples using the Mike Caldwell colornotes images. Details on variables/layout rules in readme.

Advantages of using this method for paper wallets:

- only need one app if already working offline with Electrum
- can create bulk wallets for giveaways / gifts based off a seed so that unclaimed funds can be swept back
- easy to split a single balance into a series of separate paper keys, thereby reducing risk of a single large theft
- easy to tweak your own layout graphics using Inkscape

Please have a look. I welcome feedback. Use care with real funds as this probably needs more testing before it's fully trustworthy. ie. BETA software

The Android app doesn't seem to scan watch only addresses properly. At least for me it will not scan a QR with a proper url like bitcoin:1blahblah... as provided by Electrum.

This is very annoying. It's the only easy way to get a watch only address from the desktop into the Android wallet for monitoring without having a rather bothersome exercise of cutting/pasting copying across emails or otherwise copying data across. (Actually I don't see any way to import an address other than scan QR so maybe it's not just hard but impossible?)

Is no one else having this issue? The QR code seems to be fine and is read by QR Droid.

I posted this as an issue in the github repo but it seems to have been ignored, or is there some other reason why it should not work?

Don't mind at all.
It hasn't had a lot of testing. I've tried to make it safe with prompt info but users should be careful.

Also, it may need some attention regarding a security audit. It uses HTTPS to access the API but I wonder if a MITM is possible. In theory it should as safe as using the web site. One thing I can think of off hand is DNS poisoning on local net. Users should be aware that using anything that provides an address on a insecure network has potential to spoof them.

I haven't tried that but I think it should work.

Thanks! But how or where tipped?

I've updated the mixer to work independently of Electrum mainline now. As long as you have the latest version you can now simply drop the mixer.py file into your plugins folder and it will be available and can be enabled. It no longer needs a separate fork or Electrum version.

The standalone mixer plugin file is now:

https://github.com/tkhaew/electrum/blob/mixer_plugin/plugins/mixer.py

The default folder where this is can be dropped (on my Ubuntu system anyway) is:

/usr/local/lib/python2.7/dist-packages/Electrum-1.9.5-py2.7.egg/electrum_plugins/

( though the version number could be different )

It's kind of funny when a newbie comes along and tries a naive approach to cracking something.

In this case he doesn't seem to understand he can totally remove all the code related to guessing words, and decoding them, and simply generate a 128 bit random number as seed directly. That should speed this up somewhat but to go even faster he may as well just increment a counter and check seed values sequentially - it has the same probability and would be faster still and not run into a depleted entropy pool.

2^128 = 3.402823669×10³⁸

One billion balance checks / second (very unlikely even with 10,000 computers attacking) looking for a hit in one of 2 millions addresses (current number with non-zero balances in network), would still take,

3.402823669×10³⁸ / 1x10⁹ / 2x10⁶ = 1.701411835×10⁵³ seconds,

or 5.395141537×10⁴⁵ years.

I wish him good luck.

I've created a mixer plugin for Electrum to support in-client use of the blockchain.info mixer. It's not quite standalone as Electrum doesn't really support dynamic loading plugins (which would be a nice thing to work on someday), but the changes to the main program are very minimal to hook it in, and the plugin itself is very simple.

It gives you two new features. A button to request a forwarding address when you send coins, with mixer fee estimate, and a right-click menu option for a forwarding address when showing a QR code for a receive address. These simply make an API call and present the address for the user to confirm.

This plugin will not be integrated into Electrum main line because the devs feel it maybe endangers the project by having a mixer associated with it. I feel it improves usability for those who want more privacy and may be a useful stop gap until the Dark Wallet guys finish up their work.

The plugin is available to anyone who wants to use it in a fork I created just for this purpose, in a branch called "mixer" based off the current master,

https://github.com/tkhaew/electrum/tree/mixer see below


Have a look if you're inclined and comments are welcome.

Hello,

On Sept. 1st I was involved in a motorcycle accident. I spent 3 weeks in the hospital with broken ribs, a broken leg and a serious head injury. My physical/mental state after returning home was poor, and I did not want to deal with any klondike issues for some weeks after that. I am ok physically now.

At the end of October I started reading through over 1300 emails I had, deleting ones that I could not help with and saving the ones relating to orders. After much procrastination, today I read this forum thread to catch up on everything that has happened. I avoided it for several weeks because I was sure it would be a colossal disaster, and everyone would be ready with pitch forks to blame me. I'm happy that bugs were found and fixed and that people are able to get decent hash rates, but I don't think I can help further with development (except perhaps push up previously completed bootloader code I wrote but never debugged).

At this time I want to try to handle refunds for orders that were never shipped for those requesting them. I have very little funds left for this due to a large medical bill here (no insurance), and having to pay for a friend's motorcycle (which seemed to vanish while I was gone). I am able to refund most of the orders at least partially if not fully. Maybe fully. I'm not sure.

I also have heaps of k16, k1, klego and picngo boards, stencils and other stuff here which I can ship for anyone who actually wants them at this point. I also have full parts and Avalon chips enough for about 12 k16s, which I intended to build myself but never started.

The last few weeks have been challenging for me and I have not wanted to deal with any of this. I came close to not returning here at all but decided it's better I try to deal with refunds to the extent I can, and at least let people know that I never planned to drop out, or scam anyone.

I hope you'll accept my apologies for being so late to speak up here. Posting sooner may have alleviated some concerns, but I don't feel I would have been able to help with technical matters, and didn't want to get involved again.

I'll try to deal with my emails related to requests soon. I have not read my PMs here yet and will try to skim through those in the next few days.

Chris.

I'm still here and haven't abandoned the project. I've had some disruptions over the last week as the tile guys that I've been waiting for since March finally arrived and started putting in floors. I've been moving stuff around from room to room, and it's a mess, stuff piled up everywhere. Timing couldn't have been worse, and my time diverted. I'm setting up my workbench and tools again and back working again, though the room I'm in still has no floor and I'll have to move back again in 2 days. If it were just me here I could probably have delayed them but my wife (and other family) presses on me as well. Plus I really need a floor.

I appreciate the kind words above and want to finalize this whole thing so I can move on. I feel like I'm stumbling around not knowing what's actually going to happen regarding Avalon chips, much disheartened by everything, but trying to keep a more positive outlook.

The serial # is different from the USB Product ID I received from Microchip. That is used for identifying the board at the USB level and would be the same on all K16/K1 boards. The 0xdeadbeef serial# should be replaced by an actual serial# during production. I'll be adding a ktest command that will enable setting serial# in some automated fashion for production. The only functional difference it makes is for enumeration of chained boards, which is not operational yet.

Either will work. I don't recall when I changed them on the schematic or why. 1K should be better for a longer chain length (higher line capacitance) but 2.2K is probably more normal for I2C and would use slightly less power. In fact, with multiple boards the pull ups end up in parallel and 2.2K or even higher is fine.