Discussion:
BIP - 'Block75' - New algorithm
(too old to reply)
t. khan via bitcoin-dev
2017-01-02 18:04:37 UTC
Permalink
Raw 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.
Tom Zander via bitcoin-dev
2017-01-02 19:01:11 UTC
Permalink
Raw Message
Post by t. khan via bitcoin-dev
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
t. khan via bitcoin-dev
2017-01-02 19:32:24 UTC
Permalink
Raw 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.
Post by Tom Zander via bitcoin-dev
Post by t. khan via bitcoin-dev
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
t. khan via bitcoin-dev
2017-01-02 21:05:58 UTC
Permalink
Raw Message
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.
Tom Zander via bitcoin-dev
2017-01-02 22:33:16 UTC
Permalink
Raw Message
Post by t. khan via bitcoin-dev
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.
In actual fact the block size *is* set by miners, not math. And always has
been.
In your proposal the max blocksize continues to be set by miners as a
secondary effect of them choosing the block size.

Saying the max is actually math is painting an illusion that is rather thin
and easy to see through because every single usecase for your suggestion
starts with the choice of blocksize that a human makes. There is not really
any other input except some rather simple algorithm.
Post by t. khan via bitcoin-dev
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.
This is ignoring history where miners have successfully set policy on block
size for years now.
Post by t. khan via bitcoin-dev
Obviously no one would agree on what X
bytes would be and you'd have some nodes rejecting blocks that others
already accepted.
Not sure about your "obviously". I don't agree. In fact, there is plenty of
reason to think it does work.

Miners have always been the ones to decide on the block size, and they have
always done this in a coordinated fashion. This is a natural consequence of
the rather elegant (economic) design of Bitcoin.

* Miners earn more fee-based income when they produce bigger blocks.
* Miners take more risk of their blocks being orphaned with bigger blocks.
* Miners want to avoid emptying the memory pool every block as that removes
a total need for users to pay fees.
* Miners want to make sure the mempool does not become backlogged because
users that do not see their transactions confirmed will get disappointed and
find other means to do payments. Which hurts the price and in effect hurts
the miners income.

This behaviour in block size means blocks will not get huge and they will
not stay small either, because there are reasons for both. And so the size
will be something in the middle.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
Luke Dashjr via bitcoin-dev
2017-01-02 21:19:10 UTC
Permalink
Raw Message
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?
If you reject a block based on a particular condition, that is BY DEFINITION
part of the consensus protocol, and NOT a policy. The protocol is literally
the set of rules by which blocks are determined to be valid or invalid.

Policies are things that can vary node-to-node without affecting the validity
judgement of blocks.
Post by Luke Dashjr via bitcoin-dev
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.
Then it doesn't solve the actual problems of either miner spam or growth in
resource requirements, which are the entire purpose of the block size limit.
What is your definition of "spam"?
Anything that consumes more data than necessary to properly convey the
intended transfer of value (bitcoins) from one entity to another, including
all data that is not intended for such a purpose.
Post by Luke Dashjr via bitcoin-dev
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?
Putting group X in control of a limit that exists for the sole purpose of
restricting group X.
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).
It gives miners complete control over the limit. They can make blocks of any
size (within the current limit), thus triggering the conditions by which your
proposal would raise the limit further.

Luke
Tom Zander via bitcoin-dev
2017-01-02 22:01:08 UTC
Permalink
Raw Message
Post by Luke Dashjr via bitcoin-dev
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?
If you reject a block based on a particular condition, that is BY
DEFINITION part of the consensus protocol, and NOT a policy. The protocol
is literally the set of rules by which blocks are determined to be valid
or invalid.
Policies are things that can vary node-to-node without affecting the
validity judgement of blocks.
Policy is thus expanded to allow an individual node to reject blocks that
are technically speaking valid, just unacceptable to them.

It would be fun to ponder of the effect of that when applied to many nodes.
Many people already have pondered that question and find it intriguing. So
don't reject it out of hand :)
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
t. khan via bitcoin-dev
2017-01-03 14:28:27 UTC
Permalink
Raw Message
Post by Luke Dashjr via bitcoin-dev
Post by t. khan via bitcoin-dev
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.
Then it doesn't solve the actual problems of either miner spam or growth in
resource requirements, which are the entire purpose of the block size limit.
Do you have any direct evidence of "miner spam"? If so, please link to a
transaction. Also, what could a miner possibly gain from this?

For resource requirements (bandwidth/disk space), please run the numbers on
the Block75 algorithm and compare with growth rates of both.
Post by Luke Dashjr via bitcoin-dev
What is your definition of "spam"?
Anything that consumes more data than necessary to properly convey the
intended transfer of value (bitcoins) from one entity to another, including
all data that is not intended for such a purpose.
By this definition, any transaction which transfers ownership of an asset
(stock certificate, deeds to property, copyrights, etc.) is spam. But these
are legitimate, fee paying transactions. They are not spam. Yes, they're
only moving 0.0001 btc. Some will eventually move to Lightning (or
something like it), but many will not as they are unsuitable for off-chain.
Post by Luke Dashjr via bitcoin-dev
Post by t. khan via bitcoin-dev
I doubt you'll get consensus for such a fundamentally broken proposal.
Post by Luke Dashjr via bitcoin-dev
I certainly don't foresee any circumstance where I could reasonably
support it... The block size limit exists to restrict miners; it makes
no
Post by t. khan via bitcoin-dev
Post by Luke Dashjr via bitcoin-dev
sense to put it in their control.
Specifically, what is broken about it?
Putting group X in control of a limit that exists for the sole purpose of
restricting group X.
No, it actually gives them less power than they have now. Consider the
two-week recalculation: the result of any attempt to manipulate the block
size (up or down) will only last for two weeks. There's no way for a miner
to profit from this (in fact, they'd lose money this way). The best outcome
they could hope for is a very small increase or decrease for two weeks. So
why would anyone do this?

As soon as such a manipulation ended, Block75 would correct the max block
size back to an appropriate level (defined as: average block 75% full).
Post by Luke Dashjr via bitcoin-dev
There would still be a block size limit, it would just change slightly
Post by t. khan via bitcoin-dev
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).
It gives miners complete control over the limit. They can make blocks of any
size (within the current limit), thus triggering the conditions by which your
proposal would raise the limit further.
We covered this ad nauseum in the other Block75 thread, but basically no
one has been able to come up with a realistic scenario wherein miners would
be motivated to do this *and* there aren't any pools large enough now (nor
have there ever been) to have anything more than a minor and temporary
effect.

If such a scenario actually does exist, please describe it in detail.

- t.k.
Hampus Sjöberg via bitcoin-dev
2017-02-13 11:21:44 UTC
Permalink
Raw Message
Post by Luke Dashjr via bitcoin-dev
It gives miners complete control over the limit. They can make blocks of
any size (within the current limit), thus triggering the conditions by
which your proposal would raise the limit further.

There might be a long term incentive to keep increasing the blocksize, to
further centralize the network (and kick smaller miners out), but it comes
with the cost of losing out on transaction fees.
Miners have always needed to plan for the short term, I see no rational
scenario where miners would spam their blocks with their own transactions
(or low fee transactions) to keep increasing the blocksize limit.

Hampus

Luke Dashjr via bitcoin-dev
2017-01-02 20:04:56 UTC
Permalink
Raw Message
Post by t. khan via bitcoin-dev
Thoughts? For any predictions as to how this would behave, please provide
the numbers used to arrive at any conclusions.
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.
Post by t. khan via bitcoin-dev
2. Is there any need for a minimum max blocksize? Block75 allows for
decreasing the size as well as increasing it.
Probably it should never make it so small that a reasonable generation
transaction cannot fit. But I'm not sure this needs explicit enforcement.
Post by t. khan via bitcoin-dev
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.
If you can't trust miners to signal based on the community's consensus, then
don't use miner signalling at all. Just set a block height it activates.
Post by t. khan via bitcoin-dev
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).
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.

Luke
t. khan via bitcoin-dev
2017-01-02 20:41:42 UTC
Permalink
Raw Message
Post by Luke Dashjr via bitcoin-dev
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?
Post by Luke Dashjr via bitcoin-dev
I doubt you'll get consensus for such a fundamentally broken proposal.
I certainly don't foresee any circumstance where I could reasonably support
Post by Luke Dashjr via bitcoin-dev
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.
Loading...