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

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

[Upal Chakraborty]

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

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.

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

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

[Upal Chakraborty]

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

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

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

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

[Upal Chakraborty]

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

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.

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

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

[Chris Wardell]

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

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

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

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

[Jorge Timón]

On Tue, Aug 18, 2015 at 7:26 PM, Chris Wardell via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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

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

[Milly Bitcoin]

> 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

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

[Tom Harding]

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

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

[Peter Todd]

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

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

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

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

[Tom Harding]

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.

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

[Peter Todd]

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

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

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

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

[Tom Harding]

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.

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

[Peter Todd]

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

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

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

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

[Jorge Timón]

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

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

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

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

[Peter Todd]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512



On 21 August 2015 20:21:22 GMT-07:00, "Jorge Timón" <jtimon@jtimon.cc> 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-----

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

[Tom Harding]

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.

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

[Jorge Timón]

On Mon, Aug 24, 2015 at 1:41 AM, Tom Harding via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> 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.

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

[Milly Bitcoin]

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
>

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

[Peter Todd]

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

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

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

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

[Milly Bitcoin]

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?

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

[Jorge Timón]

On Thu, Aug 20, 2015 at 12:23 PM, Milly Bitcoin via bitcoin-dev
<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).
>
>
> 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.

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

[Sriram Karra]

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

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?

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

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

[Jorge Timón]

On Fri, Aug 21, 2015 at 2:13 PM, Sriram Karra <karra.etc@gmail.com> wrote:
> 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?

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.

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

[cedric perronnet]

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

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


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

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

[Danny Thorpe]

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

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

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

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

[Chris Wardell]

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

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

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

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

[Upal Chakraborty]

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

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 <danny.thorpe@gmail.com>
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
>>
>>
>

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

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

[Rodney Morris]

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

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 <btcdrak@gmail.com>
> To: Patrick Strateman <patrick.strateman@gmail.com>
> Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Dynamically Controlled Bitcoin Block Size
>         Max Cap
> Message-ID:
>         <CADJgMzvV7cSW9aBnAf5zX7FDxN5E=AW=rET2i9EnysLao=
> vVyw@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 Lightning Network: Scalable Off-Chain Instant Payments
> <https://lightning.network/lightning-network-paper.pdf> - 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.
>
>

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

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

[Angel Leon]

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

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.

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

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

[Tier Nolan]

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

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.

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

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

[Upal Chakraborty]

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

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

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

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

[Levin Keller]

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

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

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

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

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

[Patrick Strateman]

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

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


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

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

[Btc Drak]

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

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 Lightning Network: Scalable Off-Chain Instant Payments
<https://lightning.network/lightning-network-paper.pdf> - 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
>

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