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; 
MIME-Version: 1.0
In-Reply-To: <CALC81CNidPEgLpTVCRWqXYn0UpSCU-nuo5S85NSQ4UCce=n4EA@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
	<CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
	<CANEZrP3VCaFsW4+gPm2kCJ9z7oVUZYVaeNf=_cJWEWwh4ZxiPQ@mail.gmail.com>
	<CABsx9T21zjHyO-nh1aSBM3z4Bg015O0rOfYq7=Sy4mf=QxUVQA@mail.gmail.com>
	<CANEZrP2BaKwhpPgcUHWAHswOmUeFLgEk4ysrn4+73qNzWDJ=yQ@mail.gmail.com>
	<CABsx9T3nCJ-w_v-yEbEE2Ytb+xC65mhYqhoAhoOHw9tkPpG0TA@mail.gmail.com>
	<CANEZrP1qH+zucYsGrMgnfi99e61Edxaj+xm=u_xYXga1g0WzJQ@mail.gmail.com>
	<CAE-z3OVmw+0doCe0hmYE6A1D61h0AUh4Mtnf5Fg1e4zQBkpraQ@mail.gmail.com>
	<CANEZrP0psA7hcJdKdA-r01UEt7ig3O-9vjwBMqKSEq-csu0hPQ@mail.gmail.com>
	<CABsx9T23r_y2R9OEgqb3AAZf47Hh8BUJncjxxmPp5v_9uKEiqQ@mail.gmail.com>
	<CA+VAk3O7SmDkxL9rATWe9oqCVVKcT=cFXDJnARPN8pv=UiHaiA@mail.gmail.com>
	<CACq0ZD7-qr4BCdnqOSXLYv-i58vAXWGcQ1oLsrbHoNFMeiNTtg@mail.gmail.com>
	<CALC81CNidPEgLpTVCRWqXYn0UpSCU-nuo5S85NSQ4UCce=n4EA@mail.gmail.com>
Date: Mon, 1 Jun 2015 13:46:30 +0200
Message-ID: <CAAUq484AGnEm91TAUJzLUHdxyNTERJ=FtT3w5UYc+oiFVOaq1w@mail.gmail.com>
From: Marcel Jamin <marcel@jamin.net>
To: Ricardo Filipe <ricardojdfilipe@gmail.com>
Content-Type: multipart/alternative; boundary=001a1139e66c7cb18405177360cd
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
	function
Precedence: list

--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 <ricardojdfilipe@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 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

<div dir=3D"ltr"><div>&gt;=C2=A0<span style=3D"font-size:12.8000001907349px=
">Let the block size limit be a function of the number of current=C2=A0</sp=
an><span style=3D"font-size:12.8000001907349px">transactions in the mempool=
.</span></div><div><br></div><div>There is no single mempool which transact=
ions could be counted and there is no consensus about the average number of=
 unconfirmed transactions.</div></div><div class=3D"gmail_extra"><br><div c=
lass=3D"gmail_quote">2015-06-01 13:30 GMT+02:00 Ricardo Filipe <span dir=3D=
"ltr">&lt;<a href=3D"mailto:ricardojdfilipe@gmail.com" target=3D"_blank">ri=
cardojdfilipe@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I=
&#39;ve been following the discussion of the block size limit and IMO it<br=
>
is clear that any constant block size limit is, as many have said<br>
before, just kicking the can down the road.<br>
My problem with the dynamic lower limit solution based on past blocks<br>
is that it doesn&#39;t account for usage spikes. I would like to propose<br=
>
another dynamic lower limit scheme:<br>
Let the block size limit be a function of the number of current<br>
transactions in the mempool. This way, bitcoin usage regulates the<br>
block size limit.<br>
<br>
I&#39;m sorry i don&#39;t have the knowledge of the code base or time to ma=
ke<br>
simulations on this kind of approach, but nevertheless I would like to<br>
leave it here for discussion or foster other ideas.<br>
<br>
cheers<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>

--001a1139e66c7cb18405177360cd--