[bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Jeff Garzik]

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

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.

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Andrew]

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

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:

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


-- 
PGP: B6AC 822C 451D 6304 6A28  49E9 7DB7 011C D53B 5647

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Tier Nolan]

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

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:

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

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Tier Nolan]

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

On Fri, Jul 17, 2015 at 5:12 PM, Tier Nolan <tier.nolan@gmail.com> wrote:

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

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Ross Nicoll]

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

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


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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Chris Wardell]

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

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:

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

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Ross Nicoll]

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

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


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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Ross Nicoll]

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

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


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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Jorge Timón]

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
>

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Peter Todd]

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

On Tue, Jul 21, 2015 at 11:26:35AM +0200, Jorge Timón via bitcoin-dev 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?

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.

-- 
'peter'[:-1]@petertodd.org
0000000000000000031c12b6af038524fd5dd28115b7f5591e046423cebaf6d1

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Peter Todd]

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

On Tue, Jul 21, 2015 at 09:04:12AM -0400, Peter Todd via bitcoin-dev wrote:
> 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:
> 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. :)

-- 
'peter'[:-1]@petertodd.org
00000000000000000d9cad4228c0396ff49c1de60f8ee155928eee22705f6619

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Tom Harding]

On 7/21/2015 6:58 AM, Peter Todd via bitcoin-dev wrote:
> 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?

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Sriram Karra]

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

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

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Sriram Karra]

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

On Wed, Jul 22, 2015 at 10:32 PM, Sriram Karra <karra.etc@gmail.com> wrote:

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

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Jeff Garzik]

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

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.

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Peter Todd]

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


On 22 July 2015 13:43:19 GMT-04:00, Jeff Garzik <jgarzik@gmail.com> wrote:
>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.
-----BEGIN PGP SIGNATURE-----

iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsBl2
AAoJEMCF8hzn9Lnc47AIAICM9pA+Jc6rkJ14U0vYqzhwTHmxuaNTXodmI1z88OKM
zCCJQHNw/Xhy339/ZGFeUuVS/Csw275dtzZutLoZamnGnQLh9LllxYFzN8eGJkCL
Ecfo0JcyhduwUihgDfzgE++z5/Q0z5sIo+pZBNipqXW1+N0P/GAvYlHqeb9r0uXG
ccJghZUTwqzm6aySfvXVveTmp0AtjVko1jP1sTxF2pI/RIqBdMY4wEsZvmEhX7Tk
g2iRiPWiEIYR1qETm6e5aQ/tj8W73932s15ozIM35nD5QId5qotQHTVttLAruQvl
2Z35F79TIYDvYtnnRNWIsOyiwreH/y5c0kSUIgrjASA=
=+jTv
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[jl2012]

Quoting Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>:

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[jl2012]

Quoting Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>:

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Ross Nicoll]

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Jorge Timón]

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Luke Dashjr]

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Angel Leon]

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

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

http://twitter.com/gubatron

On Fri, Jul 17, 2015 at 4:29 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:
> > 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
>

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Tier Nolan]

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

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.

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Jorge Timón]

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Jorge Timón]

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Thomas Zander]

On Friday 17. July 2015 20.29.16 Luke Dashjr via bitcoin-dev wrote:
> 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.
-- 
Thomas Zander

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Slurms MacKenzie]

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

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Venzen Khaosan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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:
> 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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVqdbsAAoJEGwAhlQc8H1m3LIIAJeBKYp0HYWYONlBxFNeQfa8
4EpYmMxwTSsDZ62CxdinxEGY3eQTqQo0GGAjpfSict4hq9ivSy74eHRb7AZihdYm
znEVGMnedyMtSDvfyaUdIj/kkUX4k9mrcLyAAJB//E2e2BYQgs3esTAYx2ScCBiR
t/UQ9gIolezasUIEmEovaQG4vOXtwMEtlzXrYy7EiAGhtoBvb1w3CJ3xa8iuF4e7
aXsleE98e44wjs0T/xLbuV4d8lBpnb0i0laOH4rpl77plpTc1HlDzjjqibourPb7
SPZhfwnk5f++3PlNc/dtwEJLFw8p578S5aDWZhUX7h+DfRXSqF6WCxYvv6XdUGQ=
=eoPX
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB

[Raystonn]

[-- Attachment #1: Type: text/html, Size: 2305 bytes --]