Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 89268416 for ; Thu, 23 Jul 2015 17:43:10 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0AFA9196 for ; Thu, 23 Jul 2015 17:43:10 +0000 (UTC) Received: by pdbnt7 with SMTP id nt7so89515270pdb.0 for ; Thu, 23 Jul 2015 10:43:09 -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=LqEJCRc5RoftTjnHyzX+Gd4fp1Q324O4VTVpOHNi4JM=; b=KISkYs301Ts0S8qxCof7LUfxGQ1rGZE1Zi8TgEvpcCFLb24T6Xo3Gu0MG5ips6zf8k PRO+DiAqGBHaUjQdbSg6ySlrxk30eWCSXQud9PqcGwyg5Tu0M61IPEKqG5pGdh4RwX+V cgqBwtgHZCYz8XHxvCbmkKJNHeijTGZhJRrX08BYG4KvN3fZOd7lbpa2RQrxAf6qQRD8 cCOaEYJa2Jc6JWCIOMl8qVf1UGpZiezjL5o6doXiRSHtMQJIuN0p1rE36DR8r1n4vjA2 GzuvnZymEYNn9itPQlEBSrF2rZyXpknN0mFvJDEMU1KEc6HazC2Bphadr3Opnu7G1VSB HWFQ== X-Received: by 10.66.101.71 with SMTP id fe7mr20873058pab.89.1437673389640; Thu, 23 Jul 2015 10:43:09 -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 fv5sm10117739pdb.19.2015.07.23.10.43.07 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 23 Jul 2015 10:43:08 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8C20BC6D-7983-4013-BAF7-D92617AD634E"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: Date: Thu, 23 Jul 2015 10:43:06 -0700 Message-Id: References: <55B113AF.40500@thinlink.com> To: Gavin Andresen 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks 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: Thu, 23 Jul 2015 17:43:10 -0000 --Apple-Mail=_8C20BC6D-7983-4013-BAF7-D92617AD634E Content-Type: multipart/alternative; boundary="Apple-Mail=_2E5EAACD-003A-494F-B3AC-2B824BB587B5" --Apple-Mail=_2E5EAACD-003A-494F-B3AC-2B824BB587B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev = wrote: >=20 > I'd really like to move from "IMPOSSIBLE because... (electrum hasn't = been optimized > (by the way: you should run on SSDs, LevelDB isn't designed for = spinning disks), > what if the network is attacked? (attacked HOW???), current p2p = network is using > the simplest, stupidest possible block propagation algorithm...)" >=20 > ... to "lets work together and work through the problems and scale it = up." Let=E2=80=99s be absolutely clear about one thing - block size increases = are *not* about scaling the network. Can we please stop promoting this = falsehood? It doesn=E2=80=99t matter by what number we multiply the = block size=E2=80=A6we can NEVER satisfy the full demand if we insist on = every single transaction from every single person everywhere in the = world being on the blockchain=E2=80=A6it=E2=80=99s just absurd. Increasing block size only temporarily addresses one significant issue - = how to postpone having to deal with transaction fees, which by design, = are how the cost of operating the Bitcoin network (which is already very = expensive) is supposed to be paid for ultimately. Suggesting we avoid = dealing with this constitutes a new economic policy - dealing with it is = the default economic policy we=E2=80=99ve all known about from the = beginning=E2=80=A6so please stop claiming otherwise. > On Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev = wrote: >=20 > Why not help on a project that actually seems to offer great = scalability like the lightning network? There have been great progress = there. Exactly. There=E2=80=99s been tremendous progress here in addressing = scalability, yet I don=E2=80=99t see you participating in that = discussion, Gavin. > On Jul 23, 2015, at 5:17 AM, Jorge Tim=C3=B3n via bitcoin-dev = wrote: >=20 > But it seems to me that the "not now side" has no centralization > concerns at all and their true position is "not ever hit the blocksize > limit", that's the only explanation I can find to their lack of > answers to the "when do you think we should allow users to notice that > there's a limit in the blocksize to guarantee that the system can be > decentralized?". I agree with what you=E2=80=99re saying, Jorge=E2=80=A6but It=E2=80=99s = even worse than that. The July 4th fork illustrated that the security = model of the network itself could be at risk from the increasing costs = in validation causing people to rely on others to validate for = them=E2=80=A6and increasing block size only makes the problem worse. - Eric Lombrozo --Apple-Mail=_2E5EAACD-003A-494F-B3AC-2B824BB587B5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jul 23, 2015, at 9:28 AM, Gavin Andresen via bitcoin-dev = <bitcoin-dev@lists.linuxfoundation.org> wrote:

I'd really like to move = from "IMPOSSIBLE because...  (electrum hasn't been = optimized
(by the way: you should run on SSDs, LevelDB isn't designed = for spinning disks),
what if the network is attacked?  (attacked = HOW???), current p2p network is using
the simplest, stupidest = possible block propagation algorithm...)"

... to "lets work = together and work through the problems and scale it = up."

Let=E2=80= =99s be absolutely clear about one thing - block size increases are = *not* about scaling the network. Can we please stop promoting this = falsehood? It doesn=E2=80=99t matter by what number we multiply the = block size=E2=80=A6we can NEVER satisfy the full demand if we insist on = every single transaction from every single person everywhere in the = world being on the blockchain=E2=80=A6it=E2=80=99s just = absurd.

Increasing block size only temporarily addresses one = significant issue - how to postpone having to deal with transaction = fees, which by design, are how the cost of operating the Bitcoin network = (which is already very expensive) is supposed to be paid for ultimately. = Suggesting we avoid dealing with this constitutes a new economic policy = - dealing with it is the default economic policy we=E2=80=99ve all known = about from the beginning=E2=80=A6so please stop claiming = otherwise.

On = Jul 23, 2015, at 9:50 AM, cipher anthem via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

Why not help on a project that actually seems to offer = great scalability like the lightning network? There have been great = progress there.

Exactly. There=E2=80=99s been tremendous = progress here in addressing scalability, yet I don=E2=80=99t see you = participating in that discussion, Gavin.

On Jul 23, = 2015, at 5:17 AM, Jorge Tim=C3=B3n via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

But it seems to me = that the "not now side" has no centralization
concerns = at all and their true position is "not ever hit the blocksize
limit", that's the only explanation I can find to their = lack of
answers to the "when do you think we should = allow users to notice that
there's a limit in = the blocksize to guarantee that the system can be
decentralized?".

I agree with what = you=E2=80=99re saying, Jorge=E2=80=A6but It=E2=80=99s even worse than = that. The July 4th fork illustrated that the security model of the = network itself could be at risk from the increasing costs in validation = causing people to rely on others to validate for them=E2=80=A6and = increasing block size only makes the problem worse.

- Eric = Lombrozo
= --Apple-Mail=_2E5EAACD-003A-494F-B3AC-2B824BB587B5-- --Apple-Mail=_8C20BC6D-7983-4013-BAF7-D92617AD634E 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 iQIcBAEBCgAGBQJVsSeqAAoJEJNAI64YFENU3LIP/isjpJl4l/DvxMOafOCpko6o EpH35RD2uKMkWNsM2a+5rCMupqHBcwE3DpqbyZuUpzd5aY8StZE4b+1v7PA+8Jtr +G7ekAMxgXL1KQ2lvVifRHeDe4SDZzkPvLC5FaUubnGu+DcbwrbPfPLRVu6mmdPP 3KMOHVSVI8e6BLM2zspEif0R+DblaU1VKr8eILp6sa3ZoVnKY+clAub92r/dpHOd zZHHUvDQsOm5nB8bjMblTaunZodd+JAxhQWVeIcYvGxmhBMG4mTcaT/SLQi9a2Dm 3JN7LvJg5HIx3bIZD4ZiwFyZSZCnjp1qSuuKDNVHItqwnAO0mUReJkj+Px4SwLCf Dd9/5anZrQz0Ijn3UyCgevVYxHEPyarq+x61uEt4s6GqhbWCResnQlIa20ras/ln ckjD65N6lGWHvCt7enzsig+ugbdUzxmwHywRGx/jk62rRRElMNALKJoBTanFuV/C 2AiaU8E/SLok0c0KADKG25yz+4wgeWoIHIg9Oq+BnpflswZXTE/o2+7MmOtHRNJZ NpqcCPPAXajmlw/+eMM5mz9vBtFlbSXFNtkuu8FctZ0BJf4N9p+YXPLR8vfDPPXb XhgTpxhMvc9V3vJKu6mgoKW2ZzdENvwAS/mJlv5BSshSoNhuqp5H3MXJQB5dJN/u 2ZNrUVPFghOfMtNCy6W8 =3Q4w -----END PGP SIGNATURE----- --Apple-Mail=_8C20BC6D-7983-4013-BAF7-D92617AD634E--