* [bitcoin-dev] BIP proposal - Max block size
@ 2015-11-13 13:07 Erik
2015-11-13 19:37 ` Luke Dashjr
0 siblings, 1 reply; 3+ messages in thread
From: Erik @ 2015-11-13 13:07 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 7110 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi devs. I was discussing the BIP proposals concerning max block size
yesterday in the #bitcoin channel. I believe that BIP101 fully utilized
will outperform consumer hardware soon or later and thereby centralize
Bitcoin. I would therefore like to do a different proposal:
Motivations:
* BIP101 propose a doubling of the block max size every second year.
This is very fast and may make the blockchain to grow faster than
consumer hardware can cope with.
* BIP102 is only a one-time solution, thus a new discussion of the next
block max size will need to arise soon after it has been implemented.
* BIP100 is an interesting solution in that the miners vote on the block
max size. Althoigh it has several cons: 1) The block max size can never
extend 32 MiB, even if we are so far in the future that it is need for
larger blocks. 2) The block max size could reach a size of 32 MiB in a
rather fast manner if pools vote for it, even though consumer hardware
today isn't really ready for the growth it implicates. 3) Block max size
can be pushed backwards, which will make TX fees higher, cause a lot of
orphaned low-fee TXes. It could make some smaller mining pools dependant
on lots of TXes with fees unprofitable. It is a serious flaw which could
damage the trust of the network.
* We does not for sure know how the evolution will proceed and if there
will be storage for the larger block chain in the future.
* There is a benefit of having a limit on the amount of transactions
that will be processed in that the fees will rise.
* Also there is a large problem if the fees rise too high because it
will prevent mainstream users from using the network. There will also be
a lot of orphan TXes which will cause uncertainity and fear of losses
among users that don't know how bitcoin works.
* Pruning is a problem if the blockchain grows too fast because some,
although a few, nodes still must store the complete data -> centralization.
Concepts:
There is always a growth in the block max size. Never a decrease.
The growth rate desicion should be in the hands of the miners.
It's good to have limits on the block max size to keep back spam TXes.
Use rules that makes a more smooth and predictable growth.
Rules:
1) Main target growth is 2^(1/2) every second year, or a doubling of the
block max size every four years.
2) The growth rate every second year will strictly be limited by the
formula 2^2 > growth > linear growth.
3) The target growth could be modified with positive or negative votes,
but it will not exceed the limits of 2) in any direction. Miners could
also choose to not vote.
4) The linear y=kx+m will be formed from the genesis block date with
size 1 MiB (m) through the last retarget block date with current size.
5) Target growth is based on votes from the last 26280 blocks (half a year).
6) Block max size grows at the same time as block difficulty retarget
(2016 blocks) with the formula 2^(((1/2)+(1/2*amount positive
votes)-(1/2*amount negative votes))/52). If the votes propose a lower
growth than the linear, use the linear growth instead. Block size is
floored to byte precision.
7) Amount positive/negative votes are calculated as following: number of
votes, positive or negative / 26280.
8) When this rule are put in force, the block max size will immidiately
be set to 4 MiB.
Notes:
* The number 52 came from 52 weeks/year * 2 years / 2 weeks. It measures
number of week pairs or difficulty retargets per two years.
* When there are no votes, the growth speed is set as main target as in
1). Also blocks mined before the implementation counts as blocks with no
votes.
Examples:
* After implementation, the block max size will be 4 MiB.
* At the first retarget, if no miner has left a vote, or equal number of
votes exists for positive and negative side. Then the next block max
size is 4096 KiB*2^((1/2)/52)=4123.3905 KiB (or exactly 4 222 351 bytes)
* If the block max size is exactly 11 MiB, it has been exactly 10 years
and 2 weeks since the genesis block, the next block is a retarget and
every vote is negative. Then 2^(((1/2)-(1/2))/52) = 1. It is lower than
the linear, then the next block max size will follow the linear derived
from: (11 MiB - 1 MiB) / (10.00 years) = 1 = k. Formula for a linear is
y=kx+m. m is the genesis block max size in MiB. Then y = 1 * (10+1/52) +
1 = 11.019 [MiB] (or exactly 11 554 500 bytes)
* If everyone in the past example continue voting negative for the next
four years, then the block max size will then be y = 1*14 + 1 = 15 [MiB].
* If the block max size was 10 MiB four years ago and every miner
instead has put positive votes into the block chain since 4.5 years,
then the block max size now is 10 MiB * 2^( ((1/2+1/2)/(52)) * 2) = 10
MiB * 4 = 40 MiB
* If there was 2628 negative votes and 5256 positive votes in the last
26280 blocks, then the formula will look like:
size*2^(((1/2)+(1/2*0.2)-(1/2*0.1))/52)
Pros:
Provides a long term solution that give opportunities to the network to
itself cope with the actual state and hardware limits of the future
network. No need to make a hard fork to adapt to other growth rates
within this proposal's limits.
Provides a smooth growth rate based on a large consensus, thus making
the growth for the near future almost predictable. No big jumps in block
max size provides stability to the network.
Miners can choose pools that votes in a way that conforms to the miners
interest.
Eliminates fluctuating block size as could happen with BIP100 proposal.
Cons:
A few single, large entities could either vote for smaller growth of
blocks for a long time, causing TX congestion and mistrust in the
bitcoin network. On the contrary they could vote for a larger growth of
blocks, causing the blockchain to be too large for consumer hardware. It
will then result in fewer nodes and in worst cases closing of small
pools. These cases seems to be extremely unlikely partly because of the
time and mining power that will be needed, partly also because of limits
in how much the votes can adjust the growth rate. It would therefore not
pose a large risk.
Sincerely,
Erik Fors
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJWReCVAAoJEJ51csApon2oLBgP/jn7mL5AzvU7/PCeAD39Kmc3
IsgFwh9LrHin/SaerPebusRGbjKXezP86kbiQVGEsSu3K3BxUAf9O09UoQiWECoc
g2EOw5E1XrtzBopxYTO06daM/2CqDydpLVIVv6NwwLMpXKvmbixdqaD6vOKfzhNF
1B5tmg9Vh1zqEkBj7exnuypagG/3llkCt3DRb0+siVzkIM/O9GzgHbGtt8rtDEnH
XHIhwLw+ySGuHg6hRhLo3uHs3gCUQmarxx1AoqR6AyvzgR6TGhJcy22vXct7QK5G
B2K4+JseyVD0bvkBeIpjuqJpGoCq4lmNu/AmI/nQ82TmqqzvOBi/ljFF/Q+HArjZ
UQO6p28lE7rmXf80GB6L117QLHktA5CdY++vW4Gwz3KDYEafs6H3CptvSmj9JbQz
SVAt/eVvvdnVkRcYw++b0WrRuOS3Z+105QIX4yqt0Kyghr87LQ76LXnZHPMKZeHt
IRX3wv7ZFqrJEpmGrTK4ZMZUAPVpkGe0kPms5kLHjEtjU92rvZJA726JJFoaAv5S
rFDiGUupLvHttZLTYfTdyFhCo6ZStOI095qDZ69awVCLMmYpC9aR/tjQ5zMu5eNS
y4hQdrX0Z4sdrJ2mTB+OXO7broLDn2G9dIqfpZwcIU493ljcXk/Uma4lj3oDrGTA
oc5Q5ie/OVUclWB6GIho
=cocM
-----END PGP SIGNATURE-----
[-- Attachment #2: 0x29A27DA8.asc --]
[-- Type: application/pgp-keys, Size: 3169 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] BIP proposal - Max block size
2015-11-13 13:07 [bitcoin-dev] BIP proposal - Max block size Erik
@ 2015-11-13 19:37 ` Luke Dashjr
2015-11-14 15:25 ` Erik
0 siblings, 1 reply; 3+ messages in thread
From: Luke Dashjr @ 2015-11-13 19:37 UTC (permalink / raw)
To: bitcoin-dev, Erik
On Friday, November 13, 2015 1:07:33 PM Erik via bitcoin-dev wrote:
> Hi devs. I was discussing the BIP proposals concerning max block size
> yesterday in the #bitcoin channel. I believe that BIP101 fully utilized
> will outperform consumer hardware soon or later and thereby centralize
> Bitcoin. I would therefore like to do a different proposal:
It doesn't look like you've considered BIP103 or newer BIPs? Especially, I'd
suggest you look at and work with John Sacco who just the other day posted a
BIP draft very similar-looking to yours. My overall impression of your summary
is that it is unnecessarily over-complicated and underspecified. How does the
2^(1/2) block size limit actually work? This is not a very precise number, so
it seems liable to produce rounding errors in different implementations.
Additionally, the miner voting thing seems pointless since miners can already
softfork lower limits. It would be beneficial to express the current
possibility so full nodes can enforce it, but this would be expressed as an
unlimited simple-majority vote to reduce the limit. Probably it would be ideal
to separate this off from the hardfork BIP, since it's fairly tangent to it.
Luke
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] BIP proposal - Max block size
2015-11-13 19:37 ` Luke Dashjr
@ 2015-11-14 15:25 ` Erik
0 siblings, 0 replies; 3+ messages in thread
From: Erik @ 2015-11-14 15:25 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 5105 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I've seen two different BIP103's and choose to not write about it
because risk of ambiguity. One of them are proposing a linear growth and
the other one is proposing an exponential growth. The all-linear growth
is an option that will not work well in the future because the growth
will be too slow soon or later. The exponential growth assumes that the
technology will rise in a certain growth, which may be too slow or too
fast in accordance to the technical evolution. None of the BIP103
proposals will actually handle an unexpected future case.
BIP105 has another feature not mentioned in my proposal that is to place
a vote requires a cost as a difficulty increase. I do not think it's a
good option since it will make users refrain from voting to "earn" a
difficulty lowering. The votes are the (yet) only soft way I see to let
the blockchain know if it should allow growing faster or slower. I also
don't see a benefit of having the opportunity to lower the block max
size in comparison to the risks involved with that. Then it proposes a
limit to how much it can increase at all which will need a new hard fork
when we need to increase the limits of the proposal.
I don't see how John Sacco's BIP proposal is similar to this one since
there is no voting mechanism to make the increase dynamic. Also John
proposes that the size will double at each halving instead of each
difficulty retarget. This could, in contrary to increase the fees by
making larger spaces in the blocks, decrease the fees because of that
the fee required to enter the next block will be lowered. Also it
proposes a hard limit at 32 MB which, again, need a new hard fork later.
The formula I've provided isn't actually complicated. The 2^(1/2...)
formula creates a number in the interval 1 to 2. The formula can tell if
the block max size every second year shall double or be the same based
on the last 6 month of votes. Because i believe there should always be
an increase to secure a stable growth of the network, there is also a
linear formula that the growth cannot be lower than. If the 2^(1/2...)
formula gives a lower increase than the linear value for the next
retarget, then the linear value should be used instead.
There will not be a rounding error since the implementation shall floor
the value to a whole byte. The next size should be calculated on that
value. Also, if the block max size is included in the retarget block,
there would be an extra correcting method to uncertain clients. The
formula isn't very different in complexity from the difficulty retarget
formula and will still need the last recalculated value to be computed.
One of the benefits of using an exponential formula is that it could
easily be fit for any arbitrary block period by changing the divisor. I
personally think the two week interval will be smooth enough.
Erik
Den 2015-11-13 kl. 20:37, skrev Luke Dashjr:
> On Friday, November 13, 2015 1:07:33 PM Erik via bitcoin-dev wrote:
>> Hi devs. I was discussing the BIP proposals concerning max block size
>> yesterday in the #bitcoin channel. I believe that BIP101 fully utilized
>> will outperform consumer hardware soon or later and thereby centralize
>> Bitcoin. I would therefore like to do a different proposal:
>
> It doesn't look like you've considered BIP103 or newer BIPs?
Especially, I'd
> suggest you look at and work with John Sacco who just the other day
posted a
> BIP draft very similar-looking to yours. My overall impression of your
summary
> is that it is unnecessarily over-complicated and underspecified. How
does the
> 2^(1/2) block size limit actually work? This is not a very precise
number, so
> it seems liable to produce rounding errors in different implementations.
> Additionally, the miner voting thing seems pointless since miners can
already
> softfork lower limits. It would be beneficial to express the current
> possibility so full nodes can enforce it, but this would be expressed
as an
> unlimited simple-majority vote to reduce the limit. Probably it would
be ideal
> to separate this off from the hardfork BIP, since it's fairly tangent
to it.
>
> Luke
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJWR1JfAAoJEJ51csApon2o1zkP/1Ik/VjakUII+2iXvPB+DSJ6
cekIC4A8zlgltSmFyE74IuQBlV/5LumNMCzXoKUaDRuKSedlyh1mUrt8hPFfISfr
yvIeWmXUQhd7s34mTTc9mBvz/TDuxuNYAFe1FYQhNzuV3GaLTysBAXScY5rGIkHf
hdgxG3mPtzaqse1I5e+3jpwlPUYpLn/0A2nmF0iXCoOv1LnTvrlV3thP8Fp/YMt3
iLsiWFQFf1jpA4mDoCC/G5bfYiqvFbtXdOKKZC12Dp3hTZZCzJ21FQ6+o/v4BT7y
MfW9kl3aWf3VSxbkvHppIrX1+HqDwTsn5u9kNcbYn8xBMRpFXFddFnsg/v6ai++L
mev+kIUrXvvDqvRSfQYmHIUKCwo+tzXbHcumydxBp412TOKW5bT1CmCRYMOvY/+C
45VWBj6foUYG/kq3QISm+lptVDQlESlAizHdWNkc9HJpKZG3VkNmmxEEXm3o7J07
LbBQ7bR2MELE6lP2Z3ImTXxZe0ZBdjyjDDV3qsIGK9D7LCK31KE70ZIueE3bePmR
9xWBfzKbm6Y3cQ6+4E8p8US7woVs9LGWXzLdKQyKEoiDx16bF7SOGvSyYcnOPsNu
O7lVpGh8Pezb0ZLEx5UnM5ONm35PzmzAT9Ng2iMEhche3AQS4s/b+wVWpyclQ62e
X4UVSr2O1mbfI9CmCPfI
=qcA8
-----END PGP SIGNATURE-----
[-- Attachment #2: Type: text/html, Size: 6039 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-11-14 15:25 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-11-13 13:07 [bitcoin-dev] BIP proposal - Max block size Erik
2015-11-13 19:37 ` Luke Dashjr
2015-11-14 15:25 ` Erik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox