I must say that I'm more than a bit peeved that my proxy code was rewritten and broken. The changes in current master break the ability to load a proxy config. I looked at the changes and thought it was broken but had to pull the current master branch to be sure. I also don't much like the numerous minor syntax changes. What I wrote was tested and worked and now it's a broken mess.

Currently if you set a proxy mode and save it will not get picked up when you start again. It also breaks the ability to disable a proxy to None with a cmd line option since None is no longer supported. These are things I tested fairly extensively before submitting my code. The changes also break fine tuning I made later and probably will result in conflicts when bringing in further improvements I've since made.

I've got whole slew of small and useful changes in my fork and I don't plan to do pull requests on any of them. All of the below are tested as working on my system. No one seems to have bothered testing them elsewhere. Socks support worked too before it was mangled up.

  confirmation-tooltips - use tooltip for confirm count instead of passing tx data
  exchanges-proxy-mode - proxy support for exchanges
  filter-history - show only selected address transactions
  import-addr-or-key-only - add watch only address support
  multi-exchange - allow selecting which exchange to use for quotes
  multi-select-send - easy coin control
  pro-show-currency - add currency quote next to balance in pro mode
  qr-scalable-centered - make qr code scale with window and centered
  red-debits - show withdraw/payments in red text as std for accounting
  remember-column-widths - stop having to re-set column widths
  sahara - new sandy brown theme
  shrink-gui-lite-settings - allow changing back to Lite mode from Pro

Right now, I'm a quite disgruntled with how this project is run. I'm not going to write code to just have it f'd with and overridden with breaking changes. I'd love to see Electrum improve but if the current devs prefer it stagnate then no problem, I can go put my efforts elsewhere.

I don't see that point of me testing my code extensively just to have it merged into master and then edited without my knowledge and broken. Shouldn't breaking changes be tested before merging in master? Doesn't that make bloody sense? Is there any rules about flow here or do people just edit willy nilly in master branch as they please?

Here is a specific suggestion for Electrum: I want to take k pieces of paper, divide the wallet seed into n parts and write on each piece of paper m of the n parts. The pieces of paper will be stored in different locations, so that someone needs access to several locations simultaneously in order to recover the wallet seed. Now, the seed being 128bit long, simply dividing into n shorter parts doesn't work even for n=2 because 64bit is not secure enough against brute force attacks. Each part should be 128bit as well. Maybe Electrum can print out n seeds, 128bit each, which XORed together give the wallet's seed?

Per communication? So you exchange the key with someone? Ah okay, that would explain it.

I understood client side encryption merely as a feature that the encrypted messages are stored in the database so that not even the pod owner can see them, but users on other pods that don't have the same feature would then not be able to decrypt them (regardless of what diaspora additionally does in inter-pod communication), even if they are in your aspect.

For purposes of posterity, here is how my cryptosystem is designed:

    Four keys are generated for each user, one key for each of these purposes: encryption, decryption, signing, verification.
    The decryption and signing keys are encrypted to the passphrase specified by the user.
    All keys are stored on the server.
    The passphrase is stored only in the user's browser using the HTML5 localStorage facility. Unlike traditional cookies, objects in localStorage are never sent over the network (unless explicitly made to via an AJAX call or something like that). This setup means that you need to re-enter your passphrase on any additional browser that you want to use to view encrypted messages (hence the reason for my first enhancement in my original post above).
    Encryption and verification keys are made public to all Diaspora users as part of each user's webfinger profile.
    When a private message is sent, a lookup is performed to verify two things: that a decryption key for the sending user is available and that an encryption key for all recipients exists. If both criteria are met, the message is encrypted prior to being submitted to the server. If either are not met, then the message is sent unencrypted.

I'm actually not using the signing and verification keys with Diaspora right now because D* already has it's own message signing mechanism and I don't see much point in duplicating that functionality.

how does it work with the client-side encryption and communication to other pods? not, i guess.  

Now that it's clear... why is this silly?

As now clarified:

By the same broad logic, people shouldn't use checks.  Anyone could write a bad check, or put a stop payment on a good one until cashed.

Narrowing it a bit, using checks is sensible when the parties have trust or recourse.  Is the same not true for conveying private keys?  Conveying private keys allows people to transact in Bitcoin units in the immediate absence of power, internet, and/or properly configured hardware, an ability taken for granted with fiat cash/checks and a feature the common populace is going to expect from any currency meant to replace it.

Why is this silly?

It sounds to me almost like saying "using any phone but the iPhone to make phone calls is silly".

Do you mean that the phrase "redeeming a private key" is a silly way to describe conveying a private key as a means of transferring bitcoins, or just that you believe that people ought never to transfer value by conveying the private keys encumbering it?

Another concern with deterministic wallets is that if a key is imported (not sure if my terminology is 100% correct here) into the wallet any btc associated with that transaction can't be recovered from the seed. Therefore, the wallet.dat needs to be backed up regularly and the seed can't be exclusively relied on to recover all the btc. I guess there is no free lunch. Despite the ease and benefits of a brain wallet you better not forget to backup the wallet!

Is this true or am I confused?

Also, why is it even necessary to import keys from another wallet (is the term sweep)? Why not just send the btc via a transaction to avoid the above problem? Is it a matter of how time consuming it might be?

Correct. Well, to be precise, you also need the seed S (besides the master public key and a single, non-master private key). Electrum uses the master public key itself as the seed, while Armory uses what it calls a chaincode. However, this doesn't make a difference because for practical purposes, i.e. in order to be able to generate the chain of public keys, both the master public key and the seed will be stored together on the same machine.

So, what are the benefits? I don't really mind ads. Why should I register to that diaspora?

About:

  Ecdsa.org is a Diaspora pod for Bitcoin users. Its features are:

  * Paying registration.

  * No advertising. No disclosure of private user data.

  * Client-side encryption: your private messages are encrypted in
    your browser, with a key that is kept on your computer. Thus, we
    cannot read them. Even if our database is compromised, your
    private messages will never be disclosed.

 * Support for 'bitcoin:' links. (I guess this will soon be merged
    in the main Diaspora code)

  * Support for Bitcoin aliases: you can receive Bitcoins at your
    Diaspora handle: your_name@ecdsa.org
    (For the moment this is only supported if you use Electrum,
    but a common spec should be decided soon, according to Gavin)



Terms of service:

 * The registration fee is 1 bitcoin. Registration is not limited in
   time; you will not need to renew your registration.

 * Partial refund guarantee: should the ecdsa.org service be
   terminated for any reason (financial, legal or other), users will
   have the possibility to retrieve their data and to transfer their
   account to another Diaspora pod. Users who have been registered for
   less than 1 year will get a partial refund, proportional to the
   time remaining from their 1 year guarantee period.

 * Account termination: We may terminate any account in case of
   behaviour that we deem non-appropriate: breaking US or EU law,
   abusing our hosting capabilities, or otherwise threatening the
   existence of this pod. No refund shall be claimed in this case.

 * Modifications: The present Terms of Service may be updated or
   otherwise modified at any time. In case of substantial
   modification, users will have the possibility to opt-out and
   receive a partial refund.



FAQ

 * Do you use free software?

   Yes! We use the same software as other Diaspora nodes, with a
   few modifications intended to facilitate the use of Bitcoin. The
   modifications we added to the code are free and public, protected
   by the GNU AGPL Licence.


 * How are private messages encrypted?

   Your private messages are encrypted in the browser, using a
   javascript extension written by Justin Thomas and deployed at
   ser.endipito.us. This means that messages are decrypted locally,
   and only you can decrypt them. Even if our database was stolen or
   confiscated, your messages would remain private. (Note: depending
   on your jurisdiction, you may be required to give your encryption
   key to law enforcement).


 * Is javascript safe?

   Client-side javascript encryption offers the same level of security
   as so-called 'web wallets', such as blockchain.info. That is, if
   our website is compromised, an attacker could in principle send you
   malicious javascript and steal your key. However, in practice, such
   an attack would be noticed quickly. In addition, we plan to develop
   dedicated apps or browser extensions, that will not be subject to
   this.


 * Are images encrypted?

   No, images are not encrypted. Neither is your list of contacts.


 * Why is there a registration fee?

   The fee is here to cover our costs, to ensure quality and sustainability
   of our service, and to allow us to develop new features for the
   Diaspora software. Other Diaspora nodes typically have relied on
   donations or advertising; we believe that Bitcoin, because it
   respects the privacy of users, allows us to use a different
   strategy.


 * Isn't the price too high?

   We are one order of magnitude cheaper than App.net, a famous
   ad-free paying social network. At the time of writing, their price
   is $50/year. In contrast, our registration fee is 1 BTC once and
   for all; there is no yearly renewal of your subscription.

   In addition, we are not in a situation of monopoly, with a closed
   network and captive users, like Facebook or App.net. We are part of
   the open Diaspora network. Anyone can run a Diaspora pod and
   propose the same service for free, or for a lower price than us. We
   believe that this will create a situation of healthy competition,
   which is in the interest of users.


 * Isn't the price too low?

   We do not know if the current registration fee will allow us to
   cover our costs in a sustainable way; we did not run a market study
   for that. If it turns out that we need to increase our fees, early
   subscribers will have gained a bargain.
  

 * Can I pay with Paypal or credit card?

   No, you have to use Bitcoin. Diaspora pods often gather communities
   of users who share common interests. This pod is dedicated to the
   Bitcoin community, and we want our users to be Bitcoin users.

Bkk, would it be possible for you to create pull requests for specific functionality. So we can asses on a per feature basis if and how to merge it back into master?

At the moment it's quite hard to assess this because you have been so active ^^

The clients that offer type-2 deterministic wallets (like electrum and armory) should advise their users that sharing any private key from the derived chain (not the master private key, of course) MUST be avoided. Such a sharing of a private key could happen for example by funding your MtGox account with the "Redeem private key" option.

If you disagree, you're wrong.

Thomas, i have no reason to doubt your integrity as Electrum appears to be working for everybody quite well.  But i have to play devil's advocate and ask what is preventing you from inserting malicious code on the server end or into the client at some point in the future to allow you to upload private keys from the offline wallets once they are decrypted?

Because some of the innovators (like Satoshi (???BTC) and mbknight (371k BTC) have hoarded there early mined bitcoins and never used the majority of them to date.

Now going back to the cmdline the addresses show up and the 11th one is the change address. I guess that's why it didn't show. So it looks ok but why didn't it work until using the GUI mode? I would want to be able to use the client offline on a cmdline only system to do recovery. Still a little fishy there.

Opening with the GUI changed the file size from 685 bytes to 1555 bytes.