[bitcoin-dev] BIP - 'Block75' - New algorithm

[bitcoin-dev] BIP - 'Block75' - New algorithm

[t. khan]

[-- Attachment #1: Type: text/plain, Size: 1556 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1915 bytes --]

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[Tom Zander]

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

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[t. khan]

[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2179 bytes --]

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[Tom Zander]

On Monday, 2 January 2017 14:32:24 CET t. khan wrote:
> 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.

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?

> A maximum block size is necessary to prevent a single nefarious miner from
> creating a ridiculously large block which would break the network.

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?

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[t. khan]

[-- Attachment #1: Type: text/plain, Size: 872 bytes --]

On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander <tomz@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.

[-- Attachment #2: Type: text/html, Size: 1373 bytes --]

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[Tom Zander]

On Monday, 2 January 2017 16:05:58 CET t. khan wrote:
> On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander <tomz@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.

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.

> > 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.

> 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

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[Luke Dashjr]

On Monday, January 02, 2017 8:35:40 PM Tom Zander via bitcoin-dev wrote:
> 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.

On Monday, January 02, 2017 8:41:42 PM t. khan wrote:
> On Mon, Jan 2, 2017 at 3:04 PM, Luke Dashjr <luke@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.

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.

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

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[Tom Zander]

On Monday, 2 January 2017 21:19:10 CET Luke Dashjr wrote:
> On Monday, January 02, 2017 8:35:40 PM Tom Zander via bitcoin-dev wrote:
> > 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

[bitcoin-dev] BIP - 'Block75' - New algorithm

[t. khan]

[-- Attachment #1: Type: text/plain, Size: 3261 bytes --]

On Mon, Jan 2, 2017 at 4:19 PM, Luke Dashjr <luke@dashjr.org
<javascript:_e(%7B%7D,'cvml','luke@dashjr.org');>> wrote:

> > 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.

> 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.

> > 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.
>

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).

> 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.


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.

[-- Attachment #2: Type: text/html, Size: 4730 bytes --]

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[Hampus Sjöberg]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

> 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

[-- Attachment #2: Type: text/html, Size: 693 bytes --]

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[Luke Dashjr]

On Monday, January 02, 2017 6:04:37 PM t. khan via bitcoin-dev wrote:
> 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.

> 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.

> 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.

> 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

Re: [bitcoin-dev] BIP - 'Block75' - New algorithm

[t. khan]

[-- Attachment #1: Type: text/plain, Size: 1180 bytes --]

On Mon, Jan 2, 2017 at 3:04 PM, Luke Dashjr <luke@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.

[-- Attachment #2: Type: text/html, Size: 2127 bytes --]