* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-17 15:55 [bitcoin-dev] BIP 102 - kick the can down the road to 2MB Jeff Garzik
@ 2015-07-17 16:11 ` Andrew
2015-07-17 16:12 ` Tier Nolan
` (3 subsequent siblings)
4 siblings, 0 replies; 29+ messages in thread
From: Andrew @ 2015-07-17 16:11 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-17 15:55 [bitcoin-dev] BIP 102 - kick the can down the road to 2MB Jeff Garzik
2015-07-17 16:11 ` Andrew
@ 2015-07-17 16:12 ` Tier Nolan
2015-07-17 16:14 ` Tier Nolan
2015-07-17 17:57 ` Ross Nicoll
` (2 subsequent siblings)
4 siblings, 1 reply; 29+ messages in thread
From: Tier Nolan @ 2015-07-17 16:12 UTC (permalink / raw)
Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-17 15:55 [bitcoin-dev] BIP 102 - kick the can down the road to 2MB Jeff Garzik
2015-07-17 16:11 ` Andrew
2015-07-17 16:12 ` Tier Nolan
@ 2015-07-17 17:57 ` Ross Nicoll
2015-07-17 19:06 ` Chris Wardell
2015-07-19 22:51 ` Ross Nicoll
2015-07-17 20:29 ` Luke Dashjr
2015-07-18 4:32 ` Venzen Khaosan
4 siblings, 2 replies; 29+ messages in thread
From: Ross Nicoll @ 2015-07-17 17:57 UTC (permalink / raw)
To: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-17 17:57 ` Ross Nicoll
@ 2015-07-17 19:06 ` Chris Wardell
2015-07-17 19:13 ` Ross Nicoll
2015-07-19 22:51 ` Ross Nicoll
1 sibling, 1 reply; 29+ messages in thread
From: Chris Wardell @ 2015-07-17 19:06 UTC (permalink / raw)
To: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-17 19:06 ` Chris Wardell
@ 2015-07-17 19:13 ` Ross Nicoll
0 siblings, 0 replies; 29+ messages in thread
From: Ross Nicoll @ 2015-07-17 19:13 UTC (permalink / raw)
To: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-17 17:57 ` Ross Nicoll
2015-07-17 19:06 ` Chris Wardell
@ 2015-07-19 22:51 ` Ross Nicoll
2015-07-21 9:26 ` Jorge Timón
1 sibling, 1 reply; 29+ messages in thread
From: Ross Nicoll @ 2015-07-19 22:51 UTC (permalink / raw)
To: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-19 22:51 ` Ross Nicoll
@ 2015-07-21 9:26 ` Jorge Timón
2015-07-21 13:04 ` Peter Todd
2015-07-21 22:05 ` Ross Nicoll
0 siblings, 2 replies; 29+ messages in thread
From: Jorge Timón @ 2015-07-21 9:26 UTC (permalink / raw)
To: Ross Nicoll; +Cc: 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:
> 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
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-21 9:26 ` Jorge Timón
@ 2015-07-21 13:04 ` Peter Todd
2015-07-21 13:58 ` Peter Todd
2015-07-22 17:00 ` jl2012
2015-07-21 22:05 ` Ross Nicoll
1 sibling, 2 replies; 29+ messages in thread
From: Peter Todd @ 2015-07-21 13:04 UTC (permalink / raw)
To: Jorge Timón; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-21 13:04 ` Peter Todd
@ 2015-07-21 13:58 ` Peter Todd
2015-07-22 15:51 ` Tom Harding
` (2 more replies)
2015-07-22 17:00 ` jl2012
1 sibling, 3 replies; 29+ messages in thread
From: Peter Todd @ 2015-07-21 13:58 UTC (permalink / raw)
To: Jorge Timón, bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-21 13:58 ` Peter Todd
@ 2015-07-22 15:51 ` Tom Harding
2015-07-22 17:02 ` Sriram Karra
2015-07-22 17:43 ` Jeff Garzik
2 siblings, 0 replies; 29+ messages in thread
From: Tom Harding @ 2015-07-22 15:51 UTC (permalink / raw)
To: bitcoin-dev
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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-21 13:58 ` Peter Todd
2015-07-22 15:51 ` Tom Harding
@ 2015-07-22 17:02 ` Sriram Karra
2015-07-22 17:40 ` Sriram Karra
2015-07-22 17:43 ` Jeff Garzik
2 siblings, 1 reply; 29+ messages in thread
From: Sriram Karra @ 2015-07-22 17:02 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-22 17:02 ` Sriram Karra
@ 2015-07-22 17:40 ` Sriram Karra
0 siblings, 0 replies; 29+ messages in thread
From: Sriram Karra @ 2015-07-22 17:40 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-21 13:58 ` Peter Todd
2015-07-22 15:51 ` Tom Harding
2015-07-22 17:02 ` Sriram Karra
@ 2015-07-22 17:43 ` Jeff Garzik
2015-07-22 22:30 ` Peter Todd
2 siblings, 1 reply; 29+ messages in thread
From: Jeff Garzik @ 2015-07-22 17:43 UTC (permalink / raw)
To: Peter Todd; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-22 17:43 ` Jeff Garzik
@ 2015-07-22 22:30 ` Peter Todd
2015-07-23 5:39 ` jl2012
0 siblings, 1 reply; 29+ messages in thread
From: Peter Todd @ 2015-07-22 22:30 UTC (permalink / raw)
To: Jeff Garzik; +Cc: bitcoin-dev
-----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-----
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-22 22:30 ` Peter Todd
@ 2015-07-23 5:39 ` jl2012
0 siblings, 0 replies; 29+ messages in thread
From: jl2012 @ 2015-07-23 5:39 UTC (permalink / raw)
To: bitcoin-dev
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)
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-21 13:04 ` Peter Todd
2015-07-21 13:58 ` Peter Todd
@ 2015-07-22 17:00 ` jl2012
1 sibling, 0 replies; 29+ messages in thread
From: jl2012 @ 2015-07-22 17:00 UTC (permalink / raw)
To: bitcoin-dev
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-21 9:26 ` Jorge Timón
2015-07-21 13:04 ` Peter Todd
@ 2015-07-21 22:05 ` Ross Nicoll
2015-07-23 11:24 ` Jorge Timón
1 sibling, 1 reply; 29+ messages in thread
From: Ross Nicoll @ 2015-07-21 22:05 UTC (permalink / raw)
To: Jorge Timón; +Cc: bitcoin-dev
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
>>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-21 22:05 ` Ross Nicoll
@ 2015-07-23 11:24 ` Jorge Timón
0 siblings, 0 replies; 29+ messages in thread
From: Jorge Timón @ 2015-07-23 11:24 UTC (permalink / raw)
To: Ross Nicoll; +Cc: bitcoin-dev
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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-17 15:55 [bitcoin-dev] BIP 102 - kick the can down the road to 2MB Jeff Garzik
` (2 preceding siblings ...)
2015-07-17 17:57 ` Ross Nicoll
@ 2015-07-17 20:29 ` Luke Dashjr
2015-07-17 21:13 ` Angel Leon
` (2 more replies)
2015-07-18 4:32 ` Venzen Khaosan
4 siblings, 3 replies; 29+ messages in thread
From: Luke Dashjr @ 2015-07-17 20:29 UTC (permalink / raw)
To: bitcoin-dev, Jeff Garzik
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
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-17 20:29 ` Luke Dashjr
@ 2015-07-17 21:13 ` Angel Leon
2015-07-17 22:25 ` Tier Nolan
2015-07-24 8:52 ` Thomas Zander
2 siblings, 0 replies; 29+ messages in thread
From: Angel Leon @ 2015-07-17 21:13 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-17 20:29 ` Luke Dashjr
2015-07-17 21:13 ` Angel Leon
@ 2015-07-17 22:25 ` Tier Nolan
2015-07-18 9:22 ` Jorge Timón
2015-07-24 8:52 ` Thomas Zander
2 siblings, 1 reply; 29+ messages in thread
From: Tier Nolan @ 2015-07-17 22:25 UTC (permalink / raw)
Cc: bitcoin-dev
[-- 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 --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-17 22:25 ` Tier Nolan
@ 2015-07-18 9:22 ` Jorge Timón
2015-07-18 9:24 ` Jorge Timón
0 siblings, 1 reply; 29+ messages in thread
From: Jorge Timón @ 2015-07-18 9:22 UTC (permalink / raw)
To: Tier Nolan; +Cc: bitcoin-dev
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...
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-18 9:22 ` Jorge Timón
@ 2015-07-18 9:24 ` Jorge Timón
0 siblings, 0 replies; 29+ messages in thread
From: Jorge Timón @ 2015-07-18 9:24 UTC (permalink / raw)
To: Tier Nolan; +Cc: bitcoin-dev
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...
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-17 20:29 ` Luke Dashjr
2015-07-17 21:13 ` Angel Leon
2015-07-17 22:25 ` Tier Nolan
@ 2015-07-24 8:52 ` Thomas Zander
2015-07-24 9:43 ` Slurms MacKenzie
2 siblings, 1 reply; 29+ messages in thread
From: Thomas Zander @ 2015-07-24 8:52 UTC (permalink / raw)
To: bitcoin-dev
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
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-24 8:52 ` Thomas Zander
@ 2015-07-24 9:43 ` Slurms MacKenzie
0 siblings, 0 replies; 29+ messages in thread
From: Slurms MacKenzie @ 2015-07-24 9:43 UTC (permalink / raw)
To: thomas; +Cc: bitcoin-dev
> 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.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB
2015-07-17 15:55 [bitcoin-dev] BIP 102 - kick the can down the road to 2MB Jeff Garzik
` (3 preceding siblings ...)
2015-07-17 20:29 ` Luke Dashjr
@ 2015-07-18 4:32 ` Venzen Khaosan
4 siblings, 0 replies; 29+ messages in thread
From: Venzen Khaosan @ 2015-07-18 4:32 UTC (permalink / raw)
To: bitcoin-dev, Jeff Garzik
-----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-----
^ permalink raw reply [flat|nested] 29+ messages in thread