Dynamically Controlled Bitcoin Block Size Max Cap
24 messages, 18 to 24 Aug 2015. Started by Upal Chakraborty.
Jorge Timón (5), Peter Todd (5), Tom Harding (4), Milly Bitcoin (3), Upal Chakraborty (2), Chris Wardell (2), cedric perronnet, Danny Thorpe, +1 more
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
Quoted text (2 lines)
> 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.
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:
Quoted text (56 lines)
> 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 > >
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 :
Quoted text (56 lines)
> 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
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:
Quoted text (56 lines)
> 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 > >
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:
Quoted text (79 lines)
> 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 > >
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:
Quoted text (73 lines)
> 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 >> >> >
On Tue, Aug 18, 2015 at 7:26 PM, Chris Wardell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (5 lines)
> 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
Quoted text (4 lines)
> 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
On 8/20/2015 3:23 AM, Milly Bitcoin via bitcoin-dev wrote:
Quoted text (9 lines)
>> 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
On Thu, Aug 20, 2015 at 05:25:59PM -0700, Tom Harding via bitcoin-dev wrote:
Quoted text (26 lines)
> 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.
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
Quoted text (22 lines)
> > 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 >
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?
Quoted text (21 lines)
> 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
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:
Quoted text (8 lines)
> 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?
On Thu, Aug 20, 2015 at 1:01 PM, Jorge Timón < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (10 lines)
> > 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?
On 8/20/2015 5:37 PM, Peter Todd wrote:
Quoted text (1 line)
> 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,
Quoted text (1 line)
> 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.
On Fri, Aug 21, 2015 at 2:13 PM, Sriram Karra <karra.etc@gmail•com> wrote:
Quoted text (17 lines)
> 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.
On Thu, Aug 20, 2015 at 12:23 PM, Milly Bitcoin via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (8 lines)
>> 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.
Quoted text (3 lines)
> (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.
On Fri, Aug 21, 2015 at 09:52:43AM -0700, Tom Harding wrote:
Quoted text (21 lines)
> 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.
On 8/21/2015 3:21 PM, Peter Todd wrote:
Quoted text (6 lines)
> 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.
On Fri, Aug 21, 2015 at 04:16:39PM -0700, Tom Harding wrote:
Quoted text (14 lines)
> 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.
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:
Quoted text (38 lines)
> > 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 >
On 21 August 2015 20:21:22 GMT-07:00, "Jorge Timón" <jtimon@jtimon•cc> wrote:
Quoted text (1 line)
>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.
On 8/21/2015 5:01 PM, Peter Todd wrote:
Quoted text (11 lines)
> >> 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.
On Mon, Aug 24, 2015 at 1:41 AM, Tom Harding via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (17 lines)
> 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.