* [bitcoin-dev] BIP - 'Block75' - New algorithm @ 2017-01-02 18:04 t. khan 2017-01-02 19:01 ` Tom Zander 2017-01-02 20:04 ` Luke Dashjr 0 siblings, 2 replies; 12+ messages in thread From: t. khan @ 2017-01-02 18:04 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1556 bytes --] Based on feedback from this list and further simulations, here is a new algorithm for Block75: new max blocksize = x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY) TARGET_CAPACITY = 0.75 AVERAGE_CAPACITY = average percentage full of the last 2016 blocks, as a decimal x = current max block size Please note that this algorithm actually tries to keep blocks 75% full, unlike the old one that unnecessarily capped growth at 250KB. While this would theoretically allow a maximum increase of 25% over the previous max block size, in practice it's not possible to get that high. This would be calculated every 2016 blocks along with difficulty. Block75 should maintain transaction fees at about the level they were in May/June 2016 when blocks started hitting 75% full somewhat consistently. Thoughts? For any predictions as to how this would behave, please provide the numbers used to arrive at any conclusions. Other questions: 1. How do we make Block75 play nice with SegWit? 2. Is there any need for a minimum max blocksize? Block75 allows for decreasing the size as well as increasing it. Activation: To help negate some of the risk associated with a hard fork and to prevent a single relatively small mining pool from blocking Block75's adoption, activation would occur once 900 of the last 1,000 blocks mined signaled support, with a grace period of 4,032 blocks. Thank you again to all those who commented on the previous Block75 thread. Together, we can make 2017 the year the block size debate ends (hopefully forever). Happy New Year! - t.k. [-- Attachment #2: Type: text/html, Size: 1915 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP - 'Block75' - New algorithm 2017-01-02 18:04 [bitcoin-dev] BIP - 'Block75' - New algorithm t. khan @ 2017-01-02 19:01 ` Tom Zander 2017-01-02 19:32 ` t. khan 2017-01-02 20:04 ` Luke Dashjr 1 sibling, 1 reply; 12+ messages in thread From: Tom Zander @ 2017-01-02 19:01 UTC (permalink / raw) To: t. khan, Bitcoin Protocol Discussion On Monday, 2 January 2017 13:04:37 CET t. khan via bitcoin-dev wrote: > Thoughts? This proposal doesn't change the block size, it only changes the maximum block size. Which is expected, nothing bad there. The direct consequence of this, though is that the miners set the maximum block size. Because they decide on the actual created block size. This leads me to the simple question why we can't just give the miners full control of the maximum block size directly? The fact of the matter is that miners have for the full history of Bitcoin been able to set the block size, until they hit the 1MB limit. And your proposal keeps that property, but why have a maximum in the protocol? -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP - 'Block75' - New algorithm 2017-01-02 19:01 ` Tom Zander @ 2017-01-02 19:32 ` t. khan 2017-01-02 20:35 ` Tom Zander 0 siblings, 1 reply; 12+ messages in thread From: t. khan @ 2017-01-02 19:32 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1412 bytes --] Math should decide the max block size, not humans (miners in this case). The goal of Block75 is to manage the max block size without any human intervention. Under Block75, miners don't have any direct control but could still choose to mine smaller blocks (same as now), though doing so would cost them the fees from transactions they didn't include in their blocks. A maximum block size is necessary to prevent a single nefarious miner from creating a ridiculously large block which would break the network. - t.k. On Mon, Jan 2, 2017 at 2:01 PM, Tom Zander <tomz@freedommail•ch> wrote: > On Monday, 2 January 2017 13:04:37 CET t. khan via bitcoin-dev wrote: > > Thoughts? > > This proposal doesn't change the block size, it only changes the maximum > block size. Which is expected, nothing bad there. > > The direct consequence of this, though is that the miners set the maximum > block size. Because they decide on the actual created block size. > > This leads me to the simple question why we can't just give the miners full > control of the maximum block size directly? > > The fact of the matter is that miners have for the full history of Bitcoin > been able to set the block size, until they hit the 1MB limit. > And your proposal keeps that property, but why have a maximum in the > protocol? > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel > [-- Attachment #2: Type: text/html, Size: 2179 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP - 'Block75' - New algorithm 2017-01-02 19:32 ` t. khan @ 2017-01-02 20:35 ` Tom Zander 2017-01-02 21:05 ` t. khan 2017-01-02 21:19 ` Luke Dashjr 0 siblings, 2 replies; 12+ messages in thread From: Tom Zander @ 2017-01-02 20:35 UTC (permalink / raw) To: t. khan; +Cc: Bitcoin Protocol Discussion On Monday, 2 January 2017 14:32:24 CET t. khan wrote: > Math should decide the max block size, not humans (miners in this > case). The goal of Block75 is to manage the max block size without any > human intervention. If the input of your math is completely free and human created, how does it follow that it was math that created it ? Why do you want it math created anyway? > A maximum block size is necessary to prevent a single nefarious miner from > creating a ridiculously large block which would break the network. A maximum is needed, yes. But does it have to be part of the protocol? A simple policy which is set by node operators (reject block if greater than X bytes) will solve this just fine, no? -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP - 'Block75' - New algorithm 2017-01-02 20:35 ` Tom Zander @ 2017-01-02 21:05 ` t. khan 2017-01-02 22:33 ` Tom Zander 2017-01-02 21:19 ` Luke Dashjr 1 sibling, 1 reply; 12+ messages in thread From: t. khan @ 2017-01-02 21:05 UTC (permalink / raw) To: Tom Zander; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 872 bytes --] On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander <tomz@freedommail•ch> wrote: > If the input of your math is completely free and human created, how does it > follow that it was math that created it ? > Why do you want it math created anyway? The beauty of math is that everyone on the planet agrees how it works. Everything in Bitcoin is math, with the exception of the blocksize limit (1MB) which was a stop-gap solution at the time. > A maximum is needed, yes. But does it have to be part of the protocol? > A simple policy which is set by node operators (reject block if greater > than > X bytes) will solve this just fine, no? No. That would be an epic disaster. There's no such thing as a "simple policy" when humans are involved. Obviously no one would agree on what X bytes would be and you'd have some nodes rejecting blocks that others already accepted. - t.k. [-- Attachment #2: Type: text/html, Size: 1373 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP - 'Block75' - New algorithm 2017-01-02 21:05 ` t. khan @ 2017-01-02 22:33 ` Tom Zander 0 siblings, 0 replies; 12+ messages in thread From: Tom Zander @ 2017-01-02 22:33 UTC (permalink / raw) To: Bitcoin Protocol Discussion On Monday, 2 January 2017 16:05:58 CET t. khan wrote: > On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander <tomz@freedommail•ch> wrote: > > If the input of your math is completely free and human created, how does > > it follow that it was math that created it ? > > Why do you want it math created anyway? > > The beauty of math is that everyone on the planet agrees how it works. > Everything in Bitcoin is math, with the exception of the blocksize limit > (1MB) which was a stop-gap solution at the time. In actual fact the block size *is* set by miners, not math. And always has been. In your proposal the max blocksize continues to be set by miners as a secondary effect of them choosing the block size. Saying the max is actually math is painting an illusion that is rather thin and easy to see through because every single usecase for your suggestion starts with the choice of blocksize that a human makes. There is not really any other input except some rather simple algorithm. > > A maximum is needed, yes. But does it have to be part of the protocol? > > A simple policy which is set by node operators (reject block if greater > > than > > X bytes) will solve this just fine, no? > > No. That would be an epic disaster. There's no such thing as a "simple > policy" when humans are involved. This is ignoring history where miners have successfully set policy on block size for years now. > Obviously no one would agree on what X > bytes would be and you'd have some nodes rejecting blocks that others > already accepted. Not sure about your "obviously". I don't agree. In fact, there is plenty of reason to think it does work. Miners have always been the ones to decide on the block size, and they have always done this in a coordinated fashion. This is a natural consequence of the rather elegant (economic) design of Bitcoin. * Miners earn more fee-based income when they produce bigger blocks. * Miners take more risk of their blocks being orphaned with bigger blocks. * Miners want to avoid emptying the memory pool every block as that removes a total need for users to pay fees. * Miners want to make sure the mempool does not become backlogged because users that do not see their transactions confirmed will get disappointed and find other means to do payments. Which hurts the price and in effect hurts the miners income. This behaviour in block size means blocks will not get huge and they will not stay small either, because there are reasons for both. And so the size will be something in the middle. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP - 'Block75' - New algorithm 2017-01-02 20:35 ` Tom Zander 2017-01-02 21:05 ` t. khan @ 2017-01-02 21:19 ` Luke Dashjr 2017-01-02 22:01 ` Tom Zander ` (2 more replies) 1 sibling, 3 replies; 12+ messages in thread From: Luke Dashjr @ 2017-01-02 21:19 UTC (permalink / raw) To: bitcoin-dev, Tom Zander, t. khan On Monday, January 02, 2017 8:35:40 PM Tom Zander via bitcoin-dev wrote: > A maximum is needed, yes. But does it have to be part of the protocol? > A simple policy which is set by node operators (reject block if greater > than X bytes) will solve this just fine, no? If you reject a block based on a particular condition, that is BY DEFINITION part of the consensus protocol, and NOT a policy. The protocol is literally the set of rules by which blocks are determined to be valid or invalid. Policies are things that can vary node-to-node without affecting the validity judgement of blocks. On Monday, January 02, 2017 8:41:42 PM t. khan wrote: > On Mon, Jan 2, 2017 at 3:04 PM, Luke Dashjr <luke@dashjr•org> wrote: > > It would probably behave as an ever-increasing block size limit. Spam has > > typically filled blocks to the max, and miners have stopped > > self-enforcing reasonable limits. > > Using the growth rate over the last year as a model ( > https://blockchain.info/charts/avg-block-size?daysAverageString=14 ), > Block75 would also have frequently decreased the limit. Though, yes, more > transactions would equal larger blocks over time, but that's the entire > point of this. Then it doesn't solve the actual problems of either miner spam or growth in resource requirements, which are the entire purpose of the block size limit. > What is your definition of "spam"? Anything that consumes more data than necessary to properly convey the intended transfer of value (bitcoins) from one entity to another, including all data that is not intended for such a purpose. > > I doubt you'll get consensus for such a fundamentally broken proposal. > > I certainly don't foresee any circumstance where I could reasonably > > support it... The block size limit exists to restrict miners; it makes no > > sense to put it in their control. > > Specifically, what is broken about it? Putting group X in control of a limit that exists for the sole purpose of restricting group X. > There would still be a block size limit, it would just change slightly > every two weeks. I agree that miners shouldn't have control of this, and > Block75 doesn't give them any (at least none they can make a profit on). It gives miners complete control over the limit. They can make blocks of any size (within the current limit), thus triggering the conditions by which your proposal would raise the limit further. Luke ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP - 'Block75' - New algorithm 2017-01-02 21:19 ` Luke Dashjr @ 2017-01-02 22:01 ` Tom Zander 2017-01-03 14:28 ` t. khan 2017-02-13 11:21 ` Hampus Sjöberg 2 siblings, 0 replies; 12+ messages in thread From: Tom Zander @ 2017-01-02 22:01 UTC (permalink / raw) To: bitcoin-dev On Monday, 2 January 2017 21:19:10 CET Luke Dashjr wrote: > On Monday, January 02, 2017 8:35:40 PM Tom Zander via bitcoin-dev wrote: > > A maximum is needed, yes. But does it have to be part of the protocol? > > A simple policy which is set by node operators (reject block if greater > > than X bytes) will solve this just fine, no? > > If you reject a block based on a particular condition, that is BY > DEFINITION part of the consensus protocol, and NOT a policy. The protocol > is literally the set of rules by which blocks are determined to be valid > or invalid. > > Policies are things that can vary node-to-node without affecting the > validity judgement of blocks. Policy is thus expanded to allow an individual node to reject blocks that are technically speaking valid, just unacceptable to them. It would be fun to ponder of the effect of that when applied to many nodes. Many people already have pondered that question and find it intriguing. So don't reject it out of hand :) -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ^ permalink raw reply [flat|nested] 12+ messages in thread
* [bitcoin-dev] BIP - 'Block75' - New algorithm 2017-01-02 21:19 ` Luke Dashjr 2017-01-02 22:01 ` Tom Zander @ 2017-01-03 14:28 ` t. khan 2017-02-13 11:21 ` Hampus Sjöberg 2 siblings, 0 replies; 12+ messages in thread From: t. khan @ 2017-01-03 14:28 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3261 bytes --] On Mon, Jan 2, 2017 at 4:19 PM, Luke Dashjr <luke@dashjr•org <javascript:_e(%7B%7D,'cvml','luke@dashjr•org');>> wrote: > > Using the growth rate over the last year as a model ( > > https://blockchain.info/charts/avg-block-size?daysAverageString=14 ), > > Block75 would also have frequently decreased the limit. Though, yes, more > > transactions would equal larger blocks over time, but that's the entire > > point of this. > > Then it doesn't solve the actual problems of either miner spam or growth in > resource requirements, which are the entire purpose of the block size > limit. > Do you have any direct evidence of "miner spam"? If so, please link to a transaction. Also, what could a miner possibly gain from this? For resource requirements (bandwidth/disk space), please run the numbers on the Block75 algorithm and compare with growth rates of both. > What is your definition of "spam"? > > Anything that consumes more data than necessary to properly convey the > intended transfer of value (bitcoins) from one entity to another, including > all data that is not intended for such a purpose. > By this definition, any transaction which transfers ownership of an asset (stock certificate, deeds to property, copyrights, etc.) is spam. But these are legitimate, fee paying transactions. They are not spam. Yes, they're only moving 0.0001 btc. Some will eventually move to Lightning (or something like it), but many will not as they are unsuitable for off-chain. > > I doubt you'll get consensus for such a fundamentally broken proposal. > > > I certainly don't foresee any circumstance where I could reasonably > > > support it... The block size limit exists to restrict miners; it makes > no > > > sense to put it in their control. > > > > Specifically, what is broken about it? > > Putting group X in control of a limit that exists for the sole purpose of > restricting group X. > No, it actually gives them less power than they have now. Consider the two-week recalculation: the result of any attempt to manipulate the block size (up or down) will only last for two weeks. There's no way for a miner to profit from this (in fact, they'd lose money this way). The best outcome they could hope for is a very small increase or decrease for two weeks. So why would anyone do this? As soon as such a manipulation ended, Block75 would correct the max block size back to an appropriate level (defined as: average block 75% full). > There would still be a block size limit, it would just change slightly > > every two weeks. I agree that miners shouldn't have control of this, and > > Block75 doesn't give them any (at least none they can make a profit on). > > It gives miners complete control over the limit. They can make blocks of > any > size (within the current limit), thus triggering the conditions by which > your > proposal would raise the limit further. We covered this ad nauseum in the other Block75 thread, but basically no one has been able to come up with a realistic scenario wherein miners would be motivated to do this *and* there aren't any pools large enough now (nor have there ever been) to have anything more than a minor and temporary effect. If such a scenario actually does exist, please describe it in detail. - t.k. [-- Attachment #2: Type: text/html, Size: 4730 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP - 'Block75' - New algorithm 2017-01-02 21:19 ` Luke Dashjr 2017-01-02 22:01 ` Tom Zander 2017-01-03 14:28 ` t. khan @ 2017-02-13 11:21 ` Hampus Sjöberg 2 siblings, 0 replies; 12+ messages in thread From: Hampus Sjöberg @ 2017-02-13 11:21 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 616 bytes --] > It gives miners complete control over the limit. They can make blocks of any size (within the current limit), thus triggering the conditions by which your proposal would raise the limit further. There might be a long term incentive to keep increasing the blocksize, to further centralize the network (and kick smaller miners out), but it comes with the cost of losing out on transaction fees. Miners have always needed to plan for the short term, I see no rational scenario where miners would spam their blocks with their own transactions (or low fee transactions) to keep increasing the blocksize limit. Hampus [-- Attachment #2: Type: text/html, Size: 693 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP - 'Block75' - New algorithm 2017-01-02 18:04 [bitcoin-dev] BIP - 'Block75' - New algorithm t. khan 2017-01-02 19:01 ` Tom Zander @ 2017-01-02 20:04 ` Luke Dashjr 2017-01-02 20:41 ` t. khan 1 sibling, 1 reply; 12+ messages in thread From: Luke Dashjr @ 2017-01-02 20:04 UTC (permalink / raw) To: bitcoin-dev, t. khan On Monday, January 02, 2017 6:04:37 PM t. khan via bitcoin-dev wrote: > Thoughts? For any predictions as to how this would behave, please provide > the numbers used to arrive at any conclusions. It would probably behave as an ever-increasing block size limit. Spam has typically filled blocks to the max, and miners have stopped self-enforcing reasonable limits. > 2. Is there any need for a minimum max blocksize? Block75 allows for > decreasing the size as well as increasing it. Probably it should never make it so small that a reasonable generation transaction cannot fit. But I'm not sure this needs explicit enforcement. > To help negate some of the risk associated with a hard fork and to prevent > a single relatively small mining pool from blocking Block75's adoption, > activation would occur once 900 of the last 1,000 blocks mined signaled > support, with a grace period of 4,032 blocks. If you can't trust miners to signal based on the community's consensus, then don't use miner signalling at all. Just set a block height it activates. > Thank you again to all those who commented on the previous Block75 thread. > Together, we can make 2017 the year the block size debate ends (hopefully > forever). I doubt you'll get consensus for such a fundamentally broken proposal. I certainly don't foresee any circumstance where I could reasonably support it... The block size limit exists to restrict miners; it makes no sense to put it in their control. Luke ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP - 'Block75' - New algorithm 2017-01-02 20:04 ` Luke Dashjr @ 2017-01-02 20:41 ` t. khan 0 siblings, 0 replies; 12+ messages in thread From: t. khan @ 2017-01-02 20:41 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1180 bytes --] On Mon, Jan 2, 2017 at 3:04 PM, Luke Dashjr <luke@dashjr•org> wrote: > It would probably behave as an ever-increasing block size limit. Spam has > typically filled blocks to the max, and miners have stopped self-enforcing > reasonable limits. Using the growth rate over the last year as a model ( https://blockchain.info/charts/avg-block-size?daysAverageString=14 ), Block75 would also have frequently decreased the limit. Though, yes, more transactions would equal larger blocks over time, but that's the entire point of this. What is your definition of "spam"? Also, can you point to data that supports the hypothesis that spam is filling blocks? > I doubt you'll get consensus for such a fundamentally broken proposal. > I certainly don't foresee any circumstance where I could reasonably support > it... The block size limit exists to restrict miners; it makes no sense to > put > it in their control. > Specifically, what is broken about it? There would still be a block size limit, it would just change slightly every two weeks. I agree that miners shouldn't have control of this, and Block75 doesn't give them any (at least none they can make a profit on). - t.k. [-- Attachment #2: Type: text/html, Size: 2127 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2017-02-13 11:21 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-01-02 18:04 [bitcoin-dev] BIP - 'Block75' - New algorithm t. khan 2017-01-02 19:01 ` Tom Zander 2017-01-02 19:32 ` t. khan 2017-01-02 20:35 ` Tom Zander 2017-01-02 21:05 ` t. khan 2017-01-02 22:33 ` Tom Zander 2017-01-02 21:19 ` Luke Dashjr 2017-01-02 22:01 ` Tom Zander 2017-01-03 14:28 ` t. khan 2017-02-13 11:21 ` Hampus Sjöberg 2017-01-02 20:04 ` Luke Dashjr 2017-01-02 20:41 ` t. khan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox