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.
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)
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.




On Fri, Sep 13, 2013 at 7:08 AM, Peter Todd <pete@???> wrote:

> On Fri, Sep 13, 2013 at 01:05:05AM -0400, Peter Todd wrote:
> > On Fri, Sep 13, 2013 at 01:56:33AM +0200, Vitalik Buterin wrote:
> > > Exclusive preview:
> > >
> > > A Google Authenticator two-factor-authentication enabled wallet using
> > > 2-of-3 multisig. Basically, it creates the multisig between the
> server, a
> > > private key deterministically generated from your username+password,
> and a
> > > randomly generated pair that you are instructed to save using some
> external
> > > backup mechanism that is necessary for backup in case you lose your
> > > password or your second factor.
> > >
> > > http://46.4.92.107:3191/
> > >
> > > Try and sign up, and deposit and withdraw a bitcent. I'm deliberately
> > > withholding any clearer explanation as a usability test; you should be
> able
> > > to figure out what's going on on your own.
> >
> > Issues:
> >
> > Why does it always create two change outputs?
> >
> > What exactly are the three addresses in the 2-of-3 for?
> >
> > Needs to calculate fees + give user option for how much fees/KB they
> > want to pay. Current version makes tx's that will get stuck:
> > 5ca25677fcb2b385437ce4ea90cb9af1e7ee8f6ee13cc8ecd3277030c9ecabfa
>
> One more issue: you let users use the same one-time-password code more
> than once...
>
> --
> 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>