Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Upal Chakraborty via bitcoin-dev]

Proposal 1 does not deal with Tx fee. Proposal 2 does. According to
proposal 2, miners wont be able to increase or decrease Max Block Size only
by manipulating Tx fee. They have to manipulate...
i. Tx fee of ~4000 blocks.
ii. Block size of ~4000 blocks.

I never proposed *next block collects Tx fee from previous block*. Not sure
what you mean here!

On Tue, Aug 25, 2015 at 2:49 PM, Chun Wang <1240...@gmail.com> wrote:

> Proposal 1 looks good, but tx fee collected can be manipulated by
> miners. I like the idea next block collect the tx fee from previous
> block.
>
> On Tue, Aug 25, 2015 at 5:07 PM, Upal Chakraborty via bitcoin-dev
>  wrote:
> > Github:
> >
> https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki
> >
> > 
> >   BIP: 1xx
> >   Title: Dynamically Controlled Bitcoin Block Size Max Cap
> >   Author: Upal Chakraborty 
> >   Status: Draft
> >   Type: Standards Track
> >   Created: 2015-08-24
> > 
> >
> > ==Abstract==
> >
> > This BIP proposes replacing the fixed one megabyte maximum block size
> with a
> > dynamically controlled maximum block size that may increase or decrease
> with
> > difficulty change depending on various network factors. I have two
> proposals
> > regarding this...
> >
> > i. Depending only on previous block size calculation.
> >
> > ii. Depending on previous block size calculation and previous Tx fee
> > collected by miners.
> >
> > ==Motivation==
> >
> > With increased adoption, transaction volume on bitcoin network is bound
> to
> > grow. If the one megabyte max cap is not changed to a flexible one which
> > changes itself with changing network demand, then adoption will hamper
> and
> > bitcoin's growth may choke up. Following graph shows the change in
> average
> > block size since inception...
> >
> >
> https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
> >
> > ==Specification==
> >
> > ===Proposal 1 : Depending only on previous block size calculation===
> >
> >   If more than 50% of block's size, found in the first 2000 of the last
> > difficulty period, is more than 90% MaxBlockSize
> >   Double MaxBlockSize
> >   Else if more than 90% of block's size, found in the first 2000 of the
> last
> > difficulty period, is less than 50% MaxBlockSize
> >   Half MaxBlockSize
> >   Else
> >   Keep the same MaxBlockSize
> >
> > ===Proposal 2 : Depending on previous block size calculation and
> previous Tx
> > fee collected by miners===
> >
> >   TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first
> 2008
> > blocks in last 2 difficulty period
> >   TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008
> > blocks in last 2 difficulty period (This actually includes 8 blocks from
> > last but one difficulty)
> >
> >   TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008
> blocks
> > in last 2 difficulty period
> >   TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks
> in
> > last 2 difficulty period (This actually includes 8 blocks from last but
> one
> > difficulty)
> >
> >   If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016
> >
> > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty >
> > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty >
> > TotalBlockSizeInLastButOneDifficulty) )
> >   MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize /
> > TotalBlockSizeInLastButOneDifficulty
> >   Else If ( ( (Sum of first 4016 block size in last 2 difficulty
> > period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty <
> > TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty <
> > TotalBlockSizeInLastButOneDifficulty) )
> >   MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize /
> > TotalBlockSizeInLastButOneDifficulty
> >   Else
> >   Keep the same MaxBlockSize
> >
> > ==Rationale==
> >
> > These two proposals have been derived after discussion on
> > [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and
> > [
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html
> > bitcoin-dev mailing list]. The original idea and its evolution in the
> light
> > of various arguements can be found [http://upalc.com/maxblocksize.php
> here].
> >
> > ===Proposal 1 : Depending only on previous block size calculation===
> >
> > This solution is derived directly from the indication of the problem. If
> > transaction volume increases, then we will naturally see bigger blocks.
> On
> > the contrary, if there are not enough transaction volume, but maximum
> block
> > size is high, then only few blocks may sweep the mempool. Hence, if block
> > size is itself taken into consideration, then maximum block size can most
> > rationally be derived. Moreover, this solution not only increases, but
> also
> > decreases the maximum block size, just like difficulty.
> >
> > ===Proposal 2 : Dependin

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Upal Chakraborty via bitcoin-dev]

Can we please keep this mail chain discussion specific to the proposed
draft -
https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki
?

I understand, voting process is an important subject of discussion. But,
that may be discussed in a separate mail chain.

On Wed, Aug 26, 2015 at 11:58 AM, Hector Chu via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 26 August 2015 at 01:29, Peter Todd via bitcoin-dev
>  wrote:
> > For instance, a very simple toy example that would work is just XORing
> your vote with SHA256(the entire blockchain)
>
> Uh, that would totally not work.
>
> I think my proposal of using CLTV to lock coins (votes) is better.
> Failing a soft-fork to implement that in time, counting votes from the
> UTXO set is also ok - the difference between that and CLTV is that it
> is not as strong an evidence of commitment.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Hector Chu via bitcoin-dev]

On 26 August 2015 at 01:29, Peter Todd via bitcoin-dev
 wrote:
> For instance, a very simple toy example that would work is just XORing your 
> vote with SHA256(the entire blockchain)

Uh, that would totally not work.

I think my proposal of using CLTV to lock coins (votes) is better.
Failing a soft-fork to implement that in time, counting votes from the
UTXO set is also ok - the difference between that and CLTV is that it
is not as strong an evidence of commitment.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Peter Todd via bitcoin-dev]

On Wed, Aug 26, 2015 at 05:44:46AM +0800, Chun Wang wrote:
> On Wed, Aug 26, 2015 at 5:18 AM, Simon Liu via bitcoin-dev
>  wrote:
> > I don't think this would work.
> >
> > If the rule is that one user can only have one vote, how do you prevent
> > a user running multiple nodes?
> 
> The vote is not counted by nodes, but bitcoin amount, or probably
> better, coin-days. It works like proof-of-stake. A mix of
> proof-of-work and proof-of-stake is good.

Yup.

To implement a vote where only users with access to a full node can
vote, you'd force part of the vote to be determined by a
non-miner-committed value calculatable by anyone with a full node. For
instance, a very simple toy example that would work is just XORing your
vote with SHA256(the entire blockchain)

-- 
'peter'[:-1]@petertodd.org
08d42f5514157c3257577e006985ea8335e4567e1bed16bd


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Chun Wang via bitcoin-dev]

On Wed, Aug 26, 2015 at 5:18 AM, Simon Liu via bitcoin-dev
 wrote:
> I don't think this would work.
>
> If the rule is that one user can only have one vote, how do you prevent
> a user running multiple nodes?

The vote is not counted by nodes, but bitcoin amount, or probably
better, coin-days. It works like proof-of-stake. A mix of
proof-of-work and proof-of-stake is good.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Eric Voskuil via bitcoin-dev]

> just as in democracy in general

One should be clear that Bitcoin is by no possible measure a democracy.

The proposed vote is on what goes into a particular github repository.
The outcome is ultimately controlled by those with control of that
repository.

Bitcoin is an anarchy by design. People will use whatever they want.

e

On 08/25/2015 02:14 PM, Matt Whitlock via bitcoin-dev wrote:
> On Tuesday, 25 August 2015, at 1:37 pm, Peter Todd wrote:
>> On Tue, Aug 25, 2015 at 04:26:23PM -0400, Matt Whitlock wrote:
>>> On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev
wrote:
 What would you think of an approach like John Dillon's proposal to
 explicitly give the economic majority of coin holders a vote for
the max
 blocksize? Miners could still vote BIP100 style for what max they were
 willing to use, limited in turn by the vote of the economic majority.
>>>
>>> What fraction of coin holders do you suppose will vote? And, of
those, what fraction have the technical knowledge to make an informed
vote? It would be like polling Toyota truck owners to see whether the
2017 Tacoma should increase its engine's cylinder displacement by 10%.
Ordinary users just aren't going to be able to vote meaningfully, and
most won't respond to the poll at all.
>>
>> Note that you can make the % of voters required adapt dyanmically to
voter
>> interest. Also, your example is rather misleading, as car buyers *do*
>> make those kinds of decisions though various market mechanisms.
>
> Yes, car buyers do make those kinds of decisions through market
mechanisms. An equivalent process for Bitcoin would be that the max
block-size limit (and other fundamental economic parameters) would be
determined via a process of forking off altcoins (such as Bitcoin XT
will do) and allowing the market to decide which coin is most valuable.
This is the "default" mechanism for change (because it's what naturally
happens when there is a lack of internal consensus), but it's not the
least painful mechanism.
>
> My point still stands that — just as in democracy in general — the
voters are really in no position to cast informed votes, nor should they
be (cf. "rational ignorance" [1]). I do not oppose opening up the
determination of the max block-size limit to a popular "check" via
stakeholder vote — actually, I think this is an important check on
miners' power — but I do argue that the vote is likely to have
drastically little participation and very low-quality results.
>
> [1] Rational Ignorance: «Ignorance about an issue is said to be
"rational" when the cost of educating oneself about the issue
sufficiently to make an informed decision can outweigh any potential
benefit one could reasonably expect to gain from that decision, and so
it would be irrational to waste time doing so.»





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Simon Liu via bitcoin-dev]

I don't think this would work.

If the rule is that one user can only have one vote, how do you prevent
a user running multiple nodes?

Also, how do you verify that a node is indeed a fully validating node
with its own copy of the blockchain?


On 08/25/2015 01:37 PM, Peter Todd via bitcoin-dev wrote:
> 
> An interesting idea would be to design a voting mechanism such that only
> users with access to validating nodes be able to vote - a fundemental
> requirement for users to fully participate in Bitcoin's goverance.
> 
> 
> 
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Matt Whitlock via bitcoin-dev]

On Tuesday, 25 August 2015, at 1:37 pm, Peter Todd wrote:
> On Tue, Aug 25, 2015 at 04:26:23PM -0400, Matt Whitlock wrote:
> > On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote:
> > > What would you think of an approach like John Dillon's proposal to
> > > explicitly give the economic majority of coin holders a vote for the max
> > > blocksize? Miners could still vote BIP100 style for what max they were
> > > willing to use, limited in turn by the vote of the economic majority.
> > 
> > What fraction of coin holders do you suppose will vote? And, of those, what 
> > fraction have the technical knowledge to make an informed vote? It would be 
> > like polling Toyota truck owners to see whether the 2017 Tacoma should 
> > increase its engine's cylinder displacement by 10%. Ordinary users just 
> > aren't going to be able to vote meaningfully, and most won't respond to the 
> > poll at all.
> 
> Note that you can make the % of voters required adapt dyanmically to voter
> interest. Also, your example is rather misleading, as car buyers *do*
> make those kinds of decisions though various market mechanisms.

Yes, car buyers do make those kinds of decisions through market mechanisms. An 
equivalent process for Bitcoin would be that the max block-size limit (and 
other fundamental economic parameters) would be determined via a process of 
forking off altcoins (such as Bitcoin XT will do) and allowing the market to 
decide which coin is most valuable. This is the "default" mechanism for change 
(because it's what naturally happens when there is a lack of internal 
consensus), but it's not the least painful mechanism.

My point still stands that — just as in democracy in general — the voters are 
really in no position to cast informed votes, nor should they be (cf. "rational 
ignorance" [1]). I do not oppose opening up the determination of the max 
block-size limit to a popular "check" via stakeholder vote — actually, I think 
this is an important check on miners' power — but I do argue that the vote is 
likely to have drastically little participation and very low-quality results.

[1] Rational Ignorance: «Ignorance about an issue is said to be "rational" when 
the cost of educating oneself about the issue sufficiently to make an informed 
decision can outweigh any potential benefit one could reasonably expect to gain 
from that decision, and so it would be irrational to waste time doing so.» 


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Peter Todd via bitcoin-dev]

On Tue, Aug 25, 2015 at 04:26:23PM -0400, Matt Whitlock wrote:
> On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote:
> > What would you think of an approach like John Dillon's proposal to
> > explicitly give the economic majority of coin holders a vote for the max
> > blocksize? Miners could still vote BIP100 style for what max they were
> > willing to use, limited in turn by the vote of the economic majority.
> 
> What fraction of coin holders do you suppose will vote? And, of those, what 
> fraction have the technical knowledge to make an informed vote? It would be 
> like polling Toyota truck owners to see whether the 2017 Tacoma should 
> increase its engine's cylinder displacement by 10%. Ordinary users just 
> aren't going to be able to vote meaningfully, and most won't respond to the 
> poll at all.

Note that you can make the % of voters required adapt dyanmically to voter
interest. Also, your example is rather misleading, as car buyers *do*
make those kinds of decisions though various market mechanisms. Equally,
you can make the same criticism of democracy in general.

An interesting idea would be to design a voting mechanism such that only
users with access to validating nodes be able to vote - a fundemental
requirement for users to fully participate in Bitcoin's goverance.

-- 
'peter'[:-1]@petertodd.org
0ba8add4a8edc1b0467e9e377da016834d2abff3fc8ce1fb


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Matt Whitlock via bitcoin-dev]

On Tuesday, 25 August 2015, at 1:16 pm, Peter Todd via bitcoin-dev wrote:
> What would you think of an approach like John Dillon's proposal to
> explicitly give the economic majority of coin holders a vote for the max
> blocksize? Miners could still vote BIP100 style for what max they were
> willing to use, limited in turn by the vote of the economic majority.

What fraction of coin holders do you suppose will vote? And, of those, what 
fraction have the technical knowledge to make an informed vote? It would be 
like polling Toyota truck owners to see whether the 2017 Tacoma should increase 
its engine's cylinder displacement by 10%. Ordinary users just aren't going to 
be able to vote meaningfully, and most won't respond to the poll at all.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Peter Todd via bitcoin-dev]

On Tue, Aug 25, 2015 at 05:19:28PM +0800, Chun Wang via bitcoin-dev wrote:
> Proposal 1 looks good, but tx fee collected can be manipulated by
> miners. I like the idea next block collect the tx fee from previous
> block.

What would you think of an approach like John Dillon's proposal to
explicitly give the economic majority of coin holders a vote for the max
blocksize? Miners could still vote BIP100 style for what max they were
willing to use, limited in turn by the vote of the economic majority.

I think in principle that would give all parties a clear voice in the
matter, which in turn makes whatever the result is more legitimit and
less controversial.

-- 
'peter'[:-1]@petertodd.org
13a6653562bcb4bda7570118635eeaa8597108576bc9733b


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Chun Wang via bitcoin-dev]

Proposal 1 looks good, but tx fee collected can be manipulated by
miners. I like the idea next block collect the tx fee from previous
block.

On Tue, Aug 25, 2015 at 5:07 PM, Upal Chakraborty via bitcoin-dev
 wrote:
> Github:
> https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki
>
> 
>   BIP: 1xx
>   Title: Dynamically Controlled Bitcoin Block Size Max Cap
>   Author: Upal Chakraborty 
>   Status: Draft
>   Type: Standards Track
>   Created: 2015-08-24
> 
>
> ==Abstract==
>
> This BIP proposes replacing the fixed one megabyte maximum block size with a
> dynamically controlled maximum block size that may increase or decrease with
> difficulty change depending on various network factors. I have two proposals
> regarding this...
>
> i. Depending only on previous block size calculation.
>
> ii. Depending on previous block size calculation and previous Tx fee
> collected by miners.
>
> ==Motivation==
>
> With increased adoption, transaction volume on bitcoin network is bound to
> grow. If the one megabyte max cap is not changed to a flexible one which
> changes itself with changing network demand, then adoption will hamper and
> bitcoin's growth may choke up. Following graph shows the change in average
> block size since inception...
>
> https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
>
> ==Specification==
>
> ===Proposal 1 : Depending only on previous block size calculation===
>
>   If more than 50% of block's size, found in the first 2000 of the last
> difficulty period, is more than 90% MaxBlockSize
>   Double MaxBlockSize
>   Else if more than 90% of block's size, found in the first 2000 of the last
> difficulty period, is less than 50% MaxBlockSize
>   Half MaxBlockSize
>   Else
>   Keep the same MaxBlockSize
>
> ===Proposal 2 : Depending on previous block size calculation and previous Tx
> fee collected by miners===
>
>   TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of first 2008
> blocks in last 2 difficulty period
>   TotalBlockSizeInLastDifficulty = Sum of all Block size of second 2008
> blocks in last 2 difficulty period (This actually includes 8 blocks from
> last but one difficulty)
>
>   TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks
> in last 2 difficulty period
>   TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in
> last 2 difficulty period (This actually includes 8 blocks from last but one
> difficulty)
>
>   If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 >
> 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty >
> TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty >
> TotalBlockSizeInLastButOneDifficulty) )
>   MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize /
> TotalBlockSizeInLastButOneDifficulty
>   Else If ( ( (Sum of first 4016 block size in last 2 difficulty
> period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty <
> TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty <
> TotalBlockSizeInLastButOneDifficulty) )
>   MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize /
> TotalBlockSizeInLastButOneDifficulty
>   Else
>   Keep the same MaxBlockSize
>
> ==Rationale==
>
> These two proposals have been derived after discussion on
> [https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and
> [http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html
> bitcoin-dev mailing list]. The original idea and its evolution in the light
> of various arguements can be found [http://upalc.com/maxblocksize.php here].
>
> ===Proposal 1 : Depending only on previous block size calculation===
>
> This solution is derived directly from the indication of the problem. If
> transaction volume increases, then we will naturally see bigger blocks. On
> the contrary, if there are not enough transaction volume, but maximum block
> size is high, then only few blocks may sweep the mempool. Hence, if block
> size is itself taken into consideration, then maximum block size can most
> rationally be derived. Moreover, this solution not only increases, but also
> decreases the maximum block size, just like difficulty.
>
> ===Proposal 2 : Depending on previous block size calculation and previous Tx
> fee collected by miners===
>
> This solution takes care of stable mining subsidy. It will not increase
> maximum block size, if Tx fee collection is not increasing and thereby
> creating a Tx fee pressure on the market. On the other hand, though the
> block size max cap is dynamically controlled, it is very difficult to game
> by any party because the increase or decrease of block size max cap will
> take place in the same ratio of average block size increase or decrease.
>
> ==Compatibility==
>
> This is a hard-forking change to the Bitcoin protocol; anybody running code
> that fully validates blocks must 

[bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap [BIP 1xx - Draft]

[Upal Chakraborty via bitcoin-dev]

Github: 
https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki


  BIP: 1xx
  Title: Dynamically Controlled Bitcoin Block Size Max Cap
  Author: Upal Chakraborty 
  Status: Draft
  Type: Standards Track
  Created: 2015-08-24


==Abstract==

This BIP proposes replacing the fixed one megabyte maximum block size
with a dynamically controlled maximum block size that may increase or
decrease with difficulty change depending on various network factors.
I have two proposals regarding this...

i. Depending only on previous block size calculation.

ii. Depending on previous block size calculation and previous Tx fee
collected by miners.

==Motivation==

With increased adoption, transaction volume on bitcoin network is
bound to grow. If the one megabyte max cap is not changed to a
flexible one which changes itself with changing network demand, then
adoption will hamper and bitcoin's growth may choke up. Following
graph shows the change in average block size since inception...
https://blockchain.info/charts/avg-block-size?timespan=all&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

==Specification==

===Proposal 1 : Depending only on previous block size calculation===

  If more than 50% of block's size, found in the first 2000 of the
last difficulty period, is more than 90% MaxBlockSize
  Double MaxBlockSize
  Else if more than 90% of block's size, found in the first 2000 of
the last difficulty period, is less than 50% MaxBlockSize
  Half MaxBlockSize
  Else
  Keep the same MaxBlockSize

===Proposal 2 : Depending on previous block size calculation and
previous Tx fee collected by miners===

  TotalBlockSizeInLastButOneDifficulty = Sum of all Block size of
first 2008 blocks in last 2 difficulty period
  TotalBlockSizeInLastDifficulty = Sum of all Block size of second
2008 blocks in last 2 difficulty period (This actually includes 8
blocks from last but one difficulty)

  TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008
blocks in last 2 difficulty period
  TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008
blocks in last 2 difficulty period (This actually includes 8 blocks
from last but one difficulty)

  If ( ( (Sum of first 4016 block size in last 2 difficulty
period)/4016 > 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty >
TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty
> TotalBlockSizeInLastButOneDifficulty) )
  MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize /
TotalBlockSizeInLastButOneDifficulty
  Else If ( ( (Sum of first 4016 block size in last 2 difficulty
period)/4016 < 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty <
TotalTxFeeInLastButOneDifficulty) AND (TotalBlockSizeInLastDifficulty
< TotalBlockSizeInLastButOneDifficulty) )
  MaxBlockSize = TotalBlockSizeInLastDifficulty * MaxBlockSize /
TotalBlockSizeInLastButOneDifficulty
  Else
  Keep the same MaxBlockSize

==Rationale==

These two proposals have been derived after discussion on
[https://bitcointalk.org/index.php?topic=1154536.0 BitcoinTalk] and
[http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010285.html
bitcoin-dev mailing list]. The original idea and its evolution in the
light of various arguements can be found
[http://upalc.com/maxblocksize.php here].

===Proposal 1 : Depending only on previous block size calculation===

This solution is derived directly from the indication of the problem.
If transaction volume increases, then we will naturally see bigger
blocks. On the contrary, if there are not enough transaction volume,
but maximum block size is high, then only few blocks may sweep the
mempool. Hence, if block size is itself taken into consideration, then
maximum block size can most rationally be derived. Moreover, this
solution not only increases, but also decreases the maximum block
size, just like difficulty.

===Proposal 2 : Depending on previous block size calculation and
previous Tx fee collected by miners===

This solution takes care of stable mining subsidy. It will not
increase maximum block size, if Tx fee collection is not increasing
and thereby creating a Tx fee pressure on the market. On the other
hand, though the block size max cap is dynamically controlled, it is
very difficult to game by any party because the increase or decrease
of block size max cap will take place in the same ratio of average
block size increase or decrease.

==Compatibility==

This is a hard-forking change to the Bitcoin protocol; anybody running
code that fully validates blocks must upgrade before the activation
time or they will risk rejecting a chain containing
larger-than-one-megabyte blocks.

==Other solutions considered==

[http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
Making Decentralized Economic Policy] - by Jeff Garzik

[https://bitcointalk.org/index.php?topic=1078521.0 Elastic block cap
with rollover penalties] - by Meni Rosenfeld

[https://github.com/bitcoi

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Jorge Timón via bitcoin-dev]

On Mon, Aug 24, 2015 at 1:41 AM, Tom Harding via bitcoin-dev
 wrote:
> On 8/21/2015 5:01 PM, Peter Todd wrote:
>>
>>> I checked the scenario where only the radio is on, and found the car
>>> does not crash.
>> Incidentally, what's your acceptable revenue difference between a small
>> (1% hashing power) and large (%30 hashing power) miner, all else being
>> equal? (remember that we shouldn't preclude variance reduction
>> techniques such as p2pool and pooled-solo mode)
>>
>> Equally, what kind of attacks on miners do you think we need to be able to
>> resist? E.g. DoS attacks, hacking, etc.
>>
>
> None of this is in the scope of Pieter's simulation.
>
> If you think that casts doubt on my conclusions, then it casts doubt on
> his original conclusions as well.

As far as I know, "his conclusions" were that there was an effect,
while suspending judgement on whether that effect was high enough to
be important for a given size or not.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Tom Harding via bitcoin-dev]

On 8/21/2015 5:01 PM, Peter Todd wrote:
>
>> I checked the scenario where only the radio is on, and found the car
>> does not crash.
> Incidentally, what's your acceptable revenue difference between a small
> (1% hashing power) and large (%30 hashing power) miner, all else being
> equal? (remember that we shouldn't preclude variance reduction
> techniques such as p2pool and pooled-solo mode)
>
> Equally, what kind of attacks on miners do you think we need to be able to
> resist? E.g. DoS attacks, hacking, etc.
>

None of this is in the scope of Pieter's simulation.

If you think that casts doubt on my conclusions, then it casts doubt on
his original conclusions as well.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Peter Todd via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512



On 21 August 2015 20:21:22 GMT-07:00, "Jorge Timón"  wrote:
>Don't you mean profits instead of revenue?

Actually no. I thought revenue would be a less subjective question to ask, with 
more focus on the underlying orphan rate question; part of the answer might 
include an assumed profit margin.
-BEGIN PGP SIGNATURE-

iQE9BAEBCgAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJV2BYO
AAoJEMCF8hzn9Lncz4MH/3Z+n1sWPIBSjRebDdZdiFZvJhOYknpE9fzHo2zv6euY
qDkQS5uAXbFroF2jrm41H3hjtDXcy0mBIgxhhYMesia8ck9jXb2mXuUlnltBNzgK
XeNEWgie1Y2kvXkeq1pXgPLtWWi9W54kQQ9IrpoMpasBMmP8UHh5WuzSqrWFP8Ha
HD8smRbByhc6ydEHbVE8FaYxg9ijBIM1e0sh3W+QPgRG8ATAaH6UVJu01YkKHtwS
V7PLW0m8WAEH+DAMV54Wgzm6prreQGy3KmldHDF58iMLzescdDIc0Pvotw613rvz
06KgQkQ20ba75XeJQOqXBygGoYS3qHOa9XwVyYq1S7g=
=elAX
-END PGP SIGNATURE-

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Jorge Timón via bitcoin-dev]

Don't you mean profits instead of revenue?

On Aug 21, 2015 5:01 PM, "Peter Todd via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote:
> > On 8/21/2015 3:21 PM, Peter Todd wrote:
> > > To use a car analogy, Pieter Wuille has shown that the brake cylinders
> > > have a fatigue problem, and if used in stop-and-go traffic regularly
> > > they'll fail during heavy braking, potentially killing someone. You've
> > > countered with a study of highway driving, showing that if the car is
> > > only used on the highway the brakes have no issues, claiming that the
> > > car design is perfectly safe.
> >
> > No.  If we must play the analogy game, it was found that the car crashes
> > when the brakes are bad (minority hash power partitioned) the radio is
> > on (partitioned miners had small individual hashrate).
> >
> > I checked the scenario where only the radio is on, and found the car
> > does not crash.
>
> Incidentally, what's your acceptable revenue difference between a small
> (1% hashing power) and large (%30 hashing power) miner, all else being
> equal? (remember that we shouldn't preclude variance reduction
> techniques such as p2pool and pooled-solo mode)
>
> Equally, what kind of attacks on miners do you think we need to be able to
> resist? E.g. DoS attacks, hacking, etc.
>
> That would let me know if you're definition of "the brakes are bad"
> corresponds to normal usage, or something that's not reasonable to
> design for.
>
> --
> 'peter'[:-1]@petertodd.org
> 0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Peter Todd via bitcoin-dev]

On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote:
> On 8/21/2015 3:21 PM, Peter Todd wrote:
> > To use a car analogy, Pieter Wuille has shown that the brake cylinders
> > have a fatigue problem, and if used in stop-and-go traffic regularly
> > they'll fail during heavy braking, potentially killing someone. You've
> > countered with a study of highway driving, showing that if the car is
> > only used on the highway the brakes have no issues, claiming that the
> > car design is perfectly safe. 
> 
> No.  If we must play the analogy game, it was found that the car crashes
> when the brakes are bad (minority hash power partitioned) the radio is
> on (partitioned miners had small individual hashrate).
> 
> I checked the scenario where only the radio is on, and found the car
> does not crash.

Incidentally, what's your acceptable revenue difference between a small
(1% hashing power) and large (%30 hashing power) miner, all else being
equal? (remember that we shouldn't preclude variance reduction
techniques such as p2pool and pooled-solo mode)

Equally, what kind of attacks on miners do you think we need to be able to
resist? E.g. DoS attacks, hacking, etc.

That would let me know if you're definition of "the brakes are bad"
corresponds to normal usage, or something that's not reasonable to
design for.

-- 
'peter'[:-1]@petertodd.org
0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Tom Harding via bitcoin-dev]

On 8/21/2015 3:21 PM, Peter Todd wrote:
> To use a car analogy, Pieter Wuille has shown that the brake cylinders
> have a fatigue problem, and if used in stop-and-go traffic regularly
> they'll fail during heavy braking, potentially killing someone. You've
> countered with a study of highway driving, showing that if the car is
> only used on the highway the brakes have no issues, claiming that the
> car design is perfectly safe. 

No.  If we must play the analogy game, it was found that the car crashes
when the brakes are bad (minority hash power partitioned) the radio is
on (partitioned miners had small individual hashrate).

I checked the scenario where only the radio is on, and found the car
does not crash.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Peter Todd via bitcoin-dev]

On Fri, Aug 21, 2015 at 09:52:43AM -0700, Tom Harding wrote:
> On 8/20/2015 5:37 PM, Peter Todd wrote:
> > On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev 
> > wrote: >> I found that small miners were not at all disadvantaged by large
> blocks. >> > > You used 20% as the size of the large miner, with all the
> small miners > having good connectivity with each other. > > That is
> *not* the scenario we're worried about. The math behind the > issue is
> that the a miner needs to get their blocks to at least 33% of > hashing
> power, but more than that is unnecessary and only helps their >
> competition; you simulated 20%, which is under that threshold. Equally,
> > why are you assuming the small miner group is well connected to each >
> other? > > You probably didn't get any replies because your experiment
> is obviously > wrong and misguided, and we're all busy. >
> 
> I gave the small miners collectively the same hashrate as the large
> miners in the original test.  I made them well-connected because
> everyone was well-connected intra-partition in the original test.
> 
> I just varied one thing: the size of the miners.  This is a principle of
> experiment design, in science.
> 
> Next you'll probably claim that second-order and cross-term effects
> dominate.  Maybe you can find the time to prove it.

This is a security issue: if you can find a likely scenario where the
system fails, that's a problem and we need to fix it.

You've taken the scenario where the system fails, and changed the
conditions to create a scenario where it works. That's not particularly
interesting or noteworthy.

To use a car analogy, Pieter Wuille has shown that the brake cylinders
have a fatigue problem, and if used in stop-and-go traffic regularly
they'll fail during heavy braking, potentially killing someone. You've
countered with a study of highway driving, showing that if the car is
only used on the highway the brakes have no issues, claiming that the
car design is perfectly safe.

-- 
'peter'[:-1]@petertodd.org
0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Upal Chakraborty via bitcoin-dev]

I have tried to solve the maximum block size debate in two different
proposal.

i. Depending only on previous block size calculation.

ii. Depending on previous block size calculation and previous Tx fee
collected by miners.


Proposal 1: Depending only on previous block size calculation

If more than 50% of block's size, found in the first 2000 of the last
difficulty period, is more than 90% MaxBlockSize
Double MaxBlockSize
Else if more than 90% of block's size, found in the first 2000 of the last
difficulty period, is less than 50% MaxBlockSize
Half MaxBlockSize
Else
Keep the same MaxBlockSize
Proposal 2: Depending on previous block size calculation and previous Tx
fee collected by miners

TotalTxFeeInLastButOneDifficulty = Sum of all Tx fees of first 2008 blocks
in last 2 difficulty period
TotalTxFeeInLastDifficulty = Sum of all Tx fees of second 2008 blocks in
last 2 difficulty period (This actually includes 8 blocks from last but one
difficulty)

If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016 >
50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty >
TotalTxFeeInLastButOneDifficulty) )
MaxBlockSize = TotalTxFeeInLastDifficulty * MaxBlockSize /
TotalTxFeeInLastButOneDifficulty
Else If ( ( (Sum of first 4016 block size in last 2 difficulty period)/4016
< 50% MaxBlockSize) AND (TotalTxFeeInLastDifficulty <
TotalTxFeeInLastButOneDifficulty) )
MaxBlockSize = TotalTxFeeInLastDifficulty * MaxBlockSize /
TotalTxFeeInLastButOneDifficulty
Else
Keep the same MaxBlockSize
Details: http://upalc.com/maxblocksize.php

Requesting for comment.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Jorge Timón via bitcoin-dev]

On Thu, Aug 20, 2015 at 12:23 PM, Milly Bitcoin via bitcoin-dev
 wrote:
>> For the 73th time or so this month on this list:
>>
>> The maximum block size consensus rule limits mining centralization
>> (which is currently pretty bad).
>
>
> Instead of posting all these messages with bald claims why don't you work on
> a decentralization metric which you can point to?

Please start with the centralization metrics we both agree are
necessary instead of keeping insulting me publicly and privately.

> (instead of trying to
> claim people don't understand things which is clearly not the case,  You are
> just attacking people you don't agree with).

I'm not inventing this, he recently said so himself publicly on this
mailing list:

"I don't believe that the maximum block size has much at all to do with
mining centralization"

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/009960.html

It is therefore not surprising that non-developers and developers with
less experience in Bitcoin than Gavin have similar misunderstandings.

That claim seems in contradiction with his earlier analysis:
http://gavinandresen.ninja/are-bigger-blocks-better-for-bigger-miners

"I ran some simulations, and if blocks take 20 seconds to propagate, a
network with a miner that has 30% of the hashing power will get 30.3%
of the blocks."

That's why I was surprised when he denied the relation between the
consensus maximum size and mining centralization, but hey, people
change their minds and that's completely fine. I change my mind about
many things quite often myself. For example, I will change my mind
about not touching the maximum blocksize consensus rule as soon as I
see some data that convinces that the proposed sizes are not very
risky.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Jorge Timón via bitcoin-dev]

On Fri, Aug 21, 2015 at 2:13 PM, Sriram Karra  wrote:
> On Thu, Aug 20, 2015 at 1:01 PM, Jorge Timón
>  wrote:
>>
>>
>> For the 73th time or so this month on this list:
>>
>> The maximum block size consensus rule limits mining centralization
>> (which is currently pretty bad).
>>
>> But don't worry about not being an authority on the subject: Gavin
>> (who has written extensively on the subject) doesn't seem to
>> understand this either.
>
>
> If your goal is to get the Miners (who are highly centralised today) to
> implement a change in consensus rule that will limit mining centralisation,
> guess what public position you will be taking?

The rule is already there. My goal is to make sure we understand the
potential consequences of changing that rule in the "less limitation
to mining centralization" better before changing it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Tom Harding via bitcoin-dev]

On 8/20/2015 5:37 PM, Peter Todd wrote:
> On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev wrote: 
> >> I found that small miners were not at all disadvantaged by large
blocks. >> > > You used 20% as the size of the large miner, with all the
small miners > having good connectivity with each other. > > That is
*not* the scenario we're worried about. The math behind the > issue is
that the a miner needs to get their blocks to at least 33% of > hashing
power, but more than that is unnecessary and only helps their >
competition; you simulated 20%, which is under that threshold. Equally,
> why are you assuming the small miner group is well connected to each >
other? > > You probably didn't get any replies because your experiment
is obviously > wrong and misguided, and we're all busy. >

I gave the small miners collectively the same hashrate as the large
miners in the original test.  I made them well-connected because
everyone was well-connected intra-partition in the original test.

I just varied one thing: the size of the miners.  This is a principle of
experiment design, in science.

Next you'll probably claim that second-order and cross-term effects
dominate.  Maybe you can find the time to prove it.


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Sriram Karra via bitcoin-dev]

On Thu, Aug 20, 2015 at 1:01 PM, Jorge Timón <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> For the 73th time or so this month on this list:
>
> The maximum block size consensus rule limits mining centralization
> (which is currently pretty bad).
>
> But don't worry about not being an authority on the subject: Gavin
> (who has written extensively on the subject) doesn't seem to
> understand this either.
>

If your goal is to get the Miners (who are highly centralised today) to
implement a change in consensus rule that will limit mining centralisation,
guess what public position you will be taking?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Milly Bitcoin via bitcoin-dev]

Yes, I am familiar with the process as i spent years doing it.  Many 
here are familiar with the Bitcoin issues but they are not familiar with 
addressing risk in a systematic way.  There are many good posts but they 
are dispersed among thousands of messages and the discussions are in a 
variety of contexts.  As a result, the same things are often argued over 
and over and much time is wasted.  Note that knowing a technical area 
and knowing a process to analyze metrics are two different things.


I am glad you want to participate in such a process.  Several developers 
on this list have mentioned the need for a decentralization metric so i 
think that is a good place to start.  I suggest getting the other 
developers/experts together and send me the various into and tools you 
have and I will put it together into a useable format.  The idea is to 
create a living document so people can discuss changes in a similar 
context.


Russ






On 8/20/2015 8:58 PM, Peter Todd wrote:

On Thu, Aug 20, 2015 at 08:45:53PM -0400, Milly Bitcoin via bitcoin-dev wrote:

You know, I've noticed you've spent a tremendous amount of time and
energy on this list promoting these kinds of metrics; obviously you're
somewhat of an expert on this compared to the rest of us.

Why don't you look into spearheading one of these analyses yourself to
show us how it's done?



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Peter Todd via bitcoin-dev]

On Thu, Aug 20, 2015 at 08:45:53PM -0400, Milly Bitcoin via bitcoin-dev wrote:

You know, I've noticed you've spent a tremendous amount of time and
energy on this list promoting these kinds of metrics; obviously you're
somewhat of an expert on this compared to the rest of us.

Why don't you look into spearheading one of these analyses yourself to
show us how it's done?

> The idea is to come up with some sort of standardized metric so as
> the tools and issues come up you are comparing similar things.
> 
> The first thing you have to do is link "centralization pressure" and
> (pressure to merge with a big miner) to some sort of overall
> decentralization metric.  For instance, how much do big miners
> reduce decentralization to begin with?  That is a complicated
> analysis on its own.  Then you can measure specif use cases with a
> tool like that.
> 
> the idea at least is that the metrics do not "take sides" on any
> issue and just provide a measure of whatever it is you are
> measuring.
> 
> most of the references have to do with measuring decentralization in
> political systems so a system would need to be developed to apply to
> software projects like Bitcoin:
> 
> http://www.sscnet.ucla.edu/polisci/faculty/treisman/Papers/defin.pdf
> 
> http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf

-- 
'peter'[:-1]@petertodd.org
0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Milly Bitcoin via bitcoin-dev]

The idea is to come up with some sort of standardized metric so as the 
tools and issues come up you are comparing similar things.


The first thing you have to do is link "centralization pressure" and 
(pressure to merge with a big miner) to some sort of overall 
decentralization metric.  For instance, how much do big miners reduce 
decentralization to begin with?  That is a complicated analysis on its 
own.  Then you can measure specif use cases with a tool like that.


the idea at least is that the metrics do not "take sides" on any issue 
and just provide a measure of whatever it is you are measuring.


most of the references have to do with measuring decentralization in 
political systems so a system would need to be developed to apply to 
software projects like Bitcoin:


http://www.sscnet.ucla.edu/polisci/faculty/treisman/Papers/defin.pdf

http://www.hks.harvard.edu/fs/pnorris/Acrobat/stm103%20articles/Schneider_Decentralization.pdf


Russ




Pieter built a nice simulation tool and posted some results.

I tweaked the parameters and ran the tool in a way that tested ONLY for
hashrate centralization effects, and did not conflate these with network
partitioning effects.

I found that small miners were not at all disadvantaged by large blocks.

The only person who commented on this result agreed with me.  He also
complimented Pieter's insight (which is entirely appropriate since
Pieter did the hard work of creating the tool).

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008820.html



___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev




___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Peter Todd via bitcoin-dev]

On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev wrote:
> On 8/20/2015 3:23 AM, Milly Bitcoin via bitcoin-dev wrote:
> >>For the 73th time or so this month on this list:
> >>
> >>The maximum block size consensus rule limits mining centralization
> >>(which is currently pretty bad).
> >
> >Instead of posting all these messages with bald claims why don't
> >you work on a decentralization metric which you can point to?
> >(instead of trying to claim people don't understand things which
> >is clearly not the case,  You are just attacking people you don't
> >agree with).
> 
> 
> Pieter built a nice simulation tool and posted some results.
> 
> I tweaked the parameters and ran the tool in a way that tested ONLY
> for hashrate centralization effects, and did not conflate these with
> network partitioning effects.
> 
> I found that small miners were not at all disadvantaged by large blocks.
> 
> The only person who commented on this result agreed with me.  He
> also complimented Pieter's insight (which is entirely appropriate
> since Pieter did the hard work of creating the tool).
> 
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008820.html

You used 20% as the size of the large miner, with all the small miners
having good connectivity with each other.

That is *not* the scenario we're worried about. The math behind the
issue is that the a miner needs to get their blocks to at least 33% of
hashing power, but more than that is unnecessary and only helps their
competition; you simulated 20%, which is under that threshold. Equally,
why are you assuming the small miner group is well connected to each
other?

You probably didn't get any replies because your experiment is obviously
wrong and misguided, and we're all busy.

-- 
'peter'[:-1]@petertodd.org
0402fe6fb9ad613c93e12bddfc6ec02a2bd92f002050594d


signature.asc
Description: Digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Tom Harding via bitcoin-dev]

On 8/20/2015 3:23 AM, Milly Bitcoin via bitcoin-dev wrote:

For the 73th time or so this month on this list:

The maximum block size consensus rule limits mining centralization
(which is currently pretty bad).


Instead of posting all these messages with bald claims why don't you 
work on a decentralization metric which you can point to? (instead of 
trying to claim people don't understand things which is clearly not 
the case,  You are just attacking people you don't agree with).



Pieter built a nice simulation tool and posted some results.

I tweaked the parameters and ran the tool in a way that tested ONLY for 
hashrate centralization effects, and did not conflate these with network 
partitioning effects.


I found that small miners were not at all disadvantaged by large blocks.

The only person who commented on this result agreed with me.  He also 
complimented Pieter's insight (which is entirely appropriate since 
Pieter did the hard work of creating the tool).


http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008820.html


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Upal Chakraborty via bitcoin-dev]

Regarding...
i.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010493.html
ii.
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010499.html

Could we please keep the conversation specific to the proposal presented at
http://upalc.com/maxblocksize.php ? If you find any demerits to this,
please point them out. Otherwise, I'll ask for a BIP. The proposal in
algorithmic format is as follows...

If more than 50% of block's size, found in the first 2000 of the last
difficulty period, is more than 90% MaxBlockSize
 Double MaxBlockSize
Else if more than 90% of block's size, found in the first 2000 of the
last difficulty period, is less than 50% MaxBlockSize
 Half MaxBlockSize
Else
 Keep the same MaxBlockSize
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Milly Bitcoin via bitcoin-dev]

For the 73th time or so this month on this list:

The maximum block size consensus rule limits mining centralization
(which is currently pretty bad).


Instead of posting all these messages with bald claims why don't you 
work on a decentralization metric which you can point to?  (instead of 
trying to claim people don't understand things which is clearly not the 
case,  You are just attacking people you don't agree with).



Russ


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Jorge Timón via bitcoin-dev]

On Tue, Aug 18, 2015 at 7:26 PM, Chris Wardell via bitcoin-dev
 wrote:
> I'm no authority on the subject, but I don't understand why there is a max
> block-size, other than anti-spam measures.
>
> The only other reason I have heard for a max-block-size is to force people
> into paying higher fees.

For the 73th time or so this month on this list:

The maximum block size consensus rule limits mining centralization
(which is currently pretty bad).

But don't worry about not being an authority on the subject: Gavin
(who has written extensively on the subject) doesn't seem to
understand this either.
He thinks it only limits full node centralization (by limiting how
expensive it can be to run a full node).
I thought the later would be quite obvious for everyone, but this
month I've discovered that I've been extremely optimistic about
people's understanding of the effects of the consensus rule they want
to change.
For the later reason (the one Gavin and I agree on) there's an old but
very clear video explaining it:
https://www.youtube.com/watch?v=cZp7UGgBR0I
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Upal Chakraborty via bitcoin-dev]

I think, keeping the reduction part is necessary to have it demand driven.
Otherwise, we could just increase it to a fixed size. If the max cap is
high, but there is not enough Tx in the mempool, then after one big block
many will go small. This will not be good when block reward become small
and mining revenue become dependent on Tx fee. But, if reduction is there,
max cap will come down soon and all miners will see revenue from Tx fee
again.

Proposal details: http://upalc.com/maxblocksize.php

On Wed, Aug 19, 2015 at 2:28 AM, Danny Thorpe 
wrote:

> I like the simplicity of this approach.  Demand driven response.
>
> Is there really a need to reduce the max block size at all?  It is just a
> maximum limit, not a required size for every block.  If a seasonal
> transaction surge bumps the max block size limit up a notch, what harm is
> there in leaving the max block size limit at the "high water mark"
> indefinitely, even though periods of decreased transaction volume?
>
> I'd argue to remove the reduction step, making the max block size
> calculation a monotonic increasing function. Cut the complexity in half.
>
> -Danny
>
> On Tue, Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Regarding:
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html
>>
>>
>> I am arguing with the following statement here...
>>
>> *I see problems to this approach. The biggest one I see is that a miner
>>> with 11% of hash power could sabotage block size increases by only ever
>>> mining empty blocks.*
>>
>>
>>
>> First, I would like to argue from economics' point of view. If someone
>> wants to hold back the block size increase with 11% hash power by mining
>> empty blocks, he has to sacrifice Tx fees, which is not economical. 11%
>> hash power will most likely be a pool and pool miners will find out soon
>> that they are losing Tx fees because of pool owner's intention. Hence,
>> they'll switch pool and pool owner will lose out. This is the same reason
>> why 51% attack will never happen, even if a pool gets more than 51% hash
>> power.
>>
>>
>> Next, I would like to propose a slightly modified technical solution to
>> this problem in algorithmic format...
>>
>> If more than 50% of block's size, found in the first 2000 of the last
>> difficulty period, is more than 90% MaxBlockSize
>>  Double MaxBlockSize
>> Else if more than 90% of block's size, found in the first 2000 of the
>> last difficulty period, is less than 50% MaxBlockSize
>>  Half MaxBlockSize
>> Else
>>  Keep the same MaxBlockSize
>>
>> This is how, those who want to stop increase, need to have more than 50%
>> hash power. Those who want to stop decrease, need to have more than 10%
>> hash power, but must mine more than 50% of MaxBlockSize in all blocks. In
>> this approach, not only miners, but also the end user have their say.
>> Because, end users will fill up the mempool, from where miners will take Tx
>> to fill up the blocks. Please note that, taking first 2000 of the last 2016
>> blocks is important to avoid data discrepancy among different nodes due to
>> orphan blocks. It is assumed that a chain can not be orphaned after having
>> 16 confirmation.
>>
>> Looking for comments.
>>
>>
>>
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Chris Wardell via bitcoin-dev]

I agree with the simplicity of this approach and with removing the
reduction step... it's unlikely the block size would ever need to be
reduced, only increased with demand?

I like this solution better than either kicking the can, or raising the
block size based on chain height (another dynamic solution).

-Chris


On Tue, Aug 18, 2015 at 4:58 PM, Danny Thorpe via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I like the simplicity of this approach.  Demand driven response.
>
> Is there really a need to reduce the max block size at all?  It is just a
> maximum limit, not a required size for every block.  If a seasonal
> transaction surge bumps the max block size limit up a notch, what harm is
> there in leaving the max block size limit at the "high water mark"
> indefinitely, even though periods of decreased transaction volume?
>
> I'd argue to remove the reduction step, making the max block size
> calculation a monotonic increasing function. Cut the complexity in half.
>
> -Danny
>
> On Tue, Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Regarding:
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html
>>
>>
>> I am arguing with the following statement here...
>>
>> *I see problems to this approach. The biggest one I see is that a miner
>>> with 11% of hash power could sabotage block size increases by only ever
>>> mining empty blocks.*
>>
>>
>>
>> First, I would like to argue from economics' point of view. If someone
>> wants to hold back the block size increase with 11% hash power by mining
>> empty blocks, he has to sacrifice Tx fees, which is not economical. 11%
>> hash power will most likely be a pool and pool miners will find out soon
>> that they are losing Tx fees because of pool owner's intention. Hence,
>> they'll switch pool and pool owner will lose out. This is the same reason
>> why 51% attack will never happen, even if a pool gets more than 51% hash
>> power.
>>
>>
>> Next, I would like to propose a slightly modified technical solution to
>> this problem in algorithmic format...
>>
>> If more than 50% of block's size, found in the first 2000 of the last
>> difficulty period, is more than 90% MaxBlockSize
>>  Double MaxBlockSize
>> Else if more than 90% of block's size, found in the first 2000 of the
>> last difficulty period, is less than 50% MaxBlockSize
>>  Half MaxBlockSize
>> Else
>>  Keep the same MaxBlockSize
>>
>> This is how, those who want to stop increase, need to have more than 50%
>> hash power. Those who want to stop decrease, need to have more than 10%
>> hash power, but must mine more than 50% of MaxBlockSize in all blocks. In
>> this approach, not only miners, but also the end user have their say.
>> Because, end users will fill up the mempool, from where miners will take Tx
>> to fill up the blocks. Please note that, taking first 2000 of the last 2016
>> blocks is important to avoid data discrepancy among different nodes due to
>> orphan blocks. It is assumed that a chain can not be orphaned after having
>> 16 confirmation.
>>
>> Looking for comments.
>>
>>
>>
>>
>>
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Danny Thorpe via bitcoin-dev]

I like the simplicity of this approach.  Demand driven response.

Is there really a need to reduce the max block size at all?  It is just a
maximum limit, not a required size for every block.  If a seasonal
transaction surge bumps the max block size limit up a notch, what harm is
there in leaving the max block size limit at the "high water mark"
indefinitely, even though periods of decreased transaction volume?

I'd argue to remove the reduction step, making the max block size
calculation a monotonic increasing function. Cut the complexity in half.

-Danny

On Tue, Aug 18, 2015 at 5:13 AM, Upal Chakraborty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Regarding:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html
>
>
> I am arguing with the following statement here...
>
> *I see problems to this approach. The biggest one I see is that a miner
>> with 11% of hash power could sabotage block size increases by only ever
>> mining empty blocks.*
>
>
>
> First, I would like to argue from economics' point of view. If someone
> wants to hold back the block size increase with 11% hash power by mining
> empty blocks, he has to sacrifice Tx fees, which is not economical. 11%
> hash power will most likely be a pool and pool miners will find out soon
> that they are losing Tx fees because of pool owner's intention. Hence,
> they'll switch pool and pool owner will lose out. This is the same reason
> why 51% attack will never happen, even if a pool gets more than 51% hash
> power.
>
>
> Next, I would like to propose a slightly modified technical solution to
> this problem in algorithmic format...
>
> If more than 50% of block's size, found in the first 2000 of the last
> difficulty period, is more than 90% MaxBlockSize
>  Double MaxBlockSize
> Else if more than 90% of block's size, found in the first 2000 of the last
> difficulty period, is less than 50% MaxBlockSize
>  Half MaxBlockSize
> Else
>  Keep the same MaxBlockSize
>
> This is how, those who want to stop increase, need to have more than 50%
> hash power. Those who want to stop decrease, need to have more than 10%
> hash power, but must mine more than 50% of MaxBlockSize in all blocks. In
> this approach, not only miners, but also the end user have their say.
> Because, end users will fill up the mempool, from where miners will take Tx
> to fill up the blocks. Please note that, taking first 2000 of the last 2016
> blocks is important to avoid data discrepancy among different nodes due to
> orphan blocks. It is assumed that a chain can not be orphaned after having
> 16 confirmation.
>
> Looking for comments.
>
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[cedric perronnet via bitcoin-dev]

Sounds like a much better approach than arbitrary deciding what the 
block size should be

BR

Le 18/08/2015 14:13, Upal Chakraborty via bitcoin-dev a écrit :
Regarding: 
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html 




I am arguing with the following statement here...

/I see problems to this approach. The biggest one I see is that a
miner with 11% of hash power could sabotage block size increases
by only ever mining empty blocks./



First, I would like to argue from economics' point of view. If someone 
wants to hold back the block size increase with 11% hash power by 
mining empty blocks, he has to sacrifice Tx fees, which is not 
economical. 11% hash power will most likely be a pool and pool miners 
will find out soon that they are losing Tx fees because of pool 
owner's intention. Hence, they'll switch pool and pool owner will lose 
out. This is the same reason why 51% attack will never happen, even if 
a pool gets more than 51% hash power.



Next, I would like to propose a slightly modified technical solution 
to this problem in algorithmic format...


If more than 50% of block's size, found in the first 2000 of the last 
difficulty period, is more than 90% MaxBlockSize

 Double MaxBlockSize
Else if more than 90% of block's size, found in the first 2000 of the 
last difficulty period, is less than 50% MaxBlockSize

 Half MaxBlockSize
Else
 Keep the same MaxBlockSize

This is how, those who want to stop increase, need to have more than 
50% hash power. Those who want to stop decrease, need to have more 
than 10% hash power, but must mine more than 50% of MaxBlockSize in 
all blocks. In this approach, not only miners, but also the end user 
have their say. Because, end users will fill up the mempool, from 
where miners will take Tx to fill up the blocks. Please note that, 
taking first 2000 of the last 2016 blocks is important to avoid data 
discrepancy among different nodes due to orphan blocks. It is assumed 
that a chain can not be orphaned after having 16 confirmation.


Looking for comments.






___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Chris Wardell via bitcoin-dev]

I'm no authority on the subject, but I don't understand why there is a max
block-size, other than anti-spam measures.

The only other reason I have heard for a max-block-size is to force people
into paying higher fees.

This seems like the wrong way to force fees.  If you want to force fees,
then do exactly that - make fees required, and set a minimum... don't force
people to pay fees by limiting transactions per second.  That's like
shooting yourself in the foot to get free surgery



On Tue, Aug 18, 2015 at 8:13 AM, Upal Chakraborty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Regarding:
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html
>
>
> I am arguing with the following statement here...
>
> *I see problems to this approach. The biggest one I see is that a miner
>> with 11% of hash power could sabotage block size increases by only ever
>> mining empty blocks.*
>
>
>
> First, I would like to argue from economics' point of view. If someone
> wants to hold back the block size increase with 11% hash power by mining
> empty blocks, he has to sacrifice Tx fees, which is not economical. 11%
> hash power will most likely be a pool and pool miners will find out soon
> that they are losing Tx fees because of pool owner's intention. Hence,
> they'll switch pool and pool owner will lose out. This is the same reason
> why 51% attack will never happen, even if a pool gets more than 51% hash
> power.
>
>
> Next, I would like to propose a slightly modified technical solution to
> this problem in algorithmic format...
>
> If more than 50% of block's size, found in the first 2000 of the last
> difficulty period, is more than 90% MaxBlockSize
>  Double MaxBlockSize
> Else if more than 90% of block's size, found in the first 2000 of the last
> difficulty period, is less than 50% MaxBlockSize
>  Half MaxBlockSize
> Else
>  Keep the same MaxBlockSize
>
> This is how, those who want to stop increase, need to have more than 50%
> hash power. Those who want to stop decrease, need to have more than 10%
> hash power, but must mine more than 50% of MaxBlockSize in all blocks. In
> this approach, not only miners, but also the end user have their say.
> Because, end users will fill up the mempool, from where miners will take Tx
> to fill up the blocks. Please note that, taking first 2000 of the last 2016
> blocks is important to avoid data discrepancy among different nodes due to
> orphan blocks. It is assumed that a chain can not be orphaned after having
> 16 confirmation.
>
> Looking for comments.
>
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Upal Chakraborty via bitcoin-dev]

Regarding:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010295.html


I am arguing with the following statement here...

*I see problems to this approach. The biggest one I see is that a miner
> with 11% of hash power could sabotage block size increases by only ever
> mining empty blocks.*



First, I would like to argue from economics' point of view. If someone
wants to hold back the block size increase with 11% hash power by mining
empty blocks, he has to sacrifice Tx fees, which is not economical. 11%
hash power will most likely be a pool and pool miners will find out soon
that they are losing Tx fees because of pool owner's intention. Hence,
they'll switch pool and pool owner will lose out. This is the same reason
why 51% attack will never happen, even if a pool gets more than 51% hash
power.


Next, I would like to propose a slightly modified technical solution to
this problem in algorithmic format...

If more than 50% of block's size, found in the first 2000 of the last
difficulty period, is more than 90% MaxBlockSize
 Double MaxBlockSize
Else if more than 90% of block's size, found in the first 2000 of the last
difficulty period, is less than 50% MaxBlockSize
 Half MaxBlockSize
Else
 Keep the same MaxBlockSize

This is how, those who want to stop increase, need to have more than 50%
hash power. Those who want to stop decrease, need to have more than 10%
hash power, but must mine more than 50% of MaxBlockSize in all blocks. In
this approach, not only miners, but also the end user have their say.
Because, end users will fill up the mempool, from where miners will take Tx
to fill up the blocks. Please note that, taking first 2000 of the last 2016
blocks is important to avoid data discrepancy among different nodes due to
orphan blocks. It is assumed that a chain can not be orphaned after having
16 confirmation.

Looking for comments.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Tier Nolan via bitcoin-dev]

On Mon, Aug 17, 2015 at 12:57 PM, Rodney Morris via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I haven't run any statistics or simulations, but I'm concerned that the
> interplay between the random distribution of transaction arrival and the
> random distribution of block times may lead to false signals.
>

You could just take the average of all the block sizes for the last 2016
window.

If average of last 2016 > 50% of the limit, then increase by 6.25%
Otherwise, decrease by 6.25%

This means that the average would be around 50% of the limit.  This gives
margin to create larger blocks when blocks are happening slowly.

A majority of miners could force the limit upwards by creating spam but
full blocks.

It could be coupled with a hard limit that grows at whatever is seen as the
maximum reasonable.  This would be both a maximum and a minimum.

All of these schemes add state to the system.  If the schedule is
predictable, then you can check determine the maximum block size purely
from the header and coinbase.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Angel Leon via bitcoin-dev]

I've been sharing a similar solution for the past 2 weeks. I think 2016
blocks is too much of a wait, I think we should look at the mean block size
during the last 60-120 minutes instead and avert any crisis caused by
transactional spikes that could well be caused by organic use of the
network (Madonna sells her next tour tickets on Bitcoin, OpenBazaar network
starts working as imagined, XYZ startup really kicks ass and succeeds in a
couple of major cities with major PR push)

Pseudo code in Python
https://gist.github.com/gubatron/143e431ee01158f27db4

My idea stems from a simple scalability metric that affects real users and
the desire to use Bitcoin:
Waiting times to get your transactions confirmed on the blockchain.
Anything past 45mins-1 hour should be unnacceptable.

Initially I wanted to measure the mean time for the transactions in blocks
to go from being sent by the user
(initial broadcast into mempools) until the transaction was effectively
confirmed on the blockchain, say for 2 blocks (acceptable 15~20mins)

When blocks get full, people start waiting unnaceptable times for their
transactions to come through
if they don't adjust their fees. The idea is to avoid that situation at all
costs and keep the network
churning to the extent of its capabilities, without pretending a certain
size will be right at some
point in time, nobody can predict the future, nobody can predict real
organic usage peaks
on an open financial network, not all sustained spikes will come from
spammers,
they will come from real world use as more and more people think of great
uses for Bitcoin.

I presented this idea to measure the mean wait time for transactions and I
was told
there's no way to reliably meassure such a number, there's no consensus
when transactions are still
in the mempool and wait times could be manipulated. Such an idea would have
to include new timestamp fields
on the transactions, or include the median wait time on the blockheader
(too complex, additional storage costs)

This is an iteration on the next thing I believe we can all agree is 100%
accurately measured, blocksize.
Full blocks are the cause why many transactions would have to be waiting in
the mempool, so we should be able
to also use the mean size of the blocks to determine if there's a
legitimate need to increase or reduce the
maximum blocksize.

The idea is simple, If blocks are starting to get full past a certain
threshold then we double the blocksize
limit starting the next block, if blocks remain within a healthy bound,
transaction wait times should be as
expected for everyone on the network, if blocks are not getting that full
and the mean goes below a certain
threshold then we half the maximum block size allowed until we reach the
level we need.
Similar to what we do with hashing difficulty, it's something you can't
predict, therefore no fixed limits,
or predicted limits should be established.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Rodney Morris via bitcoin-dev]

Words cannot capture how much I wish Satoshi had put logic like this (or
even just a simple block size doubling every reward halving) in place when
he put in the "temporary" 1MB anti-spam block size limit...

I see problems to this approach.  The biggest one I see is that a miner
with 11% of hash power could sabotage block size increases by only ever
mining empty blocks.

I haven't run any statistics or simulations, but I'm concerned that the
interplay between the random distribution of transaction arrival and the
random distribution of block times may lead to false signals.

A 90% full block 1 minute after the previous block is a more "serious"
problem than a 90% full block 30 minutes after the previous block.  A 90%
full block after a 90% full block is a more "serious" problem than a 90%
full block after an empty block.

I would expect a robust approach in this manner to look at block sizes
weighted by block times, but this is an interesting proposal regardless.

But I think you'll run up against one of the great schisms in this debate -
those that believe blocks should always be full (or close to it), to
encourage a "fee market" and to encourage off-chain transactions, and those
that think that the blockchain should be useable by almost anyone for
almost anything, implying there should always be spare space in blocks,
with off-chain transactions reserved for microtransactions and zero-conf
(and possibly low-fee transactions).  At least, that's my take on it.

Rodney



>
>
> Date: Mon, 17 Aug 2015 11:51:26 +0100
> From: Btc Drak 
> To: Patrick Strateman 
> Cc: Bitcoin Dev 
> Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size
> Max Cap
> Message-ID:
>  v...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Nobody is going to click that...
>
> I guess I am nobody. Here's a copy of the text:-
>
> *Dynamically Controlled Bitcoin Block Size Max Cap
> <http://upalc.com/maxblocksize.php>*
>
> *Assumption*: This article is for those, who already understand the bitcoin
> protocol and aware of the block size controversy. Details of the problem
> statement can be found in BIP 100
> <http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf>.
> Satoshi's opinion regarding block size can be found here
> <https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366>. I will
> be
> directly going into the solution without explaining the problem in details.
>
>
> *Solution*: Difficulty changes at every 2016 block, i.e. at every 2016
> block each full node does a calculation to find the next target. We will do
> just another calculation here. Nodes will also calculate what % of blocks
> in the last difficulty period is higher than 90% of the maximum block size,
> which is 1 MB for now. If it is found that more than 90% blocks in the last
> difficulty period is higher than 90% of the maximum block size, then double
> the maximum block size. If not, then calculate what % of blocks in the last
> difficulty period is less than 50% of the maximum block size. If it is
> higher than 90%, then half the maximum block size. If none of the above
> condition satisfies, keep the maximum block size as it is.
>
> Please note that, while calculating the % of blocks, it is better to take
> into account the first 2000 of the 2016, than the whole of 2016. This helps
> to avoid the calculation mistake if some of the last few blocks get
> orphaned.
>
>
> *Reasoning*: This solution is derived directly from the indication of the
> problem. If transaction volume increases, then we will naturally see bigger
> blocks. On the contrary, if there are not enough transaction volume, but
> maximum block size is high, then only few blocks may sweep the mempool.
> Hence, if block size is itself taken into consideration, then maximum block
> size can most rationally be derived. Moreover, this solution not only
> increases, but also decreases the maximum block size, just like difficulty.
>
>
> *Other Solutions of this Problem*:-
>
> Making Decentralized Economic Policy
> <http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf> - by
> Jeff Garzik
>
> Elastic block cap with rollover penalties
> <https://bitcointalk.org/index.php?topic=1078521> ? by Meni Rosenfeld
>
> Increase maximum block size
> <https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki> - by
> Gavin
> Andresen
>
> Block size following technological growth
> <https://gist.github.com/sipa/c65665fc360ca7a176a6> - by Pieter Wuille
>
> The Bitcoin

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Btc Drak via bitcoin-dev]

On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Nobody is going to click that...

I guess I am nobody. Here's a copy of the text:-

*Dynamically Controlled Bitcoin Block Size Max Cap
*

*Assumption*: This article is for those, who already understand the bitcoin
protocol and aware of the block size controversy. Details of the problem
statement can be found in BIP 100
.
Satoshi's opinion regarding block size can be found here
. I will be
directly going into the solution without explaining the problem in details.


*Solution*: Difficulty changes at every 2016 block, i.e. at every 2016
block each full node does a calculation to find the next target. We will do
just another calculation here. Nodes will also calculate what % of blocks
in the last difficulty period is higher than 90% of the maximum block size,
which is 1 MB for now. If it is found that more than 90% blocks in the last
difficulty period is higher than 90% of the maximum block size, then double
the maximum block size. If not, then calculate what % of blocks in the last
difficulty period is less than 50% of the maximum block size. If it is
higher than 90%, then half the maximum block size. If none of the above
condition satisfies, keep the maximum block size as it is.

Please note that, while calculating the % of blocks, it is better to take
into account the first 2000 of the 2016, than the whole of 2016. This helps
to avoid the calculation mistake if some of the last few blocks get
orphaned.


*Reasoning*: This solution is derived directly from the indication of the
problem. If transaction volume increases, then we will naturally see bigger
blocks. On the contrary, if there are not enough transaction volume, but
maximum block size is high, then only few blocks may sweep the mempool.
Hence, if block size is itself taken into consideration, then maximum block
size can most rationally be derived. Moreover, this solution not only
increases, but also decreases the maximum block size, just like difficulty.


*Other Solutions of this Problem*:-

Making Decentralized Economic Policy
 - by
Jeff Garzik

Elastic block cap with rollover penalties
 – by Meni Rosenfeld

Increase maximum block size
 - by Gavin
Andresen

Block size following technological growth
 - by Pieter Wuille

The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
 - by Joseph Poon &
Thaddeus Dryja


Please share your opinion regarding this solution below. For mail
communication, feel free to write me at bitcoin [at] upalc.com.


> On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:
>
> I have tried to solve the maximum block size debate, depending on the
> previous block size calculation.
>
> Requesting for comment - http://upalc.com/maxblocksize.php
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Patrick Strateman via bitcoin-dev]

Nobody is going to click that...

On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:
> I have tried to solve the maximum block size debate, depending on the
> previous block size calculation.
>
> Requesting for comment - http://upalc.com/maxblocksize.php
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Levin Keller via bitcoin-dev]

Interesting. I am writing down something similar. Will share soon.

Upal Chakraborty via bitcoin-dev 
schrieb am Mo., 17. Aug. 2015 um 11:45 Uhr:

> I have tried to solve the maximum block size debate, depending on the
> previous block size calculation.
>
> Requesting for comment - http://upalc.com/maxblocksize.php
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Dynamically Controlled Bitcoin Block Size Max Cap

[Upal Chakraborty via bitcoin-dev]

I have tried to solve the maximum block size debate, depending on the
previous block size calculation.

Requesting for comment - http://upalc.com/maxblocksize.php
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev