On Fri, Sep 13, 2013 at 07:30:29AM +0200, Vitalik Buterin wrote:
> Great feedback, Peter!
>
> 1. Suppost you just got your 10 BTC month's salary in one transaction and
> you go on a shopping spree. On the first day, you buy a new keyboard for
> 0.5 BTC, and send 9.5 BTC back to yourself in change. On the second day,
> you buy a chocolate bar for 0.03 BTC, and send one change output of 9.47
> BTC to yourself. You then buy a sandwich for 0.05 BTC, and send a change
> output of 9.42 BTC back to yourself. However, the 0.05 BTC payment is an
> unconfirmed transaction dependent on an unconfirmed transaction. Some
> Bitcoin clients register that as invalid, so you might be forced to
> awkwardly wait beside the merchant for five minutes for the transaction to
> clear. Now, suppose you had two 4.75 BTC outputs. Then, the chocolate bar
> would come out of the first output and the sandwich from the second, so
> everything would work fine. I haven't implemented this yet fully; at this
> point, the system would actually make a chain of two outputs, but if you
> make lots of transactions you will eventually have dozens of unspent
> outputs so everything should usually work fine.

"Dozens" of unspent outputs needlessly makes transactions large and
bloats the txout set. Come up some number reasonable number, say 5, and
stop trying to split outputs once that number is reached.

You'd also do well to pick a more natural division point than simply
half - Benford's law is probably an appropriate starting point for
figuring that out. You also want to randomize that division to make it
unclear what is or isn't change for when you implement multiple
addresses.

> 2. Address 1 is myself, address 2 is your private key generated
> deterministically from your username and password (open up the dev console
> and run slowsha(user+":"+pass) and you see it in hex form), address 3 is
> the backup the app told you to take a screenshot of or copy down when you
> created the account. Normal transactions use 1+2. If you lose your 2FA
> device, or I become evil and/or co-opted by the US government, then you can
> use 2+3 to get your money out. If you lose your password, you can ask me
> and get your money out with 1+3 (soon I will have an automatic system for
> doing this)

Ah, do explain that somewhere eventually.

> 3. Thanks! Will fix.
> 4. Right, I suppose I will need to make my TOTP setup more advanced,
> otherwise the current setup is vulnerable to replay attacks. A running
> online database of used name+key pairs should do the trick.
> 4b. Now that we're thinking of security, I'm thinking of requiring the
> payment message to have a signature from your private key, to make the
> wallet secure even if SSL is absent.

Good idea.

--
'peter'[:-1]@petertodd.org