MIME-Version: 1.0
In-Reply-To: <CAL8tG=mxYE97iMO05mPq4_f8VcmFBYqAmyPqTs439bPRGhaVqA@mail.gmail.com>
References: <CABCnA7Wqz76m8qo5BYT41Z=hBH+fUfOc4xsFAGg=Niv7Jgkqsg@mail.gmail.com>
	<CAJmQggC1X5Lgt4xGoMtBZ_v3hC2GXcYaj2FngV2_7A=TDfSuEg@mail.gmail.com>
	<CAL8tG=mxYE97iMO05mPq4_f8VcmFBYqAmyPqTs439bPRGhaVqA@mail.gmail.com>
Date: Wed, 9 Dec 2015 22:58:10 -0500
Message-ID: <CABCnA7W25KoHuSuB3Az250_PiRcFd5MjjKJfrm_qv4oaYUT5mg@mail.gmail.com>
From: Akiva Lichtner <akiva.lichtner@gmail.com>
To: Andrew <onelineproof@gmail.com>
Content-Type: multipart/alternative; boundary=001a113a66901efdd305268337eb
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Scaling by Partitioning
Precedence: list

--001a113a66901efdd305268337eb
Content-Type: text/plain; charset=UTF-8

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

--001a113a66901efdd305268337eb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Hi Andrew,<br><br></div>What you suggested =
is much more sophisticated than what I suggested. I am strictly talking abo=
ut independent chains - that&#39;s all.<br><br></div>I am struck by the fac=
t that the topic of &quot;scaling bitcoin&quot; seems to be a mix of differ=
ent problems, and when people are really trying to solve different problems=
, or arguing about applying the same solution in different settings, it&#39=
;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 w=
ith process groups and total ordering. I view Bitcoin as a timestamp servic=
e on all transactions, a total order. A total order is difficult to scale. =
Period.<br><br>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&#39;t need to verify everything.=
 I think these are two problems that should have two different names.<br><b=
r></div><div>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 ou=
t the window long ago. I think that went out with the special mining hardwa=
re. If my organization had to accept bitcoin payments I would assume that w=
e&#39;ll need a small server farm for transaction verification, and that we=
 would see all the transactions. Figure 10,000 transactions per second, lik=
e 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 ve=
rification to a trusted party, as long as the trust chain stops there and t=
here is plenty of choice.<br><br></div><div>I am guessing the trustless vir=
tual currency police would get pretty upset about such a pragmatic approach=
, but it&#39;s not really a choice, the failure to scale has already occurr=
ed. All things considered I think that Bitcoin will only scale when pragmat=
ic considerations take center stage and the academic goals take a lower pri=
ority. I would think companies would make a good living out of running trus=
ted verification services.<br><br></div><div>Once again, it doesn&#39;t mea=
n 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&#39;s not that weird.<br></div><div><br></div><div>=
Akiva<br></div><div><br></div></div>

--001a113a66901efdd305268337eb--