:: Re: [unSYSTEM] Tonight's Bitcoin: D…
Kezdőlap
Delete this message
Reply to this message
Szerző: Amir Taaki
Dátum:  
Címzett: unsystem
Tárgy: Re: [unSYSTEM] Tonight's Bitcoin: Discrimination of Coloured Coins [VIDEO]
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
>