path: root/2d/e9e3ac50782f4c0dc87ec2325f682eb4095da5

Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <elombrozo@gmail.com>) id 1Z4IeJ-0000LM-U4
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Jun 2015 00:53:15 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.178 as permitted sender)
	client-ip=209.85.192.178; envelope-from=elombrozo@gmail.com;
	helo=mail-pd0-f178.google.com; 
Received: from mail-pd0-f178.google.com ([209.85.192.178])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z4IeI-0005Bk-OD
	for bitcoin-development@lists.sourceforge.net;
	Mon, 15 Jun 2015 00:53:15 +0000
Received: by pdbnf5 with SMTP id nf5so60616486pdb.2
	for <bitcoin-development@lists.sourceforge.net>;
	Sun, 14 Jun 2015 17:53:09 -0700 (PDT)
X-Received: by 10.66.144.40 with SMTP id sj8mr42779668pab.55.1434329589047;
	Sun, 14 Jun 2015 17:53:09 -0700 (PDT)
Received: from [192.168.1.102] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202])
	by mx.google.com with ESMTPSA id cu8sm10275852pad.1.2015.06.14.17.53.07
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Sun, 14 Jun 2015 17:53:07 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_F0C1FEA2-E014-442F-A84E-53AD981B4CC3";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5b6
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <CALqxMTENbj+E7ypJASrM1r04eW3kYe+afwy+Rt3i9ubeT-=2mA@mail.gmail.com>
Date: Sun, 14 Jun 2015 17:53:05 -0700
Message-Id: <674CED15-3F4C-4E24-BCA2-3C474CC01708@gmail.com>
References: <CALqxMTHrnSS9MGgKO-5+=fVhiOOvk12Recs11S0PcSUxQT1wdQ@mail.gmail.com>
	<CANEZrP1nx9rNf1q-nubP77U8RMABuLtmEB_P7UpY2zyFf-Ns-w@mail.gmail.com>
	<CALqxMTENbj+E7ypJASrM1r04eW3kYe+afwy+Rt3i9ubeT-=2mA@mail.gmail.com>
To: Adam Back <adam@cypherspace.org>
X-Mailer: Apple Mail (2.2098)
X-Spam-Score: -1.4 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(elombrozo[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	0.2 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1Z4IeI-0005Bk-OD
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] comments on BIP 100
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 15 Jun 2015 00:53:15 -0000


--Apple-Mail=_F0C1FEA2-E014-442F-A84E-53AD981B4CC3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I think the whole complexity talk is missing the bigger issue.

Sure, per block validation scales linearly (or quasilinearly=E2=80=A6there=
=E2=80=99s an O(log n) term in there somewhere but it=E2=80=99s probably =
dominated by linear factors at current levels=E2=80=A6asymptotic limits =
don=E2=80=99t always apply very well to finite systems). And there=E2=80=99=
s an O(n^2) bandwidth issue.

The real issue, though, is validation cost. The n in O(n) here does not =
represent block size - it represents the size of the entire block chain =
for every new validator that must be synchronized! It means we have no =
way to construct short proofs (or at least arguments that are =
computationally *hard* to forge) without requiring the validator to =
maintain the complete system state. And currently, there is no mechanism =
for directly compensating validators.

A full validator that goes offline even for a short period of time takes =
a while to fully catch up to the rest of the network - and starting up a =
new validator from scratch will continue to be painful=E2=80=A6even for =
those of us who=E2=80=99ve turned this into routine by now, let alone =
new nontechnical users.

Satoshi=E2=80=99s SPV is not a real solution - it=E2=80=99s a mere =
suggestion that wasn=E2=80=99t fully thought out at the time of the =
Bitcoin white paper. Besides lacking a good validation security model, =
practical implementations of it weaken privacy and complicate client =
implementations substantially=E2=80=A6and the worst part, it still =
doesn=E2=80=99t scale all that well. The validator still has to query =
every single block (even if filtered) back to the first transaction =
(which cannot be determined without doing a blockchain scan anyway).

So yes, we will most certainly need algorithmic improvements!

- Eric Lombrozo


> On Jun 14, 2015, at 4:58 PM, Adam Back <adam@cypherspace.org> wrote:
>=20
> Hi Mike
>=20
> On 15 June 2015 at 00:23, Mike Hearn <mike@plan99.net> wrote:
>>> One thing that is concerning is that few in industry seem inclined =
to
>>> take any development initiatives or even integrate a library.
>>=20
>> Um, you mean except all the people who have built more scalable =
wallets over
>> the past few years, which is the only reason anyone can even use =
Bitcoin
>> from their phone?
>=20
> No slight intended obviously to people who do write actual client =
code.
>=20
> That was probably insufficiently specific, let me rephrase: I am
> referring to the trend that much of the industry is built on web2.0
> technology using bitcoin via a library in a web scripting language,
> often with consensus bugs, and even outsourcing and not even running
> their own full node, so that the service itself offered to their users
> isn't even SPV secure to the operator.  As well as being heavily based
> on a third-party custody model that is the root cause of the repeated
> wallet breaches.  Some of these companies have a noted tendency not to
> upgrade or fix code.
>=20
> So I mean this not to call out specific companies, but in the sense
> that if we're technologists we should be trying to move the technology
> forward, not just changing parameters which run into an O(n^2) scaling
> wall or break decentralisation security.  And we shouldnt take the
> above state of affairs as an immutable reality.  It can not persist
> for bitcoin to reach maturity on scale nor security.
>=20
>> I still think you guys don't recognise what you are actually asking =
for here
>> - scrapping virtually the entire existing investment in software, =
wallets
>> and tools.
>=20
> As I said I dont think we can expect Bitcoin to scale with no further
> algorithmic improvements.  Algorithmic improvements take code.  There
> is reasonable scope to build in an incrementally deployable way,
> there's plenty of time for people to code, test and opt-in to things,
> the sky is not falling.  Companies do care about scaling, and can
> invest in the integration and coding implied to improve their products
> scalability, they have an economic incentive to do it and there is no
> scalable and safe way todo it without this work.
>=20
>> Computational complexity for the entire network is O(nm) where
>> n=3Dtransactions and m=3Dfully validating nodes. There is no fixed =
relationships
>> between those two variables.
>=20
> I am referring to global bandwidth O(n^2) with n=3Dusers, or O(n) per
> user bandwidth cost to the system, while O(nm) is accurate nodes is an
> internal system concept.  Anyway suffice to say the network does not
> scale O(1) in per user cost.
>=20
>> "Exposing the companies to back-pressure" sounds quite nice and =
gentle. Let
>> me rephrase it to be equivalent but perhaps more direct: you mean =
"breaking
>> the current software ecosystem to force people into a new, fictional =
system
>> that bears little resemblance to the Bitcoin we use today, whether =
they want
>> that or not".
>>=20
>> As nothing that has been proposed so far (Lightning, merge mined =
chains,
>> extension blocks etc) has much chance of actual deployment any time =
soon,
>> that leaves raising the block size limit as the only possible path =
left.
>=20
> A hard-fork takes a long period of time to deploy due to the
> non-upgrade risk, people are working on things in the mean-time.
> There can be a case for some increase to create some breathing room to
> work on scaling and decentralising tech, I just mean to say that if we
> do it in isolation, we're not focussing on the big picture.
>=20
> Adam
>=20
> =
--------------------------------------------------------------------------=
----
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--Apple-Mail=_F0C1FEA2-E014-442F-A84E-53AD981B4CC3
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVfiHxAAoJEJNAI64YFENU/7sP/imCdKL+Apa5m3CNaaqsG5/g
WIOVk99gqL4hPZd5TX7a3CjxLW8A4inuQJi56pwE1jgb17qLYT+bzi/W41KjPOsL
ytivCAlW02Yem9IohXy9UBi5JInHrgrTh83D6dXQ39JvHdCVsdeDrqPOwrP07mr2
Uf/6RchCJGKRkLARkwDCLd1H+JfCqqegrRbYv8qa7U3K8PzrCOuYLEd3oIAEv86f
mWKZiRiWmkUVtrUHWrpM6Ghjr9jxIN0lHYYLFslMIk+FbT9ELMh3YbvbdHC4pkNW
yqd0mDKAXEPuSrJkwkp07QA5QG/BFHt6RR0uzGnGOXj+HmI5y9B5dyEuOMW9nloS
JP9HJsAgLCogWb+sazkYbcUX+j61WjG5NKb3UY3W7xVyPKRLx69K5WbTk6LenZe+
0P1IUaHupdcIeGEn1eu/OOwM2SALEpVG4sCf56M9s7d/wfcha3Idw+FcYcjcuBbF
N/V9ycH1NyreUgU3YBvAg1ziqnXQbG15uBUrHnbHfD5r1DsYxageXqfYsIg9Yr0b
rSXDBW8kAb5XHdGaNh6aBrRIPYzJ7pbJwlVVqhKaJyAjnXborJf5Q2e2EngBQ7lL
1XtG3c4JHi87Mkx+o4MI01lY+xBaXSwViKE6o0Pltb2ugTDa7qGz4hT69UEjsrQH
NlkSnmC5Qrd4W3AHKru6
=QB0U
-----END PGP SIGNATURE-----

--Apple-Mail=_F0C1FEA2-E014-442F-A84E-53AD981B4CC3--