From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YzOz4-0004XF-G2 for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 12:38:26 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of jamin.net designates 209.85.213.42 as permitted sender) client-ip=209.85.213.42; envelope-from=marcel@jamin.net; helo=mail-yh0-f42.google.com; Received: from mail-yh0-f42.google.com ([209.85.213.42]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YzOz3-0001S8-BR for bitcoin-development@lists.sourceforge.net; Mon, 01 Jun 2015 12:38:26 +0000 Received: by yhom41 with SMTP id m41so32739620yho.1 for ; Mon, 01 Jun 2015 05:38:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=pwtg2EvTi/Ds5nKUpvu+MNDEOgvPijtFkEx6NdslWuw=; b=UgjQQMPrBKdkdSXGNN6IxDfsoPYoZhRGqSFGDaJ34lPBCezt6lDxS+JvyF1OijlTWf gE/uPqS9t3OHGmN6lWirJS7Whd3XoN/bdPUDh/+YBfXm7PovFkjraD3jFPZYzGzh5xY2 l8Z5PT1tAxQaJkmNPFM0fIYY8MHRGiFxvexNxHOASjHsXS2P7dM3BgMIqnIQSx8zvxAC QWPcL+F1Sqt+s+h2sByxTEV/XiPjQq9IZbuobPgXFJabgzh0+lBFcHLNrnQNy7nozmOT gmuQ6lmNhbITEtUBazDFkfMVWnksSJzlXqcUF0/hy89IGyzd08jzFvL34U3C7FZOOn6e LNjg== X-Gm-Message-State: ALoCoQkfPXtlgCKFkFiAkHIkATYUM+FYGWHJD1W7CDkcb+3kU2GSIPfu3vexIMErncuJHNs0keSz MIME-Version: 1.0 X-Received: by 10.170.71.5 with SMTP id n5mr25237754ykn.85.1433159191009; Mon, 01 Jun 2015 04:46:31 -0700 (PDT) Received: by 10.13.224.7 with HTTP; Mon, 1 Jun 2015 04:46:30 -0700 (PDT) In-Reply-To: References: <16096345.A1MpJQQkRW@crushinator> Date: Mon, 1 Jun 2015 13:46:30 +0200 Message-ID: From: Marcel Jamin To: Ricardo Filipe Content-Type: multipart/alternative; boundary=001a1139e66c7cb18405177360cd 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 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YzOz3-0001S8-BR Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step function 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: Mon, 01 Jun 2015 12:38:26 -0000 --001a1139e66c7cb18405177360cd Content-Type: text/plain; charset=UTF-8 > Let the block size limit be a function of the number of current transactions in the mempool. There is no single mempool which transactions could be counted and there is no consensus about the average number of unconfirmed transactions. 2015-06-01 13:30 GMT+02:00 Ricardo Filipe : > I've been following the discussion of the block size limit and IMO it > is clear that any constant block size limit is, as many have said > before, just kicking the can down the road. > My problem with the dynamic lower limit solution based on past blocks > is that it doesn't account for usage spikes. I would like to propose > another dynamic lower limit scheme: > Let the block size limit be a function of the number of current > transactions in the mempool. This way, bitcoin usage regulates the > block size limit. > > I'm sorry i don't have the knowledge of the code base or time to make > simulations on this kind of approach, but nevertheless I would like to > leave it here for discussion or foster other ideas. > > cheers > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a1139e66c7cb18405177360cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0Let the block size limit be a function of the number of current=C2=A0transactions in the mempool= .

There is no single mempool which transact= ions could be counted and there is no consensus about the average number of= unconfirmed transactions.

2015-06-01 13:30 GMT+02:00 Ricardo Filipe <ri= cardojdfilipe@gmail.com>:
I= 've been following the discussion of the block size limit and IMO it is clear that any constant block size limit is, as many have said
before, just kicking the can down the road.
My problem with the dynamic lower limit solution based on past blocks
is that it doesn't account for usage spikes. I would like to propose another dynamic lower limit scheme:
Let the block size limit be a function of the number of current
transactions in the mempool. This way, bitcoin usage regulates the
block size limit.

I'm sorry i don't have the knowledge of the code base or time to ma= ke
simulations on this kind of approach, but nevertheless I would like to
leave it here for discussion or foster other ideas.

cheers

---------------------------------------------------------------------------= ---
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a1139e66c7cb18405177360cd--