Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QwHRi-0006FG-KO for bitcoin-development@lists.sourceforge.net; Wed, 24 Aug 2011 17:40:58 +0000 X-ACL-Warn: Received: from mail-gy0-f175.google.com ([209.85.160.175]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QwHRf-0002QY-KX for bitcoin-development@lists.sourceforge.net; Wed, 24 Aug 2011 17:40:58 +0000 Received: by gyg4 with SMTP id 4so1321080gyg.34 for ; Wed, 24 Aug 2011 10:40:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.43.45.68 with SMTP id uj4mr4761678icb.87.1314207649958; Wed, 24 Aug 2011 10:40:49 -0700 (PDT) Received: by 10.42.244.130 with HTTP; Wed, 24 Aug 2011 10:40:49 -0700 (PDT) In-Reply-To: References: <201108241215.36847.luke@dashjr.org> Date: Wed, 24 Aug 2011 10:40:49 -0700 Message-ID: From: Rick Wesson To: Gregory Maxwell Content-Type: multipart/alternative; boundary=bcaec51a76ec230cbd04ab43d0da X-Spam-Score: 1.3 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message 0.3 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QwHRf-0002QY-KX Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split? 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: Wed, 24 Aug 2011 17:40:58 -0000 --bcaec51a76ec230cbd04ab43d0da Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 24, 2011 at 10:19 AM, Gregory Maxwell wrote: > On Wed, Aug 24, 2011 at 1:07 PM, Rick Wesson > wrote: > > On Wed, Aug 24, 2011 at 9:46 AM, Gregory Maxwell > wrote: > >> On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr wrote: > >> > >> > - Replace hard limits (like 1 MB maximum block size) with something > that > >> > can > >> > dynamically adapt with the times. Maybe based on difficulty so it > can't > >> > be > >> > gamed? > >> Too early for that. > > Could you provide a reference to why in your estimation it is "to early." > > Simpy stating this as fact isn't enough to sway demand. > > Can you provide a reference to this 'demand' a post by Luke isn't > enough to support the claim of demand. > > how about trend, its a hard limit and as you acknowledged below we are not there yet; however the trend is for more transactions and we will bump into the limit. Being good architects we should consider how to scale or explicitly state why its a good idea not to. -rick > We're not at maximum size right now (thankfully). > > We don't know what the network dynamics would look like at that > traffic level. So how could we competently say what the right metrics > would be to get the right behavior there? Thats what I meant by too > early. > no one ever "knows" what the network dynamics are going to be in developing infrastructure -- so lets not kid our selves, in being able to estimate this before the code is even written. -rick --bcaec51a76ec230cbd04ab43d0da Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Aug 24, 2011 at 10:19 AM, Gregor= y Maxwell <gmaxw= ell@gmail.com> wrote:
On Wed, Aug 24, 2011 at 1:07 PM, Rick Wesson
<rick@support-intellige= nce.com> wrote:
> On Wed, Aug 24, 2011 at 9:46 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
>> On Wed, Aug 24, 2011 at 12:15 PM, Luke-Jr <luke@dashjr.org> wrote:
>>
>> > - Replace hard limits (like 1 MB maximum block size) with som= ething that
>> > can
>> > dynamically adapt with the times. Maybe based on difficulty s= o it can't
>> > be
>> > gamed?
>> Too early for that.
> Could you provide a=A0reference=A0to why in your estimation it is &quo= t;to early."
> =A0Simpy stating this as fact isn't enough to sway demand.

Can you provide a reference to this 'demand' a post by Luke i= sn't
enough to support the claim of demand.

how about trend, its a hard limit and as you=A0acknow= ledged=A0below we are not there yet; however the trend is for more transact= ions and we will bump into the limit. Being good architects we should consi= der how to scale or explicitly state why its a good idea not to.

-rick

=A0
We're not at maximum size right now (thankfully).

We don't know what the network dynamics would look like at that
traffic level. So how could we competently say what the right metrics
would be to get the right behavior there? =A0Thats what I meant by too
early.

no one ever "knows" what the network = dynamics are going to be in developing infrastructure -- so lets not kid ou= r selves, in being able to estimate this before the code is even written.

-rick

--bcaec51a76ec230cbd04ab43d0da--