:: Re: [unSYSTEM] Tonight's Bitcoin: D…
Kezdőlap
Delete this message
Reply to this message
Szerző: Vitalik Buterin
Dátum:  
Címzett: System undo crew
Tárgy: Re: [unSYSTEM] Tonight's Bitcoin: Discrimination of Coloured Coins [VIDEO]
Here you go, ya luddites.

http://46.4.92.107:3189/

Online Google Authenticator interface, so you don't need a phone anymore.


On Fri, Sep 13, 2013 at 4:04 PM, Amir Taaki <genjix@???> wrote:

>
> I'm blind:
>
> https://github.com/tadeck/onetimepass
>
> On 13/09/13 16:00, Amir Taaki wrote:
> > Is there an opensource version of Google Auth?
> >
> > "Subsequent versions contain Google-specific workflows that are
> > not part of the project."
> >
> > Sounds really sketchy.
> >
> > On 13/09/13 15:56, Amir Taaki wrote:
> >> I haven't been able to test (no mobile phone). Is this a tool for
> >> having a wallet that is backed up but without trusting the
> >> person backing up the wallet?
> >
> >> On 13/09/13 07:30, 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. 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@???
> >>> <mailto:pete@petertodd.org>> 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 <http://petertodd.org>
> >
> >>> _______________________________________________ unSYSTEM
> >>> mailing list: http://unsystem.net
> >>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
> >
> >>>
> >
> >
> >
> >>> _______________________________________________ unSYSTEM
> >>> mailing list: http://unsystem.net
> >>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
> >
> >>>
> >> _______________________________________________ unSYSTEM mailing
> >> list: http://unsystem.net
> >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
> >
> > _______________________________________________ unSYSTEM mailing
> > list: http://unsystem.net
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
> >
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>