:: Re: [unSYSTEM] [Bitcoin-development…
Pàgina inicial
Delete this message
Reply to this message
Autor: Amir Taaki
Data:  
A: unsystem
Assumpte: Re: [unSYSTEM] [Bitcoin-development] DarkWallet Best Practices
Very good quote. Thanks for sharing.

On 27/12/13 21:38, Adam Midvidy wrote:
> "The current system where every user is a network node is not the
> intended configuration for large scale. That would be like every Usenet
> user runs their own NNTP server. The design supports letting users just
> be users. The more burden it is to run a node, the fewer nodes there
> will be. Those few nodes will be big server farms. The rest will be
> client nodes that only do transactions and don't generate."
>
> -Satoshi Nakamoto (2010)
> https://bitcointalk.org/index.php?topic=532.msg6306#msg6306
>
> Mining centralization was built in from the start.
>
>
> On Fri, Dec 27, 2013 at 3:36 PM, Jorge Timón <jtimon@???
> <mailto:jtimon@monetize.io>> wrote:
>
>     I don't think this kind of legal attack is very realistic.
>     While there's miners that don't censor txs with "unregistered
>     addresses", all those transactions can go trough them.
>     Say the US tries to enforce white lists through US-based pools.
>     There will be other pools in other countries or even in tor.
>     Are they going house by house looking for ASIC buyers? Mining the
>     transactions with the highest fees instead of only the "white ones"
>     will always be more profitable, so they're really only pushing mining
>     out of the country and making the local miners who try lose money on
>     their investments because they can't compete with foreign miners.
>     Which country will copy those regulations next? After seeing that
>     produce undesirable economic results and at the same time don't impede
>     transactions with addresses outside of their white-listing centralized
>     server?
>     The idea of a centralized white-list server for a p2p currency is so
>     stupid that failure is the only possible outcome I contemplate.
>     But even if this ever became a real problem, we could always switch to
>     a less efficient system that guarantees anonymity ala zerocoin or
>     other similar proposals.

>
>     So, Daniel, I completely disagree with your analysis, but I'm curious
>     as to what's your proposed replacement for PoW. I guess you want
>     something like proof of stake or ripple.com <http://ripple.com>'s
>     consensus?
>     Both have much bigger problems than PoW.

>
>
>     On 12/23/13, Metatron YHVH <metatrongone@???
>     <mailto:metatrongone@gmail.com>> wrote:
>     > 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@???
>     <mailto:dlarimer@invictus-innovations.com>> wrote:

>     >
>     >> The solution is to move away from Proof-of-Work based coins.

>     >>

>     >>
>     >> On Dec 23, 2013, at 1:59 PM, Thomas Hartman
>     <thomas@??? <mailto:thomas@standardcrypto.com>>
>     >> 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@???
>     <mailto:genjix@riseup.net>> 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>
>     >> >>> <mailto:metatrongone@gmail.com
>     <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> <mailto:thomas@standardcrypto.com
>     <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> <mailto:metatrongone@gmail.com
>     <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>
>     >> >>>        <mailto:caedes@sindominio.net
>     <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ॐ

>     >

>
>
>     --
>     Jorge Timón

>
>     http://freico.in/
>     _______________________________________________
>     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
>