From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yqf7f-0003Ku-Qv for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 10:03:11 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.175 as permitted sender) client-ip=209.85.212.175; envelope-from=mh.in.england@gmail.com; helo=mail-wi0-f175.google.com; Received: from mail-wi0-f175.google.com ([209.85.212.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yqf7e-0006rB-Hw for bitcoin-development@lists.sourceforge.net; Fri, 08 May 2015 10:03:11 +0000 Received: by wiun10 with SMTP id n10so21538511wiu.1 for ; Fri, 08 May 2015 03:03:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.12.228 with SMTP id b4mr4617584wic.92.1431079384511; Fri, 08 May 2015 03:03:04 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.194.143.9 with HTTP; Fri, 8 May 2015 03:03:04 -0700 (PDT) In-Reply-To: <554BE0E1.5030001@bluematt.me> References: <554BE0E1.5030001@bluematt.me> Date: Fri, 8 May 2015 12:03:04 +0200 X-Google-Sender-Auth: D4Sz1v65Vtub6viZx-IZhnUJY68 Message-ID: From: Mike Hearn To: Matt Corallo Content-Type: multipart/alternative; boundary=001a11c2a3a85bfc0305158f2236 X-Spam-Score: -0.5 (/) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 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 X-Headers-End: 1Yqf7e-0006rB-Hw Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Block Size Increase Requirements X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 May 2015 10:03:11 -0000 --001a11c2a3a85bfc0305158f2236 Content-Type: text/plain; charset=UTF-8 > > * Though there are many proposals floating around which could > significantly decrease block propagation latency, none of them are > implemented today. With a 20mb cap, miners still have the option of the soft limit. I would actually be quite surprised if there were no point along the road from 1mb to 20mb where miners felt a need to throttle their block sizes artificially, for the exact reason you point out: propagation delays. But we don't *need* to have fancy protocol upgrades implemented right now. All we need is to demolish one bottleneck (the hard cap) so we can then move on and demolish the next one (whatever that is, probably faster propagation). Scaling is a series of walls we punch through as we encounter them. One down, onto the next. We don't have to tackle them all simultaneously. FWIW I don't think the GFW just triggers packet loss, these days. It's blocked port 8333 entirely. * I'd very much like to see someone working on better scaling > technology ... I know StrawPay is working on development, > So this request is already satisfied, isn't it? As you point out, expecting more at this stage in development is unreasonable, there's nothing for anyone to experiment with or commit to. They have code here, by the way: https://github.com/strawpay You can find their fork of MultiBit HD, their implementation library, etc. They've contributed patches and improvements to the payment channels code we wrote. > * I'd like to see some better conclusions to the discussion around > long-term incentives within the system. > What are your thoughts on using assurance contracts to fund network security? I don't *know* if hashing assurance contracts (HACs) will work. But I don't know they won't work either. And right now I'm pretty sure that plain old fee pressure won't work. Demand doesn't outstrip supply forever - people find substitutes. --001a11c2a3a85bfc0305158f2236 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=C2=A0* Though there are many proposals floating around which = could
significantly decrease block propagation latency, none of them are
implemented today.

With a 20mb cap, miners= still have the option of the soft limit.

I would = actually be quite surprised if there were no point along the road from 1mb = to 20mb where miners felt a need to throttle their block sizes artificially= , for the exact reason you point out: propagation delays.

But we don't need=C2=A0to have fancy protocol upgrades i= mplemented right now. All we need is to demolish one bottleneck (the hard c= ap) so we can then move on and demolish the next one (whatever that is, pro= bably faster propagation). Scaling is a series of walls we punch through as= we encounter them. One down, onto the next. We don't have to tackle th= em all simultaneously.

FWIW I don't think the = GFW just triggers packet loss, these days. It's blocked port 8333 entir= ely.

=C2=A0* I'd very much like to= see someone working on better scaling
technology ...=C2=A0I know StrawPay is working on development,

So this request is already satisfied, isn't it?= As you point out, expecting more at this stage in development is unreasona= ble, there's nothing for anyone to experiment with or commit to.
<= div>
They have code here, by the way:

=C2=A0 =C2=A0https://github.com/s= trawpay

You can find their fork of MultiBi= t HD, their implementation library, etc. They've contributed patches an= d improvements to the payment channels code we wrote.
=C2=A0
=C2=A0* I'd like to see some better conclusions to the discussion aroun= d
long-term incentives within the system.

What are your thoughts on using assurance contracts to fund network securi= ty?

I don't know=C2=A0if hashing assura= nce contracts (HACs) will work. But I don't know they won't work ei= ther. And right now I'm pretty sure that plain old fee pressure won'= ;t work. Demand doesn't outstrip supply forever - people find substitut= es.=C2=A0
--001a11c2a3a85bfc0305158f2236--