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

[Hampus Sjöberg 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Tom Zander via bitcoin-dev]

On Monday, 2 January 2017 16:05:58 CET t. khan wrote:
> On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander  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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Tom Zander via bitcoin-dev]

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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Tom Zander via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[t. khan via bitcoin-dev]

On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander  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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Luke Dashjr via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[t. khan via bitcoin-dev]

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  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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Tom Zander via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[t. khan via bitcoin-dev]

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev