From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B26A53EE for ; 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 ; Wed, 29 Jul 2015 02:40:25 +0000 (UTC) Received: by pdjr16 with SMTP id r16so82108365pdj.3 for ; 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 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> <35B780B8-7282-4C98-9A0D-C7774028E277@gmail.com> To: Mark Friedenbach 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 = 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 > 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 = > 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 = >> 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 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:

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

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).

- Eric

On Jul 28, 2015, at 5:46 PM, Mark Friedenbach = <mark@friedenbach.org> wrote:

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.

On Tue, = Jul 28, 2015 at 5:43 PM, Jean-Paul Kogelman via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> = wrote:
> 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
>

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.


jp

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<= /a>



= --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--