:: Re: [unSYSTEM] [Bitcoin-development…
Página Inicial
Delete this message
Reply to this message
Autor: Metatron YHVH
Data:  
Para: System undo crew
Assunto: Re: [unSYSTEM] [Bitcoin-development] DarkWallet Best Practices
So if the powers that be can set up god tier mining pools, then how is this
even fair?

The fiat currency of today is still governing who has how much and that
doesn't give me much hope for crypto currencies as a whole.

Moreover, I don't like politics however, as soon as those bastards on
C-Span made bitcoin apart of the conversation, bitcoin became a political
topic.

The Dark Wallet is a good idea, but it doesn't matter what technology you
have, as long as people influence (or govern) the USERS, you might as well
sign up a coinbase account.

- Metatron


On Mon, Dec 23, 2013 at 11:16 AM, Daniel Larimer <
dlarimer@???> wrote:

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




--
ॐMetatronॐ