path: root/7d/041e3d9e9864d1f4d65acb633c30e82fe71431

Return-Path: <elombrozo@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B26A53EE
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Jul 2015 02:40:26 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pd0-f177.google.com (mail-pd0-f177.google.com
	[209.85.192.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B3D15D5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 29 Jul 2015 02:40:25 +0000 (UTC)
Received: by pdjr16 with SMTP id r16so82108365pdj.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 28 Jul 2015 19:40:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=subject:mime-version:content-type:from:in-reply-to:date:cc
	:message-id:references:to;
	bh=r950hlSoOLWWVcPbN2QWsrDJ5qWy44mNCrbVzep9U5o=;
	b=UFlxELKgQKyePsAQA3OYms0JI9yHVLG2QAaOZAaLDIW7IfvO9Nq/AIh1PumFWWJf7C
	JJJqqDBRXtOkDqzk7v0jZNNs9AmF31tdDyJtiq6R2E8i0MXtJ4/ET3kTlZTxLZUCmf29
	fe3UFgC3iLirMB9O8/aKzrNIQ+Vz02wXJBU8HJy/RaBGAjvgGbQcGqGrVSXpsI9C2ndJ
	udPpTpEx4xrhbypRgqhPRZfFoL53mlsofXZzlvJAakQ87hbD/bDd/wt4dJcqVD3fLIMe
	5kmiV/+pY9eAyg0k1zLNnzj730FtOmqx8+R7D52xf8XomoSEx19J9XX5jOMaJpXSHBKD
	b/Hw==
X-Received: by 10.70.130.107 with SMTP id od11mr88517190pdb.145.1438137625433; 
	Tue, 28 Jul 2015 19:40:25 -0700 (PDT)
Received: from [192.168.1.107] (cpe-76-167-237-202.san.res.rr.com.
	[76.167.237.202]) by smtp.gmail.com with ESMTPSA id
	e8sm37565286pdm.13.2015.07.28.19.40.22
	(version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
	Tue, 28 Jul 2015 19:40:24 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Content-Type: multipart/signed;
	boundary="Apple-Mail=_5D1EA61A-D7A3-458B-93C6-F1B2AD9D259B";
	protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail 2.5
From: Eric Lombrozo <elombrozo@gmail.com>
In-Reply-To: <35B780B8-7282-4C98-9A0D-C7774028E277@gmail.com>
Date: Tue, 28 Jul 2015 19:40:21 -0700
Message-Id: <4F7FB1A0-E201-40F2-80BA-4C8D6ECC4DC4@gmail.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
	<D2CDA490-F04A-41EA-85F7-56BA5B052729@me.com>
	<CAOG=w-sanb-vOt6YaDJhdT2CCmnqWYTBF204sBZ1=Dsveko7og@mail.gmail.com>
	<35B780B8-7282-4C98-9A0D-C7774028E277@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
X-Mailer: Apple Mail (2.2098)
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't
	temporary
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Jul 2015 02:40:26 -0000


--Apple-Mail=_5D1EA61A-D7A3-458B-93C6-F1B2AD9D259B
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_EC151483-D03B-487C-92F9-ABA7A94708B3"


--Apple-Mail=_EC151483-D03B-487C-92F9-ABA7A94708B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

In the interest of promoting some constructive discussion on this, let =
me start by making a few proposals to correct the listed issues.

Note: many of these ideas are neither my own nor really all that new, =
but it seems in the past we=E2=80=99ve given up too easily on actually =
moving forward on them despite their critical importance.


=E2=80=94=E2=80=94

1) A fee market never really got created, we don=E2=80=99t really know =
how transaction fees would  work in practice.

The only way to see how fees would work in practice is to have scarcity. =
If the network is still not sufficiently mature to be able to handle =
actual resource limits securely, the safest way to do this is to =
artificially impose limits. Some economists might bicker about the =
problems with production quotas and what not=E2=80=A6but how else are we =
to solve the real, non-trivial engineering problems without risking =
system collapse? The eventual goal would be to remove these artificial =
limits once we=E2=80=99re confident that the economic incentives are =
properly aligned to maintain security. We=E2=80=99re still quite far =
from this goal, though, and it would be irresponsible, IMHO, to insist =
on letting the system hit its real limits.


2) Turns out the vast majority of validation nodes have little if =
anything to do with mining - validators do not get =
compensated=E2=80=A6validation cost is externalized to the entire =
network.
3) Miners don=E2=80=99t even properly validate blocks. And the bigger =
the blocks get, the greater the propensity to skip this step. Oops!

Issues (2) and (3) are inextricably related so I=E2=80=99ll cover both =
together.

The obvious problem here is that as long as the cost of checking =
validators is the same as the cost of validating itself, there=E2=80=99s =
really little we can do to properly have any sort of division of labor. =
Requiring, at the very least, random checks might be a start. Perhaps =
some clever use of SNARKs might eventually be secure and practical.

It might also be possible to directly pay validators for satisfying =
random checks or providing SNARKs. If only we could trustlessly and =
securely outsource this work we=E2=80=99d make tremendous progress.

Of all the issues I=E2=80=99ve listed, these are perhaps the ones for =
which practical solutions seem most tentative at present.


4) A satisfactory mechanism for thin clients to be able to securely =
obtain reasonably secure, short proofs for their transactions never =
materialized.

The first part of the solution to this issue is the use of better data =
structures. Satoshi=E2=80=99s SPV can prove that transactions are =
included in blocks=E2=80=A6and that outputs are spent. But it has no =
mechanism for proving that a given transaction is *not* included in any =
block=E2=80=A6or that some particular output remains unspent. The =
structures to which we=E2=80=99re committing extremely inefficient for =
querying some of the most important things required for =
validation=E2=80=A6i.e. whether an output exists and whether it is =
spent.

The second part is shifting the responsibility for constructing proofs =
to the parties who already have the greatest incentives to store the =
necessary data to construct these proofs to allow efficient prunability. =
Outsourceability of proofs would also be highly desirable.

=E2=80=94=E2=80=94

If we want to be able to raise the block size limit=E2=80=A6or perhaps =
get rid of it altogether, I would suggest we start by addressing these =
specific issues and work to find practical solutions. Since raising the =
block size limit is already a hard forking consensus rule change, at =
least the need for hard forks isn=E2=80=99t what=E2=80=99s stopping us.

- Eric


> On Jul 28, 2015, at 5:55 PM, Eric Lombrozo <elombrozo@gmail.com> =
wrote:
>=20
> I agree that the historical reasons are irrelevant from an engineering =
perspective. But they still set a context for the discussion=E2=80=A6and =
might help shed some insight into the motivations behind some of the =
participants. It=E2=80=99s also good to know these things to counter =
arguments that start with =E2=80=9CBut Satoshi said that=E2=80=A6=E2=80=9D=

>=20
> What=E2=80=99s critically important to note is that several of the =
assumptions that were being made at the time this limit was decided have =
turned out wrong=E2=80=A6and that these other issues should probably be =
of greater concern and more highly prioritized in any discussion =
considering the merits of deploying potentially incompatible consensus =
rule changes. It seems if these other issues were fixed perhaps no block =
size limit would be required at all (as was originally hoped).
>=20
> - Eric
>=20
>> On Jul 28, 2015, at 5:46 PM, Mark Friedenbach <mark@friedenbach.org =
<mailto:mark@friedenbach.org>> wrote:
>>=20
>> Does it matter even in the slightest why the block size limit was put =
in place? It does not. Bitcoin is a decentralized payment network, and =
the relationship between utility (block size) and decentralization is =
empirical. Why the 1MB limit was put in place at the time might be a =
historically interesting question, but it bears little relevance to the =
present engineering issues.
>>=20
>> On Tue, Jul 28, 2015 at 5:43 PM, Jean-Paul Kogelman via bitcoin-dev =
<bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
>>=20
>> > Enter a =E2=80=9Ctemporary=E2=80=9D anti-spam measure - a one =
megabyte block size limit. Let=E2=80=99s test this out, then increase it =
once we see how things work. So far so good=E2=80=A6
>> >
>>=20
>> The block size limit was put in place as an anti-DoS measure (monster =
blocks), not "anti-spam". It was never intended to have any economic =
effect, not on spam and not on any future fee market.
>>=20
>>=20
>> jp
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org =
<mailto:bitcoin-dev@lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev =
<https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>>=20
>=20


--Apple-Mail=_EC151483-D03B-487C-92F9-ABA7A94708B3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" =
class=3D"">In the interest of promoting some constructive discussion on =
this, let me start by making a few proposals to correct the listed =
issues.<div class=3D""><br class=3D""></div><div class=3D"">Note: many =
of these ideas are neither my own nor really all that new, but it seems =
in the past we=E2=80=99ve given up too easily on actually moving forward =
on them despite their critical importance.</div><div class=3D""><br =
class=3D""><div class=3D""><br class=3D""></div><div =
class=3D"">=E2=80=94=E2=80=94</div><div class=3D""><br =
class=3D""></div><div class=3D"">1) A fee market never really got =
created, we don=E2=80=99t really know how transaction fees would =
&nbsp;work in practice.</div><div class=3D""><br class=3D""></div><div =
class=3D"">The only way to see how fees would work in practice is to =
have scarcity. If the network is still not sufficiently mature to be =
able to handle actual resource limits securely, the safest way to do =
this is to artificially impose limits. Some economists might bicker =
about the problems with production quotas and what not=E2=80=A6but how =
else are we to solve the real, non-trivial engineering problems without =
risking system collapse? The eventual goal would be to remove these =
artificial limits once we=E2=80=99re confident that the economic =
incentives are properly aligned to maintain security. We=E2=80=99re =
still quite far from this goal, though, and it would be irresponsible, =
IMHO, to insist on letting the system hit its real limits.</div><div =
class=3D""><br class=3D""></div><div class=3D""><br class=3D"">2) Turns =
out the vast majority of validation nodes have little if anything to do =
with mining - validators do not get compensated=E2=80=A6validation cost =
is externalized to the entire network.</div><div class=3D"">3) Miners =
don=E2=80=99t even properly validate blocks. And the bigger the blocks =
get, the greater the propensity to skip this step. Oops!</div><div =
class=3D""><br class=3D""></div><div class=3D"">Issues (2) and (3) are =
inextricably related so I=E2=80=99ll cover both together.</div><div =
class=3D""><br class=3D""></div><div class=3D"">The obvious problem here =
is that as long as the cost of checking validators is the same as the =
cost of validating itself, there=E2=80=99s really little we can do to =
properly have any sort of division of labor. Requiring, at the very =
least, random checks might be a start. Perhaps some clever use of SNARKs =
might eventually be secure and practical.</div><div class=3D""><br =
class=3D""></div><div class=3D"">It might also be possible to directly =
pay validators for satisfying random checks or providing SNARKs. If only =
we could trustlessly and securely outsource this work we=E2=80=99d make =
tremendous progress.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Of all the issues I=E2=80=99ve listed, these are perhaps the =
ones for which practical solutions seem most tentative at present.<br =
class=3D""><br class=3D""><br class=3D"">4) A satisfactory mechanism for =
thin clients to be able to securely obtain reasonably secure, short =
proofs for their transactions never materialized.</div><div class=3D""><br=
 class=3D""></div><div class=3D"">The first part of the solution to this =
issue is the use of better data structures. Satoshi=E2=80=99s SPV can =
prove that transactions are included in blocks=E2=80=A6and that outputs =
are spent. But it has no mechanism for proving that a given transaction =
is *not* included in any block=E2=80=A6or that some particular output =
remains unspent. The structures to which we=E2=80=99re committing =
extremely inefficient for querying some of the most important things =
required for validation=E2=80=A6i.e. whether an output exists and =
whether it is spent.</div><div class=3D""><br class=3D""></div><div =
class=3D"">The second part is shifting the responsibility for =
constructing proofs to the parties who already have the greatest =
incentives to store the necessary data to construct these proofs to =
allow efficient prunability. Outsourceability of proofs would also be =
highly desirable.</div><div class=3D""><br class=3D""></div><div =
class=3D"">=E2=80=94=E2=80=94</div><div class=3D""><br =
class=3D""></div><div class=3D"">If we want to be able to raise the =
block size limit=E2=80=A6or perhaps get rid of it altogether, I would =
suggest we start by addressing these specific issues and work to find =
practical solutions. Since raising the block size limit is already a =
hard forking consensus rule change, at least the need for hard forks =
isn=E2=80=99t what=E2=80=99s stopping us.</div><div class=3D""><br =
class=3D""></div><div class=3D"">- Eric</div><div class=3D""><br =
class=3D""></div><div class=3D""><br class=3D""><div><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Jul 28, 2015, at 5:55 PM, =
Eric Lombrozo &lt;<a href=3D"mailto:elombrozo@gmail.com" =
class=3D"">elombrozo@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><meta =
http-equiv=3D"Content-Type" content=3D"text/html charset=3Dutf-8" =
class=3D""><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: =
space; -webkit-line-break: after-white-space;" class=3D"">I agree that =
the historical reasons are irrelevant from an engineering perspective. =
But they still set a context for the discussion=E2=80=A6and might help =
shed some insight into the motivations behind some of the participants. =
It=E2=80=99s also good to know these things to counter arguments that =
start with =E2=80=9CBut Satoshi said that=E2=80=A6=E2=80=9D<div =
class=3D""><div class=3D""><br class=3D""></div><div class=3D"">What=E2=80=
=99s critically important to note is that several of the assumptions =
that were being made at the time this limit was decided have turned out =
wrong=E2=80=A6and that these other issues should probably be of greater =
concern and more highly prioritized in any discussion considering the =
merits of deploying potentially incompatible consensus rule changes. It =
seems if these other issues were fixed perhaps no block size limit would =
be required at all (as was originally hoped).<br class=3D""><div =
class=3D""><br class=3D""></div><div class=3D"">- Eric</div><div =
class=3D""><br class=3D""><div class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D"">On Jul 28, 2015, at 5:46 PM, Mark Friedenbach =
&lt;<a href=3D"mailto:mark@friedenbach.org" =
class=3D"">mark@friedenbach.org</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D"">Does it matter even in the slightest why the block size limit =
was put in place? It does not. Bitcoin is a decentralized payment =
network, and the relationship between utility (block size) and =
decentralization is empirical. Why the 1MB limit was put in place at the =
time might be a historically interesting question, but it bears little =
relevance to the present engineering issues.<br class=3D""></div><div =
class=3D"gmail_extra"><br class=3D""><div class=3D"gmail_quote">On Tue, =
Jul 28, 2015 at 5:43 PM, Jean-Paul Kogelman via bitcoin-dev <span =
dir=3D"ltr" class=3D"">&lt;<a =
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> =
wrote:<br class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D""><br=
 class=3D"">
&gt; Enter a =E2=80=9Ctemporary=E2=80=9D anti-spam measure - a one =
megabyte block size limit. Let=E2=80=99s test this out, then increase it =
once we see how things work. So far so good=E2=80=A6<br class=3D"">
&gt;<br class=3D"">
<br class=3D"">
</span>The block size limit was put in place as an anti-DoS measure =
(monster blocks), not "anti-spam". It was never intended to have any =
economic effect, not on spam and not on any future fee market.<br =
class=3D"">
<br class=3D"">
<br class=3D"">
jp<br class=3D"">
<br class=3D"">
_______________________________________________<br class=3D"">
bitcoin-dev mailing list<br class=3D"">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" =
class=3D"">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev"=
 rel=3D"noreferrer" target=3D"_blank" =
class=3D"">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br class=3D"">
</blockquote></div><br class=3D""></div>
</div></blockquote></div><br =
class=3D""></div></div></div></div></div></blockquote></div><br =
class=3D""></div></div></body></html>=

--Apple-Mail=_EC151483-D03B-487C-92F9-ABA7A94708B3--

--Apple-Mail=_5D1EA61A-D7A3-458B-93C6-F1B2AD9D259B
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

iQIcBAEBCgAGBQJVuD0VAAoJEJNAI64YFENUshQQALVGYXolwSN51g5fDFdszZ5R
FWlbowlu9SsbCX0iPfwpIXITLnd4EgUziDonGNcRp+Avq2sUjBMfseaWDhVYhjMi
1rVyQE5BOwhicGStVCGSrGTGKqKwjRw2OB9S5nRdDi7D6xKMeH0q6XYgICYPXcAr
Y3ahjpF8psS/kwovV8rjZ78RwGfOu1AoVN8aKosYrBPQR6Mj864nIkxmGWUE7xOp
VBrja5KQclbScGvsOE2r74l1oiIXUGaEQObHIOhenFpzOxKVlPqbR6FINAJLyJoX
8RRBCjalpiDMb3M7DKu3QkPsOZps/m3JsZwg6aeYpSA6jBswvqBKhhUYIooYzyb2
uP0FhZnHFN/EKujYDPA1Rg9iJQrilClVPyqv5MTl29SyBOECLPUgmryyyGijxJ1r
Y25h8dUFzpGaXF/eRgpWOBjBEgBr5C8qW8/6vYyIFi3nds9Q20FELF9it/IlSPxU
PfLoTmo4kat7DQ06xp28x+mvUglIro1pGxplIxgGF4c6rFpKhLvGoT+LqMYmTsP1
tlbLu2h57mD6nJjZV2/NDkO4tTzT9I+l2o2rFdBFRi5DpNcUQFRbP/DGFrLEQxuD
r245i5zxaBSkhj1KXc3JiQ5z+HWy1RXLQClCvVjH/ovpykyOl4JSy70ejlowOCzr
O9/BZpVZVyDgDMG2ds9Y
=OXXj
-----END PGP SIGNATURE-----

--Apple-Mail=_5D1EA61A-D7A3-458B-93C6-F1B2AD9D259B--