public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Bryan Bishop <kanzure@gmail.com>
To: Akiva Lichtner <akiva.lichtner@gmail.com>,
	Bryan Bishop <kanzure@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling by Partitioning
Date: Wed, 9 Dec 2015 22:31:42 -0600	[thread overview]
Message-ID: <CABaSBay9G3NQHn0HUkKfenr+e4be6arSBvy6vD=1+M3eSZJHtw@mail.gmail.com> (raw)
In-Reply-To: <CABCnA7W25KoHuSuB3Az250_PiRcFd5MjjKJfrm_qv4oaYUT5mg@mail.gmail.com>

On Wed, Dec 9, 2015 at 9:58 PM, Akiva Lichtner wrote:
> Correct me if I am wrong, but the dream of a virtual currency where
> everybody is equal and runs the client on their mobile device went out the
> window long ago. I think that went out with the special mining hardware. If

Mining equipment isn't for transaction verification. The mining
equipment is used to work on Proof-of-Work. Thanks.

> my organization had to accept bitcoin payments I would assume that we'll
> need a small server farm for transaction verification, and that we would see

Unfortunately Bitcoin does not work like those centralized systems; it
should not be surprising that a system focused so much on
decentralized and independent verification would have developers
working on so many non-bandwidth scaling solutions. These other
proposals seek to preserve existing properties of Bitcoin (such as
cheap verification, low-bandwidth) while also increasing the amount of
activity that can enjoy the decentralized fruits of Proof-of-Work
labor. But not helpful to assume this can only look like Visa or any
database on a cluster etc...

> would be entirely okay for a guy on a smartphone to delegate verification to
> a trusted party, as long as the trust chain stops there and there is plenty
> of choice.

I don't suppose I could tempt you with probabilistically checkable
proofs, could I? These verify in milliseconds, grow sublinear in size
of the total data, but have no near-term proposal available yet.

> I am guessing the trustless virtual currency police would get pretty upset
> about such a pragmatic approach, but it's not really a choice, the failure
> to scale has already occurred. All things considered I think that Bitcoin

Perhaps instead of failure-to-scale you mean "failure to apply
traditional scaling has already failed", which shouldn't be so
surprising given the different security model that Bitcoin operates
on.

> most people trust at least one other person, so it's not that weird.

see the following recent text,
"""
Bitcoin is P2P electronic cash that is valuable over legacy systems
because of the monetary autonomy it brings to its users through
decentralization. Bitcoin seeks to address the root problem with
conventional currency: all the trust that's required to make it work--

-- Not that justified trust is a bad thing, but trust makes systems
brittle, opaque, and costly to operate. Trust failures result in systemic
collapses, trust curation creates inequality and monopoly lock-in, and
naturally arising trust choke-points can be abused to deny access to
due process. Through the use of cryptographic proof and decentralized
networks Bitcoin minimizes and replaces these trust costs.

With the available technology, there are fundamental trade-offs between
scale and decentralization. If the system is too costly people will be
forced to trust third parties rather than independently enforcing the
system's rules. If the Bitcoin blockchain’s resource usage, relative
to the available technology, is too great, Bitcoin loses its competitive
advantages compared to legacy systems because validation will be too
costly (pricing out many users), forcing trust back into the system.
If capacity is too low and our methods of transacting too inefficient,
access to the chain for dispute resolution will be too costly, again
pushing trust back into the system.
"""

- Bryan
http://heybryan.org/
1 512 203 0507


  reply	other threads:[~2015-12-10  4:31 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-08 16:27 [bitcoin-dev] Scaling by Partitioning Akiva Lichtner
2015-12-08 16:45 ` Bryan Bishop
2015-12-08 18:30   ` Akiva Lichtner
2015-12-08 20:50 ` Patrick Strateman
2015-12-08 21:23   ` Akiva Lichtner
2015-12-08 21:29     ` Patrick Strateman
2015-12-08 21:41       ` Akiva Lichtner
2015-12-09  6:30 ` Loi Luu
2015-12-09 18:26   ` Akiva Lichtner
2015-12-09 21:16     ` Loi Luu
2015-12-10  4:04       ` Akiva Lichtner
2015-12-09 22:35   ` Andrew
2015-12-10  3:58     ` Akiva Lichtner
2015-12-10  4:31       ` Bryan Bishop [this message]
2015-12-10  4:08     ` Dave Scotese
2015-12-10  4:14       ` Dave Scotese

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABaSBay9G3NQHn0HUkKfenr+e4be6arSBvy6vD=1+M3eSZJHtw@mail.gmail.com' \
    --to=kanzure@gmail.com \
    --cc=akiva.lichtner@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox