BIP 102 - kick the can down the road to 2MB
29 messages, 17 to 24 Jul 2015. Started by Jeff Garzik.
Ross Nicoll (4), Jorge Timón (4), Tier Nolan (3), Peter Todd (3), Jeff Garzik (2), Johnson Lau (2), Sriram Karra (2), Andrew, +8 more
Opening a mailing list thread on this BIP:
BIP PR: https://github.com/bitcoin/bips/pull/173 Code PR: https://github.com/bitcoin/bitcoin/pull/6451
The general intent of this BIP is as a minimum viable alternative plan to my preferred proposal (BIP 100).
If agreement is not reached on a more comprehensive solution, then this solution is at least available and a known quantity. A good backup plan.
Benefits: conservative increase. proves network can upgrade. permits some added growth, while the community & market gathers data on how an increased block size impacts privacy, security, centralization, transaction throughput and other metrics. 2MB seems to be a Least Common Denominator on an increase.
Costs: requires a hard fork. requires another hard fork down the road.
What are you trying to do? Break the ice with a hard fork so that later it becomes easier to do so, with people more complacent towards it? There are many solutions to the scaling problem that do not require a hard fork and are quite simple to implement actually, and don't come with the complications involved with a hard fork. I'm not a reputable developer on this list, so my opinion probably doesn't matter much, but I watched and analyzed this situation closely and I don't like this idea.
On Fri, Jul 17, 2015 at 3:55 PM, Jeff Garzik via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (27 lines)
> Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > Code PR: https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative plan to > my preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then this > solution is at least available and a known quantity. A good backup plan. > > Benefits: conservative increase. proves network can upgrade. permits > some added growth, while the community & market gathers data on how an > increased block size impacts privacy, security, centralization, transaction > throughput and other metrics. 2MB seems to be a Least Common Denominator > on an increase. > > Costs: requires a hard fork. requires another hard fork down the road. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
Transaction sizes are still limited to 1MB with this patch. While this isn't technically a change, it does mean that both are no longer linked together.
Since this has no voting step, I assume the intention is that as a compromise suggestion, it would have full support.
It establishes a precedent for hard forks not to require a vote though.
On Fri, Jul 17, 2015 at 4:55 PM, Jeff Garzik via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (27 lines)
> Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > Code PR: https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative plan to > my preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then this > solution is at least available and a known quantity. A good backup plan. > > Benefits: conservative increase. proves network can upgrade. permits > some added growth, while the community & market gathers data on how an > increased block size impacts privacy, security, centralization, transaction > throughput and other metrics. 2MB seems to be a Least Common Denominator > on an increase. > > Costs: requires a hard fork. requires another hard fork down the road. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > >
On Fri, Jul 17, 2015 at 5:12 PM, Tier Nolan <tier.nolan@gmail•com> wrote:
Quoted text (3 lines)
> While this isn't technically a change, it does mean that both are no > longer linked together. >
I meant both block and transaction sizes are no longer linked together.
I'd back this if we can't find a permanent solution - 2MB gives us a lot more wiggle room in the interim at least; one of my concerns with block size is 3 transactions per second is absolutely tiny, and we need space for the network to search for an equilibrium between volume and pricing without risk of an adoption spike rendering it essentially unusable.
I'd favour switching over by block height rather than time, and I'd suggest that given virtually every wallet/node out there will require testing (even if many do not currently enforce a limit and therefore do not need changing), 6 months should be considered a minimum target. I'd open with a suggestion of block 390k as a target.
Ross
On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
Quoted text (27 lines)
> Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > Code PR: https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative plan > to my preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then > this solution is at least available and a known quantity. A good > backup plan. > > Benefits: conservative increase. proves network can upgrade. > permits some added growth, while the community & market gathers data > on how an increased block size impacts privacy, security, > centralization, transaction throughput and other metrics. 2MB seems > to be a Least Common Denominator on an increase. > > Costs: requires a hard fork. requires another hard fork down the road. > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
I would prefer a dynamic solution that did not necessitate a second hard fork down the road.
I propose doubling the block size every 100k blocks (~2 years)
block 400,000 = 2MB (2016) block 500,000 = 4MB (2017) block 600,000 = 8MB (2018)
Chris
On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (50 lines)
> I'd back this if we can't find a permanent solution - 2MB gives us a lot > more wiggle room in the interim at least; one of my concerns with block > size is 3 transactions per second is absolutely tiny, and we need space for > the network to search for an equilibrium between volume and pricing without > risk of an adoption spike rendering it essentially unusable. > > I'd favour switching over by block height rather than time, and I'd > suggest that given virtually every wallet/node out there will require > testing (even if many do not currently enforce a limit and therefore do not > need changing), 6 months should be considered a minimum target. I'd open > with a suggestion of block 390k as a target. > > Ross > > > On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: > > Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > Code PR: https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative plan > to my preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then this > solution is at least available and a known quantity. A good backup plan. > > Benefits: conservative increase. proves network can upgrade. permits > some added growth, while the community & market gathers data on how an > increased block size impacts privacy, security, centralization, transaction > throughput and other metrics. 2MB seems to be a Least Common Denominator > on an increase. > > Costs: requires a hard fork. requires another hard fork down the road. > > > > > _______________________________________________ > bitcoin-dev mailing listbitcoin-dev@lists•linuxfoundation•orghttps://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'll leave others to comment on whether we can get consensus on that, but your years listed are inconsistent with everything else you've written. Should be:
block 400,000 = 2MB (2016) block 500,000 = 4MB (2018) block 600,000 = 8MB (2020)
On 17/07/2015 20:06, Chris Wardell via bitcoin-dev wrote:
Quoted text (77 lines)
> I would prefer a dynamic solution that did not necessitate a second > hard fork down the road. > > I propose doubling the block size every 100k blocks (~2 years) > > block 400,000 = 2MB (2016) > block 500,000 = 4MB (2017) > block 600,000 = 8MB (2018) > > Chris > > > On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > I'd back this if we can't find a permanent solution - 2MB gives us > a lot more wiggle room in the interim at least; one of my concerns > with block size is 3 transactions per second is absolutely tiny, > and we need space for the network to search for an equilibrium > between volume and pricing without risk of an adoption spike > rendering it essentially unusable. > > I'd favour switching over by block height rather than time, and > I'd suggest that given virtually every wallet/node out there will > require testing (even if many do not currently enforce a limit and > therefore do not need changing), 6 months should be considered a > minimum target. I'd open with a suggestion of block 390k as a target. > > Ross > > > On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: >> Opening a mailing list thread on this BIP: >> >> BIP PR: https://github.com/bitcoin/bips/pull/173 >> Code PR: https://github.com/bitcoin/bitcoin/pull/6451 >> >> The general intent of this BIP is as a minimum viable alternative >> plan to my preferred proposal (BIP 100). >> >> If agreement is not reached on a more comprehensive solution, >> then this solution is at least available and a known quantity. A >> good backup plan. >> >> Benefits: conservative increase. proves network can upgrade. >> permits some added growth, while the community & market gathers >> data on how an increased block size impacts privacy, security, >> centralization, transaction throughput and other metrics. 2MB >> seems to be a Least Common Denominator on an increase. >> >> Costs: requires a hard fork. requires another hard fork down >> the road. >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> <mailto:bitcoin-dev@lists.linuxfoundation.org> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > <mailto: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
On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote:
Quoted text (1 line)
> BIP PR: https://github.com/bitcoin/bips/pull/173
I'm concerned that miners are prematurely bumping their soft limit to 1 MB lately. The only reason block size limit lifting is remotely reasonable is if we can trust miners to at the very least keep their soft limits set at a manageable size, but this assumption appears to already be failing in practice.
We are unlikely to approach 1 MB of actual volume by November, so I would prefer to see the activation date on this moved later - maybe November 2016, if not 2017. It would also be an improvement to try to follow reasonably- expected bandwidth increases, so 15% (1.15 MB) rather than doubling. Doubling in only a few months seems to be far from a "conservative" increase.
If we can get some kind of commitment from miners not to move their soft limits beyond 1 MB until some future-agreed-on point, maybe the BIP is acceptable as-is.
On Friday, July 17, 2015 4:12:05 PM Tier Nolan via bitcoin-dev wrote:
Quoted text (1 line)
> It establishes a precedent for hard forks not to require a vote though.
Hardforks are not something where voting makes sense. They need consensus among /nodes/, not majority among /miners/. No hardfork has ever had such a vote.
Luke
When blocks are found under or over the 10 minute threshold, hashing difficulty is raised or reduced dinamically to keep a balance. This intelligent measure has avoided us having discussions and kept a balance.
The same way you can't assume how much hashpower there will be to find the next blocks, why can't we have a function that adapts to the transactional volume on the blockchain, one which allows us to grow/shrink an acceptable maximum block size. We're not putting caps on processing, why should we put a date based cap on transactional volume per block? You can't predict the future, but you can look at what's happened recently to correct these limits.
Such function/filter should be able to recognize real sustained growth in transactional volume and let us adjust the maximum accepted blocksize to allow for the organic growth that will come due to real activity from things like distributed market-places, decentralized bitcoin based services (and all the things the community dreams about and might be building already), truly decentralized technological breakthroughs that geniunely need to use the blockchain. <Going the off-chain way only leads to centralization and personal/corporate agendas, which to me goes against the Bitcoin ethos>
It should be able to adapt fast enough so that we don't have episodes where people need to wait 4 hours to days for transactions to get on the blockchain and be confirmed. I believe proposals that include "every 100,000 blocks" are out of touch with reality, the blocksize needs to adapt the same way blockdifficulty already adapts to growth or lack of hashing power.
I'm not a statistician/mathematician, but I'm sure if we propose the parameters that need to be considered for a realistic blocksize that reflects the needs of the Bitcoin network users, there's plenty of crypto/statistician/mathematician brain power to propose such filtering function here.
Things that could be considered: - median number of transactions per block (between 6 to 12 hours, you should be able to adjust to a real shopping sprint for instance, or huge pop band/artist decides to sell concert tickets on Bitcoin) - median fees offered per transaction (can we detect spammers) - median blocksizes - median size per transaction - number of new addresses signing off transactions, number of addresses we've already seen in the blockchain before (are these spammers creating lots of new addresses to move around the same outputs, is there an efficient way to detect the likelyhood of a transaction being spam? Bayes? No clue, no mathematician) - median velocity between which an address receives an input and sends it to another one? - more things I've no knowledge of since I'm not familiar with the details, but could immediatly come to mind to the experts.
Mining Centralization is already happening due to its competitive nature, we don't complain or try to force hashing limits, we shouldn't do the same for storage. There will be no shortage of blockchain mirrors, and those interested in running full nodes, will surely find a way to do so.
Angel
On Fri, Jul 17, 2015 at 4:29 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (35 lines)
> On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > > I'm concerned that miners are prematurely bumping their soft limit to 1 MB > lately. The only reason block size limit lifting is remotely reasonable is > if > we can trust miners to at the very least keep their soft limits set at a > manageable size, but this assumption appears to already be failing in > practice. > > We are unlikely to approach 1 MB of actual volume by November, so I would > prefer to see the activation date on this moved later - maybe November > 2016, > if not 2017. It would also be an improvement to try to follow reasonably- > expected bandwidth increases, so 15% (1.15 MB) rather than doubling. > Doubling > in only a few months seems to be far from a "conservative" increase. > > If we can get some kind of commitment from miners not to move their soft > limits beyond 1 MB until some future-agreed-on point, maybe the BIP is > acceptable as-is. > > On Friday, July 17, 2015 4:12:05 PM Tier Nolan via bitcoin-dev wrote: > > It establishes a precedent for hard forks not to require a vote though. > > Hardforks are not something where voting makes sense. They need consensus > among /nodes/, not majority among /miners/. No hardfork has ever had such a > vote. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Fri, Jul 17, 2015 at 9:29 PM, Luke Dashjr <luke@dashjr•org> wrote:
Quoted text (4 lines)
> Hardforks are not something where voting makes sense. They need consensus > among /nodes/, not majority among /miners/. No hardfork has ever had such a > vote. >
Agreed.
I meant that since some of the new hard fork proposals use a voting system for activation, they may not want to establish that precedent.
Quoted text (1 line)
> I'm concerned that miners are prematurely bumping their soft limit to 1 MB lately.
By what measure do you call this premature?
On 17 Jul 2015 1:30 pm, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote:
Quoted text (1 line)
> BIP PR: https://github.com/bitcoin/bips/pull/173
I'm concerned that miners are prematurely bumping their soft limit to 1 MB
lately. The only reason block size limit lifting is remotely reasonable is if
we can trust miners to at the very least keep their soft limits set at a
manageable size, but this assumption appears to already be failing in
practice.
We are unlikely to approach 1 MB of actual volume by November, so I would
prefer to see the activation date on this moved later - maybe November 2016,
if not 2017. It would also be an improvement to try to follow reasonably-
expected bandwidth increases, so 15% (1.15 MB) rather than doubling. Doubling
in only a few months seems to be far from a "conservative" increase.
If we can get some kind of commitment from miners not to move their soft
limits beyond 1 MB until some future-agreed-on point, maybe the BIP is
acceptable as-is.
On Friday, July 17, 2015 4:12:05 PM Tier Nolan via bitcoin-dev wrote:
Quoted text (1 line)
> It establishes a precedent for hard forks not to require a vote though.
Hardforks are not something where voting makes sense. They need consensus
among /nodes/, not majority among /miners/. No hardfork has ever had such a
vote.
Luke
As an alternative to the preferred BIP100 this proposal is good because it establishes a plan of action for dealing with the recent ramp-up (100% increase) in number of transactions and transaction size. Arguably, a transitory spam attack, yes, but with a speculative rally brewing (and implied increases in network usage) this BIP may prove to be just-in-time.
Solutions favoring dynamic vs. scheduled increases in blocksize (and by how much) are interesting and the proponents should explore and map out their proposal with data sets, trend projections and future scenarios. It will require labor and time, but convince the list about the scientific merit of your proposal.
In the meantime, the current "sufficient" state of network capacity may soon experience "insufficient" moments. Developer confluence around a workable plan and testing should, reasonably, begin now.
Jeff's proposal addresses an approaching capacity crunch whilst honoring decentralization and providing time for testing and alternative future innovations. It's the best solution the user base and developers currently have for all the reasons Jeff gives: conservative blocksize increase, added capacity, low impact and minimal implication for the network and its users.
Then, many of the more far-reaching proposals being offered can be tested, formalized, and fleshed out with scenario data.
On 07/17/2015 10:55 PM, Jeff Garzik via bitcoin-dev wrote:
Quoted text (28 lines)
> Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 Code PR: > https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative > plan to my preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then > this solution is at least available and a known quantity. A good > backup plan. > > Benefits: conservative increase. proves network can upgrade. > permits some added growth, while the community & market gathers > data on how an increased block size impacts privacy, security, > centralization, transaction throughput and other metrics. 2MB > seems to be a Least Common Denominator on an increase. > > Costs: requires a hard fork. requires another hard fork down the > road. > > > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Sat, Jul 18, 2015 at 12:25 AM, Tier Nolan via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (12 lines)
> On Fri, Jul 17, 2015 at 9:29 PM, Luke Dashjr <luke@dashjr•org> wrote: >> >> Hardforks are not something where voting makes sense. They need consensus >> among /nodes/, not majority among /miners/. No hardfork has ever had such >> a >> vote. > > > Agreed. > > I meant that since some of the new hard fork proposals use a voting system > for activation, they may not want to establish that precedent.
I wonder how many people read http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html apart from you...
Sorry... More specifically, how many people made it to https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#uncontroversial-hardforks
On Sat, Jul 18, 2015 at 11:22 AM, Jorge Timón <jtimon@jtimon•cc> wrote:
Quoted text (18 lines)
> On Sat, Jul 18, 2015 at 12:25 AM, Tier Nolan via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org> wrote: >> On Fri, Jul 17, 2015 at 9:29 PM, Luke Dashjr <luke@dashjr•org> wrote: >>> >>> Hardforks are not something where voting makes sense. They need consensus >>> among /nodes/, not majority among /miners/. No hardfork has ever had such >>> a >>> vote. >> >> >> Agreed. >> >> I meant that since some of the new hard fork proposals use a voting system >> for activation, they may not want to establish that precedent. > > I wonder how many people read > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html > apart from you...
Further to that - please disregard what I said about using block height. Had failed to realise that in using contextual information (block height) it complicates block validation (i.e. it would be impossible to tell if a block is too big, without having all previous blocks first). Block time is in fact the better option.
Ross
On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev wrote:
Quoted text (50 lines)
> I'd back this if we can't find a permanent solution - 2MB gives us a > lot more wiggle room in the interim at least; one of my concerns with > block size is 3 transactions per second is absolutely tiny, and we > need space for the network to search for an equilibrium between volume > and pricing without risk of an adoption spike rendering it essentially > unusable. > > I'd favour switching over by block height rather than time, and I'd > suggest that given virtually every wallet/node out there will require > testing (even if many do not currently enforce a limit and therefore > do not need changing), 6 months should be considered a minimum target. > I'd open with a suggestion of block 390k as a target. > > Ross > > On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: >> Opening a mailing list thread on this BIP: >> >> BIP PR: https://github.com/bitcoin/bips/pull/173 >> Code PR: https://github.com/bitcoin/bitcoin/pull/6451 >> >> The general intent of this BIP is as a minimum viable alternative >> plan to my preferred proposal (BIP 100). >> >> If agreement is not reached on a more comprehensive solution, then >> this solution is at least available and a known quantity. A good >> backup plan. >> >> Benefits: conservative increase. proves network can upgrade. >> permits some added growth, while the community & market gathers data >> on how an increased block size impacts privacy, security, >> centralization, transaction throughput and other metrics. 2MB seems >> to be a Least Common Denominator on an increase. >> >> Costs: requires a hard fork. requires another hard fork down the road. >> >> >> >> >> _______________________________________________ >> 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 still disagree. Using height instead of time may make the implementation more complex by requiring some additional preparations but using height is in fact a simpler design. Why relay on clocks that we know will differ in different computers and places when we have a universal tick with every block?
Btw, BIP16 and BIP34 could be changed to height-based activation already. BIP16 simply should have used height instead of time from the beginning.
On Mon, Jul 20, 2015 at 12:51 AM, Ross Nicoll via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (69 lines)
> Further to that - please disregard what I said about using block height. Had > failed to realise that in using contextual information (block height) it > complicates block validation (i.e. it would be impossible to tell if a block > is too big, without having all previous blocks first). Block time is in fact > the better option. > > Ross > > > On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev wrote: > > I'd back this if we can't find a permanent solution - 2MB gives us a lot > more wiggle room in the interim at least; one of my concerns with block size > is 3 transactions per second is absolutely tiny, and we need space for the > network to search for an equilibrium between volume and pricing without risk > of an adoption spike rendering it essentially unusable. > > I'd favour switching over by block height rather than time, and I'd suggest > that given virtually every wallet/node out there will require testing (even > if many do not currently enforce a limit and therefore do not need > changing), 6 months should be considered a minimum target. I'd open with a > suggestion of block 390k as a target. > > Ross > > On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: > > Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > Code PR: https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative plan to my > preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then this > solution is at least available and a known quantity. A good backup plan. > > Benefits: conservative increase. proves network can upgrade. permits some > added growth, while the community & market gathers data on how an increased > block size impacts privacy, security, centralization, transaction throughput > and other metrics. 2MB seems to be a Least Common Denominator on an > increase. > > Costs: requires a hard fork. requires another hard fork down the road. > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
On Tue, Jul 21, 2015 at 11:26:35AM +0200, Jorge Timón via bitcoin-dev wrote:
Quoted text (5 lines)
> I still disagree. Using height instead of time may make the > implementation more complex by requiring some additional preparations > but using height is in fact a simpler design. Why relay on clocks that > we know will differ in different computers and places when we have a > universal tick with every block?
The Bitcoin protocol fundementally uses time in a consensus-critical manner anyway; miners vote on what time it is via the median time mechanism.
Triggering events based on median time is compatable with consensus and gives more human scale predictability as to when events may happen. In addition the median time is guaranteed to be monotonic by the consensus rules.
See the version bits proposal for an example of its use:
https://gist.github.com/sipa/bf69659f43e763540550#Specification
Having said that, in general triggering events without verifying a supermajority of miner support can be very dangerous. Without miner support the chain is insecure, and can be attacked. For instance a blocksize limit increase that a majority of miners choose not to implement raises huge risks of reorg for any miners who attempt to create large blocks, and huge risks of payment reversal for any merchants accepting transactions in such blocks. Note how with BIP102, extending the original Bitcoin chain is inherently an attack on the Garzik chain.
For that reason I think BIP102 is extremely poorly designed. I can only conclude that Jeff Garzik is either deliberately trolling us and/or manipulating discussion with a badly designed proposal that he doesn't actually expect to be adopted verbatim, or is incompetent.
On Tue, Jul 21, 2015 at 09:04:12AM -0400, Peter Todd via bitcoin-dev wrote:
Quoted text (4 lines)
> For that reason I think BIP102 is extremely poorly designed. I can only > conclude that Jeff Garzik is either deliberately trolling us and/or > manipulating discussion with a badly designed proposal that he doesn't > actually expect to be adopted verbatim, or is incompetent.
Expanding on that a bit:
On Tue, Jul 21, 2015 at 09:14:26PM +0800, Jeremy Rubin wrote:
Quoted text (19 lines)
> unsolicited feedback: > > I'd send a quick apology for this bit > > """ > For that reason I think BIP102 is extremely poorly designed. I can only > conclude that Jeff Garzik is either deliberately trolling us and/or > manipulating discussion with a badly designed proposal that he doesn't > actually expect to be adopted verbatim, or is incompetent. > """ > > it's a little over the top. > > I think that Garzik is probably releasing it in reaction to the fact > certain people are only looking at something with code attached. > > No need to call someone stupid for sharing a proposal... although it seems > sketchy that he got a BIP # for this. You want to foster a less hostile > community...
I don't agree with you at all.
This is a case where if Jeff doesn't understand that issue, he's proposing changes that he's not competent enough to understand, and it'd save us a lot of review effort if he left that discussion. Equally, Jeff is in a position in the dev community where he should be that competent; if he actually isn't it does a lot of good for the broader community to change that opinion.
I personally *don't* think he's doing that, rather I believe he knows full well it's a bad patch and is proposing it because he wants to push discussion towards a solution. Often trolling the a audience with bad patches is an effective way to motivate people to respond by writing better ones; Jeff has told me he often does exactly that.
I think in this case we shouldn't do anything, so short-circuiting that process by pointing out what he's doing publicly makes sense.
Re: BIP #'s, we explicitly have a policy of allocating them for stupid ideas, to avoid having to be gatekeepers. Ironically that makes it harder to get a BIP # if you know what you're doing, because Gregory Maxwell will argue against you in private and delay actually allocating one if he knows you should know better. :)
Not so much that the implementation is difficult, as it requires context to validate a block size, rather than being able to validate it without requiring the preceeding blocks. Yes, time on different machines may vary, but block time is safe to use for this, because it's a straight-forward test of "if block time is acceptable and block time is after <date> then maximum block size allowed is n MB otherwise m MB".
Ross
On 21/07/2015 10:26, Jorge Timón wrote:
Quoted text (81 lines)
> I still disagree. Using height instead of time may make the > implementation more complex by requiring some additional preparations > but using height is in fact a simpler design. Why relay on clocks that > we know will differ in different computers and places when we have a > universal tick with every block? > > Btw, BIP16 and BIP34 could be changed to height-based activation > already. BIP16 simply should have used height instead of time from the > beginning. > > On Mon, Jul 20, 2015 at 12:51 AM, Ross Nicoll via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation•org> wrote: >> Further to that - please disregard what I said about using block height. Had >> failed to realise that in using contextual information (block height) it >> complicates block validation (i.e. it would be impossible to tell if a block >> is too big, without having all previous blocks first). Block time is in fact >> the better option. >> >> Ross >> >> >> On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev wrote: >> >> I'd back this if we can't find a permanent solution - 2MB gives us a lot >> more wiggle room in the interim at least; one of my concerns with block size >> is 3 transactions per second is absolutely tiny, and we need space for the >> network to search for an equilibrium between volume and pricing without risk >> of an adoption spike rendering it essentially unusable. >> >> I'd favour switching over by block height rather than time, and I'd suggest >> that given virtually every wallet/node out there will require testing (even >> if many do not currently enforce a limit and therefore do not need >> changing), 6 months should be considered a minimum target. I'd open with a >> suggestion of block 390k as a target. >> >> Ross >> >> On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: >> >> Opening a mailing list thread on this BIP: >> >> BIP PR: https://github.com/bitcoin/bips/pull/173 >> Code PR: https://github.com/bitcoin/bitcoin/pull/6451 >> >> The general intent of this BIP is as a minimum viable alternative plan to my >> preferred proposal (BIP 100). >> >> If agreement is not reached on a more comprehensive solution, then this >> solution is at least available and a known quantity. A good backup plan. >> >> Benefits: conservative increase. proves network can upgrade. permits some >> added growth, while the community & market gathers data on how an increased >> block size impacts privacy, security, centralization, transaction throughput >> and other metrics. 2MB seems to be a Least Common Denominator on an >> increase. >> >> Costs: requires a hard fork. requires another hard fork down the road. >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >>
On 7/21/2015 6:58 AM, Peter Todd via bitcoin-dev wrote:
Quoted text (5 lines)
> Re: BIP #'s, we explicitly have a policy of allocating them for stupid > ideas, to avoid having to be gatekeepers. Ironically that makes it > harder to get a BIP # if you know what you're doing, because Gregory > Maxwell will argue against you in private and delay actually > allocating one if he knows you should know better. :)
Kalle asked for a BIP# for his PoP standardization proposal one month ago. Should he have known better?
Quoting Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org>:
Quoted text (19 lines)
> > Having said that, in general triggering events without verifying a > supermajority of miner support can be very dangerous. Without miner > support the chain is insecure, and can be attacked. For instance a > blocksize limit increase that a majority of miners choose not to > implement raises huge risks of reorg for any miners who attempt to > create large blocks, and huge risks of payment reversal for any > merchants accepting transactions in such blocks. Note how with BIP102, > extending the original Bitcoin chain is inherently an attack on the > Garzik chain. > > For that reason I think BIP102 is extremely poorly designed. I can only > conclude that Jeff Garzik is either deliberately trolling us and/or > manipulating discussion with a badly designed proposal that he doesn't > actually expect to be adopted verbatim, or is incompetent. > > -- > 'peter'[:-1]@petertodd.org > 0000000000000000031c12b6af038524fd5dd28115b7f5591e046423cebaf6d1
To avoid any risk of reorg, the hardfork may require that the first block with GetMedianTimePast() after a pre-determined time (the "flag block") MUST be version 0. The exception is applied ONLY to the flag block.
Alternatively, the hardfork may require that the flag block MUST be larger than 1MB. Comparing with exploiting the block version, this does not require additional exceptions in consensus rules. However, miner may need to artificially inflate the size of the flag block and that could be trouble in coding. I don't have any preference.
Old nodes will not accept the new chain because it violates BIP66 / block size limit. New nodes will not accept the old chain because its flag block is not version 0 / not larger than 1MB.
This is actually checkpointing in a decentralized way. In that case, we can say goodbye to the old chain forever, as long as all major merchants and exchanges agree to upgrade. Miner support is less relevant. It is a no-brainer for miners to support the new chain, unless they don't want to sell or spend their bitcoin, or just give up mining after heavily investing in ASIC.
jl2012
On Tue, Jul 21, 2015 at 7:28 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (9 lines)
> I personally *don't* think he's doing that, rather I believe he knows > full well it's a bad patch and is proposing it because he wants to push > discussion towards a solution. Often trolling the a audience with bad > patches is an effective way to motivate people to respond by writing > better ones; Jeff has told me he often does exactly that. > > I think in this case we shouldn't do anything, so short-circuiting that > process by pointing out what he's doing publicly makes sense. >
Assuming that's what Jeff is doing, how does preventing better solutions from emerging 'make sense'?
On Wed, Jul 22, 2015 at 10:32 PM, Sriram Karra <karra.etc@gmail•com> wrote:
Quoted text (18 lines)
> > On Tue, Jul 21, 2015 at 7:28 PM, Peter Todd via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > > >> I personally *don't* think he's doing that, rather I believe he knows >> full well it's a bad patch and is proposing it because he wants to push >> discussion towards a solution. Often trolling the a audience with bad >> patches is an effective way to motivate people to respond by writing >> better ones; Jeff has told me he often does exactly that. >> >> I think in this case we shouldn't do anything, so short-circuiting that >> process by pointing out what he's doing publicly makes sense. >> > > Assuming that's what Jeff is doing, how does preventing better solutions > from emerging 'make sense'? >
Peter, sorry, scratch that.
On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (16 lines)
> I don't agree with you at all. > > This is a case where if Jeff doesn't understand that issue, he's > proposing changes that he's not competent enough to understand, and it'd > save us a lot of review effort if he left that discussion. Equally, Jeff > is in a position in the dev community where he should be that competent; > if he actually isn't it does a lot of good for the broader community to > change that opinion. > > I personally *don't* think he's doing that, rather I believe he knows > full well it's a bad patch and is proposing it because he wants to push > discussion towards a solution. Often trolling the a audience with bad > patches is an effective way to motivate people to respond by writing > better ones; Jeff has told me he often does exactly that. > >
mmmm kay. Let's try to keep it technical, please.
2MB is a limit that has been discussed as a viable next-step, meeting with the most consensus.
2MB gets beyond the 1MB hard fork issue, while still remaining within a safety cap that should ensure the system does not go "off the rails" as some has predicted.
Security, privacy and centralization are not going to disappear at 2MB.
Further, a limited step gains valuable field data for judging whether further steps are warranted - thus informing the "better block size solution" development process.
Finally, as stated in the initial PR, it is intended as a viable fallback should we reach a point of criticality where the user community feels a block size increase is warranted, yet cannot reach consensus on a fancy, all-consuming solution be it 20MB, flexcap, BIP 100, BIP 102, etc.
I am open to suggestions for improving BIP 102. The goal is a minimum complexity fallback that others have previously agreed was a useful kick-the-can compromise - a static 2MB cap.
Sorry, but I think you need to re-read my first message. What you've written below has nothing to do with what I actually said re: how you're BIP102 and associated pull-req doesn't measure miner consensus.
On 22 July 2015 13:43:19 GMT-04:00, Jeff Garzik <jgarzik@gmail•com> wrote:
Quoted text (50 lines)
>On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev < >bitcoin-dev@lists•linuxfoundation•org> wrote: > >> I don't agree with you at all. >> >> This is a case where if Jeff doesn't understand that issue, he's >> proposing changes that he's not competent enough to understand, and >it'd >> save us a lot of review effort if he left that discussion. Equally, >Jeff >> is in a position in the dev community where he should be that >competent; >> if he actually isn't it does a lot of good for the broader community >to >> change that opinion. >> >> I personally *don't* think he's doing that, rather I believe he knows >> full well it's a bad patch and is proposing it because he wants to >push >> discussion towards a solution. Often trolling the a audience with bad >> patches is an effective way to motivate people to respond by writing >> better ones; Jeff has told me he often does exactly that. >> >> >mmmm kay. Let's try to keep it technical, please. > >2MB is a limit that has been discussed as a viable next-step, meeting >with >the most consensus. > >2MB gets beyond the 1MB hard fork issue, while still remaining within a >safety cap that should ensure the system does not go "off the rails" as >some has predicted. > >Security, privacy and centralization are not going to disappear at 2MB. > >Further, a limited step gains valuable field data for judging whether >further steps are warranted - thus informing the "better block size >solution" development process. > >Finally, as stated in the initial PR, it is intended as a viable >fallback >should we reach a point of criticality where the user community feels a >block size increase is warranted, yet cannot reach consensus on a >fancy, >all-consuming solution be it 20MB, flexcap, BIP 100, BIP 102, etc. > >I am open to suggestions for improving BIP 102. The goal is a minimum >complexity fallback that others have previously agreed was a useful >kick-the-can compromise - a static 2MB cap.
Quoting Peter Todd via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org>:
Quoted text (8 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Sorry, but I think you need to re-read my first message. What you've > written below has nothing to do with what I actually said re: how > you're BIP102 and associated pull-req doesn't measure miner consensus. > >
I think I have already answered this with my previous mail. If there is consensus among major exchanges and merchants, the preference of miners are not particularly relevant. A checkpoint could be implemented in a decentralized way to make sure miners of the original chain won't be able to overtake the new chain.
Bitcoin has no intrinsic value. Bitcoin has value because people are willing to exchange it with something really valuable (e.g. a pizza; or USD which could buy a pizza). If most bitcoin-accepting business agree to follow BIP102 and ONLY BIP102, then BIP102 is THE Bitcoin, and the original chain is just a dSHA256 alt-coin which one can't even merge mine with BIP102. Switching to BIP102 is the only economically viable choice for miners.
Having said that, a miner voting may still be useful. It is just to make sure enough miners are ready for the change, instead of measuring their consensus. For example, the new rule will be implemented 1) 1 week after 70% of miners are ready; or 2) on 1 Feb 2016, whichever happens first.
For SPV wallets, they have to strengthen their security model after the BIP66 fork, anyway. They should be able to identify potential consensus fork in the network and stop accepting incoming txs when it is in doubt. My "version 0 flag block" proposal could be a good generic way to indicate a hardfork to SPV wallets. (see my previous email on this topic)
Peter Todd, as discussed on IRC, I'm not opposed to median time, which has many of the properties nheight has, I'm just opposed to just using nTime which is what all "hardfork proposals" I've seen so far (including this one) do.
On Wed, Jul 22, 2015 at 12:05 AM, Ross Nicoll <jrn@jrn•me•uk> wrote:
Quoted text (14 lines)
> On 21/07/2015 10:26, Jorge Timón wrote: >> >> I still disagree. Using height instead of time may make the >> implementation more complex by requiring some additional preparations >> but using height is in fact a simpler design. Why relay on clocks that >> we know will differ in different computers and places when we have a >> universal tick with every block? > > Not so much that the implementation is difficult, as it requires context to > validate a block size, rather than being able to validate it without > requiring the preceeding blocks. Yes, time on different machines may vary, > but block time is safe to use for this, because it's a straight-forward test > of "if block time is acceptable and block time is after <date> then maximum > block size allowed is n MB otherwise m MB".
No, the height is in the current block after bip34, no context required. In any case, you already have the nHeight in most functions that would require it (for example, main::ConnectBlock). The median time actually needs a context (the last 10 headers), but it's not hard to calculate and pass around either. But simply using nTime is not a good idea. Leaving aside time zones, einstein and all that it introduces edge cases and weird incentives for no good reason. If the goal is to make it "human-schedule-friendly", median time should be good enough. If we're going to make miners 95% confirm after the date/height, I still prefer the height, but as said median time seems a reasonable compromise.
Can we move the "height/medianTime/nTime" and "is it good to confirm that the change is uncontroversial to miners by requiring 95% to activate the consensus change, like we do with uncontroversial softforks?" discussions to the thread with my bip draft ( http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html ) on precisely this subject? I have requested a bip number. Let's please have an uncontroversial hardfork to set a precedent. Hopefully that way we may decouple some parts of the blocksize discussion.
On Friday 17. July 2015 20.29.16 Luke Dashjr via bitcoin-dev wrote:
Quoted text (6 lines)
> We are unlikely to approach 1 MB of actual volume by November, so I would > prefer to see the activation date on this moved later - maybe November > 2016, if not 2017. It would also be an improvement to try to follow > reasonably- expected bandwidth increases, so 15% (1.15 MB) rather than > doubling. Doubling in only a few months seems to be far from a > "conservative" increase.
The reference to bandwidth increases makes no sense, the bandwidth in most of the world is already far exceeding the 8Mb limit. Not everyone lives where you live :)
In Germany you buy a 150Mbit connection for a flatrate and a cheap monthly rate, for instance. Not saying that Germany is where all the miners are, but since 150Mbit allows one to comfortably have 16 megabyte blocks, it is a good example of how far off Luke's calculations are from real-world.
I don't belief your argument to push forward holds.
Quoted text (14 lines)
> Sent: Friday, July 24, 2015 at 10:52 AM > From: "Thomas Zander via bitcoin-dev" <bitcoin-dev@lists•linuxfoundation•org> > To: bitcoin-dev@lists•linuxfoundation•org > Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB > > > The reference to bandwidth increases makes no sense, the bandwidth in most of > the world is already far exceeding the 8Mb limit. Not everyone lives where you > live :) > > In Germany you buy a 150Mbit connection for a flatrate and a cheap monthly > rate, for instance. Not saying that Germany is where all the miners are, but > since 150Mbit allows one to comfortably have 16 megabyte blocks, it is a good > example of how far off Luke's calculations are from real-world.
I'll have better stats available soon, but this does not reflect the current state of the network.
Only 4% of my initial crawl presented bandwidth above your stated 18MB/s.