Very good quote. Thanks for sharing.
> "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
>
::
Re: [unSYSTEM] [Bitcoin-development…
