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

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

[Upal Chakraborty]

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

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

<pre>
  BIP: 1xx
  Title: Dynamically Controlled Bitcoin Block Size Max Cap
  Author: Upal Chakraborty <bitcoin@upalc.com>
  Status: Draft
  Type: Standards Track
  Created: 2015-08-24
</pre>

==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/bitcoin/bips/blob/master/bip-0101.mediawiki
Increase maximum block size] - by Gavin Andresen

[https://gist.github.com/sipa/c65665fc360ca7a176a6 Block size
following technological growth] - by Pieter Wuille

[https://lightning.network/lightning-network-paper.pdf The Bitcoin
Lightning Network: Scalable Off-Chain Instant Payments] - by Joseph
Poon & Thaddeus Dryja

==Deployment==

If consensus is achieved, deployment can be made at a future block
number at which difficulty will change.

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

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

[Chun Wang]

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
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Github:
> https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki
>
> <pre>
>   BIP: 1xx
>   Title: Dynamically Controlled Bitcoin Block Size Max Cap
>   Author: Upal Chakraborty <bitcoin@upalc.com>
>   Status: Draft
>   Type: Standards Track
>   Created: 2015-08-24
> </pre>
>
> ==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/bitcoin/bips/blob/master/bip-0101.mediawiki Increase
> maximum block size] - by Gavin Andresen
>
> [https://gist.github.com/sipa/c65665fc360ca7a176a6 Block size following
> technological growth] - by Pieter Wuille
>
> [https://lightning.network/lightning-network-paper.pdf The Bitcoin Lightning
> Network: Scalable Off-Chain Instant Payments] - by Joseph Poon & Thaddeus
> Dryja
>
> ==Deployment==
>
> If consensus is achieved, deployment can be made at a future block number at
> which difficulty will change.
>
>
> _______________________________________________
> 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]

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Matt Whitlock]

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.

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

[Peter Todd]

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

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Matt Whitlock]

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.» <https://en.wikipedia.org/wiki/Rational_ignorance>

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

[Eric Voskuil]

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

> 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.»
<https://en.wikipedia.org/wiki/Rational_ignorance>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Simon Liu]

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
> 

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

[Chun Wang]

On Wed, Aug 26, 2015 at 5:18 AM, Simon Liu via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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.

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

[Peter Todd]

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

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
> <bitcoin-dev@lists.linuxfoundation.org> 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
000000000000000008d42f5514157c3257577e006985ea8335e4567e1bed16bd

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

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

[Hector Chu]

On 26 August 2015 at 01:29, Peter Todd via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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.

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

[Upal Chakraborty]

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

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
> <bitcoin-dev@lists.linuxfoundation.org> 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
>

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

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

[Upal Chakraborty]

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

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 <1240902@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
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Github:
> >
> https://github.com/UpalChakraborty/bips/blob/master/BIP-DynamicMaxBlockSize.mediawiki
> >
> > <pre>
> >   BIP: 1xx
> >   Title: Dynamically Controlled Bitcoin Block Size Max Cap
> >   Author: Upal Chakraborty <bitcoin@upalc.com>
> >   Status: Draft
> >   Type: Standards Track
> >   Created: 2015-08-24
> > </pre>
> >
> > ==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/bitcoin/bips/blob/master/bip-0101.mediawiki Increase
> > maximum block size] - by Gavin Andresen
> >
> > [https://gist.github.com/sipa/c65665fc360ca7a176a6 Block size following
> > technological growth] - by Pieter Wuille
> >
> > [https://lightning.network/lightning-network-paper.pdf The Bitcoin
> Lightning
> > Network: Scalable Off-Chain Instant Payments] - by Joseph Poon & Thaddeus
> > Dryja
> >
> > ==Deployment==
> >
> > If consensus is achieved, deployment can be made at a future block
> number at
> > which difficulty will change.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

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