<unnamed>

Public Key

npub1lupuse8cysuanxcpq8h4d32359xxzedzjj83rmwv4yr9qxfmhtzqghjqch

Profile Code

nprofile1qqs07q7gvnuzgwwenvqsrm6kc4g6znrpvk3ffrc3ahx2jpjsryam43qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsdzx3qm

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 19:56:02 CEST

- reply

📅 Original date posted:2017-02-06
📝 Original message:>My BIP draft didn't make progress because the community opposes any block
size
>increase hardfork ever.
Luke, how do you know the community opposes that? Specifically, how did you
come to this conclusion?
>Your version doesn't address the current block size
>issues (ie, the blocks being too large).
Why do you think blocks are "too large"? Please cite some evidence. I've
asked this before and you ignored it, but an answer would be helpful to the
discussion.
- t.k.
On Sun, Feb 5, 2017 at 6:02 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> My BIP draft didn't make progress because the community opposes any block
> size
> increase hardfork ever. Your version doesn't address the current block size
> issues (ie, the blocks being too large). So you've retained the only
> certain-
> DOA parts of my proposal, and removed the most useful part... I'm not sure
> the
> point. Also, your version is now EXCLUSIVELY a hardfork, so it makes no
> sense
> to keep the BIP 9 deployment at all - either it gets consensus or it
> doesn't,
> but miners have no part in deployment of it.
>
> On Sunday, February 05, 2017 9:50:26 PM Andrew C via bitcoin-dev wrote:
> > Hello all,
> >
> > Many people have expressed discontent with Luke-jr's proposed block size
> > BIP, in particular with the decrease in size that would occur if it were
> > to be activated prior to 2024.
> >
> > I have decided to modify the proposal to instead begin the increase
> > steps at the current 1000000 byte limit. The increases and the time spam
> > of each increase will remain the same, just that the increase begins
> > from 1000000 bytes instead of 300000 bytes.
> >
> > Furthermore, instead of a fixed schedule from a fixed point in time, the
> > increases will instead be calculated off of the MTP of the activation
> > block (the first block to be in the active state for this fork).
> >
> > While this proposal shares many of the same issues with the one it
> > modifies, I hope that it will be slightly less controversial and can
> > allow us to move forward with scaling Bitcoin.
> >
> > The full text of the proposal can be found at
> > https://github.com/achow101/bips/blob/bip-blksize/bip-blksize.mediawiki.
> > My implementation of it is available at
> > https://github.com/achow101/bitcoin/tree/bip-blksize
> >
> >
> > Andrew
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170206/fcf1d14b/attachment.html>

2023-06-07 19:55:16 CEST

- reply

📅 Original date posted:2017-01-02
📝 Original message:On Mon, Jan 2, 2017 at 3:04 PM, Luke Dashjr <luke at dashjr.org> wrote:
> It would probably behave as an ever-increasing block size limit. Spam has
> typically filled blocks to the max, and miners have stopped self-enforcing
> reasonable limits.
Using the growth rate over the last year as a model (
https://blockchain.info/charts/avg-block-size?daysAverageString=14 ),
Block75 would also have frequently decreased the limit. Though, yes, more
transactions would equal larger blocks over time, but that's the entire
point of this.
What is your definition of "spam"? Also, can you point to data that
supports the hypothesis that spam is filling blocks?
> I doubt you'll get consensus for such a fundamentally broken proposal.
>
I certainly don't foresee any circumstance where I could reasonably support
> it... The block size limit exists to restrict miners; it makes no sense to
> put
> it in their control.
>
Specifically, what is broken about it?
There would still be a block size limit, it would just change slightly
every two weeks. I agree that miners shouldn't have control of this, and
Block75 doesn't give them any (at least none they can make a profit on).
- t.k.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170102/8116b645/attachment.html>

2023-06-07 19:55:16 CEST

- reply

📅 Original date posted:2017-01-02
📝 Original message:On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander <tomz at freedommail.ch> wrote:
> If the input of your math is completely free and human created, how does it
> follow that it was math that created it ?
> Why do you want it math created anyway?
The beauty of math is that everyone on the planet agrees how it works.
Everything in Bitcoin is math, with the exception of the blocksize limit
(1MB) which was a stop-gap solution at the time.
> A maximum is needed, yes. But does it have to be part of the protocol?
> A simple policy which is set by node operators (reject block if greater
> than
> X bytes) will solve this just fine, no?
No. That would be an epic disaster. There's no such thing as a "simple
policy" when humans are involved. Obviously no one would agree on what X
bytes would be and you'd have some nodes rejecting blocks that others
already accepted.
- t.k.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170102/4082357f/attachment-0001.html>

2023-06-07 19:55:14 CEST

- reply

📅 Original date posted:2017-01-02
📝 Original message:Math should decide the max block size, not humans (miners in this
case). The goal of Block75 is to manage the max block size without any
human intervention.
Under Block75, miners don't have any direct control but could still choose
to mine smaller blocks (same as now), though doing so would cost them the
fees from transactions they didn't include in their blocks.
A maximum block size is necessary to prevent a single nefarious miner from
creating a ridiculously large block which would break the network.
- t.k.
On Mon, Jan 2, 2017 at 2:01 PM, Tom Zander <tomz at freedommail.ch> wrote:
> On Monday, 2 January 2017 13:04:37 CET t. khan via bitcoin-dev wrote:
> > Thoughts?
>
> This proposal doesn't change the block size, it only changes the maximum
> block size. Which is expected, nothing bad there.
>
> The direct consequence of this, though is that the miners set the maximum
> block size. Because they decide on the actual created block size.
>
> This leads me to the simple question why we can't just give the miners full
> control of the maximum block size directly?
>
> The fact of the matter is that miners have for the full history of Bitcoin
> been able to set the block size, until they hit the 1MB limit.
> And your proposal keeps that property, but why have a maximum in the
> protocol?
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170102/b2a3d4b7/attachment.html>

2023-06-07 19:55:14 CEST

- reply

📅 Original date posted:2017-01-02
📝 Original message:Based on feedback from this list and further simulations, here is a new
algorithm for Block75:
new max blocksize = x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY)
TARGET_CAPACITY = 0.75
AVERAGE_CAPACITY = average percentage full of the last 2016 blocks, as a
decimal
x = current max block size
Please note that this algorithm actually tries to keep blocks 75% full,
unlike the old one that unnecessarily capped growth at 250KB. While this
would theoretically allow a maximum increase of 25% over the previous max
block size, in practice it's not possible to get that high.
This would be calculated every 2016 blocks along with difficulty.
Block75 should maintain transaction fees at about the level they were in
May/June 2016 when blocks started hitting 75% full somewhat consistently.
Thoughts? For any predictions as to how this would behave, please provide
the numbers used to arrive at any conclusions.
Other questions:
1. How do we make Block75 play nice with SegWit?
2. Is there any need for a minimum max blocksize? Block75 allows for
decreasing the size as well as increasing it.
Activation:
To help negate some of the risk associated with a hard fork and to prevent
a single relatively small mining pool from blocking Block75's adoption,
activation would occur once 900 of the last 1,000 blocks mined signaled
support, with a grace period of 4,032 blocks.
Thank you again to all those who commented on the previous Block75 thread.
Together, we can make 2017 the year the block size debate ends (hopefully
forever).
Happy New Year!
- t.k.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170102/dab8e778/attachment.html>

2023-06-07 19:54:53 CEST

- reply

📅 Original date posted:2016-12-10
📝 Original message:Agreed, the clear goal of 10 minutes per block is why the difficulty
adjustment works well. Blocks averaging 75% full is the clear goal of the
described method. That's the target to attempt.
Under Block75, there will still be full blocks. There will still be
transaction fees and a fee market. The fees will be lower than they are now
of course.
Hardcoding a cap will inevitably become a roadblock (again), and we'll be
back in the same position as we are now. Permanent solutions are preferred.
On Sat, Dec 10, 2016 at 6:12 PM, Bram Cohen <bram at bittorrent.com> wrote:
> On Mon, Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>>
>> Put another way: let’s stop thinking about what the max block size should
>> be and start thinking about how full we want the average block to be
>> regardless of size. Over the last year, we’ve had averages of 75% or
>> higher, so aiming for 75% full seems reasonable, hence naming this concept
>> ‘Block75’.
>>
>
> That's effectively making the blocksize limit completely uncapped and only
> preventing spikes, and even in the case of spikes it doesn't differentiate
> between 'real' traffic and low value spam attacks. It suffers from the same
> fundamental problems as bitcoin unlimited: There are in the end no
> transaction fees, and inevitably some miners will want to impose some cap
> on block size for practical purposes, resulting in a fork.
>
> Difficulty adjustment works because there's a clear goal of having a
> certain rate of making new blocks. Without a target to attempt automatic
> adjustment makes no sense.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161210/fff14476/attachment.html>

2023-06-07 19:54:50 CEST

- reply

📅 Original date posted:2016-12-11
📝 Original message:The assumption you're making is incorrect. There is not an infinite number
of low-fee transactions.
Yes, the average fee will go down compared to today with Block75, but this
will balance itself between demand and the minimum fee miners are willing
to accept (not zero).
For example, add 200kb to today's max block size. How does that affect fees?
(200kb would likely be the first increase if Block75 activated today)
-t.k.
On Sun, Dec 11, 2016 at 4:55 PM, James Hilliard <james.hilliard1 at gmail.com>
wrote:
> I think the main thing you're missing is that there will always be
> transactions available to mine simply because demand for blockspace is
> effectively unbounded as fees approach 0. Nodes generally have a
> static mempool size and dynamic minrelaytxfee nowadays so as
> transactions get mined lower fee transactions get accepted into the
> mempool. An individual opting to not send a transaction would not make
> the blocks smaller simply because there will always be other
> transactions available(it would really only have an effect on the
> transaction fees needed to get mined).
>
> On Sun, Dec 11, 2016 at 3:40 PM, t. khan <teekhan42 at gmail.com> wrote:
> >
> > On Sun, Dec 11, 2016 at 3:31 PM, James Hilliard <
> james.hilliard1 at gmail.com>
> > wrote:
> >>
> >> What's most likely to happen is miners will max out the blocks they
> >> mine simply to try and get as many transaction fees as possible like
> >> they are doing right now(there will be a backlog of transactions at
> >> any block size). Having the block size double every year would likely
> >> cause major problems and this proposal allows over a 7x increase it
> >> seems.
> >
> >
> > Block75 is not exponential scaling. It's true the max theoretical
> increase
> > in the first year would be 7x, but the next year would be a max of 2x,
> and
> > the next could only increase by 50% and so on.
> >
> > However, to reach the max in the first year: 1) ALL blocks would have to
> be
> > 100% full and 2) transactions would have to increase at the same rate.
> We'd
> > have to be doing 2.1 million transactions a day within a year to make
> that
> > happen, and would therefore need blocks to be that big.
> >
> > Realistically, max block size will grow (and shrink) at a much slower
> rate
> > ... even more so with SegWit.
> >
> >>
> >> The main problem with this proposal I think is that users effectively
> >>
> >> have no way to stop the miners from increasing block size
> >> continuously.
> >
> >
> > Yes they could, simply by not sending transactions. Users don't care at
> all
> > about block size. They just want their transactions to be fast and
> > relatively cheap.
> >
> > -t.k.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161211/8822ce40/attachment-0001.html>

2023-06-07 19:54:49 CEST

- reply

📅 Original date posted:2016-12-11
📝 Original message:On Sun, Dec 11, 2016 at 3:31 PM, James Hilliard <james.hilliard1 at gmail.com>
wrote:
> What's most likely to happen is miners will max out the blocks they
> mine simply to try and get as many transaction fees as possible like
> they are doing right now(there will be a backlog of transactions at
> any block size). Having the block size double every year would likely
> cause major problems and this proposal allows over a 7x increase it
> seems.
Block75 is not exponential scaling. It's true the max theoretical increase
in the first year would be 7x, but the next year would be a max of 2x, and
the next could only increase by 50% and so on.
However, to reach the max in the first year: 1) ALL blocks would have to be
100% full and 2) transactions would have to increase at the same rate. We'd
have to be doing 2.1 million transactions a day within a year to make that
happen, and would therefore need blocks to be that big.
Realistically, max block size will grow (and shrink) at a much slower rate
... even more so with SegWit.
> The main problem with this proposal I think is that users effectively
have no way to stop the miners from increasing block size
> continuously.
Yes they could, simply by not sending transactions. Users don't care at all
about block size. They just want their transactions to be fast and
relatively cheap.
-t.k.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161211/3af4ea5c/attachment.html>

2023-06-07 19:54:49 CEST

- reply

📅 Original date posted:2016-12-11
📝 Original message:On Sun, Dec 11, 2016 at 12:11 PM, s7r <s7r at sky-ip.org> wrote:
>
> This is an incentive, if few miners agree to create a large conglomerate
> that will ultimately control the network.
>
> You miss something obvious that makes this attack actually free of cost.
> Nothing will "cost them more in transaction fees". A miner can create
> thousands of transactions paying to himself, and not broadcast them to
> the network, but hold them and include them in the blocks he mines. The
> fees are collected by him because transactions are included in a block
> that he mined and the left amount is in another wallet of the same
> person. Repeat this continuously to fill blocks.
>
No, that wasn't overlooked. Miners could indeed stuff their own blocks for
free, but they can't stuff blocks mined by others for free.
In the hypothetical scenario where there is a single mining pool which
mines most (if not all) of the blocks, we would have much larger problems
than their ability to raise the max block size gradually. Even if they were
able to fill 100% of the blocks for an entire year, the max block size for
that 2016 block period would be 7.25MB (not accounting for SegWit). After
the whole year they would have made no extra profit vs doing nothing. And
as soon as they stopped this scheme, block size would spring back to it's
natural level.
The good news is, this scenario has never happened and even when we've come
remotely close (when ASICs first shipped), the situation was temporary. The
odds of this happening in the future and persisting long enough to have any
major effect with Block75 are very close to zero.
> Topology and bandwidth speed / hash rate of the network cannot be
> controlled - if we make assumptions about these it might have terrible
> consequences.
>
> Even if we take in consideration that bandwidth will only grow and disk
> space will only cost less (which is not something we can safely assume,
> by the way) the hard limit max. block size cannot grow to unlimited
> value (even if the growth happens over time). There is also a validation
> cost in time for each block, for the health of the network any node
> should be able to download _and_ validate a block, before next block
> gets mined.
>
> You said in another post that a permanent solution is preferred, rather
> than kicking the can down the road. I fully agree, as well as many
> others reading this list, but the permanent solution doesn't necessarily
> have to be increasing the max block size dynamically.
>
Increasing *and* decreasing max block size dynamically. Block75 is
self-correcting, whereas any solution with hardcoded limits can't correct
without human intervention and would rely on our ability to predict the
future (which as you pointed out, we can't do). Therefore, any solution
that's not dynamic cannot be permanent.
Additionally, the frequent and gradual changes in max block size would
allow us to see any consequences well in advance (years probably).
> If you think about it the other way around, dynamically growing the max
> block size is also kicking the can down the road ... just without having
> to touch it and get dust on the boot ;)
Not having to touch it again = permanent solution. ;)
It would be helpful if some others would run the numbers on how Block75
would adjust the block size over time:
new max block size = 1000kb + (average block size over last 2016 blocks -
750kb)
-t.k.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161211/cb598cfa/attachment.html>

2023-06-07 19:54:47 CEST

- reply

📅 Original date posted:2016-12-10
📝 Original message:Miners 'gaming' the Block75 system -
There is no financial incentive for miners to attempt to game the Block75
system. Even if it were attempted and assuming the goal was to create
bigger blocks, the maximum possible increase would be 25% over the previous
block size. And, that size would only last for two weeks before readjusting
down. It would cost them more in transaction fees to stuff the network than
they could ever make up. To game the system, they'd have to game it forever
with no possibility of profit.
Blocks would get too big -
Eventually, blocks would get too big, but only if bandwidth stopped
increasing and the cost of disk space stopped decreasing. Otherwise, the
incremental adjustments made by Block75 (especially in combination with
SegWit) wouldn't break anyone's connection or result in significantly more
orphaned blocks.
The frequent and small adjustments made by Block75 have the added benefit
of being more easily adapted to, both psychologically and technologically,
with regards to miners/node operators.
-t.k
On Sat, Dec 10, 2016 at 5:44 AM, s7r via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> t. khan via bitcoin-dev wrote:
> > BIP Proposal - Managing Bitcoin’s block size the same way we do
> > difficulty (aka Block75)
> >
> > The every two-week adjustment of difficulty has proven to be a
> > reasonably effective and predictable way of managing how quickly blocks
> > are mined. Bitcoin needs a reasonably effective and predictable way of
> > managing the maximum block size.
> >
> > It’s clear at this point that human beings should not be involved in the
> > determination of max block size, just as they’re not involved in
> > deciding the difficulty.
> >
> > Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.) or
> > passing the decision to miners/pool operators, the max block size should
> > be adjusted every two weeks (2016 blocks) using a system similar to how
> > difficulty is calculated.
> >
> > Put another way: let’s stop thinking about what the max block size
> > should be and start thinking about how full we want the average block to
> > be regardless of size. Over the last year, we’ve had averages of 75% or
> > higher, so aiming for 75% full seems reasonable, hence naming this
> > concept ‘Block75’.
> >
> > The target capacity over 2016 blocks would be 75%. If the last 2016
> > blocks are more than 75% full, add the difference to the max block size.
> > Like this:
> >
> > MAX_BLOCK_BASE_SIZE = 1000000
> > TARGET_CAPACITY = 750000
> > AVERAGE_OVER_CAP = average block size of last 2016 blocks minus
> > TARGET_CAPACITY
> >
> > To check if a block is valid, ≤ (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)
> >
> > For example, if the last 2016 blocks are 85% full (average block is 850
> > KB), add 10% to the max block size. The new max block size would be
> > 1,100 KB until the next 2016 blocks are mined, then reset and
> > recalculate. The 1,000,000 byte limit that exists currently would
> > remain, but would effectively be the minimum max block size.
> >
> > Another two weeks goes by, the last 2016 blocks are again 85% full, but
> > now that means they average 935 KB out of the 1,100 KB max block size.
> > This is 93.5% of the 1,000,000 byte limit, so 18.5% would be added to
> > that to make the new max block size of 1,185 KB.
> >
> > Another two weeks passes. This time, the average block is 1,050 KB. The
> > new max block size is calculated to 1,300 KB (as blocks were 105% full,
> > minus the 75% capacity target, so 30% added to max block size).
> >
> > Repeat every 2016 blocks, forever.
> >
> > If Block75 had been applied at the difficulty adjustment on November
> > 18th, the max block size would have been 1,080KB, as the average block
> > during that period was 83% full, so 8% is added to the 1,000KB limit.
> > The current size, after the December 2nd adjustment would be 1,150K.
> >
> > Block75 would allow the max block size to grow (or shrink) in response
> > to transaction volume, and does so predictably, reasonably quickly, and
> > in a method that prevents wild swings in block size or transaction fees.
> > It attempts to keep blocks at 75% total capacity over each two week
> > period, the same way difficulty tries to keep blocks mined every ten
> > minutes. It also keeps blocks as small as possible.
> >
> > Thoughts?
> >
> > -t.k.
> >
>
> I like the idea. It is good wrt growing the max. block size
> automatically without human action, but the main problem (or question)
> is not how to grow this number, it is what number can the network
> handle, considering both miners and users. While disk space requirements
> might not be a big problem, block propagation time is. The time required
> for a block to propagate in the network (or at least to all the miners)
> is directly dependent of its size. If blocks take too much time to
> propagate in the network, the orphan rate will increase in unpredictable
> ways. For example if the internet speed in China is worse than in
> Europe, and miners in China have more than 50% of the hashing power,
> blocks mined by European miners might get orphaned.
>
> The system as described can also be gamed, by filling the network with
> transactions. Miners have the monetary interest to include as many
> transactions as possible in a block in order to collect the fees.
> Regardless how you think about it, there has to be a maximum block size
> that the network will allow as a consensus rule. Increasing it
> dynamically based on transaction volume will reach a point where the
> number got big enough that it broke things. Bitcoin, because its
> fundamental design, can scale by using offchain solutions.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161210/e1899177/attachment-0001.html>

2023-06-07 19:54:45 CEST

- reply

📅 Original date posted:2016-12-05
📝 Original message:BIP Proposal - Managing Bitcoin’s block size the same way we do difficulty
(aka Block75)
The every two-week adjustment of difficulty has proven to be a reasonably
effective and predictable way of managing how quickly blocks are mined.
Bitcoin needs a reasonably effective and predictable way of managing the
maximum block size.
It’s clear at this point that human beings should not be involved in the
determination of max block size, just as they’re not involved in deciding
the difficulty.
Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.) or
passing the decision to miners/pool operators, the max block size should be
adjusted every two weeks (2016 blocks) using a system similar to how
difficulty is calculated.
Put another way: let’s stop thinking about what the max block size should
be and start thinking about how full we want the average block to be
regardless of size. Over the last year, we’ve had averages of 75% or
higher, so aiming for 75% full seems reasonable, hence naming this concept
‘Block75’.
The target capacity over 2016 blocks would be 75%. If the last 2016 blocks
are more than 75% full, add the difference to the max block size. Like this:
MAX_BLOCK_BASE_SIZE = 1000000
TARGET_CAPACITY = 750000
AVERAGE_OVER_CAP = average block size of last 2016 blocks minus
TARGET_CAPACITY
To check if a block is valid, ≤ (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)
For example, if the last 2016 blocks are 85% full (average block is 850
KB), add 10% to the max block size. The new max block size would be 1,100
KB until the next 2016 blocks are mined, then reset and recalculate. The
1,000,000 byte limit that exists currently would remain, but would
effectively be the minimum max block size.
Another two weeks goes by, the last 2016 blocks are again 85% full, but now
that means they average 935 KB out of the 1,100 KB max block size. This is
93.5% of the 1,000,000 byte limit, so 18.5% would be added to that to make
the new max block size of 1,185 KB.
Another two weeks passes. This time, the average block is 1,050 KB. The new
max block size is calculated to 1,300 KB (as blocks were 105% full, minus
the 75% capacity target, so 30% added to max block size).
Repeat every 2016 blocks, forever.
If Block75 had been applied at the difficulty adjustment on November 18th,
the max block size would have been 1,080KB, as the average block during
that period was 83% full, so 8% is added to the 1,000KB limit. The current
size, after the December 2nd adjustment would be 1,150K.
Block75 would allow the max block size to grow (or shrink) in response to
transaction volume, and does so predictably, reasonably quickly, and in a
method that prevents wild swings in block size or transaction fees. It
attempts to keep blocks at 75% total capacity over each two week period,
the same way difficulty tries to keep blocks mined every ten minutes. It
also keeps blocks as small as possible.
Thoughts?
-t.k.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161205/c24d6c6d/attachment.html>