From: Akiva Lichtner <akiva.lichtner@gmail.com>
To: Andrew <onelineproof@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling by Partitioning
Date: Wed, 9 Dec 2015 22:58:10 -0500 [thread overview]
Message-ID: <CABCnA7W25KoHuSuB3Az250_PiRcFd5MjjKJfrm_qv4oaYUT5mg@mail.gmail.com> (raw)
In-Reply-To: <CAL8tG=mxYE97iMO05mPq4_f8VcmFBYqAmyPqTs439bPRGhaVqA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]
Hi Andrew,
What you suggested is much more sophisticated than what I suggested. I am
strictly talking about independent chains - that's all.
I am struck by the fact that the topic of "scaling bitcoin" seems to be a
mix of different problems, and when people are really trying to solve
different problems, or arguing about applying the same solution in
different settings, it's easy to argue back and forth endlessly. Your post
talks about validating transactions without seeing all transactions. This
is a different problem than what I am addressing. My view of Bitcoin is
colored by my experience with process groups and total ordering. I view
Bitcoin as a timestamp service on all transactions, a total order. A total
order is difficult to scale. Period.
I am just addressing how to change the system so that blocks can be
generated faster if a) the transaction volume increases and b) you are
willing to have more miners. But you are also talking about transaction
verification and making sure that you don't need to verify everything. I
think these are two problems that should have two different names.
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
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 all the transactions. Figure 10,000 transactions per second, like VISA.
As far as small organizations or private individuals are concerned, I think
it 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 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
will only scale when pragmatic considerations take center stage and the
academic goals take a lower priority. I would think companies would make a
good living out of running trusted verification services.
Once again, it doesn't mean that there is a bank, the network still allows
malicious nodes, but there can be pockets of trust. This is only natural,
most people trust at least one other person, so it's not that weird.
Akiva
[-- Attachment #2: Type: text/html, Size: 2661 bytes --]
next prev parent reply other threads:[~2015-12-10 3:58 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 [this message]
2015-12-10 4:31 ` Bryan Bishop
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=CABCnA7W25KoHuSuB3Az250_PiRcFd5MjjKJfrm_qv4oaYUT5mg@mail.gmail.com \
--to=akiva.lichtner@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=onelineproof@gmail.com \
/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