:: Re: [unSYSTEM] [Bitcoin-development…
Página Principal
Delete this message
Reply to this message
Autor: Daniel Larimer
Data:  
Para: System undo crew
Assunto: Re: [unSYSTEM] [Bitcoin-development] DarkWallet Best Practices
The solution is to move away from Proof-of-Work based coins.


On Dec 23, 2013, at 1:59 PM, Thomas Hartman <thomas@???> wrote:

> Mining is moving to an industrial model, giant shipping containers
> full of gear that costs millions of dollars. Regulation by the state
> seems almost inevitable to me.
>
> So I think if the state and regulators can capture miners and force
> them to only clear transactions to registered addresses, what can a
> technology such as darkwallet do?
>
> This is a political fight, isn't it?
>
> The freedom to have an unregistered address (financial privacy) is
> either a basic human right, recognized by governments and citizens
> across the globe (and >51% of miners), or it isn't.
>
> If there is regulatory capture of the miners, my understanding is dark
> wallet could still provide obfuscation of FLOWS, even though balances
> would be transparent. So, the government could tax your bitcoin but
> they might not know where it came from. It's still more freedom than
> every flow being known and datamined.
>
>
>
>
>
>
>
>
>
> On Mon, Dec 23, 2013 at 9:58 AM, Amir Taaki <genjix@???> wrote:
>> Freezing BitCoin addresses by regulating miners, April 2011
>> https://bitcointalk.org/index.php?topic=5979.0
>>
>> "Whilst I think it's inevitable, this sort of legal framework would
>> ultimately be self regulating and so should not be feared. BitCoin is a
>> system for agreeing on a global consensus around the ordering of
>> transactions. If that consensus is truly a consensus then there will no
>> be real controversy over the freeze orders and few (or no) miners will
>> ignore them. Consider temporarily freezing the assets of Gadaffi or
>> Mubarak as examples."
>>
>> pushing blacklists from way back when.
>>
>> On 23/12/13 16:22, Thomas Hartman wrote:
>>> Short answer no, long answer barely.
>>>
>>> Node distribution of miners has some impact on centralization of power,
>>> which has implications for state and regulatory capture of bitcoin. And
>>> in the long run DW may want to lobby the miners to prioritize certain
>>> types of transactions.
>>>
>>> In the short run I think we don't need to think about mining.
>>>
>>> On Dec 22, 2013 10:02 PM, "Metatron YHVH" <metatrongone@???
>>> <mailto:metatrongone@gmail.com>> wrote:
>>>
>>>    Is mining relevant here?

>>>
>>>
>>>    On Sun, Dec 22, 2013 at 9:36 AM, Thomas Hartman
>>>    <thomas@??? <mailto:thomas@standardcrypto.com>> wrote:

>>>
>>>        Well, at least you posted some budget and a spec.

>>>
>>>        You still hijacked the thread (3 threads) though. If you would at
>>>        least start a new thread, it would be somewhat more socially
>>>        acceptable.

>>>
>>>        On Sun, Dec 22, 2013 at 8:49 AM, Metatron YHVH
>>>        <metatrongone@??? <mailto:metatrongone@gmail.com>> wrote:
>>>> Bitcoins and RFID currency. I've got 7,692 USD to anyone who
>>>        prove they are
>>>> different.

>>>>
>>>>
>>>> On Sun, Dec 22, 2013 at 7:47 AM, caedes <caedes@???
>>>        <mailto:caedes@sindominio.net>> wrote:

>>>>>
>>>>> Hi!
>>>>>
>>>>> On 19/12/13 18:23, Mike Belshe wrote:
>>>>>> Hey Peter -
>>>>>>
>>>>>> I think this is a super list. A couple of thoughts:
>>>>>>
>>>>>> a) In the section on multi-sig and multi-factor, I think we
>>>        can split
>>>>>> these apart. Multi-factor user authentication is very
>>>        valuable and not
>>>>>> the same as multi-factor signing, which is a second level of
>>>>>> complexity.   The multi-factor auth can be off-blockchain, e.g.
>>>>>> authenticating with SMS message to your phone or Google
>>>        Authenticator
>>>>>> challenge.  Given the state of malware today, I personally
>>>        would
>>>>>> propose two requirements:
>>>>>>    1) wallets SHOULD use multi-factor authentication before
>>>>>> authorizing access to a wallet (e.g. view balances, addresses,
>>>>>> transactions, etc)
>>>>>>    2) wallets MUST use multi-factor auth before signing a
>>>>>> transaction.   [note: I recognize that MUST might be too
>>>        aggressive
>>>>>> right now, but I wouldn't use a wallet without it.  this
>>>        can also be
>>>>>> impractical for server-side wallets]

>>>>>
>>>>> Using multi-sig for multi-factor so the wallet needs to get some
>>>>> additional signatures (or even the keys can be somewhere
>>>        else) can make
>>>>> 2factor more orthogonal to the whole thing specially since we
>>>        need to
>>>>> support multisig spending, and other partial transaction
>>>        fullfilling.

>>>>>
>>>>> We can still account for other 2fa schemes, but i'm thinking
>>>        more of
>>>>> exploiting key signing itself and maybe bip32 wallet structure.

>>>>>
>>>>> I agee on uour requirements, but also think they might be too
>>>        harsh for
>>>>> some uses I would require them myself so I could feel safe
>>>        with my wallet.

>>>>>
>>>>>
>>>>>>
>>>>>> b) Multi-factor signing (e.g. P2SH) may be too early to
>>>        really define.
>>>>>> But here are some issues which have come up from my own
>>>        personal
>>>>>> development experience:
>>>>>>    - Wallets SHOULD NOT create two keys on a single host
>>>        or device
>>>>>>    - Wallets SHOULD provide a way to import external
>>>        public keys
>>>>>> which can be used as part of a P2SH address

>>>>>
>>>>>
>>>>> Agree on these ones. Public keys could be imported through
>>>        extended
>>>>> public keys too if we agree to using those.

>>>>>
>>>>>>
>>>>>> Slightly off topic:  For P2SH, address creation requires
>>>        the public
>>>>>> key, not the public hash of an address.  For me, this has
>>>        made it
>>>>>> difficult to import keys created through out-of-band
>>>        sources.  Most
>>>>>> wallets/key generators/etc only provide the address and not
>>>        the public
>>>>>> key, and this is a hinderance to easy P2SH creation off
>>>        host.  It
>>>>>> would be great if there were a way to address this, but I
>>>        don't know
>>>>>> how.

>>>>>>
>>>>>
>>>>>
>>>>> We have to work on solutions... our aim is settle down on a
>>>        way to
>>>>> negotiate addresses and other parameters among identities,
>>>        also key
>>>>> importing can be supported to make these easier.

>>>>>
>>>>> cheers!
>>>>>
>>>>> _______________________________________________
>>>>> unSYSTEM mailing list: http://unsystem.net
>>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> ॐMetatronॐ
>>>>
>>>>
>>>> _______________________________________________
>>>> 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

>>>
>>>
>>>
>>>
>>>    --

>>>
>>>
>>>      ॐMetatronॐ

>>>
>>>
>>>    _______________________________________________
>>>    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