Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.47 as permitted sender)
	client-ip=209.85.212.47; envelope-from=mh.in.england@gmail.com;
	helo=mail-vw0-f47.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
References: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
Date: Fri, 26 Aug 2011 13:42:29 +0200
Message-ID: <CANEZrP2FYjJXvB=kzu+wBcoGOyL=45QeDqLfyZONxYu-9M50Uw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New standard transaction types: time to
 schedule a blockchain split?
Precedence: list

> It seems to me the fastest path to very secure, very-hard-to-lose
> bitcoin wallets is multi-signature transactions.

Agreed.

That said I'm not sure it makes sense for payers to care about the
details of how somebody is protecting their wallets (which is what new
address types means). It's possible for a users software to notice
inbound payments to a regular Bitcoin address and then immediately
respend them to multi-signed outputs. This way key management can be
simpler as you don't need to integrate it with your shopping cart
software or anything like that - you can just do the usual thing of
pre-generating a few hundred thousand addresses, fill up your cart
implementation and go. When a payment is received, your wallet
software can keep an eye on how much unlocked balance it has and start
locking value once it goes over a pre-set amount, or use any other
policy the user might have.

This fits with my belief that we'll eventually move away from senders
attaching tx fees, instead receivers will respend the fee-less
transaction adding whatever fee they believe is appropriate (eg, maybe
it's very low in the case of a buyer with good reputation, or higher
for unknown buyers). It doesn't make a whole lot of sense for buyers
to have to attach more fees just because the merchant is using complex
wallet policies.

Whitelisting the basic CHECKMULTISIG form (assuming it can be made to
work) seems uncontroversial, why not do it today? The forms designed
to make fancier addresses be embeddable inside QRcodes, can come later
if people feel it's necessary. I'm still not convinced it is.

Once malware can't just email wallets to the attacker, or steal the
keys when the user decrypts due to a second factor, the next easiest
attack is to that malware can rewrite addresses on-screen as it sees
fit, forwarding small payments so the user doesn't notice then
stealing a big one. To solve that, Bitcoin addresses need to contain
not only a pubkey[hash] but some kind of endpoint the second factor
can use to verify ownership of the key. It can be discussed later, I
don't think there are many possible designs here so it shouldn't be
too controversial.