[bitcoin-dev] Draft BIP : fixed-schedule block size increase

[bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Gavin Andresen]

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

I promised to write a BIP after I'd implemented
increase-the-maximum-block-size code, so here it is. It also lives at:
https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki

I don't expect any proposal to please everybody; there are unavoidable
tradeoffs to increasing the maximum block size. I prioritize implementation
simplicity -- it is hard to write consensus-critical code, so simpler is
better.




  BIP: ??
  Title: Increase Maximum Block Size
  Author: Gavin Andresen <gavinandresen@gmail.com>
  Status: Draft
  Type: Standards Track
  Created: 2015-06-22

==Abstract==

This BIP proposes replacing the fixed one megabyte maximum block size with
a maximum size that grows over time at a predictable rate.

==Motivation==

Transaction volume on the Bitcoin network has been growing, and will soon
reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte
maximum block size. Increasing the maximum size reduces the impact of that
limit on Bitcoin adoption and growth.

==Specification==

After deployment on the network (see the Deployment section for details),
the maximum allowed size of a block on the main network shall be calculated
based on the timestamp in the block header.

The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11
00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000
seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC
(timestamp 2083190400). The maximum size of blocks in between doublings
will increase linearly based on the block's timestamp. The maximum size of
blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.

Expressed in pseudo-code, using integer math:

    function max_block_size(block_timestamp):

        time_start = 1452470400
        time_double = 60*60*24*365*2
        size_start = 8000000
        if block_timestamp >= time_start+time_double*10
            return size_start * 2^10

        // Piecewise-linear-between-doublings growth:
        time_delta = block_timestamp - t_start
        doublings = time_delta / time_double
        remainder = time_delta % time_double
        interpolate = (size_start * 2^doublings * remainder) / time_double
        max_size = size_start * 2^doublings + interpolate

        return max_size

==Deployment==

Deployment shall be controlled by hash-power supermajority vote (similar to
the technique used in BIP34), but the earliest possible activation time is
2016-01-11 00:00:00 UTC.

Activation is achieved when 750 of 1,000 consecutive blocks in the best
chain have a version number with bits 3 and 14 set (0x20000004 in hex). The
activation time will be the timestamp of the 750'th block plus a two week
(1,209,600 second) grace period to give any remaining miners or services
time to upgrade to support larger blocks. If a supermajority is achieved
more than two weeks before 2016-01-11 00:00:00 UTC, the activation time
will be 2016-01-11 00:00:00 UTC.

Block version numbers are used only for activation; once activation is
achieved, the maximum block size shall be as described in the specification
section, regardless of the version number of the block.


==Rationale==

The initial size of 8,000,000 bytes was chosen after testing the current
reference implementation code with larger block sizes and receiving
feedback from miners stuck behind bandwidth-constrained networks (in
particular, Chinese miners behind the Great Firewall of China).

The doubling interval was chosen based on long-term growth trends for CPU
power, storage, and Internet bandwidth. The 20-year limit was chosen
because exponential growth cannot continue forever.

Calculations are based on timestamps and not blockchain height because a
timestamp is part of every block's header. This allows implementations to
know a block's maximum size after they have downloaded it's header, but
before downloading any transactions.

The deployment plan is taken from Jeff Garzik's proposed BIP100 block size
increase, and is designed to give miners, merchants, and
full-node-running-end-users sufficient time to upgrade to software that
supports bigger blocks. A 75% supermajority was chosen so that one large
mining pool does not have effective veto power over a blocksize increase.
The version number scheme is designed to be compatible with Pieter's
Wuille's proposed "Version bits" BIP.

TODO: summarize objections/arguments from
http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.

TODO: describe other proposals and their advantages/disadvantages over this
proposal.


==Compatibility==

This is a hard-forking change to the Bitcoin protocol; anybody running code
that fully validates blocks must upgrade before the activation time or they
will risk rejecting a chain containing larger-than-one-megabyte blocks.

Simplified Payment Verification software is not affected, unless it makes
assumptions about the maximum depth of a transaction's merkle branch based
on the minimum size of a transaction and the maximum block size.

==Implementation==

https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Tier Nolan]

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

The BIP-100 proposal uses a window of 12000 blocks (83 days) rather than
the standard 1000.  Given that the threshold is lower than is normal for
hard-forks, noise on the measurement could cause an activation even if less
than 75% of miners agree.  It also means that the vote has to be sustained
for longer and inherently gives a longer notice period.

Two weeks seems low for an upgrade warning.  I guess there would be an
alert on the network.

Do old nodes detect an upgrade by version numbers?  If that was headers
only, then they could detect that large blocks have activated.

Have you considered a "fail" condition?  For example, if 750 of the last
1000 blocks set bits 4 and 14, then it counts as a rejection by 75% of the
miners.  Alternatively, if the rule doesn't activate by 11th Jan 2017, then
it is disabled.

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Gavin Andresen]

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

On Mon, Jun 22, 2015 at 2:33 PM, Tier Nolan <tier.nolan@gmail.com> wrote:

> The BIP-100 proposal uses a window of 12000 blocks (83 days) rather than
> the standard 1000.  Given that the threshold is lower than is normal for
> hard-forks, noise on the measurement could cause an activation even if less
> than 75% of miners agree.  It also means that the vote has to be sustained
> for longer and inherently gives a longer notice period.
>

9,000 of last 12,000 blocks is OK with me (I don't think scanning through
the last 12,000 block headers every new block will cause performance
problems, but I'd want to benchmark it to be absolutely sure).


> Two weeks seems low for an upgrade warning.  I guess there would be an
> alert on the network.
>
Do old nodes detect an upgrade by version numbers?  If that was headers
> only, then they could detect that large blocks have activated.
>

Bitcoin Core will alert when automatically when 51% of blocks have a
version it doesn't understand.

It will also alert automatically if it detects a chain with more work that
it doesn't consider valid for some reason. And 0.11 contains code that
alerts if you're on a chain that is being mined really slowly.

Have you considered a "fail" condition?  For example, if 750 of the last
> 1000 blocks set bits 4 and 14, then it counts as a rejection by 75% of the
> miners.  Alternatively, if the rule doesn't activate by 11th Jan 2017, then
> it is disabled.
>

I like the fail-if-not-activated-by idea. Not so crazy about the vote idea
(what if miners set bits 3 AND 4 ?).

-- 
--
Gavin Andresen

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Martin Schwarz]

Gavin,

in 2022 your proposal (BIP as well as code) crosses the 32MB maximum
message size limit. In order to avoid deployment of code that deterministically
fails fatally in 2022, I'd propose to stop the doublings at 32MB for now and fix
the message size limit in the mean time. Since the message size fix requires
a 2nd hard fork anyway, your current 8GB limit could be re-instateted in that
2nd fork as well. Even if you disagree, I'd suggest to address the topic in the BIP.

best regards,
Martin

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Tier Nolan]

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

On Mon, Jun 22, 2015 at 8:10 PM, Martin Schwarz <martin.schwarz@gmail.com>
wrote:

> Gavin,
>
> in 2022 your proposal (BIP as well as code) crosses the 32MB maximum
> message size limit. In order to avoid deployment of code that
> deterministically
> fails fatally in 2022, I'd propose to stop the doublings at 32MB for now
> and fix
> the message size limit in the mean time.


There is an exception in the code for "block" messages.

https://github.com/gavinandresen/bitcoinxt/commit/c81898ec46e4962daf975e352931b848026fdc34#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR3548

This means 2MB limit for all other messages.  "block" messages are limited
to the max block size for 2 hours into the future.

I think setting it to a week into the future might be better, since it is
only a DOS protection.  This would guarantee that message sizes are
reasonable.  The size check would still be done anyway.

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Gavin Andresen]

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

As Tier says, the current network message limit is 2MB (reduced from 32MB
in the... uhh, 0.10? release).

I think keeping the consensus rules distinct from limitations of the p2p
network makes sense-- we are already seeing different protocols for
announcing transactions and blocks (Matt's relay network is, essentially, a
separate protocol). I could write a separate BIP describing the change to
the p2p network protocol, but that feels like busy-work to me.

RE: setting the DoS size check farther than 2 hours into the future: the
block, itself, will be rejected if it has a timestamp more than 2 hours in
the future. That is already a consensus rule.

RE: what happens if block timestamps are not in chronological order:
Nothing.

The activation counting happens in block-height-order, so timestamps on all
but the "activating" block are all that matters.

Code that looks for the activation condition must properly handle re-orgs
around the activation block, of course.


RE: testnet parameters:  big blocks can be tested in -regtest mode with
arbitrary timestamps in the past or future. Testing maximum-8MB-blocks
mined "in the past" on testnet will just result in a testnet that is even
more useless for ordinary testing of products or services being developed
-- part of what makes testnet useful for things like testing transaction
creation code is it syncs quickly.

That said, I have thought for a while now somebody should take a fresh look
at the testnet, talk to people who might be customers for a reset testnet
or testnets (we probably want separate testnets for people testing mining
and people testing transaction creation, for example), and implement
testnets designed to make it easy to test what people need testing.

RE: scraping together money to run a few hundred full-load full-nodes:
 hardware is cheap, people are expensive. You seem to expect that companies
will be willing to invest the time of their people testing something that
may never happen (8MB of transactions every ten minutes). Maybe they would,
but most companies are very busy trying to stay in business by attracting
customers to their products or services. Scaling up is a good problem to
have, and, in my experience, the way to be successful scaling up is to
tackle problems as they occur.

Because there's no use spending a bunch of person-hours hyper-optimizing
for 8MB blocks stored in MySQL if a year from now you find out your
customers don't actually want your product or MySQL 5.11 comes out and is
100 times faster....

-- 
--
Gavin Andresen

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Peter Todd]

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

On Mon, Jun 22, 2015 at 03:54:26PM -0400, Gavin Andresen wrote:

It would be useful if you replied directly to the emails in question as
opposed to breaking the flow of conversation and taking replies out of
context for other readers.

> As Tier says, the current network message limit is 2MB (reduced from 32MB
> in the... uhh, 0.10? release).

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

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Peter Todd]

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

On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
> I promised to write a BIP after I'd implemented
> increase-the-maximum-block-size code, so here it is. It also lives at:
> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki

It's important that we see a wide range of realistic testing of what an
8MB limit could look in the near future. An important part of that
testing is load testing.

As of writing the BIP above has no mention of what switchover rules will
be used for testnet; code floating around has August 1st 2015 as that
date. I propose we use August 1st 2013.

This switch over date should be set in the _past_ to allow for the
creation (via reorg) of a realistic full-load blockchain on testnet to
fully test the real-world behavior of the entire infrastructure
ecosystem, including questions like the scalability of block explorers,
SPV wallets, feasibility of initial syncronization, scalability of the
UTXO set, etc. While this is of course inconvenient - 2 years of 8MB
blocks is 840GB worth of data - the Bitcoin ecosystem can-not afford to
make a change like this blindly.

I'm sure with a $3.5 billion market cap at stake we can scrape together
the resources to voluntarily run a few hundred full-load full-nodes for
testing a change with the potential to destroy that market cap.

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

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Ross Nicoll]

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

I don't think essentially replacing most of Testnet with a specialised 
test chain is a good idea, but this might be a good time to consider a 
4th test network with very large blocks from genesis onwards.

I do tend to think 2 years of 8mb blocks is excessive as a test, too, 
and while certainly large projects should have or can raise funds for 
test infrastructure, I would worry about the smaller stuff out there. Is 
there anything specific 2 years gives us over, say, 6 months?

Ross

On 22/06/2015 20:23, Peter Todd wrote:
> On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
>> I promised to write a BIP after I'd implemented
>> increase-the-maximum-block-size code, so here it is. It also lives at:
>> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
> It's important that we see a wide range of realistic testing of what an
> 8MB limit could look in the near future. An important part of that
> testing is load testing.
>
> As of writing the BIP above has no mention of what switchover rules will
> be used for testnet; code floating around has August 1st 2015 as that
> date. I propose we use August 1st 2013.
>
> This switch over date should be set in the _past_ to allow for the
> creation (via reorg) of a realistic full-load blockchain on testnet to
> fully test the real-world behavior of the entire infrastructure
> ecosystem, including questions like the scalability of block explorers,
> SPV wallets, feasibility of initial syncronization, scalability of the
> UTXO set, etc. While this is of course inconvenient - 2 years of 8MB
> blocks is 840GB worth of data - the Bitcoin ecosystem can-not afford to
> make a change like this blindly.
>
> I'm sure with a $3.5 billion market cap at stake we can scrape together
> the resources to voluntarily run a few hundred full-load full-nodes for
> testing a change with the potential to destroy that market cap.
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Jorge Timón]

On Tue, Jun 23, 2015 at 9:35 AM, Ross Nicoll <jrn@jrn.me.uk> wrote:
> I don't think essentially replacing most of Testnet with a specialised test
> chain is a good idea, but this might be a good time to consider a 4th test
> network with very large blocks from genesis onwards.

You may be interested in this patch/PR:

https://github.com/bitcoin/bitcoin/pull/6382

Why only one more testchain when you can add
std::numeric_limits<uint64_t>::max() new testchains with approximately
the same code?

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Peter Todd]

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

On Mon, Jun 22, 2015 at 03:23:09PM -0400, Peter Todd wrote:
> On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
> > I promised to write a BIP after I'd implemented
> > increase-the-maximum-block-size code, so here it is. It also lives at:
> > https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
> 
> It's important that we see a wide range of realistic testing of what an
> 8MB limit could look in the near future. An important part of that
> testing is load testing.
> 
> As of writing the BIP above has no mention of what switchover rules will
> be used for testnet; code floating around has August 1st 2015 as that
> date. I propose we use August 1st 2013.
> 
> This switch over date should be set in the _past_ to allow for the
> creation (via reorg) of a realistic full-load blockchain on testnet to
> fully test the real-world behavior of the entire infrastructure
> ecosystem, including questions like the scalability of block explorers,
> SPV wallets, feasibility of initial syncronization, scalability of the
> UTXO set, etc. While this is of course inconvenient - 2 years of 8MB
> blocks is 840GB worth of data - the Bitcoin ecosystem can-not afford to
> make a change like this blindly.
> 
> I'm sure with a $3.5 billion market cap at stake we can scrape together
> the resources to voluntarily run a few hundred full-load full-nodes for
> testing a change with the potential to destroy that market cap.

Also, as a few people have pointed out to me, the BIP proposal has no
information at all about testing, reproducable or not.

As much of the discussion about the acceptability of this BIP will be
heavily influenced by real world test results we should expect
sufficient information available to understand and reproduce those
tests; the Quality Assurance Test Plan done for BIP16 is a model worth
looking at:

https://github.com/bitcoin/bips/blob/master/bip-0016/qa.mediawiki

-- 
'peter'[:-1]@petertodd.org
000000000000000008c0be16e152f86ab3a271a13c3f41c56228d72990abf7bd

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Kalle Rosenbaum]

Thank you!

A few questions/comments:

* In the specification, you refer to "t_start". I guess you mean "time_start"?

* Miners can, especially when close to a block doubling or shortly
after activation, to some extent manipulate max block size by
manipulating the time stamp in the block header within valid limits.
According to the pseudo code in the specification, the first and a
handful of subsequent blocks after activation could actually have
negative max block sizes due to this (depending on how you define the
% operator of the pseudo code). I haven't checked the reference
implementation, but I do think that the specification section should
explicitly handle this.

Regards,
Kalle

2015-06-22 20:18 GMT+02:00 Gavin Andresen <gavinandresen@gmail.com>:
> I promised to write a BIP after I'd implemented
> increase-the-maximum-block-size code, so here it is. It also lives at:
> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
>
> I don't expect any proposal to please everybody; there are unavoidable
> tradeoffs to increasing the maximum block size. I prioritize implementation
> simplicity -- it is hard to write consensus-critical code, so simpler is
> better.
>
>
>
>
>   BIP: ??
>   Title: Increase Maximum Block Size
>   Author: Gavin Andresen <gavinandresen@gmail.com>
>   Status: Draft
>   Type: Standards Track
>   Created: 2015-06-22
>
> ==Abstract==
>
> This BIP proposes replacing the fixed one megabyte maximum block size with a
> maximum size that grows over time at a predictable rate.
>
> ==Motivation==
>
> Transaction volume on the Bitcoin network has been growing, and will soon
> reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte
> maximum block size. Increasing the maximum size reduces the impact of that
> limit on Bitcoin adoption and growth.
>
> ==Specification==
>
> After deployment on the network (see the Deployment section for details),
> the maximum allowed size of a block on the main network shall be calculated
> based on the timestamp in the block header.
>
> The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11
> 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000
> seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC
> (timestamp 2083190400). The maximum size of blocks in between doublings will
> increase linearly based on the block's timestamp. The maximum size of blocks
> after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.
>
> Expressed in pseudo-code, using integer math:
>
>     function max_block_size(block_timestamp):
>
>         time_start = 1452470400
>         time_double = 60*60*24*365*2
>         size_start = 8000000
>         if block_timestamp >= time_start+time_double*10
>             return size_start * 2^10
>
>         // Piecewise-linear-between-doublings growth:
>         time_delta = block_timestamp - t_start
>         doublings = time_delta / time_double
>         remainder = time_delta % time_double
>         interpolate = (size_start * 2^doublings * remainder) / time_double
>         max_size = size_start * 2^doublings + interpolate
>
>         return max_size
>
> ==Deployment==
>
> Deployment shall be controlled by hash-power supermajority vote (similar to
> the technique used in BIP34), but the earliest possible activation time is
> 2016-01-11 00:00:00 UTC.
>
> Activation is achieved when 750 of 1,000 consecutive blocks in the best
> chain have a version number with bits 3 and 14 set (0x20000004 in hex). The
> activation time will be the timestamp of the 750'th block plus a two week
> (1,209,600 second) grace period to give any remaining miners or services
> time to upgrade to support larger blocks. If a supermajority is achieved
> more than two weeks before 2016-01-11 00:00:00 UTC, the activation time will
> be 2016-01-11 00:00:00 UTC.
>
> Block version numbers are used only for activation; once activation is
> achieved, the maximum block size shall be as described in the specification
> section, regardless of the version number of the block.
>
>
> ==Rationale==
>
> The initial size of 8,000,000 bytes was chosen after testing the current
> reference implementation code with larger block sizes and receiving feedback
> from miners stuck behind bandwidth-constrained networks (in particular,
> Chinese miners behind the Great Firewall of China).
>
> The doubling interval was chosen based on long-term growth trends for CPU
> power, storage, and Internet bandwidth. The 20-year limit was chosen because
> exponential growth cannot continue forever.
>
> Calculations are based on timestamps and not blockchain height because a
> timestamp is part of every block's header. This allows implementations to
> know a block's maximum size after they have downloaded it's header, but
> before downloading any transactions.
>
> The deployment plan is taken from Jeff Garzik's proposed BIP100 block size
> increase, and is designed to give miners, merchants, and
> full-node-running-end-users sufficient time to upgrade to software that
> supports bigger blocks. A 75% supermajority was chosen so that one large
> mining pool does not have effective veto power over a blocksize increase.
> The version number scheme is designed to be compatible with Pieter's
> Wuille's proposed "Version bits" BIP.
>
> TODO: summarize objections/arguments from
> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
>
> TODO: describe other proposals and their advantages/disadvantages over this
> proposal.
>
>
> ==Compatibility==
>
> This is a hard-forking change to the Bitcoin protocol; anybody running code
> that fully validates blocks must upgrade before the activation time or they
> will risk rejecting a chain containing larger-than-one-megabyte blocks.
>
> Simplified Payment Verification software is not affected, unless it makes
> assumptions about the maximum depth of a transaction's merkle branch based
> on the minimum size of a transaction and the maximum block size.
>
> ==Implementation==
>
> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Gavin Andresen]

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

On Mon, Jun 22, 2015 at 4:27 PM, Kalle Rosenbaum <kalle@rosenbaum.se> wrote:

> * In the specification, you refer to "t_start". I guess you mean
> "time_start"?
>

Thanks, I'll fix.


> * Miners can, especially when close to a block doubling or shortly
> after activation, to some extent manipulate max block size by
> manipulating the time stamp in the block header within valid limits.
> According to the pseudo code in the specification, the first and a
> handful of subsequent blocks after activation could actually have
> negative max block sizes due to this (depending on how you define the
> % operator of the pseudo code). I haven't checked the reference
> implementation, but I do think that the specification section should
> explicitly handle this.
>

Excellent point. That could only happen if activation happened on 11 Jan
2016; instead of complicating the code and spec with another condition, I
think it would be better to specify that the activation date is the later
of the miner supermajority and 11 Jan, with the first big block two weeks
later.


-- 
--
Gavin Andresen

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Gavin Andresen]

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

On Mon, Jun 22, 2015 at 4:46 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:

> Excellent point. That could only happen if activation happened on 11 Jan
> 2016; instead of complicating the code and spec with another condition, I
> think it would be better to specify that the activation date is the later
> of the miner supermajority and 11 Jan, with the first big block two weeks
> later.
>

.... I take that back, I'm wrong and Tier is correct: if activation
happened right at midnight 11 Jan 2016 and the next block's timestamp was
before midnight, that next block would just be limited to 1MB in size.

-- 
--
Gavin Andresen

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Mark Friedenbach]

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

Can you please add a discussion of the tradeoffs of decentralization vs
block size?

On Mon, Jun 22, 2015 at 11:18 AM, Gavin Andresen <gavinandresen@gmail.com>
wrote:

> I promised to write a BIP after I'd implemented
> increase-the-maximum-block-size code, so here it is. It also lives at:
> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
>
> I don't expect any proposal to please everybody; there are unavoidable
> tradeoffs to increasing the maximum block size. I prioritize implementation
> simplicity -- it is hard to write consensus-critical code, so simpler is
> better.
>
>
>
>
>   BIP: ??
>   Title: Increase Maximum Block Size
>   Author: Gavin Andresen <gavinandresen@gmail.com>
>   Status: Draft
>   Type: Standards Track
>   Created: 2015-06-22
>
> ==Abstract==
>
> This BIP proposes replacing the fixed one megabyte maximum block size with
> a maximum size that grows over time at a predictable rate.
>
> ==Motivation==
>
> Transaction volume on the Bitcoin network has been growing, and will soon
> reach the one-megabyte-every-ten-minutes limit imposed by the one megabyte
> maximum block size. Increasing the maximum size reduces the impact of that
> limit on Bitcoin adoption and growth.
>
> ==Specification==
>
> After deployment on the network (see the Deployment section for details),
> the maximum allowed size of a block on the main network shall be calculated
> based on the timestamp in the block header.
>
> The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11
> 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000
> seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC
> (timestamp 2083190400). The maximum size of blocks in between doublings
> will increase linearly based on the block's timestamp. The maximum size of
> blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.
>
> Expressed in pseudo-code, using integer math:
>
>     function max_block_size(block_timestamp):
>
>         time_start = 1452470400
>         time_double = 60*60*24*365*2
>         size_start = 8000000
>         if block_timestamp >= time_start+time_double*10
>             return size_start * 2^10
>
>         // Piecewise-linear-between-doublings growth:
>         time_delta = block_timestamp - t_start
>         doublings = time_delta / time_double
>         remainder = time_delta % time_double
>         interpolate = (size_start * 2^doublings * remainder) / time_double
>         max_size = size_start * 2^doublings + interpolate
>
>         return max_size
>
> ==Deployment==
>
> Deployment shall be controlled by hash-power supermajority vote (similar
> to the technique used in BIP34), but the earliest possible activation time
> is 2016-01-11 00:00:00 UTC.
>
> Activation is achieved when 750 of 1,000 consecutive blocks in the best
> chain have a version number with bits 3 and 14 set (0x20000004 in hex). The
> activation time will be the timestamp of the 750'th block plus a two week
> (1,209,600 second) grace period to give any remaining miners or services
> time to upgrade to support larger blocks. If a supermajority is achieved
> more than two weeks before 2016-01-11 00:00:00 UTC, the activation time
> will be 2016-01-11 00:00:00 UTC.
>
> Block version numbers are used only for activation; once activation is
> achieved, the maximum block size shall be as described in the specification
> section, regardless of the version number of the block.
>
>
> ==Rationale==
>
> The initial size of 8,000,000 bytes was chosen after testing the current
> reference implementation code with larger block sizes and receiving
> feedback from miners stuck behind bandwidth-constrained networks (in
> particular, Chinese miners behind the Great Firewall of China).
>
> The doubling interval was chosen based on long-term growth trends for CPU
> power, storage, and Internet bandwidth. The 20-year limit was chosen
> because exponential growth cannot continue forever.
>
> Calculations are based on timestamps and not blockchain height because a
> timestamp is part of every block's header. This allows implementations to
> know a block's maximum size after they have downloaded it's header, but
> before downloading any transactions.
>
> The deployment plan is taken from Jeff Garzik's proposed BIP100 block size
> increase, and is designed to give miners, merchants, and
> full-node-running-end-users sufficient time to upgrade to software that
> supports bigger blocks. A 75% supermajority was chosen so that one large
> mining pool does not have effective veto power over a blocksize increase.
> The version number scheme is designed to be compatible with Pieter's
> Wuille's proposed "Version bits" BIP.
>
> TODO: summarize objections/arguments from
> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
>
> TODO: describe other proposals and their advantages/disadvantages over
> this proposal.
>
>
> ==Compatibility==
>
> This is a hard-forking change to the Bitcoin protocol; anybody running
> code that fully validates blocks must upgrade before the activation time or
> they will risk rejecting a chain containing larger-than-one-megabyte blocks.
>
> Simplified Payment Verification software is not affected, unless it makes
> assumptions about the maximum depth of a transaction's merkle branch based
> on the minimum size of a transaction and the maximum block size.
>
> ==Implementation==
>
> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Peter Todd]

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

On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
> ==Rationale==
> 
> The initial size of 8,000,000 bytes was chosen after testing the current
> reference implementation code with larger block sizes and receiving
> feedback from miners stuck behind bandwidth-constrained networks (in
> particular, Chinese miners behind the Great Firewall of China).
> 
> The doubling interval was chosen based on long-term growth trends for CPU
> power, storage, and Internet bandwidth. The 20-year limit was chosen
> because exponential growth cannot continue forever.

Wladimir noted that 'The original presented intention of block size
increase was a one-time "scaling" to grant time for more decentralizing
solutions to develop'

Comments?

In particular, if bandwidth scaling doesn't go according to your plan,
e.g. the exponential exponent is too large, perhaps due to technological
growth not keeping pace, or the political realities of actual bandwidth
deployment making theoretical technological growth irrelevant, what
mechanism will prevent centralization? (if any)

-- 
'peter'[:-1]@petertodd.org
000000000000000008c0be16e152f86ab3a271a13c3f41c56228d72990abf7bd

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Gavin Andresen]

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

On Tue, Jun 23, 2015 at 3:28 PM, Peter Todd <pete@petertodd.org> wrote:

> On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
> > ==Rationale==
> >
> > The initial size of 8,000,000 bytes was chosen after testing the current
> > reference implementation code with larger block sizes and receiving
> > feedback from miners stuck behind bandwidth-constrained networks (in
> > particular, Chinese miners behind the Great Firewall of China).
> >
> > The doubling interval was chosen based on long-term growth trends for CPU
> > power, storage, and Internet bandwidth. The 20-year limit was chosen
> > because exponential growth cannot continue forever.
>
> Wladimir noted that 'The original presented intention of block size
> increase was a one-time "scaling" to grant time for more decentralizing
> solutions to develop'
>
> Comments?
>

Consensus is that this process is too painful to go through once a year.  I
agree.

If you disagree and would like to see a Blocksize Council meet once a year
to issue a decree on what the maximum block size shall be for the next
year, then propose a process for who gets to sit on the Council and how
their decrees are enforced.....


>
> In particular, if bandwidth scaling doesn't go according to your plan,
> e.g. the exponential exponent is too large, perhaps due to technological
> growth not keeping pace, or the political realities of actual bandwidth
> deployment making theoretical technological growth irrelevant, what
> mechanism will prevent centralization? (if any)


Simulations show that:

Latency/bandwidth matter for miners.  Low latency, high bandwidth is
better. However, miners with bad connectivity can simply create smaller
blocks...

... until transaction fees become significant.  But by the time that
happens, protocol optimizations of block propagation will make the block
size an insignificant term in the "how profitable is it to mine in THIS
particular place on the Internet / part of the world" equation.

(Reference:
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg08224.html
)

So: for the immediate future, there is no problem. And in the long term,
there is no problem.

-- 
--
Gavin Andresen

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Pieter Wuille]

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

On Tue, Jun 23, 2015 at 10:12 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:

> On Tue, Jun 23, 2015 at 3:28 PM, Peter Todd <pete@petertodd.org> wrote:
>
>> Wladimir noted that 'The original presented intention of block size
>> increase was a one-time "scaling" to grant time for more decentralizing
>> solutions to develop'
>>
>> Comments?
>>
>
> Consensus is that this process is too painful to go through once a year.
> I agree.
>

If you believe we will need to go through this process once a year, we are
not talking about a one-time scaling to grant time for more decentralizing
solutions. It means you think we should keep scaling. I don't disagree
there - as long as we're talking about scaling as availability of
bandwidth, storage and processing power increase, there is no reason
Bitcoin's blockchain can't grow proportionally.

However, an initial bump 8 MB and the growth rate afterwards seem more like
a no-effectively-limit-ever to me.

I fear that the wish of not wanting to deal with - admittedly - a very hard
problem, resulted here in throwing away several protections we currently
have. And yes, I know you believe 8 MB won't be created immediately. I
truly, honestly, do not think so either. But I prefer a system where I
don't need to rely on anyone's guesses for the future.

-- 
Pieter

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Peter Todd]

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

On Tue, Jun 23, 2015 at 10:26:38PM +0200, Pieter Wuille wrote:
> On Tue, Jun 23, 2015 at 10:12 PM, Gavin Andresen <gavinandresen@gmail.com>
> wrote:
> 
> > On Tue, Jun 23, 2015 at 3:28 PM, Peter Todd <pete@petertodd.org> wrote:
> >
> >> Wladimir noted that 'The original presented intention of block size
> >> increase was a one-time "scaling" to grant time for more decentralizing
> >> solutions to develop'
> >>
> >> Comments?
> >>
> >
> > Consensus is that this process is too painful to go through once a year.
> > I agree.
> >
> 
> If you believe we will need to go through this process once a year, we are
> not talking about a one-time scaling to grant time for more decentralizing
> solutions. It means you think we should keep scaling. I don't disagree
> there - as long as we're talking about scaling as availability of
> bandwidth, storage and processing power increase, there is no reason
> Bitcoin's blockchain can't grow proportionally.
> 
> However, an initial bump 8 MB and the growth rate afterwards seem more like
> a no-effectively-limit-ever to me.

In particular, note how this bump is being proposed at a time when
blockchain space demand is so low that transactions usually cost well
under a penny each, a insignificant amount of money for almost all
use-cases.

> I fear that the wish of not wanting to deal with - admittedly - a very hard
> problem, resulted here in throwing away several protections we currently
> have. And yes, I know you believe 8 MB won't be created immediately. I
> truly, honestly, do not think so either. But I prefer a system where I
> don't need to rely on anyone's guesses for the future.

In that regard Jeff Garzik's proposal of a blocksize increase with a
miner vote feedback mechanism is a huge improvement over Gavin's
proposal.

-- 
'peter'[:-1]@petertodd.org
000000000000000008c0be16e152f86ab3a271a13c3f41c56228d72990abf7bd

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[grarpamp]

On Tue, Jun 23, 2015 at 4:50 PM, Peter Todd <pete@petertodd.org> wrote:
> In particular, note how this bump is being proposed at a time when
> blockchain space demand is so low that transactions usually cost well
> under a penny each

Recent averages seem to be offering around $0.04...
https://tradeblock.com/blog/bitcoin-network-capacity-analysis-part-2-macro-transaction-trends
With various stress tests indicate needing 10x more...
http://www.reddit.com/r/Bitcoin/search?restrict_sr=on&q=stress+test+fees

> a insignificant amount of money for almost all
> use-cases.

Penny stocks? Voting? Notarizing?
There's a whole ecosystem of non-purchase cases
for which non-profit-mining fees are enabling.

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Peter Todd]

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

On Tue, Jun 23, 2015 at 04:12:17PM -0400, Gavin Andresen wrote:
> > In particular, if bandwidth scaling doesn't go according to your plan,
> > e.g. the exponential exponent is too large, perhaps due to technological
> > growth not keeping pace, or the political realities of actual bandwidth
> > deployment making theoretical technological growth irrelevant, what
> > mechanism will prevent centralization? (if any)
> 
> 
> Simulations show that:
> 
> Latency/bandwidth matter for miners.  Low latency, high bandwidth is
> better. However, miners with bad connectivity can simply create smaller
> blocks...

Pieter Wuille showed with simulations that miners with bad connectivity
are negatively affected by other miners creating larger blocks.
Similarly I showed that with equation-based analysis. I've seen no
response to either argument, and it's a centralization pressure.

Note how propagation times are important enough to miners that they
already mine on top of unverified headers from other miners to increase
profitability, a grave threat to the security of the Bitcoin network.

> ... until transaction fees become significant.  But by the time that
> happens, protocol optimizations of block propagation will make the block
> size an insignificant term in the "how profitable is it to mine in THIS
> particular place on the Internet / part of the world" equation.

These block propagation improvements are both already implemented (Matt
Corallo's relay network, p2pool) and require co-operation.

For instance, notice the recent full-RBF debate where Coinbase said
they'd consider getting contracts directly with miners to get
transactions they desired mined even when they otherwise would not be
due to double-spends. This is one of many scenarios where block
propagation improvements fail. Thus for a safety engineering
analysis we need to talk about worst-case scenarios.

Equally, I don't see any analysis from anyone of that % of non-optimized
transactions need to fail for what kind of centralizing pressure.


In any case, this ponts to the need for your proposal to explictly talk
about what kind of resources are needed by miners for what kind of
profitability, including the case where other miners are sabotaging
their profitability.

-- 
'peter'[:-1]@petertodd.org
000000000000000008c0be16e152f86ab3a271a13c3f41c56228d72990abf7bd

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Gavin Andresen]

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

On Tue, Jun 23, 2015 at 4:46 PM, Peter Todd <pete@petertodd.org> wrote:

> Pieter Wuille showed with simulations that miners with bad connectivity
> are negatively affected by other miners creating larger blocks.
>

... but the effect is only significant if they have an absurdly
low-bandwidth connection and do NOTHING to work around it (like rent a
server on the other side of the bandwidth bottleneck and write some code to
make sure you're creating blocks that will propagate quickly on both sides
of the bottleneck).


Why do you think connectivity is a centralizing effect? It is just one
factor in the profitability-of-mining equation. A location with bad
connectivity (the US, maybe) but 10% cheaper electricity might be just as
good as one with great connectivity but more expensive electricity.

Having lots of variables in the profitability equation is a decentralizing
force, it means there is very likely to be several different places in the
world / on the net where mining is equally profitable.


> ... until transaction fees become significant.  But by the time that
> > happens, protocol optimizations of block propagation will make the block
> > size an insignificant term in the "how profitable is it to mine in THIS
> > particular place on the Internet / part of the world" equation.
>
> These block propagation improvements are both already implemented (Matt
> Corallo's relay network, p2pool) and require co-operation.
>

Long term the p2p protocol will evolve to incorporate those optimizations,
so will require no co-operation.



> For instance, notice the recent full-RBF debate where Coinbase said
> they'd consider getting contracts directly with miners to get
> transactions they desired mined even when they otherwise would not be
> due to double-spends. This is one of many scenarios where block
> propagation improvements fail. Thus for a safety engineering
> analysis we need to talk about worst-case scenarioss



> Equally, I don't see any analysis from anyone of that % of non-optimized
> transactions need to fail for what kind of centralizing pressure.
>
> In any case, this ponts to the need for your proposal to explictly talk
> about what kind of resources are needed by miners for what kind of
> profitability, including the case where other miners are sabotaging
> their profitability.
>

Are you familiar with the terms "Gish Gallop" and "Moving the Goalposts" ?

I have written quite a lot about the kind of resources needed to run a full
node, and have asked you, specifically, several times "how much do you
think is too much" and received no answer.

-- 
--
Gavin Andresen

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Peter Todd]

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

On Tue, Jun 23, 2015 at 05:24:23PM -0400, Gavin Andresen wrote:
> On Tue, Jun 23, 2015 at 4:46 PM, Peter Todd <pete@petertodd.org> wrote:
> 
> > Pieter Wuille showed with simulations that miners with bad connectivity
> > are negatively affected by other miners creating larger blocks.
> >
> 
> ... but the effect is only significant if they have an absurdly
> low-bandwidth connection and do NOTHING to work around it (like rent a
> server on the other side of the bandwidth bottleneck and write some code to
> make sure you're creating blocks that will propagate quickly on both sides
> of the bottleneck).

"Just rent a server" forces miners into deploying insecure hosted
infrastructure that's vulnerable to hacking and seizure; that we
encourage this already is worrying; requiring it for miners to be
profitable isn't acceptable.

> Why do you think connectivity is a centralizing effect? It is just one
> factor in the profitability-of-mining equation. A location with bad
> connectivity (the US, maybe) but 10% cheaper electricity might be just as
> good as one with great connectivity but more expensive electricity.

See above. The obvious thing to do if connectivity matters is keep your
hashing in the cheapest possible place and sell that hashing power to
centralized miners, an effect we're already seeing. Making this effect
about an order of magnitude worse, then doubling the problem every two
years is dangerous.

> Having lots of variables in the profitability equation is a decentralizing
> force, it means there is very likely to be several different places in the
> world / on the net where mining is equally profitable.

As mining and hashing can be trivially separated that theory just
doesn't work.

Again, what concretely works against centralization of mining control?
A proper proposal would discuss this issue, and explain what the
expected effect will be.

> > These block propagation improvements are both already implemented (Matt
> > Corallo's relay network, p2pool) and require co-operation.
> >
> 
> Long term the p2p protocol will evolve to incorporate those optimizations,
> so will require no co-operation.

The co-operation comes form the fact that mempool policies have to be
syncronized, not the protocol itself.

-- 
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Ivan Brightly]

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

On Fri, Jun 26, 2015 at 3:08 PM, Peter Todd <pete@petertodd.org> wrote:

> On Tue, Jun 23, 2015 at 05:24:23PM -0400, Gavin Andresen wrote:
> > On Tue, Jun 23, 2015 at 4:46 PM, Peter Todd <pete@petertodd.org> wrote:
> >
> > > Pieter Wuille showed with simulations that miners with bad connectivity
> > > are negatively affected by other miners creating larger blocks.
> > >
> >
> > ... but the effect is only significant if they have an absurdly
> > low-bandwidth connection and do NOTHING to work around it (like rent a
> > server on the other side of the bandwidth bottleneck and write some code
> to
> > make sure you're creating blocks that will propagate quickly on both
> sides
> > of the bottleneck).
>
> "Just rent a server" forces miners into deploying insecure hosted
> infrastructure that's vulnerable to hacking and seizure; that we
> encourage this already is worrying; requiring it for miners to be
> profitable isn't acceptable.
>

There are a number of factors that contribute to mining vulnerabilities.
For example, presuming a miner is a meaningful contributor to the network,
they'll be using more electricity than their neighbors and will be easily
identifiable in the same way illegal grow-houses are identified by the
local power company working with authorities. A hacked or seized hosted
server is far easier to recover from than seized equipment. Its hard to see
how requiring a reasonably reliable internet connection is a particularly
high barrier to entry when compared to the other mining requirements, such
as funds to purchase ASICs, competitive electricity costs, reasonable
belief that equipment won't be stolen or seized, the technical knowledge
for setting up a p2pool node, etc.

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Peter Todd]

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

On Tue, Jun 23, 2015 at 05:24:23PM -0400, Gavin Andresen wrote:
> > In any case, this ponts to the need for your proposal to explictly talk
> > about what kind of resources are needed by miners for what kind of
> > profitability, including the case where other miners are sabotaging
> > their profitability.
> >
> 
> Are you familiar with the terms "Gish Gallop" and "Moving the Goalposts" ?
> 
> I have written quite a lot about the kind of resources needed to run a full
> node, and have asked you, specifically, several times "how much do you
> think is too much" and received no answer.

You're the one proposing a change here; we're evaluating the safety of
that change.

An analogous situation is imagine we have two islands, with a suspension
bridge between them. The bridge has just two lanes in either direction,
so obviously there's a limited amount of traffic that can flow across
it. It used to be used to little that people would joyride back and
forth as the toll booths at either end just charged a hundreth of a
penny per trip, or even not at all, but as demand has been increasing
tolls are going up as well.

You've come along with a bold new plan to add fifteen more lanes to that
bridge by expanding the bridge deck, then hire contractors in advance to
double the number of lanes every two years after that with no clear way
of terminating their contract if anything goes wrong. (in just over a
decade our two lane bridge will be a mile wide!)

Of course, obviously if we add enough lanes the cables holding it up
will snap, so we've better carefully analyse the carrying capacity of
the brdige and the threats it faces. For instance, earthquakes happen
every so often - the last one even snapped a few strands in the main
cables, which people claim were fixed... but we don't really know for
sure as a thick layer of paint was quickly slapped over the fix and
no-one's been able to inspect it.

It's perfectly reasonable to ask what kind of earthquakes you expect the
bridge to withstand, as well as peer-reviewed and peer-reproducable
figures about the strength of the cables and the weight of the traffic.
Similarly, we've got the funds to make a test bridge of the same
dimensions and see if it collapses. Any bridge widening proposal that
doesn't have this data is simply incomplete, end of story.

As for the other side, the worst that happens if nothing changes is
usage of this bridge gets proportioned to the most valuable users by the
supply and demand toll system. Some people might decide to take the bus
across rather than an inefficient individual car, some of the
advertising companies running trucks back and forth with billboards on
the side are going to stop doing that. But traffic is still going to get
across. It's not a politically easy position to be in - there's enormous
pressure to quickly "do something" however dangerous - but the actual
effects of doing nothing are ultimately not a big deal.

In civil engineering we have enough experience with disasters to know
that you can't give into political pressure to do potentially dangerous
things until the consequences are well understood; hopefully we'll learn
that in the consensus cryptography space before a big disaster rather
than after.

-- 
'peter'[:-1]@petertodd.org
0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Simon Liu]

If Bitcoin is a $3bn project where stakeholder interests are to be
safeguarded, or if Bitcoin is to be compared to a civil engineering
project where life and death is at stake, it seems only logical that a
well-defined and well-documented process be introduced to properly
evaluate proposed changes.  Although too late for the block size debate,
it seems odd that discussion of such a process is often dismissed out of
hand.

To maintain the current approach of supermajority consensus, based
around ingrained wisdom, personal preference and unwritten rules would
suggest that Bitcoin is still an experiment, in which case perhaps any
decision regarding the block size should be based upon technical merit
alone rather than economic interest.

--Simon

> You're the one proposing a change here; we're evaluating the safety of
that change.

> In civil engineering we have enough experience with disasters to know
> that you can't give into political pressure to do potentially dangerous
> things until the consequences are well understood; hopefully we'll learn
> that in the consensus cryptography space before a big disaster rather
> than after.

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Milly Bitcoin]

It is actually not odd at all that a formal process is dismissed out of 
hand.  It is all about protecting turf and holding on to power.  If 
there is a well defined process then that takes the power out of the 
hands of the people who have been running the show and making up the 
rules.  In some cases developers see Bitcoin as their "baby" and they 
think they must control it in order to protect it but in doing so they 
can become an "overprotective parent."  Another problem is that some 
people in Bitcoin have disdain for the people they need such as 
financial, economic, security, and legal experts.  Some think they are 
smarter than those people because they discovered Bitcoin first and they 
think their knowledge of Bitcoin means they are also superior in all 
these other areas.  I have seen some discussions of developers who have 
met with people from the financial sector and they come out of the 
meeting with the attitude that all the experts are stupid and that 
Bitcoiners have everything figured out.  One developer tried to tell me 
that you can't do systems engineering in Bitcoin because it involves 
security rather than safety (of course that issue has been well vetted 
and NIST has a whole series of documents to address that very issue 
http://csrc.nist.gov/publications/PubsSPs.html).

Russ




On 6/26/2015 6:16 PM, Simon Liu wrote:
> If Bitcoin is a $3bn project where stakeholder interests are to be
> safeguarded, or if Bitcoin is to be compared to a civil engineering
> project where life and death is at stake, it seems only logical that a
> well-defined and well-documented process be introduced to properly
> evaluate proposed changes.  Although too late for the block size debate,
> it seems odd that discussion of such a process is often dismissed out of
> hand.
>
> To maintain the current approach of supermajority consensus, based
> around ingrained wisdom, personal preference and unwritten rules would
> suggest that Bitcoin is still an experiment, in which case perhaps any
> decision regarding the block size should be based upon technical merit
> alone rather than economic interest.
>
> --Simon
>
>> You're the one proposing a change here; we're evaluating the safety of
> that change.
>
>> In civil engineering we have enough experience with disasters to know
>> that you can't give into political pressure to do potentially dangerous
>> things until the consequences are well understood; hopefully we'll learn
>> that in the consensus cryptography space before a big disaster rather
>> than after.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Roy Badami]

> Consensus is that this process is too painful to go through once a year.  I
> agree.
> 
> If you disagree and would like to see a Blocksize Council meet once a year
> to issue a decree on what the maximum block size shall be for the next
> year, then propose a process for who gets to sit on the Council and how
> their decrees are enforced.....

We could just as well say that the increases continue for 20 years, or
until there is concensus to schedule a soft-fork to prevent further
increase - whichever comes first.  That is the case already, of
course, since there is no way to prevent a modest supermajority of
miners from pushing through a soft-fork.  But explicitly accepting the
possibility that the community might choose to cut the process short
might make the BIP more palatable to some.

It is also the reality: halting the blocksize increase before it hits
the final 8GB limit is relatively easy, compared to the task of
setting it in motion, so it does no real harm to set the "20 years"
figure at the upper range of what we think is reasonable - even though
under other circumstances one would probably say that extrapolating
exponentials that far out would be foolhardy...

roy

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[odinn]

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

1) Hard fork not (necessarily) needed
2) See Garzik's BIP 100, better (this is not meant to say "superior to
your stuff," but rather simply to say, "Better you should work with
Garzik to implement BIP-100, that would be good")
3) See points 1 and 2 above
4) If still reading... changes should be (as you seem to have been
trying to lean towards)... lean towards gradual change; hence, changes
that would flow from this BIP would be better off oriented in a
process that dies not require the "way you have done it."

You did address that, to be fair - in your TODO, this link:
http://gavinandresen.ninja/time-to-roll-out-bigger-blocks

contained the following link:

http://gavinandresen.ninja/bigger-blocks-another-way

However, in reading that, I didn't see any meaningful statements that
would refute the approach in Garzik's BIP-100.

Maybe a better way to say this is,

Work with Jeff Garzik (which I am sure you are already having such
discussions in private) as well as the list discussions,
Move forward on BIP-100 with Garzik and other developers (not such a
bad plan really) and don't get caught up in XT.  (If you feel you can
develop XT further, that is your thing but it would perhaps make you
lose focus, work together with other developers.)

Relax into the process.  Things will be ok.

Respectfully,

- -O

On 06/22/2015 11:18 AM, Gavin Andresen wrote:
> I promised to write a BIP after I'd implemented 
> increase-the-maximum-block-size code, so here it is. It also lives
> at: 
> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
>
>  I don't expect any proposal to please everybody; there are
> unavoidable tradeoffs to increasing the maximum block size. I
> prioritize implementation simplicity -- it is hard to write
> consensus-critical code, so simpler is better.
> 
> 
> 
> 
> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
> <gavinandresen@gmail.com <mailto:gavinandresen@gmail.com>> Status:
> Draft Type: Standards Track Created: 2015-06-22
> 
> ==Abstract==
> 
> This BIP proposes replacing the fixed one megabyte maximum block
> size with a maximum size that grows over time at a predictable
> rate.
> 
> ==Motivation==
> 
> Transaction volume on the Bitcoin network has been growing, and
> will soon reach the one-megabyte-every-ten-minutes limit imposed by
> the one megabyte maximum block size. Increasing the maximum size
> reduces the impact of that limit on Bitcoin adoption and growth.
> 
> ==Specification==
> 
> After deployment on the network (see the Deployment section for 
> details), the maximum allowed size of a block on the main network
> shall be calculated based on the timestamp in the block header.
> 
> The maximum size shall be 8,000,000 bytes at a timestamp of
> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
> every 63,072,000 seconds (two years, ignoring leap years), until
> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
> blocks in between doublings will increase linearly based on the
> block's timestamp. The maximum size of blocks after 2036-01-06
> 00:00:00 UTC shall be 8,192,000,000 bytes.
> 
> Expressed in pseudo-code, using integer math:
> 
> function max_block_size(block_timestamp):
> 
> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =
> 8000000 if block_timestamp >= time_start+time_double*10 return
> size_start * 2^10
> 
> // Piecewise-linear-between-doublings growth: time_delta =
> block_timestamp - t_start doublings = time_delta / time_double 
> remainder = time_delta % time_double interpolate = (size_start *
> 2^doublings * remainder) / time_double max_size = size_start *
> 2^doublings + interpolate
> 
> return max_size
> 
> ==Deployment==
> 
> Deployment shall be controlled by hash-power supermajority vote
> (similar to the technique used in BIP34), but the earliest possible
> activation time is 2016-01-11 00:00:00 UTC.
> 
> Activation is achieved when 750 of 1,000 consecutive blocks in the
> best chain have a version number with bits 3 and 14 set (0x20000004
> in hex). The activation time will be the timestamp of the 750'th
> block plus a two week (1,209,600 second) grace period to give any
> remaining miners or services time to upgrade to support larger
> blocks. If a supermajority is achieved more than two weeks before
> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
> 00:00:00 UTC.
> 
> Block version numbers are used only for activation; once activation
> is achieved, the maximum block size shall be as described in the 
> specification section, regardless of the version number of the
> block.
> 
> 
> ==Rationale==
> 
> The initial size of 8,000,000 bytes was chosen after testing the
> current reference implementation code with larger block sizes and
> receiving feedback from miners stuck behind bandwidth-constrained
> networks (in particular, Chinese miners behind the Great Firewall
> of China).
> 
> The doubling interval was chosen based on long-term growth trends
> for CPU power, storage, and Internet bandwidth. The 20-year limit
> was chosen because exponential growth cannot continue forever.
> 
> Calculations are based on timestamps and not blockchain height
> because a timestamp is part of every block's header. This allows
> implementations to know a block's maximum size after they have
> downloaded it's header, but before downloading any transactions.
> 
> The deployment plan is taken from Jeff Garzik's proposed BIP100
> block size increase, and is designed to give miners, merchants,
> and full-node-running-end-users sufficient time to upgrade to
> software that supports bigger blocks. A 75% supermajority was
> chosen so that one large mining pool does not have effective veto
> power over a blocksize increase. The version number scheme is
> designed to be compatible with Pieter's Wuille's proposed "Version
> bits" BIP.
> 
> TODO: summarize objections/arguments from 
> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
> 
> TODO: describe other proposals and their advantages/disadvantages
> over this proposal.
> 
> 
> ==Compatibility==
> 
> This is a hard-forking change to the Bitcoin protocol; anybody
> running code that fully validates blocks must upgrade before the
> activation time or they will risk rejecting a chain containing
> larger-than-one-megabyte blocks.
> 
> Simplified Payment Verification software is not affected, unless
> it makes assumptions about the maximum depth of a transaction's
> merkle branch based on the minimum size of a transaction and the
> maximum block size.
> 
> ==Implementation==
> 
> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
> 
> 
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
=ft62
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[William Madden]

Here are refutations of the approach in BIP-100 here:
http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf

To recap BIP-100:

1) Hard form to remove static 1MB block size limit
2) Add new floating block size limit set to 1MB
3) Historical 32MB message limit remains
4) Hard form on testnet 9/1/2015
5) Hard form on main 1/11/2016
6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
threshold by 90% of blocks
7) Limit increase or decrease may not exceed 2x in any one step
8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
scriptSig, e.g. "/BV8000000/" to vote for 8M.
9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
most common floor (minimum) is chosen.

8MB limits doubling just under every 2 years makes a static value grow
in a predictable manner.

BIP-100 makes a static value grow (or more importantly potentially
shrink) in an unpredictable manner based on voting mechanics that are
untested in this capacity in the bitcoin network.  Introducing a highly
variable and untested dynamic into an already complex system is
unnecessarily risky.

For example, the largely arbitrary voting rules listed in 9 above can be
gamed.  If I control pools or have affiliates involved in pools that
mine slightly more than 20% of blocks, I could wait until block sizes
are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
"/BV5000001/" for the remaining 10%.  If others don't consistently vote
for the same "/BV#/" value, vote too consistently and have their value
thrown out as the top 20%, I could win the resize to half capacity
"/BV5000001/" because it was the lowest repeated value not in the bottom
20%.

I could use this to force an exodus to my sidechain/alt coin, or to
choke out the bitcoin network.  A first improvement would be to only let
BIP-100 raise the cap and not lower it, but if I can think of a
vulnerability off the top of my head, there will be others on the other
side of the equation that have not been thought of.  Why bother
introducing a rube goldberg machine like voting when a simple 8mb cap
with predictable growth gets the job done, potentially permanently?


On 6/23/2015 9:43 PM, odinn wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 1) Hard fork not (necessarily) needed
> 2) See Garzik's BIP 100, better (this is not meant to say "superior to
> your stuff," but rather simply to say, "Better you should work with
> Garzik to implement BIP-100, that would be good")
> 3) See points 1 and 2 above
> 4) If still reading... changes should be (as you seem to have been
> trying to lean towards)... lean towards gradual change; hence, changes
> that would flow from this BIP would be better off oriented in a
> process that dies not require the "way you have done it."
> 
> You did address that, to be fair - in your TODO, this link:
> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
> 
> contained the following link:
> 
> http://gavinandresen.ninja/bigger-blocks-another-way
> 
> However, in reading that, I didn't see any meaningful statements that
> would refute the approach in Garzik's BIP-100.
> 
> Maybe a better way to say this is,
> 
> Work with Jeff Garzik (which I am sure you are already having such
> discussions in private) as well as the list discussions,
> Move forward on BIP-100 with Garzik and other developers (not such a
> bad plan really) and don't get caught up in XT.  (If you feel you can
> develop XT further, that is your thing but it would perhaps make you
> lose focus, work together with other developers.)
> 
> Relax into the process.  Things will be ok.
> 
> Respectfully,
> 
> - -O
> 
> On 06/22/2015 11:18 AM, Gavin Andresen wrote:
>> I promised to write a BIP after I'd implemented 
>> increase-the-maximum-block-size code, so here it is. It also lives
>> at: 
>> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
>>
>>  I don't expect any proposal to please everybody; there are
>> unavoidable tradeoffs to increasing the maximum block size. I
>> prioritize implementation simplicity -- it is hard to write
>> consensus-critical code, so simpler is better.
>>
>>
>>
>>
>> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
>> <gavinandresen@gmail.com <mailto:gavinandresen@gmail.com>> Status:
>> Draft Type: Standards Track Created: 2015-06-22
>>
>> ==Abstract==
>>
>> This BIP proposes replacing the fixed one megabyte maximum block
>> size with a maximum size that grows over time at a predictable
>> rate.
>>
>> ==Motivation==
>>
>> Transaction volume on the Bitcoin network has been growing, and
>> will soon reach the one-megabyte-every-ten-minutes limit imposed by
>> the one megabyte maximum block size. Increasing the maximum size
>> reduces the impact of that limit on Bitcoin adoption and growth.
>>
>> ==Specification==
>>
>> After deployment on the network (see the Deployment section for 
>> details), the maximum allowed size of a block on the main network
>> shall be calculated based on the timestamp in the block header.
>>
>> The maximum size shall be 8,000,000 bytes at a timestamp of
>> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
>> every 63,072,000 seconds (two years, ignoring leap years), until
>> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
>> blocks in between doublings will increase linearly based on the
>> block's timestamp. The maximum size of blocks after 2036-01-06
>> 00:00:00 UTC shall be 8,192,000,000 bytes.
>>
>> Expressed in pseudo-code, using integer math:
>>
>> function max_block_size(block_timestamp):
>>
>> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =
>> 8000000 if block_timestamp >= time_start+time_double*10 return
>> size_start * 2^10
>>
>> // Piecewise-linear-between-doublings growth: time_delta =
>> block_timestamp - t_start doublings = time_delta / time_double 
>> remainder = time_delta % time_double interpolate = (size_start *
>> 2^doublings * remainder) / time_double max_size = size_start *
>> 2^doublings + interpolate
>>
>> return max_size
>>
>> ==Deployment==
>>
>> Deployment shall be controlled by hash-power supermajority vote
>> (similar to the technique used in BIP34), but the earliest possible
>> activation time is 2016-01-11 00:00:00 UTC.
>>
>> Activation is achieved when 750 of 1,000 consecutive blocks in the
>> best chain have a version number with bits 3 and 14 set (0x20000004
>> in hex). The activation time will be the timestamp of the 750'th
>> block plus a two week (1,209,600 second) grace period to give any
>> remaining miners or services time to upgrade to support larger
>> blocks. If a supermajority is achieved more than two weeks before
>> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
>> 00:00:00 UTC.
>>
>> Block version numbers are used only for activation; once activation
>> is achieved, the maximum block size shall be as described in the 
>> specification section, regardless of the version number of the
>> block.
>>
>>
>> ==Rationale==
>>
>> The initial size of 8,000,000 bytes was chosen after testing the
>> current reference implementation code with larger block sizes and
>> receiving feedback from miners stuck behind bandwidth-constrained
>> networks (in particular, Chinese miners behind the Great Firewall
>> of China).
>>
>> The doubling interval was chosen based on long-term growth trends
>> for CPU power, storage, and Internet bandwidth. The 20-year limit
>> was chosen because exponential growth cannot continue forever.
>>
>> Calculations are based on timestamps and not blockchain height
>> because a timestamp is part of every block's header. This allows
>> implementations to know a block's maximum size after they have
>> downloaded it's header, but before downloading any transactions.
>>
>> The deployment plan is taken from Jeff Garzik's proposed BIP100
>> block size increase, and is designed to give miners, merchants,
>> and full-node-running-end-users sufficient time to upgrade to
>> software that supports bigger blocks. A 75% supermajority was
>> chosen so that one large mining pool does not have effective veto
>> power over a blocksize increase. The version number scheme is
>> designed to be compatible with Pieter's Wuille's proposed "Version
>> bits" BIP.
>>
>> TODO: summarize objections/arguments from 
>> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
>>
>> TODO: describe other proposals and their advantages/disadvantages
>> over this proposal.
>>
>>
>> ==Compatibility==
>>
>> This is a hard-forking change to the Bitcoin protocol; anybody
>> running code that fully validates blocks must upgrade before the
>> activation time or they will risk rejecting a chain containing
>> larger-than-one-megabyte blocks.
>>
>> Simplified Payment Verification software is not affected, unless
>> it makes assumptions about the maximum depth of a transaction's
>> merkle branch based on the minimum size of a transaction and the
>> maximum block size.
>>
>> ==Implementation==
>>
>> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
>>
>>
>>
>> _______________________________________________ bitcoin-dev mailing
>> list bitcoin-dev@lists.linuxfoundation.org 
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> 
> - -- 
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> 
> iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
> Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
> K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
> OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
> fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
> CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
> =ft62
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Jeff Garzik]

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

Miners can collude today to lower the block size limit.

In fact, this largely happens already out of laziness - miners often follow
the "soft" default limit set by Bitcoin Core, to the point where you can
chart when miners upgrade to new software:
http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block



On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri.com>
wrote:

> Here are refutations of the approach in BIP-100 here:
> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>
> To recap BIP-100:
>
> 1) Hard form to remove static 1MB block size limit
> 2) Add new floating block size limit set to 1MB
> 3) Historical 32MB message limit remains
> 4) Hard form on testnet 9/1/2015
> 5) Hard form on main 1/11/2016
> 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
> threshold by 90% of blocks
> 7) Limit increase or decrease may not exceed 2x in any one step
> 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
> scriptSig, e.g. "/BV8000000/" to vote for 8M.
> 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
> most common floor (minimum) is chosen.
>
> 8MB limits doubling just under every 2 years makes a static value grow
> in a predictable manner.
>
> BIP-100 makes a static value grow (or more importantly potentially
> shrink) in an unpredictable manner based on voting mechanics that are
> untested in this capacity in the bitcoin network.  Introducing a highly
> variable and untested dynamic into an already complex system is
> unnecessarily risky.
>
> For example, the largely arbitrary voting rules listed in 9 above can be
> gamed.  If I control pools or have affiliates involved in pools that
> mine slightly more than 20% of blocks, I could wait until block sizes
> are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
> "/BV5000001/" for the remaining 10%.  If others don't consistently vote
> for the same "/BV#/" value, vote too consistently and have their value
> thrown out as the top 20%, I could win the resize to half capacity
> "/BV5000001/" because it was the lowest repeated value not in the bottom
> 20%.
>
> I could use this to force an exodus to my sidechain/alt coin, or to
> choke out the bitcoin network.  A first improvement would be to only let
> BIP-100 raise the cap and not lower it, but if I can think of a
> vulnerability off the top of my head, there will be others on the other
> side of the equation that have not been thought of.  Why bother
> introducing a rube goldberg machine like voting when a simple 8mb cap
> with predictable growth gets the job done, potentially permanently?
>
>
> On 6/23/2015 9:43 PM, odinn wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > 1) Hard fork not (necessarily) needed
> > 2) See Garzik's BIP 100, better (this is not meant to say "superior to
> > your stuff," but rather simply to say, "Better you should work with
> > Garzik to implement BIP-100, that would be good")
> > 3) See points 1 and 2 above
> > 4) If still reading... changes should be (as you seem to have been
> > trying to lean towards)... lean towards gradual change; hence, changes
> > that would flow from this BIP would be better off oriented in a
> > process that dies not require the "way you have done it."
> >
> > You did address that, to be fair - in your TODO, this link:
> > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
> >
> > contained the following link:
> >
> > http://gavinandresen.ninja/bigger-blocks-another-way
> >
> > However, in reading that, I didn't see any meaningful statements that
> > would refute the approach in Garzik's BIP-100.
> >
> > Maybe a better way to say this is,
> >
> > Work with Jeff Garzik (which I am sure you are already having such
> > discussions in private) as well as the list discussions,
> > Move forward on BIP-100 with Garzik and other developers (not such a
> > bad plan really) and don't get caught up in XT.  (If you feel you can
> > develop XT further, that is your thing but it would perhaps make you
> > lose focus, work together with other developers.)
> >
> > Relax into the process.  Things will be ok.
> >
> > Respectfully,
> >
> > - -O
> >
> > On 06/22/2015 11:18 AM, Gavin Andresen wrote:
> >> I promised to write a BIP after I'd implemented
> >> increase-the-maximum-block-size code, so here it is. It also lives
> >> at:
> >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
> >>
> >>  I don't expect any proposal to please everybody; there are
> >> unavoidable tradeoffs to increasing the maximum block size. I
> >> prioritize implementation simplicity -- it is hard to write
> >> consensus-critical code, so simpler is better.
> >>
> >>
> >>
> >>
> >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
> >> <gavinandresen@gmail.com <mailto:gavinandresen@gmail.com>> Status:
> >> Draft Type: Standards Track Created: 2015-06-22
> >>
> >> ==Abstract==
> >>
> >> This BIP proposes replacing the fixed one megabyte maximum block
> >> size with a maximum size that grows over time at a predictable
> >> rate.
> >>
> >> ==Motivation==
> >>
> >> Transaction volume on the Bitcoin network has been growing, and
> >> will soon reach the one-megabyte-every-ten-minutes limit imposed by
> >> the one megabyte maximum block size. Increasing the maximum size
> >> reduces the impact of that limit on Bitcoin adoption and growth.
> >>
> >> ==Specification==
> >>
> >> After deployment on the network (see the Deployment section for
> >> details), the maximum allowed size of a block on the main network
> >> shall be calculated based on the timestamp in the block header.
> >>
> >> The maximum size shall be 8,000,000 bytes at a timestamp of
> >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
> >> every 63,072,000 seconds (two years, ignoring leap years), until
> >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
> >> blocks in between doublings will increase linearly based on the
> >> block's timestamp. The maximum size of blocks after 2036-01-06
> >> 00:00:00 UTC shall be 8,192,000,000 bytes.
> >>
> >> Expressed in pseudo-code, using integer math:
> >>
> >> function max_block_size(block_timestamp):
> >>
> >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =
> >> 8000000 if block_timestamp >= time_start+time_double*10 return
> >> size_start * 2^10
> >>
> >> // Piecewise-linear-between-doublings growth: time_delta =
> >> block_timestamp - t_start doublings = time_delta / time_double
> >> remainder = time_delta % time_double interpolate = (size_start *
> >> 2^doublings * remainder) / time_double max_size = size_start *
> >> 2^doublings + interpolate
> >>
> >> return max_size
> >>
> >> ==Deployment==
> >>
> >> Deployment shall be controlled by hash-power supermajority vote
> >> (similar to the technique used in BIP34), but the earliest possible
> >> activation time is 2016-01-11 00:00:00 UTC.
> >>
> >> Activation is achieved when 750 of 1,000 consecutive blocks in the
> >> best chain have a version number with bits 3 and 14 set (0x20000004
> >> in hex). The activation time will be the timestamp of the 750'th
> >> block plus a two week (1,209,600 second) grace period to give any
> >> remaining miners or services time to upgrade to support larger
> >> blocks. If a supermajority is achieved more than two weeks before
> >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
> >> 00:00:00 UTC.
> >>
> >> Block version numbers are used only for activation; once activation
> >> is achieved, the maximum block size shall be as described in the
> >> specification section, regardless of the version number of the
> >> block.
> >>
> >>
> >> ==Rationale==
> >>
> >> The initial size of 8,000,000 bytes was chosen after testing the
> >> current reference implementation code with larger block sizes and
> >> receiving feedback from miners stuck behind bandwidth-constrained
> >> networks (in particular, Chinese miners behind the Great Firewall
> >> of China).
> >>
> >> The doubling interval was chosen based on long-term growth trends
> >> for CPU power, storage, and Internet bandwidth. The 20-year limit
> >> was chosen because exponential growth cannot continue forever.
> >>
> >> Calculations are based on timestamps and not blockchain height
> >> because a timestamp is part of every block's header. This allows
> >> implementations to know a block's maximum size after they have
> >> downloaded it's header, but before downloading any transactions.
> >>
> >> The deployment plan is taken from Jeff Garzik's proposed BIP100
> >> block size increase, and is designed to give miners, merchants,
> >> and full-node-running-end-users sufficient time to upgrade to
> >> software that supports bigger blocks. A 75% supermajority was
> >> chosen so that one large mining pool does not have effective veto
> >> power over a blocksize increase. The version number scheme is
> >> designed to be compatible with Pieter's Wuille's proposed "Version
> >> bits" BIP.
> >>
> >> TODO: summarize objections/arguments from
> >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
> >>
> >> TODO: describe other proposals and their advantages/disadvantages
> >> over this proposal.
> >>
> >>
> >> ==Compatibility==
> >>
> >> This is a hard-forking change to the Bitcoin protocol; anybody
> >> running code that fully validates blocks must upgrade before the
> >> activation time or they will risk rejecting a chain containing
> >> larger-than-one-megabyte blocks.
> >>
> >> Simplified Payment Verification software is not affected, unless
> >> it makes assumptions about the maximum depth of a transaction's
> >> merkle branch based on the minimum size of a transaction and the
> >> maximum block size.
> >>
> >> ==Implementation==
> >>
> >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
> >>
> >>
> >>
> >> _______________________________________________ bitcoin-dev mailing
> >> list bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> > - --
> > http://abis.io ~
> > "a protocol concept to enable decentralization
> > and expansion of a giving economy, and a new social good"
> > https://keybase.io/odinn
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
> > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
> > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
> > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
> > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
> > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
> > =ft62
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > 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: 14984 bytes --]

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Will]

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

Yes, but with a key distinction.   Today miners may collude to (or unintentionally) lower the block size limit for blocks they win.  BIP-100 introduces the possibility of lowering the block size limit for everyone over the next 12,000 blocks.

Another gap involves laziness.  What is a far more likely issue is not a conspiracy but that miners will be lazy and hard code their vote values, requiring arm twisting later to change them.  Preventing this headache introduces the need for more complexity, either by making the default a non-vote (which makes it easier to game the system with less voting power), or by making the default vote = MAX_BLOCK_SIZE * 1.09 (which makes the default similar is to Gavin's proposal).

I think with a default vote that is ~9% larger than the previous max block size and no option to lower the max block size then BIP-100 could work without added risk or defeating the intended purpose.  Still, one has to ask if the benefit is there to justify the additional moving parts.

> On Jun 23, 2015, at 11:49 PM, Jeff Garzik <jgarzik@gmail.com> wrote:
> 
> Miners can collude today to lower the block size limit.
> 
> In fact, this largely happens already out of laziness - miners often follow the "soft" default limit set by Bitcoin Core, to the point where you can chart when miners upgrade to new software: http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block
> 
> 
> 
>> On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri.com> wrote:
>> Here are refutations of the approach in BIP-100 here:
>> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>> 
>> To recap BIP-100:
>> 
>> 1) Hard form to remove static 1MB block size limit
>> 2) Add new floating block size limit set to 1MB
>> 3) Historical 32MB message limit remains
>> 4) Hard form on testnet 9/1/2015
>> 5) Hard form on main 1/11/2016
>> 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
>> threshold by 90% of blocks
>> 7) Limit increase or decrease may not exceed 2x in any one step
>> 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
>> scriptSig, e.g. "/BV8000000/" to vote for 8M.
>> 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
>> most common floor (minimum) is chosen.
>> 
>> 8MB limits doubling just under every 2 years makes a static value grow
>> in a predictable manner.
>> 
>> BIP-100 makes a static value grow (or more importantly potentially
>> shrink) in an unpredictable manner based on voting mechanics that are
>> untested in this capacity in the bitcoin network.  Introducing a highly
>> variable and untested dynamic into an already complex system is
>> unnecessarily risky.
>> 
>> For example, the largely arbitrary voting rules listed in 9 above can be
>> gamed.  If I control pools or have affiliates involved in pools that
>> mine slightly more than 20% of blocks, I could wait until block sizes
>> are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
>> "/BV5000001/" for the remaining 10%.  If others don't consistently vote
>> for the same "/BV#/" value, vote too consistently and have their value
>> thrown out as the top 20%, I could win the resize to half capacity
>> "/BV5000001/" because it was the lowest repeated value not in the bottom
>> 20%.
>> 
>> I could use this to force an exodus to my sidechain/alt coin, or to
>> choke out the bitcoin network.  A first improvement would be to only let
>> BIP-100 raise the cap and not lower it, but if I can think of a
>> vulnerability off the top of my head, there will be others on the other
>> side of the equation that have not been thought of.  Why bother
>> introducing a rube goldberg machine like voting when a simple 8mb cap
>> with predictable growth gets the job done, potentially permanently?
>> 
>> 
>> On 6/23/2015 9:43 PM, odinn wrote:
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA1
>> >
>> > 1) Hard fork not (necessarily) needed
>> > 2) See Garzik's BIP 100, better (this is not meant to say "superior to
>> > your stuff," but rather simply to say, "Better you should work with
>> > Garzik to implement BIP-100, that would be good")
>> > 3) See points 1 and 2 above
>> > 4) If still reading... changes should be (as you seem to have been
>> > trying to lean towards)... lean towards gradual change; hence, changes
>> > that would flow from this BIP would be better off oriented in a
>> > process that dies not require the "way you have done it."
>> >
>> > You did address that, to be fair - in your TODO, this link:
>> > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
>> >
>> > contained the following link:
>> >
>> > http://gavinandresen.ninja/bigger-blocks-another-way
>> >
>> > However, in reading that, I didn't see any meaningful statements that
>> > would refute the approach in Garzik's BIP-100.
>> >
>> > Maybe a better way to say this is,
>> >
>> > Work with Jeff Garzik (which I am sure you are already having such
>> > discussions in private) as well as the list discussions,
>> > Move forward on BIP-100 with Garzik and other developers (not such a
>> > bad plan really) and don't get caught up in XT.  (If you feel you can
>> > develop XT further, that is your thing but it would perhaps make you
>> > lose focus, work together with other developers.)
>> >
>> > Relax into the process.  Things will be ok.
>> >
>> > Respectfully,
>> >
>> > - -O
>> >
>> > On 06/22/2015 11:18 AM, Gavin Andresen wrote:
>> >> I promised to write a BIP after I'd implemented
>> >> increase-the-maximum-block-size code, so here it is. It also lives
>> >> at:
>> >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
>> >>
>> >>  I don't expect any proposal to please everybody; there are
>> >> unavoidable tradeoffs to increasing the maximum block size. I
>> >> prioritize implementation simplicity -- it is hard to write
>> >> consensus-critical code, so simpler is better.
>> >>
>> >>
>> >>
>> >>
>> >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
>> >> <gavinandresen@gmail.com <mailto:gavinandresen@gmail.com>> Status:
>> >> Draft Type: Standards Track Created: 2015-06-22
>> >>
>> >> ==Abstract==
>> >>
>> >> This BIP proposes replacing the fixed one megabyte maximum block
>> >> size with a maximum size that grows over time at a predictable
>> >> rate.
>> >>
>> >> ==Motivation==
>> >>
>> >> Transaction volume on the Bitcoin network has been growing, and
>> >> will soon reach the one-megabyte-every-ten-minutes limit imposed by
>> >> the one megabyte maximum block size. Increasing the maximum size
>> >> reduces the impact of that limit on Bitcoin adoption and growth.
>> >>
>> >> ==Specification==
>> >>
>> >> After deployment on the network (see the Deployment section for
>> >> details), the maximum allowed size of a block on the main network
>> >> shall be calculated based on the timestamp in the block header.
>> >>
>> >> The maximum size shall be 8,000,000 bytes at a timestamp of
>> >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
>> >> every 63,072,000 seconds (two years, ignoring leap years), until
>> >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
>> >> blocks in between doublings will increase linearly based on the
>> >> block's timestamp. The maximum size of blocks after 2036-01-06
>> >> 00:00:00 UTC shall be 8,192,000,000 bytes.
>> >>
>> >> Expressed in pseudo-code, using integer math:
>> >>
>> >> function max_block_size(block_timestamp):
>> >>
>> >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =
>> >> 8000000 if block_timestamp >= time_start+time_double*10 return
>> >> size_start * 2^10
>> >>
>> >> // Piecewise-linear-between-doublings growth: time_delta =
>> >> block_timestamp - t_start doublings = time_delta / time_double
>> >> remainder = time_delta % time_double interpolate = (size_start *
>> >> 2^doublings * remainder) / time_double max_size = size_start *
>> >> 2^doublings + interpolate
>> >>
>> >> return max_size
>> >>
>> >> ==Deployment==
>> >>
>> >> Deployment shall be controlled by hash-power supermajority vote
>> >> (similar to the technique used in BIP34), but the earliest possible
>> >> activation time is 2016-01-11 00:00:00 UTC.
>> >>
>> >> Activation is achieved when 750 of 1,000 consecutive blocks in the
>> >> best chain have a version number with bits 3 and 14 set (0x20000004
>> >> in hex). The activation time will be the timestamp of the 750'th
>> >> block plus a two week (1,209,600 second) grace period to give any
>> >> remaining miners or services time to upgrade to support larger
>> >> blocks. If a supermajority is achieved more than two weeks before
>> >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
>> >> 00:00:00 UTC.
>> >>
>> >> Block version numbers are used only for activation; once activation
>> >> is achieved, the maximum block size shall be as described in the
>> >> specification section, regardless of the version number of the
>> >> block.
>> >>
>> >>
>> >> ==Rationale==
>> >>
>> >> The initial size of 8,000,000 bytes was chosen after testing the
>> >> current reference implementation code with larger block sizes and
>> >> receiving feedback from miners stuck behind bandwidth-constrained
>> >> networks (in particular, Chinese miners behind the Great Firewall
>> >> of China).
>> >>
>> >> The doubling interval was chosen based on long-term growth trends
>> >> for CPU power, storage, and Internet bandwidth. The 20-year limit
>> >> was chosen because exponential growth cannot continue forever.
>> >>
>> >> Calculations are based on timestamps and not blockchain height
>> >> because a timestamp is part of every block's header. This allows
>> >> implementations to know a block's maximum size after they have
>> >> downloaded it's header, but before downloading any transactions.
>> >>
>> >> The deployment plan is taken from Jeff Garzik's proposed BIP100
>> >> block size increase, and is designed to give miners, merchants,
>> >> and full-node-running-end-users sufficient time to upgrade to
>> >> software that supports bigger blocks. A 75% supermajority was
>> >> chosen so that one large mining pool does not have effective veto
>> >> power over a blocksize increase. The version number scheme is
>> >> designed to be compatible with Pieter's Wuille's proposed "Version
>> >> bits" BIP.
>> >>
>> >> TODO: summarize objections/arguments from
>> >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
>> >>
>> >> TODO: describe other proposals and their advantages/disadvantages
>> >> over this proposal.
>> >>
>> >>
>> >> ==Compatibility==
>> >>
>> >> This is a hard-forking change to the Bitcoin protocol; anybody
>> >> running code that fully validates blocks must upgrade before the
>> >> activation time or they will risk rejecting a chain containing
>> >> larger-than-one-megabyte blocks.
>> >>
>> >> Simplified Payment Verification software is not affected, unless
>> >> it makes assumptions about the maximum depth of a transaction's
>> >> merkle branch based on the minimum size of a transaction and the
>> >> maximum block size.
>> >>
>> >> ==Implementation==
>> >>
>> >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
>> >>
>> >>
>> >>
>> >> _______________________________________________ bitcoin-dev mailing
>> >> list bitcoin-dev@lists.linuxfoundation.org
>> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >>
>> >
>> > - --
>> > http://abis.io ~
>> > "a protocol concept to enable decentralization
>> > and expansion of a giving economy, and a new social good"
>> > https://keybase.io/odinn
>> > -----BEGIN PGP SIGNATURE-----
>> > Version: GnuPG v1
>> >
>> > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
>> > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
>> > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
>> > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
>> > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
>> > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
>> > =ft62
>> > -----END PGP SIGNATURE-----
>> > _______________________________________________
>> > 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: 16334 bytes --]

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Gavin Andresen]

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

This BIP has been assigned number 101 by the BIP editor. I plan on filling
in the TODOs and will submit it as a pull request to the BIP repository
today.

> Title: Increase Maximum Block Size

-- 
--
Gavin Andresen

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Pindar Wong]

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

Dear Gavin,

Thank you for your kind consideration and for working within the
established BIP process.

http://cointelegraph.com/news/114657/chinese-mining-pools-call-for-consensus-refuse-switch-to-bitcoin-xt

p.


On Wed, Jun 24, 2015 at 9:44 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:

> This BIP has been assigned number 101 by the BIP editor. I plan on filling
> in the TODOs and will submit it as a pull request to the BIP repository
> today.
>
> > Title: Increase Maximum Block Size
>
> --
> --
> Gavin Andresen
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Gareth Williams]

On 24 June 2015 1:49:51 PM AEST, Jeff Garzik <jgarzik@gmail.com> wrote:
>Miners can collude today to lower the block size limit.

Of course they can. What, then, is the need for BIP100's hard-limit voting mechanism?

You only need consensus rules to enforce block size limits if you're enforcing them _against_ miners. Which may be a perfectly valid thing to do (if your threat model includes, for example, the possibility that large miners deliberately create large blocks to gain an advantage over small miners.) But BIP100 doesn't address that anyway. 

Wouldn't it be safer for consensus to get behind Gavin's simpler 8MB->8GB hard-limit growth curve*, and then encourage miners to enforce a soft limit below that, agreed through a voting mechanism? The later can be implemented at any time without consensus changes -- nobody can prevent miners from coordinating the max block size they'll build on anyway.

* but with a safer "supermajority" than 75% please :)
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Adam Back]

Note Jeff's proposal and Greg Maxwell's flexcap proposals also have a
growth limiter as a hard-cap and a mechanism for influencing a dynamic
cap within that envelope.

The hard-cap serves the purpose of a safety limit in case our
understanding about the economics, incentives or game-theory is wrong
worst case.

More comments to follow.

Adam


On 25 June 2015 at 15:50, Gareth Williams <gacrux@gmail.com> wrote:
> On 24 June 2015 1:49:51 PM AEST, Jeff Garzik <jgarzik@gmail.com> wrote:
>>Miners can collude today to lower the block size limit.
>
> Of course they can. What, then, is the need for BIP100's hard-limit voting mechanism?
>
> You only need consensus rules to enforce block size limits if you're enforcing them _against_ miners. Which may be a perfectly valid thing to do (if your threat model includes, for example, the possibility that large miners deliberately create large blocks to gain an advantage over small miners.) But BIP100 doesn't address that anyway.
>
> Wouldn't it be safer for consensus to get behind Gavin's simpler 8MB->8GB hard-limit growth curve*, and then encourage miners to enforce a soft limit below that, agreed through a voting mechanism? The later can be implemented at any time without consensus changes -- nobody can prevent miners from coordinating the max block size they'll build on anyway.
>
> * but with a safer "supermajority" than 75% please :)
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Tier Nolan]

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

On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace.org> wrote:

> The hard-cap serves the purpose of a safety limit in case our
> understanding about the economics, incentives or game-theory is wrong
> worst case.
>

True.

BIP 100 and 101 could be combined.  Would that increase consensus?

- Miner vote threshold reached
- Wait notice period or until earliest start time
- Block size default target set to 1 MB
- Soft limit set to 1MB
- Hard limit set to 8MB + double every 2 years
- Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB
minimum)

Block size updates could be aligned with the difficulty setting and based
on the last 2016 blocks.

Miners could leave the 1MB limit in place initially.  The vote is to get
the option to increase the block size.

Legacy clients would remain in the network until >80% of miners vote to
raise the limit and a miner produces a >1MB block.

If the growth rate over-estimates hardware improvements, the devs could add
a limit into the core client.  If they give notice and enough users update,
then miners would have to accept it.

The block size becomes min(miner's vote, core devs).  Even if 4 years
notice is given, blocks would only be 4X optimal.

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Will]

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

Make the default soft vote = to previous max block size * 1.09 every 12k (or whatever mirrors the hard cap growth rate) and don't allow voting to lower the soft limit and I think you have something.

You need a default that grows because most miners are lazy and will do squirrelly things like hard code 8000000 as their vote permanently.  

Make the lazy miners' default choice grow at the hard cap growth rate and you should be ok if you want voting.

> On Jun 26, 2015, at 9:47 AM, Tier Nolan <tier.nolan@gmail.com> wrote:
> 
>> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace.org> wrote:
>> The hard-cap serves the purpose of a safety limit in case our
>> understanding about the economics, incentives or game-theory is wrong
>> worst case.
> 
> True.
> 
> BIP 100 and 101 could be combined.  Would that increase consensus?
> 
> - Miner vote threshold reached
> - Wait notice period or until earliest start time
> - Block size default target set to 1 MB
> - Soft limit set to 1MB
> - Hard limit set to 8MB + double every 2 years
> - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB minimum)
> 
> Block size updates could be aligned with the difficulty setting and based on the last 2016 blocks.
> 
> Miners could leave the 1MB limit in place initially.  The vote is to get the option to increase the block size.
> 
> Legacy clients would remain in the network until >80% of miners vote to raise the limit and a miner produces a >1MB block.
> 
> If the growth rate over-estimates hardware improvements, the devs could add a limit into the core client.  If they give notice and enough users update, then miners would have to accept it.
> 
> The block size becomes min(miner's vote, core devs).  Even if 4 years notice is given, blocks would only be 4X optimal.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Gavin Andresen]

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

On Fri, Jun 26, 2015 at 11:13 AM, Will <will.madden@novauri.com> wrote:

> Make the lazy miners' default choice grow at the hard cap growth rate and
> you should be ok if you want voting.


I think the default block size is an orthogonal issue to the max block size.

HOWEVER: I think changing the default 'target' block size from the current,
fixed 750K to the average of the size of the last N blocks would have some
nice properties. It is policy-neutral (we should get out of the business of
deciding the right block size and let the miners who care drive block size
up or down) and if there are a significant proportion of lazy miners going
with defaults it gives the system a healthy "fee pressure."

-- 
--
Gavin Andresen

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Will]

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

Moving averages have upsides and downsides vs fixed growth.  Moving averages are backwards looking and don't handle seasonalities or unanticipated increases in demand very well.

Think "Black Friday" or the horribly named "Cyber 
Monday" in retail or market hysteria where millions of noobs jump into or out of bitcoin.

If you want to create fee pressure I think this can be done, but I would keep both of these in mind before choosing a value for N.  Adjustments would need to be frequent and nimble enough to handle seasonalities and other unanticipated outliers.

> On Jun 26, 2015, at 1:39 PM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> 
>> On Fri, Jun 26, 2015 at 11:13 AM, Will <will.madden@novauri.com> wrote:
>> Make the lazy miners' default choice grow at the hard cap growth rate and you should be ok if you want voting.
> 
> I think the default block size is an orthogonal issue to the max block size.
> 
> HOWEVER: I think changing the default 'target' block size from the current, fixed 750K to the average of the size of the last N blocks would have some nice properties. It is policy-neutral (we should get out of the business of deciding the right block size and let the miners who care drive block size up or down) and if there are a significant proportion of lazy miners going with defaults it gives the system a healthy "fee pressure."
> 
> -- 
> --
> Gavin Andresen

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[odinn]

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

(My replies below)

On 06/26/2015 06:47 AM, Tier Nolan wrote:
> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace.org 
> <mailto:adam@cypherspace.org>> wrote:
> 
> The hard-cap serves the purpose of a safety limit in case our 
> understanding about the economics, incentives or game-theory is
> wrong worst case.
> 
> 
> True.

Yep.

> 
> BIP 100 and 101 could be combined.  Would that increase consensus?

Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100
is a better alternative to Gavin's proposal(s), but that I didn't
think that this should be taken to mean that I am saying one thing is
"superior" to Gavin's work, rather, I emphasized that Gavin work with
Jeff and Adam.

At least, at this stage the things are in a BIP process.

If the BIP 100 and BIP 101 would be combined, what would that look
like on paper?

> 
> - Miner vote threshold reached - Wait notice period or until
> earliest start time - Block size default target set to 1 MB - Soft
> limit set to 1MB - Hard limit set to 8MB + double every 2 years -
> Miner vote to decide soft limit (lowest size ignoring bottom 20%
> but 1MB minimum)
> 
> Block size updates could be aligned with the difficulty setting
> and based on the last 2016 blocks.
> 
> Miners could leave the 1MB limit in place initially.  The vote is
> to get the option to increase the block size.
> 
> Legacy clients would remain in the network until >80% of miners
> vote to raise the limit and a miner produces a >1MB block.
> 
> If the growth rate over-estimates hardware improvements, the devs
> could add a limit into the core client.  If they give notice and
> enough users update, then miners would have to accept it.
> 
> The block size becomes min(miner's vote, core devs).  Even if 4
> years notice is given, blocks would only be 4X optimal.
> 
> 
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev@lists.linuxfoundation.org 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb
hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC
5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP
wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH
YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ
0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog=
=rtTH
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Tier Nolan]

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

One of the comments made by the mining pools is that they won't run XT
because it is "experimental".

Has there been any consideration to making available a version of XT with
only the blocksize changes?

The least "experimental" version would be one that makes the absolute
minimum changes to core.

The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip
changes.  This saves creating a new function.

Without the consensus measuring code, the patch would be even easier.
Satoshi's proposal was just a block height comparison (a year in advance).

The state storing code is also another complication.  If the standard
"counting" upgrade system was used, then no state would need to be stored
in the database.

On Wed, Jul 1, 2015 at 11:49 PM, odinn <odinn.cyberguerrilla@riseup.net>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> (My replies below)
>
> On 06/26/2015 06:47 AM, Tier Nolan wrote:
> > On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace.org
> > <mailto:adam@cypherspace.org>> wrote:
> >
> > The hard-cap serves the purpose of a safety limit in case our
> > understanding about the economics, incentives or game-theory is
> > wrong worst case.
> >
> >
> > True.
>
> Yep.
>
> >
> > BIP 100 and 101 could be combined.  Would that increase consensus?
>
> Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100
> is a better alternative to Gavin's proposal(s), but that I didn't
> think that this should be taken to mean that I am saying one thing is
> "superior" to Gavin's work, rather, I emphasized that Gavin work with
> Jeff and Adam.
>
> At least, at this stage the things are in a BIP process.
>
> If the BIP 100 and BIP 101 would be combined, what would that look
> like on paper?
>
> >
> > - Miner vote threshold reached - Wait notice period or until
> > earliest start time - Block size default target set to 1 MB - Soft
> > limit set to 1MB - Hard limit set to 8MB + double every 2 years -
> > Miner vote to decide soft limit (lowest size ignoring bottom 20%
> > but 1MB minimum)
> >
> > Block size updates could be aligned with the difficulty setting
> > and based on the last 2016 blocks.
> >
> > Miners could leave the 1MB limit in place initially.  The vote is
> > to get the option to increase the block size.
> >
> > Legacy clients would remain in the network until >80% of miners
> > vote to raise the limit and a miner produces a >1MB block.
> >
> > If the growth rate over-estimates hardware improvements, the devs
> > could add a limit into the core client.  If they give notice and
> > enough users update, then miners would have to accept it.
> >
> > The block size becomes min(miner's vote, core devs).  Even if 4
> > years notice is given, blocks would only be 4X optimal.
> >
> >
> > _______________________________________________ bitcoin-dev mailing
> > list bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> - --
> http://abis.io ~
> "a protocol concept to enable decentralization
> and expansion of a giving economy, and a new social good"
> https://keybase.io/odinn
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb
> hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC
> 5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP
> wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH
> YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ
> 0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog=
> =rtTH
> -----END PGP SIGNATURE-----
>

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Clément Elbaz]

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

The "only bigblock" patch you want is actually available here :
https://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks

Le lun. 17 août 2015 à 15:16, Tier Nolan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> a écrit :

> One of the comments made by the mining pools is that they won't run XT
> because it is "experimental".
>
> Has there been any consideration to making available a version of XT with
> only the blocksize changes?
>
> The least "experimental" version would be one that makes the absolute
> minimum changes to core.
>
> The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip
> changes.  This saves creating a new function.
>
> Without the consensus measuring code, the patch would be even easier.
> Satoshi's proposal was just a block height comparison (a year in advance).
>
> The state storing code is also another complication.  If the standard
> "counting" upgrade system was used, then no state would need to be stored
> in the database.
>
> On Wed, Jul 1, 2015 at 11:49 PM, odinn <odinn.cyberguerrilla@riseup.net>
> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> (My replies below)
>>
>> On 06/26/2015 06:47 AM, Tier Nolan wrote:
>> > On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace.org
>> > <mailto:adam@cypherspace.org>> wrote:
>> >
>> > The hard-cap serves the purpose of a safety limit in case our
>> > understanding about the economics, incentives or game-theory is
>> > wrong worst case.
>> >
>> >
>> > True.
>>
>> Yep.
>>
>> >
>> > BIP 100 and 101 could be combined.  Would that increase consensus?
>>
>> Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100
>> is a better alternative to Gavin's proposal(s), but that I didn't
>> think that this should be taken to mean that I am saying one thing is
>> "superior" to Gavin's work, rather, I emphasized that Gavin work with
>> Jeff and Adam.
>>
>> At least, at this stage the things are in a BIP process.
>>
>> If the BIP 100 and BIP 101 would be combined, what would that look
>> like on paper?
>>
>> >
>> > - Miner vote threshold reached - Wait notice period or until
>> > earliest start time - Block size default target set to 1 MB - Soft
>> > limit set to 1MB - Hard limit set to 8MB + double every 2 years -
>> > Miner vote to decide soft limit (lowest size ignoring bottom 20%
>> > but 1MB minimum)
>> >
>> > Block size updates could be aligned with the difficulty setting
>> > and based on the last 2016 blocks.
>> >
>> > Miners could leave the 1MB limit in place initially.  The vote is
>> > to get the option to increase the block size.
>> >
>> > Legacy clients would remain in the network until >80% of miners
>> > vote to raise the limit and a miner produces a >1MB block.
>> >
>> > If the growth rate over-estimates hardware improvements, the devs
>> > could add a limit into the core client.  If they give notice and
>> > enough users update, then miners would have to accept it.
>> >
>> > The block size becomes min(miner's vote, core devs).  Even if 4
>> > years notice is given, blocks would only be 4X optimal.
>> >
>> >
>> > _______________________________________________ bitcoin-dev mailing
>> > list bitcoin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>> - --
>> http://abis.io ~
>> "a protocol concept to enable decentralization
>> and expansion of a giving economy, and a new social good"
>> https://keybase.io/odinn
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb
>> hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC
>> 5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP
>> wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH
>> YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ
>> 0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog=
>> =rtTH
>> -----END PGP SIGNATURE-----
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[odinn]

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

Tier ~

I don't think the XT author(s) are going to do what you are
describing.  Their recent release, at
https://github.com/bitcoinxt/bitcoinxt/blob/0.11A/README.md
doesn't show any sign of moving toward a version which would be
"increasing consensus." Instead, they ignore any meaningful process
and, as I have recently indicated, have created somthing which
"sidetrack(s) real discussion necessary to resolve the issues so as to
achieve some level of consensus in block size debates."

That doesn't rule out that the BIP authors can't work together and
create something meaningful and useful, though.  As I stated before,

"In my past message(s), I've suggested that Jeff's BIP 100
is a better alternative to Gavin's proposal(s), but that I didn't
think that this should be taken to mean that I am saying one thing is
"superior" to Gavin's work, rather, I emphasized that Gavin work with
Jeff and Adam."

I am also looking forward to seeing some visualizations or graphs of
the miner votes going on right now on BIP 100 and BIP 101, for example.

Regarding XT, my statement is simple:

"Do not download this loathsome XT thing. Cast it back into the fires
from whence it came."

- - Odinn



On 08/17/2015 06:15 AM, Tier Nolan via bitcoin-dev wrote:
> One of the comments made by the mining pools is that they won't run
> XT because it is "experimental".
> 
> Has there been any consideration to making available a version of
> XT with only the blocksize changes?
> 
> The least "experimental" version would be one that makes the
> absolute minimum changes to core.
> 
> The MAX_BLOCK_SIZE parameter could be overwritten whenever the
> longest tip changes.  This saves creating a new function.
> 
> Without the consensus measuring code, the patch would be even
> easier. Satoshi's proposal was just a block height comparison (a
> year in advance).
> 
> The state storing code is also another complication.  If the
> standard "counting" upgrade system was used, then no state would
> need to be stored in the database.
> 
> On Wed, Jul 1, 2015 at 11:49 PM, odinn
> <odinn.cyberguerrilla@riseup.net 
> <mailto:odinn.cyberguerrilla@riseup.net>> wrote:
> 
> (My replies below)
> 
> On 06/26/2015 06:47 AM, Tier Nolan wrote:
>> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam@cypherspace.org
>> <mailto:adam@cypherspace.org> <mailto:adam@cypherspace.org
>> <mailto:adam@cypherspace.org>>> wrote:
> 
>> The hard-cap serves the purpose of a safety limit in case our 
>> understanding about the economics, incentives or game-theory is 
>> wrong worst case.
> 
> 
>> True.
> 
> Yep.
> 
> 
>> BIP 100 and 101 could be combined.  Would that increase
>> consensus?
> 
> Possibly ~ In my past message(s), I've suggested that Jeff's BIP
> 100 is a better alternative to Gavin's proposal(s), but that I
> didn't think that this should be taken to mean that I am saying one
> thing is "superior" to Gavin's work, rather, I emphasized that
> Gavin work with Jeff and Adam.
> 
> At least, at this stage the things are in a BIP process.
> 
> If the BIP 100 and BIP 101 would be combined, what would that look 
> like on paper?
> 
> 
>> - Miner vote threshold reached - Wait notice period or until 
>> earliest start time - Block size default target set to 1 MB -
>> Soft limit set to 1MB - Hard limit set to 8MB + double every 2
>> years - Miner vote to decide soft limit (lowest size ignoring
>> bottom 20% but 1MB minimum)
> 
>> Block size updates could be aligned with the difficulty setting 
>> and based on the last 2016 blocks.
> 
>> Miners could leave the 1MB limit in place initially.  The vote
>> is to get the option to increase the block size.
> 
>> Legacy clients would remain in the network until >80% of miners 
>> vote to raise the limit and a miner produces a >1MB block.
> 
>> If the growth rate over-estimates hardware improvements, the
>> devs could add a limit into the core client.  If they give notice
>> and enough users update, then miners would have to accept it.
> 
>> The block size becomes min(miner's vote, core devs).  Even if 4 
>> years notice is given, blocks would only be 4X optimal.
> 
> 
>> _______________________________________________ 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
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJV0/vrAAoJEGxwq/inSG8CUSQH/0rX9j1f/tSYYxUeD8ktLm6b
WkB26eNEIEwpTNGwjjYbfVou29ZGGkp58P2jv7S52RekTS3dQshjj5wgFdXE1IX4
HhgMVEnyX2Hgooeu9O32HHfjSLxgxkAozibu0NM4NnRfFQU/DTSz5+H1rABUKnl3
k2LWkhoyX517/x1GUPiGGweGpOTSwC/6BxuhCUjx1vuL9Bpp93gWRf9cRlf99Xn3
GaaXCvGFeL/VT2P9uwUWLLuOinEdvx+AGScIfdhNuN6JhN3KFY6dHXSCYTvNtNg/
XEZWNeyF3nu5lCtNQCryobDobhVdhSsv6FIWgmEdS7Ubh30jv1oWbR1wELWFEDc=
=iY5p
-----END PGP SIGNATURE-----

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Jorge Timón]

On Fri, Jun 26, 2015 at 3:47 PM, Tier Nolan <tier.nolan@gmail.com> wrote:
> - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB
> minimum)

I don't think is all that interesting to make miners vote on lower
limit. Say the community wants to reduce the size to limit mining
centralization, it's not unthinkable that the hashrate majority (which
may have to face more competition or harvest less transactions after
the change) may oppose to that and then the community is forced to
deploy an anti-miner's hardfork (maybe even asic-reset hardfork?)
instead of a softfork.
Yes, uncontroversial sofforks are easier and less risky to deploy than
uncontroversial hardforks, but anti-miner hardforks are not.
Not only I don't think it's a good idea for miners to vote on the
block size (which is there to control them), I don't even buy the
assumption that "we can always just softfork a smallwer size later".
If you give something to miners they may not want to give it back later.
We could hardfork to 42 M supply and then "just softfork back to 21 M", right?
Or what's the same, we could "just softfork supply to 15 M". Such a
change would be clearly controversial among miners, so it wouldn't be
an uncontroversial softfork anymore. Some of these cases are discussed
in BIP99.

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Carsten Otto]

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

Dear all,

On Mon, Jun 22, 2015 at 02:18:19PM -0400, Gavin Andresen wrote:
> I promised to write a BIP after I'd implemented
> increase-the-maximum-block-size code, so here it is. It also lives at:
> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki

The URL is dead, and the BIP moved here:
https://github.com/gavinandresen/bips/blob/blocksize/bip-0101.mediawiki

Corresponding Pull Request:
https://github.com/bitcoin/bips/pull/163/

Best regards,
Dr. Carsten Otto
-- 
andrena objects ag
Büro Frankfurt
Clemensstr. 8
60487 Frankfurt

Tel: +49 (0) 69 977 860 38
Fax: +49 (0) 69 977 860 39
http://www.andrena.de

Vorstand: Hagen Buchwald, Matthias Grund, Dr. Dieter Kuhn
Aufsichtsratsvorsitzender: Rolf Hetzelberger

Sitz der Gesellschaft: Karlsruhe
Amtsgericht Mannheim, HRB 109694
USt-IdNr. DE174314824

Bitte beachten Sie auch unsere anstehenden Veranstaltungen:
http://www.andrena.de/events

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Jean-Paul Kogelman]

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



On Jun 22, 2015, at 11:18 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:

The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blocks in between doublings will increase linearly based on the block's timestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.
 
Since it's possible that block timestamps aren't chronological in order, what would happen if a block following a size increase trigger is back in the past before the size increase? Would that block have a lower size restriction again? Would using block height not be a more stable number to work with?

jp

[-- Attachment #2.1: Type: text/html, Size: 1206 bytes --]

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Tier Nolan]

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

On Mon, Jun 22, 2015 at 8:32 PM, Jean-Paul Kogelman <jeanpaulkogelman@me.com
> wrote:

>
> Since it's possible that block timestamps aren't chronological in order,
> what would happen if a block following a size increase trigger is back in
> the past before the size increase? Would that block have a lower size
> restriction again? Would using block height not be a more stable number to
> work with?
>

The activation or not rule is purely timestamp based.  Blocks with a
timestamp less than 1452470400 have a limit of 1MB.  There could be an 8MB
block followed by a block that is limited to 1MB.

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Peter Todd]

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

On Mon, Jun 22, 2015 at 07:32:22PM +0000, Jean-Paul Kogelman wrote:
> 
> 
> On Jun 22, 2015, at 11:18 AM, Gavin Andresen <gavinandresen@gmail.com> wrote:
> 
> The maximum size shall be 8,000,000 bytes at a timestamp of 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double every 63,072,000 seconds (two years, ignoring leap years), until 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of blocks in between doublings will increase linearly based on the block's timestamp. The maximum size of blocks after 2036-01-06 00:00:00 UTC shall be 8,192,000,000 bytes.
>  
> Since it's possible that block timestamps aren't chronological in order, what would happen if a block following a size increase trigger is back in the past before the size increase? Would that block have a lower size restriction again? Would using block height not be a more stable number to work with?

In the nVersion bits proposal that I co-authored we solved that issue by
comparing the timestamp against the median time, which is guaranteed by
the protocol rules to monotonically advance.

-- 
'peter'[:-1]@petertodd.org
0000000000000000138b2613c026e0ed1dbf6f8f193f1c3115bdf540dc22fbf6

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Stephen Morse]

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

> In the nVersion bits proposal that I co-authored we solved that issue by
> comparing the timestamp against the median time, which is guaranteed by
> the protocol rules to monotonically advance.
>

I'm also a fan of using the median time to ensure that there is a clear
point where the protocol change starts. Something like "blocks only allow
the larger block size if the associate pindex has pindex->GetMedianTimePast()
after midnight 11 Jan 2016 and where a supermajority showing support for
the fork has previously been reached".

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Ross Nicoll]

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

Potentially daft question, why not use a minimum height? Yes, it's 
imprecise, but over an extended period of time they're good enough IMHO.

I'd have to do more careful calculations to confirm, but block 388,000 
should be about right as a minimum.

Ross

On 22/06/2015 22:04, Stephen Morse wrote:
>
>     In the nVersion bits proposal that I co-authored we solved that
>     issue by
>     comparing the timestamp against the median time, which is
>     guaranteed by
>     the protocol rules to monotonically advance.
>
>
> I'm also a fan of using the median time to ensure that there is a 
> clear point where the protocol change starts. Something like "blocks 
> only allow the larger block size if the associate pindex has 
> pindex->GetMedianTimePast() after midnight 11 Jan 2016 and where a 
> supermajority showing support for the fork has previously been reached".
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Jorge Timón]

On Mon, Jun 22, 2015 at 11:32 PM, Ross Nicoll <jrn@jrn.me.uk> wrote:
> Potentially daft question, why not use a minimum height? Yes, it's
> imprecise, but over an extended period of time they're good enough IMHO.
>
> I'd have to do more careful calculations to confirm, but block 388,000
> should be about right as a minimum.

BIP99 (still a draft too) currently recommends a minimum height plus
95% mining upgrade confirmation (aka "miner voting") after that for
uncontroversial hardforks:

https://github.com/jtimon/bips/blob/bip-forks/bip-0099.mediawiki#Uncontroversial_hardforks
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009837.html

But general hardfork activation discussion is still inconclusive in
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009731.html

The code for the example uncontroversial hardfork proposed in bip99 is
at: https://github.com/bitcoin/bitcoin/compare/0.11...jtimon:hardfork-timewarp-0.11
But I haven't created a PR for either the code or the bip yet.

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Gavin Andresen]

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

On Mon, Jun 22, 2015 at 4:54 PM, Peter Todd <pete@petertodd.org> wrote:

> > Since it's possible that block timestamps aren't chronological in order,
> what would happen if a block following a size increase trigger is back in
> the past before the size increase? Would that block have a lower size
> restriction again? Would using block height not be a more stable number to
> work with?
>
> In the nVersion bits proposal that I co-authored we solved that issue by
> comparing the timestamp against the median time, which is guaranteed by
> the protocol rules to monotonically advance.
>

That complicates the implementation quite a bit.

I mostly implemented a variant that replaced the MAX_BLOCK_SIZE constant
with a function that took both a timestamp and a block height, and there
are several places in the current reference implementation where digging
out the block height (or, worse, calculating the median timestamp for the
block) would involve changing quite a few functions in the call-chain or
acquiring the cs_main lock to consult the current best chain.

-- 
--
Gavin Andresen

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Patrick Strateman]

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

If you truly have a consensus then the rational behavior is to
permanently change the nodes behavior after the trigger.

On 06/22/2015 02:21 PM, Gavin Andresen wrote:
> On Mon, Jun 22, 2015 at 4:54 PM, Peter Todd <pete@petertodd.org
> <mailto:pete@petertodd.org>> wrote:
>
>     > Since it's possible that block timestamps aren't chronological
>     in order, what would happen if a block following a size increase
>     trigger is back in the past before the size increase? Would that
>     block have a lower size restriction again? Would using block
>     height not be a more stable number to work with?
>
>     In the nVersion bits proposal that I co-authored we solved that
>     issue by
>     comparing the timestamp against the median time, which is
>     guaranteed by
>     the protocol rules to monotonically advance.
>
>
> That complicates the implementation quite a bit.
>
> I mostly implemented a variant that replaced the MAX_BLOCK_SIZE
> constant with a function that took both a timestamp and a block
> height, and there are several places in the current reference
> implementation where digging out the block height (or, worse,
> calculating the median timestamp for the block) would involve changing
> quite a few functions in the call-chain or acquiring the cs_main lock
> to consult the current best chain.
>
> -- 
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Tier Nolan]

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

On Mon, Jun 22, 2015 at 10:21 PM, Gavin Andresen <gavinandresen@gmail.com>
wrote:

> That complicates the implementation quite a bit.
>

I think trying to keep the number of rules that require context to a
minimum is a good idea.  As pointed out in the BIP, using only the
timestamp of the block means that the block limit can be determined purely
from the block header.

I don't think there is much issue with having a 1MB block following an 8MB
block during the activation.

This is inherent in using the timestamps.  It occurs for every block that
has a timestamp lower than its parent, but to a lesser degree.

When fees are the main source of income, it does create a slight incentive
to use higher timestamps, but that is probably not massive, since it is 2
hours out of the 2 year doubling time.

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Ross Nicoll]

Also, before that's turned into "8MB blocks are infeasible", my presumption is that blocks are not expected to jump suddenly to 8MB, and that most will have time to ramp up storage and bandwidth.

The point about not outright replacing existing test data is the more critical one, anyway, although in retrospect we could simply add spam transactions on top of existing transactions.

Ross

On 23 Jun 2015 08:35, Ross Nicoll <jrn@jrn.me.uk> wrote:

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Raystonn]

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Mark Friedenbach]

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

They do so by not building on larger blocks
On Jun 23, 2015 9:31 PM, "Raystonn" <raystonn@hotmail.com> wrote:

> No, they can lower their own block sizes.  But they cannot currently lower
> the sizes of blocks mined by others.  That is not the same thing by any
> stretch of the imagination.
> On 23 Jun 2015 8:50 pm, Jeff Garzik <jgarzik@gmail.com> wrote:
>
> Miners can collude today to lower the block size limit.
>
> In fact, this largely happens already out of laziness - miners often
> follow the "soft" default limit set by Bitcoin Core, to the point where you
> can chart when miners upgrade to new software:
> http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block
>
>
>
> On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri.com>
> wrote:
>
> Here are refutations of the approach in BIP-100 here:
> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>
> To recap BIP-100:
>
> 1) Hard form to remove static 1MB block size limit
> 2) Add new floating block size limit set to 1MB
> 3) Historical 32MB message limit remains
> 4) Hard form on testnet 9/1/2015
> 5) Hard form on main 1/11/2016
> 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
> threshold by 90% of blocks
> 7) Limit increase or decrease may not exceed 2x in any one step
> 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
> scriptSig, e.g. "/BV8000000/" to vote for 8M.
> 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
> most common floor (minimum) is chosen.
>
> 8MB limits doubling just under every 2 years makes a static value grow
> in a predictable manner.
>
> BIP-100 makes a static value grow (or more importantly potentially
> shrink) in an unpredictable manner based on voting mechanics that are
> untested in this capacity in the bitcoin network.  Introducing a highly
> variable and untested dynamic into an already complex system is
> unnecessarily risky.
>
> For example, the largely arbitrary voting rules listed in 9 above can be
> gamed.  If I control pools or have affiliates involved in pools that
> mine slightly more than 20% of blocks, I could wait until block sizes
> are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
> "/BV5000001/" for the remaining 10%.  If others don't consistently vote
> for the same "/BV#/" value, vote too consistently and have their value
> thrown out as the top 20%, I could win the resize to half capacity
> "/BV5000001/" because it was the lowest repeated value not in the bottom
> 20%.
>
> I could use this to force an exodus to my sidechain/alt coin, or to
> choke out the bitcoin network.  A first improvement would be to only let
> BIP-100 raise the cap and not lower it, but if I can think of a
> vulnerability off the top of my head, there will be others on the other
> side of the equation that have not been thought of.  Why bother
> introducing a rube goldberg machine like voting when a simple 8mb cap
> with predictable growth gets the job done, potentially permanently?
>
>
> On 6/23/2015 9:43 PM, odinn wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > 1) Hard fork not (necessarily) needed
> > 2) See Garzik's BIP 100, better (this is not meant to say "superior to
> > your stuff," but rather simply to say, "Better you should work with
> > Garzik to implement BIP-100, that would be good")
> > 3) See points 1 and 2 above
> > 4) If still reading... changes should be (as you seem to have been
> > trying to lean towards)... lean towards gradual change; hence, changes
> > that would flow from this BIP would be better off oriented in a
> > process that dies not require the "way you have done it."
> >
> > You did address that, to be fair - in your TODO, this link:
> > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
> >
> > contained the following link:
> >
> > http://gavinandresen.ninja/bigger-blocks-another-way
> >
> > However, in reading that, I didn't see any meaningful statements that
> > would refute the approach in Garzik's BIP-100.
> >
> > Maybe a better way to say this is,
> >
> > Work with Jeff Garzik (which I am sure you are already having such
> > discussions in private) as well as the list discussions,
> > Move forward on BIP-100 with Garzik and other developers (not such a
> > bad plan really) and don't get caught up in XT.  (If you feel you can
> > develop XT further, that is your thing but it would perhaps make you
> > lose focus, work together with other developers.)
> >
> > Relax into the process.  Things will be ok.
> >
> > Respectfully,
> >
> > - -O
> >
> > On 06/22/2015 11:18 AM, Gavin Andresen wrote:
> >> I promised to write a BIP after I'd implemented
> >> increase-the-maximum-block-size code, so here it is. It also lives
> >> at:
> >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
> >>
> >>  I don't expect any proposal to please everybody; there are
> >> unavoidable tradeoffs to increasing the maximum block size. I
> >> prioritize implementation simplicity -- it is hard to write
> >> consensus-critical code, so simpler is better.
> >>
> >>
> >>
> >>
> >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
> >> <gavinandresen@gmail.com <mailto:gavinandresen@gmail.com>> Status:
> >> Draft Type: Standards Track Created: 2015-06-22
> >>
> >> ==Abstract==
> >>
> >> This BIP proposes replacing the fixed one megabyte maximum block
> >> size with a maximum size that grows over time at a predictable
> >> rate.
> >>
> >> ==Motivation==
> >>
> >> Transaction volume on the Bitcoin network has been growing, and
> >> will soon reach the one-megabyte-every-ten-minutes limit imposed by
> >> the one megabyte maximum block size. Increasing the maximum size
> >> reduces the impact of that limit on Bitcoin adoption and growth.
> >>
> >> ==Specification==
> >>
> >> After deployment on the network (see the Deployment section for
> >> details), the maximum allowed size of a block on the main network
> >> shall be calculated based on the timestamp in the block header.
> >>
> >> The maximum size shall be 8,000,000 bytes at a timestamp of
> >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
> >> every 63,072,000 seconds (two years, ignoring leap years), until
> >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
> >> blocks in between doublings will increase linearly based on the
> >> block's timestamp. The maximum size of blocks after 2036-01-06
> >> 00:00:00 UTC shall be 8,192,000,000 bytes.
> >>
> >> Expressed in pseudo-code, using integer math:
> >>
> >> function max_block_size(block_timestamp):
> >>
> >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =
> >> 8000000 if block_timestamp >= time_start+time_double*10 return
> >> size_start * 2^10
> >>
> >> // Piecewise-linear-between-doublings growth: time_delta =
> >> block_timestamp - t_start doublings = time_delta / time_double
> >> remainder = time_delta % time_double interpolate = (size_start *
> >> 2^doublings * remainder) / time_double max_size = size_start *
> >> 2^doublings + interpolate
> >>
> >> return max_size
> >>
> >> ==Deployment==
> >>
> >> Deployment shall be controlled by hash-power supermajority vote
> >> (similar to the technique used in BIP34), but the earliest possible
> >> activation time is 2016-01-11 00:00:00 UTC.
> >>
> >> Activation is achieved when 750 of 1,000 consecutive blocks in the
> >> best chain have a version number with bits 3 and 14 set (0x20000004
> >> in hex). The activation time will be the timestamp of the 750'th
> >> block plus a two week (1,209,600 second) grace period to give any
> >> remaining miners or services time to upgrade to support larger
> >> blocks. If a supermajority is achieved more than two weeks before
> >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
> >> 00:00:00 UTC.
> >>
> >> Block version numbers are used only for activation; once activation
> >> is achieved, the maximum block size shall be as described in the
> >> specification section, regardless of the version number of the
> >> block.
> >>
> >>
> >> ==Rationale==
> >>
> >> The initial size of 8,000,000 bytes was chosen after testing the
> >> current reference implementation code with larger block sizes and
> >> receiving feedback from miners stuck behind bandwidth-constrained
> >> networks (in particular, Chinese miners behind the Great Firewall
> >> of China).
> >>
> >> The doubling interval was chosen based on long-term growth trends
> >> for CPU power, storage, and Internet bandwidth. The 20-year limit
> >> was chosen because exponential growth cannot continue forever.
> >>
> >> Calculations are based on timestamps and not blockchain height
> >> because a timestamp is part of every block's header. This allows
> >> implementations to know a block's maximum size after they have
> >> downloaded it's header, but before downloading any transactions.
> >>
> >> The deployment plan is taken from Jeff Garzik's proposed BIP100
> >> block size increase, and is designed to give miners, merchants,
> >> and full-node-running-end-users sufficient time to upgrade to
> >> software that supports bigger blocks. A 75% supermajority was
> >> chosen so that one large mining pool does not have effective veto
> >> power over a blocksize increase. The version number scheme is
> >> designed to be compatible with Pieter's Wuille's proposed "Version
> >> bits" BIP.
> >>
> >> TODO: summarize objections/arguments from
> >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
> >>
> >> TODO: describe other proposals and their advantages/disadvantages
> >> over this proposal.
> >>
> >>
> >> ==Compatibility==
> >>
> >> This is a hard-forking change to the Bitcoin protocol; anybody
> >> running code that fully validates blocks must upgrade before the
> >> activation time or they will risk rejecting a chain containing
> >> larger-than-one-megabyte blocks.
> >>
> >> Simplified Payment Verification software is not affected, unless
> >> it makes assumptions about the maximum depth of a transaction's
> >> merkle branch based on the minimum size of a transaction and the
> >> maximum block size.
> >>
> >> ==Implementation==
> >>
> >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
> >>
> >>
> >>
> >> _______________________________________________ bitcoin-dev mailing
> >> list bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> > - --
> > http://abis.io ~
> > "a protocol concept to enable decentralization
> > and expansion of a giving economy, and a new social good"
> > https://keybase.io/odinn
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
> > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
> > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
> > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
> > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
> > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
> > =ft62
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > 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
>
>

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Roy Badami]

Or put another way, lowering the block size limit (or cancelling an
increase) is a soft fork.  Like all soft forks, a majority of the hash
power can force the soft fork to take place.

On Wed, Jun 24, 2015 at 10:05:42AM -0700, Mark Friedenbach wrote:
> They do so by not building on larger blocks
> On Jun 23, 2015 9:31 PM, "Raystonn" <raystonn@hotmail.com> wrote:
> 
> > No, they can lower their own block sizes.  But they cannot currently lower
> > the sizes of blocks mined by others.  That is not the same thing by any
> > stretch of the imagination.
> > On 23 Jun 2015 8:50 pm, Jeff Garzik <jgarzik@gmail.com> wrote:
> >
> > Miners can collude today to lower the block size limit.
> >
> > In fact, this largely happens already out of laziness - miners often
> > follow the "soft" default limit set by Bitcoin Core, to the point where you
> > can chart when miners upgrade to new software:
> > http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block
> >
> >
> >
> > On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri.com>
> > wrote:
> >
> > Here are refutations of the approach in BIP-100 here:
> > http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
> >
> > To recap BIP-100:
> >
> > 1) Hard form to remove static 1MB block size limit
> > 2) Add new floating block size limit set to 1MB
> > 3) Historical 32MB message limit remains
> > 4) Hard form on testnet 9/1/2015
> > 5) Hard form on main 1/11/2016
> > 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
> > threshold by 90% of blocks
> > 7) Limit increase or decrease may not exceed 2x in any one step
> > 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
> > scriptSig, e.g. "/BV8000000/" to vote for 8M.
> > 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
> > most common floor (minimum) is chosen.
> >
> > 8MB limits doubling just under every 2 years makes a static value grow
> > in a predictable manner.
> >
> > BIP-100 makes a static value grow (or more importantly potentially
> > shrink) in an unpredictable manner based on voting mechanics that are
> > untested in this capacity in the bitcoin network.  Introducing a highly
> > variable and untested dynamic into an already complex system is
> > unnecessarily risky.
> >
> > For example, the largely arbitrary voting rules listed in 9 above can be
> > gamed.  If I control pools or have affiliates involved in pools that
> > mine slightly more than 20% of blocks, I could wait until block sizes
> > are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
> > "/BV5000001/" for the remaining 10%.  If others don't consistently vote
> > for the same "/BV#/" value, vote too consistently and have their value
> > thrown out as the top 20%, I could win the resize to half capacity
> > "/BV5000001/" because it was the lowest repeated value not in the bottom
> > 20%.
> >
> > I could use this to force an exodus to my sidechain/alt coin, or to
> > choke out the bitcoin network.  A first improvement would be to only let
> > BIP-100 raise the cap and not lower it, but if I can think of a
> > vulnerability off the top of my head, there will be others on the other
> > side of the equation that have not been thought of.  Why bother
> > introducing a rube goldberg machine like voting when a simple 8mb cap
> > with predictable growth gets the job done, potentially permanently?
> >
> >
> > On 6/23/2015 9:43 PM, odinn wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > 1) Hard fork not (necessarily) needed
> > > 2) See Garzik's BIP 100, better (this is not meant to say "superior to
> > > your stuff," but rather simply to say, "Better you should work with
> > > Garzik to implement BIP-100, that would be good")
> > > 3) See points 1 and 2 above
> > > 4) If still reading... changes should be (as you seem to have been
> > > trying to lean towards)... lean towards gradual change; hence, changes
> > > that would flow from this BIP would be better off oriented in a
> > > process that dies not require the "way you have done it."
> > >
> > > You did address that, to be fair - in your TODO, this link:
> > > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
> > >
> > > contained the following link:
> > >
> > > http://gavinandresen.ninja/bigger-blocks-another-way
> > >
> > > However, in reading that, I didn't see any meaningful statements that
> > > would refute the approach in Garzik's BIP-100.
> > >
> > > Maybe a better way to say this is,
> > >
> > > Work with Jeff Garzik (which I am sure you are already having such
> > > discussions in private) as well as the list discussions,
> > > Move forward on BIP-100 with Garzik and other developers (not such a
> > > bad plan really) and don't get caught up in XT.  (If you feel you can
> > > develop XT further, that is your thing but it would perhaps make you
> > > lose focus, work together with other developers.)
> > >
> > > Relax into the process.  Things will be ok.
> > >
> > > Respectfully,
> > >
> > > - -O
> > >
> > > On 06/22/2015 11:18 AM, Gavin Andresen wrote:
> > >> I promised to write a BIP after I'd implemented
> > >> increase-the-maximum-block-size code, so here it is. It also lives
> > >> at:
> > >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
> > >>
> > >>  I don't expect any proposal to please everybody; there are
> > >> unavoidable tradeoffs to increasing the maximum block size. I
> > >> prioritize implementation simplicity -- it is hard to write
> > >> consensus-critical code, so simpler is better.
> > >>
> > >>
> > >>
> > >>
> > >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
> > >> <gavinandresen@gmail.com <mailto:gavinandresen@gmail.com>> Status:
> > >> Draft Type: Standards Track Created: 2015-06-22
> > >>
> > >> ==Abstract==
> > >>
> > >> This BIP proposes replacing the fixed one megabyte maximum block
> > >> size with a maximum size that grows over time at a predictable
> > >> rate.
> > >>
> > >> ==Motivation==
> > >>
> > >> Transaction volume on the Bitcoin network has been growing, and
> > >> will soon reach the one-megabyte-every-ten-minutes limit imposed by
> > >> the one megabyte maximum block size. Increasing the maximum size
> > >> reduces the impact of that limit on Bitcoin adoption and growth.
> > >>
> > >> ==Specification==
> > >>
> > >> After deployment on the network (see the Deployment section for
> > >> details), the maximum allowed size of a block on the main network
> > >> shall be calculated based on the timestamp in the block header.
> > >>
> > >> The maximum size shall be 8,000,000 bytes at a timestamp of
> > >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
> > >> every 63,072,000 seconds (two years, ignoring leap years), until
> > >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
> > >> blocks in between doublings will increase linearly based on the
> > >> block's timestamp. The maximum size of blocks after 2036-01-06
> > >> 00:00:00 UTC shall be 8,192,000,000 bytes.
> > >>
> > >> Expressed in pseudo-code, using integer math:
> > >>
> > >> function max_block_size(block_timestamp):
> > >>
> > >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =
> > >> 8000000 if block_timestamp >= time_start+time_double*10 return
> > >> size_start * 2^10
> > >>
> > >> // Piecewise-linear-between-doublings growth: time_delta =
> > >> block_timestamp - t_start doublings = time_delta / time_double
> > >> remainder = time_delta % time_double interpolate = (size_start *
> > >> 2^doublings * remainder) / time_double max_size = size_start *
> > >> 2^doublings + interpolate
> > >>
> > >> return max_size
> > >>
> > >> ==Deployment==
> > >>
> > >> Deployment shall be controlled by hash-power supermajority vote
> > >> (similar to the technique used in BIP34), but the earliest possible
> > >> activation time is 2016-01-11 00:00:00 UTC.
> > >>
> > >> Activation is achieved when 750 of 1,000 consecutive blocks in the
> > >> best chain have a version number with bits 3 and 14 set (0x20000004
> > >> in hex). The activation time will be the timestamp of the 750'th
> > >> block plus a two week (1,209,600 second) grace period to give any
> > >> remaining miners or services time to upgrade to support larger
> > >> blocks. If a supermajority is achieved more than two weeks before
> > >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
> > >> 00:00:00 UTC.
> > >>
> > >> Block version numbers are used only for activation; once activation
> > >> is achieved, the maximum block size shall be as described in the
> > >> specification section, regardless of the version number of the
> > >> block.
> > >>
> > >>
> > >> ==Rationale==
> > >>
> > >> The initial size of 8,000,000 bytes was chosen after testing the
> > >> current reference implementation code with larger block sizes and
> > >> receiving feedback from miners stuck behind bandwidth-constrained
> > >> networks (in particular, Chinese miners behind the Great Firewall
> > >> of China).
> > >>
> > >> The doubling interval was chosen based on long-term growth trends
> > >> for CPU power, storage, and Internet bandwidth. The 20-year limit
> > >> was chosen because exponential growth cannot continue forever.
> > >>
> > >> Calculations are based on timestamps and not blockchain height
> > >> because a timestamp is part of every block's header. This allows
> > >> implementations to know a block's maximum size after they have
> > >> downloaded it's header, but before downloading any transactions.
> > >>
> > >> The deployment plan is taken from Jeff Garzik's proposed BIP100
> > >> block size increase, and is designed to give miners, merchants,
> > >> and full-node-running-end-users sufficient time to upgrade to
> > >> software that supports bigger blocks. A 75% supermajority was
> > >> chosen so that one large mining pool does not have effective veto
> > >> power over a blocksize increase. The version number scheme is
> > >> designed to be compatible with Pieter's Wuille's proposed "Version
> > >> bits" BIP.
> > >>
> > >> TODO: summarize objections/arguments from
> > >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
> > >>
> > >> TODO: describe other proposals and their advantages/disadvantages
> > >> over this proposal.
> > >>
> > >>
> > >> ==Compatibility==
> > >>
> > >> This is a hard-forking change to the Bitcoin protocol; anybody
> > >> running code that fully validates blocks must upgrade before the
> > >> activation time or they will risk rejecting a chain containing
> > >> larger-than-one-megabyte blocks.
> > >>
> > >> Simplified Payment Verification software is not affected, unless
> > >> it makes assumptions about the maximum depth of a transaction's
> > >> merkle branch based on the minimum size of a transaction and the
> > >> maximum block size.
> > >>
> > >> ==Implementation==
> > >>
> > >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
> > >>
> > >>
> > >>
> > >> _______________________________________________ bitcoin-dev mailing
> > >> list bitcoin-dev@lists.linuxfoundation.org
> > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > >>
> > >
> > > - --
> > > http://abis.io ~
> > > "a protocol concept to enable decentralization
> > > and expansion of a giving economy, and a new social good"
> > > https://keybase.io/odinn
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1
> > >
> > > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
> > > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
> > > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
> > > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
> > > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
> > > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
> > > =ft62
> > > -----END PGP SIGNATURE-----
> > > _______________________________________________
> > > 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
> >
> >

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Raystonn]

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Allen Piscitello]

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

This is no different than any other soft fork.  Proper communication can
coordinate soft forks easily.

On Wed, Jun 24, 2015 at 12:23 PM, Raystonn <raystonn@hotmail.com> wrote:

> You really believe they would risk getting orphaned by skipping the longer
> chain, just to attempt to reduce average block size? No, that doesn't
> happen today. Laziness in leaving the default size is common. But that is
> not collusion, nor an attempt to manipulate the block sizes of other miners.
>  On 24 Jun 2015 10:05 am, Mark Friedenbach <mark@friedenbach.org> wrote:
>
> They do so by not building on larger blocks
> On Jun 23, 2015 9:31 PM, "Raystonn" <raystonn@hotmail.com> wrote:
>
> No, they can lower their own block sizes.  But they cannot currently lower
> the sizes of blocks mined by others.  That is not the same thing by any
> stretch of the imagination.
> On 23 Jun 2015 8:50 pm, Jeff Garzik <jgarzik@gmail.com> wrote:
>
> Miners can collude today to lower the block size limit.
>
> In fact, this largely happens already out of laziness - miners often
> follow the "soft" default limit set by Bitcoin Core, to the point where you
> can chart when miners upgrade to new software:
> http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block
>
>
>
> On Tue, Jun 23, 2015 at 8:05 PM, William Madden <will.madden@novauri.com>
> wrote:
>
> Here are refutations of the approach in BIP-100 here:
> http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf
>
> To recap BIP-100:
>
> 1) Hard form to remove static 1MB block size limit
> 2) Add new floating block size limit set to 1MB
> 3) Historical 32MB message limit remains
> 4) Hard form on testnet 9/1/2015
> 5) Hard form on main 1/11/2016
> 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block
> threshold by 90% of blocks
> 7) Limit increase or decrease may not exceed 2x in any one step
> 8) Miners vote by encoding 'BV'+BlockSizeRequestValue into coinbase
> scriptSig, e.g. "/BV8000000/" to vote for 8M.
> 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the
> most common floor (minimum) is chosen.
>
> 8MB limits doubling just under every 2 years makes a static value grow
> in a predictable manner.
>
> BIP-100 makes a static value grow (or more importantly potentially
> shrink) in an unpredictable manner based on voting mechanics that are
> untested in this capacity in the bitcoin network.  Introducing a highly
> variable and untested dynamic into an already complex system is
> unnecessarily risky.
>
> For example, the largely arbitrary voting rules listed in 9 above can be
> gamed.  If I control pools or have affiliates involved in pools that
> mine slightly more than 20% of blocks, I could wait until block sizes
> are 10MB, and then suddenly vote "/BV5000000/" for 20% of blocks and
> "/BV5000001/" for the remaining 10%.  If others don't consistently vote
> for the same "/BV#/" value, vote too consistently and have their value
> thrown out as the top 20%, I could win the resize to half capacity
> "/BV5000001/" because it was the lowest repeated value not in the bottom
> 20%.
>
> I could use this to force an exodus to my sidechain/alt coin, or to
> choke out the bitcoin network.  A first improvement would be to only let
> BIP-100 raise the cap and not lower it, but if I can think of a
> vulnerability off the top of my head, there will be others on the other
> side of the equation that have not been thought of.  Why bother
> introducing a rube goldberg machine like voting when a simple 8mb cap
> with predictable growth gets the job done, potentially permanently?
>
>
> On 6/23/2015 9:43 PM, odinn wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > 1) Hard fork not (necessarily) needed
> > 2) See Garzik's BIP 100, better (this is not meant to say "superior to
> > your stuff," but rather simply to say, "Better you should work with
> > Garzik to implement BIP-100, that would be good")
> > 3) See points 1 and 2 above
> > 4) If still reading... changes should be (as you seem to have been
> > trying to lean towards)... lean towards gradual change; hence, changes
> > that would flow from this BIP would be better off oriented in a
> > process that dies not require the "way you have done it."
> >
> > You did address that, to be fair - in your TODO, this link:
> > http://gavinandresen.ninja/time-to-roll-out-bigger-blocks
> >
> > contained the following link:
> >
> > http://gavinandresen.ninja/bigger-blocks-another-way
> >
> > However, in reading that, I didn't see any meaningful statements that
> > would refute the approach in Garzik's BIP-100.
> >
> > Maybe a better way to say this is,
> >
> > Work with Jeff Garzik (which I am sure you are already having such
> > discussions in private) as well as the list discussions,
> > Move forward on BIP-100 with Garzik and other developers (not such a
> > bad plan really) and don't get caught up in XT.  (If you feel you can
> > develop XT further, that is your thing but it would perhaps make you
> > lose focus, work together with other developers.)
> >
> > Relax into the process.  Things will be ok.
> >
> > Respectfully,
> >
> > - -O
> >
> > On 06/22/2015 11:18 AM, Gavin Andresen wrote:
> >> I promised to write a BIP after I'd implemented
> >> increase-the-maximum-block-size code, so here it is. It also lives
> >> at:
> >> https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki
> >>
> >>  I don't expect any proposal to please everybody; there are
> >> unavoidable tradeoffs to increasing the maximum block size. I
> >> prioritize implementation simplicity -- it is hard to write
> >> consensus-critical code, so simpler is better.
> >>
> >>
> >>
> >>
> >> BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen
> >> <gavinandresen@gmail.com <mailto:gavinandresen@gmail.com>> Status:
> >> Draft Type: Standards Track Created: 2015-06-22
> >>
> >> ==Abstract==
> >>
> >> This BIP proposes replacing the fixed one megabyte maximum block
> >> size with a maximum size that grows over time at a predictable
> >> rate.
> >>
> >> ==Motivation==
> >>
> >> Transaction volume on the Bitcoin network has been growing, and
> >> will soon reach the one-megabyte-every-ten-minutes limit imposed by
> >> the one megabyte maximum block size. Increasing the maximum size
> >> reduces the impact of that limit on Bitcoin adoption and growth.
> >>
> >> ==Specification==
> >>
> >> After deployment on the network (see the Deployment section for
> >> details), the maximum allowed size of a block on the main network
> >> shall be calculated based on the timestamp in the block header.
> >>
> >> The maximum size shall be 8,000,000 bytes at a timestamp of
> >> 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double
> >> every 63,072,000 seconds (two years, ignoring leap years), until
> >> 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of
> >> blocks in between doublings will increase linearly based on the
> >> block's timestamp. The maximum size of blocks after 2036-01-06
> >> 00:00:00 UTC shall be 8,192,000,000 bytes.
> >>
> >> Expressed in pseudo-code, using integer math:
> >>
> >> function max_block_size(block_timestamp):
> >>
> >> time_start = 1452470400 time_double = 60*60*24*365*2 size_start =
> >> 8000000 if block_timestamp >= time_start+time_double*10 return
> >> size_start * 2^10
> >>
> >> // Piecewise-linear-between-doublings growth: time_delta =
> >> block_timestamp - t_start doublings = time_delta / time_double
> >> remainder = time_delta % time_double interpolate = (size_start *
> >> 2^doublings * remainder) / time_double max_size = size_start *
> >> 2^doublings + interpolate
> >>
> >> return max_size
> >>
> >> ==Deployment==
> >>
> >> Deployment shall be controlled by hash-power supermajority vote
> >> (similar to the technique used in BIP34), but the earliest possible
> >> activation time is 2016-01-11 00:00:00 UTC.
> >>
> >> Activation is achieved when 750 of 1,000 consecutive blocks in the
> >> best chain have a version number with bits 3 and 14 set (0x20000004
> >> in hex). The activation time will be the timestamp of the 750'th
> >> block plus a two week (1,209,600 second) grace period to give any
> >> remaining miners or services time to upgrade to support larger
> >> blocks. If a supermajority is achieved more than two weeks before
> >> 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11
> >> 00:00:00 UTC.
> >>
> >> Block version numbers are used only for activation; once activation
> >> is achieved, the maximum block size shall be as described in the
> >> specification section, regardless of the version number of the
> >> block.
> >>
> >>
> >> ==Rationale==
> >>
> >> The initial size of 8,000,000 bytes was chosen after testing the
> >> current reference implementation code with larger block sizes and
> >> receiving feedback from miners stuck behind bandwidth-constrained
> >> networks (in particular, Chinese miners behind the Great Firewall
> >> of China).
> >>
> >> The doubling interval was chosen based on long-term growth trends
> >> for CPU power, storage, and Internet bandwidth. The 20-year limit
> >> was chosen because exponential growth cannot continue forever.
> >>
> >> Calculations are based on timestamps and not blockchain height
> >> because a timestamp is part of every block's header. This allows
> >> implementations to know a block's maximum size after they have
> >> downloaded it's header, but before downloading any transactions.
> >>
> >> The deployment plan is taken from Jeff Garzik's proposed BIP100
> >> block size increase, and is designed to give miners, merchants,
> >> and full-node-running-end-users sufficient time to upgrade to
> >> software that supports bigger blocks. A 75% supermajority was
> >> chosen so that one large mining pool does not have effective veto
> >> power over a blocksize increase. The version number scheme is
> >> designed to be compatible with Pieter's Wuille's proposed "Version
> >> bits" BIP.
> >>
> >> TODO: summarize objections/arguments from
> >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks.
> >>
> >> TODO: describe other proposals and their advantages/disadvantages
> >> over this proposal.
> >>
> >>
> >> ==Compatibility==
> >>
> >> This is a hard-forking change to the Bitcoin protocol; anybody
> >> running code that fully validates blocks must upgrade before the
> >> activation time or they will risk rejecting a chain containing
> >> larger-than-one-megabyte blocks.
> >>
> >> Simplified Payment Verification software is not affected, unless
> >> it makes assumptions about the maximum depth of a transaction's
> >> merkle branch based on the minimum size of a transaction and the
> >> maximum block size.
> >>
> >> ==Implementation==
> >>
> >> https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork
> >>
> >>
> >>
> >> _______________________________________________ bitcoin-dev mailing
> >> list bitcoin-dev@lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> > - --
> > http://abis.io ~
> > "a protocol concept to enable decentralization
> > and expansion of a giving economy, and a new social good"
> > https://keybase.io/odinn
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> >
> > iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175
> > Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO+
> > K2h3DmAcA6W/Thk0C2cV3ewv+OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw
> > OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN
> > fZAeLCuwuN2qWMrVrr+cbpCXjEuE1xZG3WEj7ppYoGR+AgF/Y5/U1j7S4PVpk85s
> > CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo=
> > =ft62
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > 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
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

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

Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase

[Roy Badami]

60% of the hashrate can easily agree to force a softfork which reduces
the block size.  As soon as the fork occurs, there is a very strong
incentive for all the remaining 40% to go along with it: if they
don't, they're mining worthless blocks.

They can use a BIP-34 style mechanism to trigger the fork so there's
negligible risk to the miners.

On Wed, Jun 24, 2015 at 10:23:18AM -0700, Raystonn wrote:
> <p dir="ltr">You really believe they would risk getting orphaned by skipping the longer chain, just to attempt to reduce average block size? No, that doesn't happen today. Laziness in leaving the default size is common. But that is not collusion, nor an attempt to manipulate the block sizes of other miners.<br>
> </p>
> <div class="gmail_quote">On 24 Jun 2015 10:05 am, Mark Friedenbach &lt;mark@friedenbach.org&gt; wrote:<br type='attribution'><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">They do so by not building on larger blocks</p>
> <div class="elided-text">On Jun 23, 2015 9:31 PM, &#34;Raystonn&#34; &lt;<a href="mailto:raystonn&#64;hotmail.com">raystonn&#64;hotmail.com</a>&gt; wrote:<br /><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">No, they can lower their own block sizes.?? But they cannot currently lower the sizes of blocks mined by others.?? That is not the same thing by any stretch of the imagination.</p>
> <div class="elided-text">On 23 Jun 2015 8:50 pm, Jeff Garzik &lt;<a href="mailto:jgarzik&#64;gmail.com">jgarzik&#64;gmail.com</a>&gt; wrote:<br /><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Miners can collude today to lower the block size limit.<div><br /></div><div>In fact, this largely happens already out of laziness - miners often follow the &#34;soft&#34; default limit set by Bitcoin Core, to the point where you can chart when miners upgrade to new software:??<a href="http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block">http://hashingit.com/analysis/39-the-myth-of-the-megabyte-bitcoin-block</a></div><div><br /></div><div><br /></div></div><div><br /><div>On Tue, Jun 23, 2015 at 8:05 PM, William Madden <span dir="ltr">&lt;<a href="mailto:will.madden&#64;novauri.com">will.madden&#64;novauri.com</a>&gt;</span> wrote:<br /><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex">Here are refutations of the approach in BIP-100 here:<br />
> <a href="http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf">http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf</a><br />
> <br />
> To recap BIP-100:<br />
> <br />
> 1) Hard form to remove static 1MB block size limit<br />
> 2) Add new floating block size limit set to 1MB<br />
> 3) Historical 32MB message limit remains<br />
> 4) Hard form on testnet 9/1/2015<br />
> 5) Hard form on main 1/11/2016<br />
> 6) 1MB limit changed via one-way lock in upgrade with a 12,000 block<br />
> threshold by 90% of blocks<br />
> 7) Limit increase or decrease may not exceed 2x in any one step<br />
> 8) Miners vote by encoding &#39;BV&#39;&#43;BlockSizeRequestValue into coinbase<br />
> scriptSig, e.g. &#34;/BV8000000/&#34; to vote for 8M.<br />
> 9) Votes are evaluated by dropping bottom 20% and top 20%, and then the<br />
> most common floor (minimum) is chosen.<br />
> <br />
> 8MB limits doubling just under every 2 years makes a static value grow<br />
> in a predictable manner.<br />
> <br />
> BIP-100 makes a static value grow (or more importantly potentially<br />
> shrink) in an unpredictable manner based on voting mechanics that are<br />
> untested in this capacity in the bitcoin network.?? Introducing a highly<br />
> variable and untested dynamic into an already complex system is<br />
> unnecessarily risky.<br />
> <br />
> For example, the largely arbitrary voting rules listed in 9 above can be<br />
> gamed.?? If I control pools or have affiliates involved in pools that<br />
> mine slightly more than 20% of blocks, I could wait until block sizes<br />
> are 10MB, and then suddenly vote &#34;/BV5000000/&#34; for 20% of blocks and<br />
> &#34;/BV5000001/&#34; for the remaining 10%.?? If others don&#39;t consistently vote<br />
> for the same &#34;/BV#/&#34; value, vote too consistently and have their value<br />
> thrown out as the top 20%, I could win the resize to half capacity<br />
> &#34;/BV5000001/&#34; because it was the lowest repeated value not in the bottom<br />
> 20%.<br />
> <br />
> I could use this to force an exodus to my sidechain/alt coin, or to<br />
> choke out the bitcoin network.?? A first improvement would be to only let<br />
> BIP-100 raise the cap and not lower it, but if I can think of a<br />
> vulnerability off the top of my head, there will be others on the other<br />
> side of the equation that have not been thought of.?? Why bother<br />
> introducing a rube goldberg machine like voting when a simple 8mb cap<br />
> with predictable growth gets the job done, potentially permanently?<br />
> <div><div><br />
> <br />
> On 6/23/2015 9:43 PM, odinn wrote:<br />
> &gt; -----BEGIN PGP SIGNED MESSAGE-----<br />
> &gt; Hash: SHA1<br />
> &gt;<br />
> &gt; 1) Hard fork not (necessarily) needed<br />
> &gt; 2) See Garzik&#39;s BIP 100, better (this is not meant to say &#34;superior to<br />
> &gt; your stuff,&#34; but rather simply to say, &#34;Better you should work with<br />
> &gt; Garzik to implement BIP-100, that would be good&#34;)<br />
> &gt; 3) See points 1 and 2 above<br />
> &gt; 4) If still reading... changes should be (as you seem to have been<br />
> &gt; trying to lean towards)... lean towards gradual change; hence, changes<br />
> &gt; that would flow from this BIP would be better off oriented in a<br />
> &gt; process that dies not require the &#34;way you have done it.&#34;<br />
> &gt;<br />
> &gt; You did address that, to be fair - in your TODO, this link:<br />
> &gt; <a href="http://gavinandresen.ninja/time-to-roll-out-bigger-blocks">http://gavinandresen.ninja/time-to-roll-out-bigger-blocks</a><br />
> &gt;<br />
> &gt; contained the following link:<br />
> &gt;<br />
> &gt; <a href="http://gavinandresen.ninja/bigger-blocks-another-way">http://gavinandresen.ninja/bigger-blocks-another-way</a><br />
> &gt;<br />
> &gt; However, in reading that, I didn&#39;t see any meaningful statements that<br />
> &gt; would refute the approach in Garzik&#39;s BIP-100.<br />
> &gt;<br />
> &gt; Maybe a better way to say this is,<br />
> &gt;<br />
> &gt; Work with Jeff Garzik (which I am sure you are already having such<br />
> &gt; discussions in private) as well as the list discussions,<br />
> &gt; Move forward on BIP-100 with Garzik and other developers (not such a<br />
> &gt; bad plan really) and don&#39;t get caught up in XT.?? (If you feel you can<br />
> &gt; develop XT further, that is your thing but it would perhaps make you<br />
> &gt; lose focus, work together with other developers.)<br />
> &gt;<br />
> &gt; Relax into the process.?? Things will be ok.<br />
> &gt;<br />
> &gt; Respectfully,<br />
> &gt;<br />
> &gt; - -O<br />
> &gt;<br />
> &gt; On 06/22/2015 11:18 AM, Gavin Andresen wrote:<br />
> &gt;&gt; I promised to write a BIP after I&#39;d implemented<br />
> &gt;&gt; increase-the-maximum-block-size code, so here it is. It also lives<br />
> &gt;&gt; at:<br />
> &gt;&gt; <a href="https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki">https://github.com/gavinandresen/bips/blob/blocksize/bip-8MB.mediawiki</a><br />
> &gt;&gt;<br />
> &gt;&gt;?? I don&#39;t expect any proposal to please everybody; there are<br />
> &gt;&gt; unavoidable tradeoffs to increasing the maximum block size. I<br />
> &gt;&gt; prioritize implementation simplicity -- it is hard to write<br />
> &gt;&gt; consensus-critical code, so simpler is better.<br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt; BIP: ?? Title: Increase Maximum Block Size Author: Gavin Andresen<br />
> &gt;&gt; &lt;<a href="mailto:gavinandresen&#64;gmail.com">gavinandresen&#64;gmail.com</a> &lt;mailto:<a href="mailto:gavinandresen&#64;gmail.com">gavinandresen&#64;gmail.com</a>&gt;&gt; Status:<br />
> &gt;&gt; Draft Type: Standards Track Created: 2015-06-22<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Abstract&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; This BIP proposes replacing the fixed one megabyte maximum block<br />
> &gt;&gt; size with a maximum size that grows over time at a predictable<br />
> &gt;&gt; rate.<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Motivation&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; Transaction volume on the Bitcoin network has been growing, and<br />
> &gt;&gt; will soon reach the one-megabyte-every-ten-minutes limit imposed by<br />
> &gt;&gt; the one megabyte maximum block size. Increasing the maximum size<br />
> &gt;&gt; reduces the impact of that limit on Bitcoin adoption and growth.<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Specification&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; After deployment on the network (see the Deployment section for<br />
> &gt;&gt; details), the maximum allowed size of a block on the main network<br />
> &gt;&gt; shall be calculated based on the timestamp in the block header.<br />
> &gt;&gt;<br />
> &gt;&gt; The maximum size shall be 8,000,000 bytes at a timestamp of<br />
> &gt;&gt; 2016-01-11 00:00:00 UTC (timestamp 1452470400), and shall double<br />
> &gt;&gt; every 63,072,000 seconds (two years, ignoring leap years), until<br />
> &gt;&gt; 2036-01-06 00:00:00 UTC (timestamp 2083190400). The maximum size of<br />
> &gt;&gt; blocks in between doublings will increase linearly based on the<br />
> &gt;&gt; block&#39;s timestamp. The maximum size of blocks after 2036-01-06<br />
> &gt;&gt; 00:00:00 UTC shall be 8,192,000,000 bytes.<br />
> &gt;&gt;<br />
> &gt;&gt; Expressed in pseudo-code, using integer math:<br />
> &gt;&gt;<br />
> &gt;&gt; function max_block_size(block_timestamp):<br />
> &gt;&gt;<br />
> &gt;&gt; time_start &#61; 1452470400 time_double &#61; 60*60*24*365*2 size_start &#61;<br />
> &gt;&gt; 8000000 if block_timestamp &gt;&#61; time_start&#43;time_double*10 return<br />
> &gt;&gt; size_start * 2^10<br />
> &gt;&gt;<br />
> &gt;&gt; // Piecewise-linear-between-doublings growth: time_delta &#61;<br />
> &gt;&gt; block_timestamp - t_start doublings &#61; time_delta / time_double<br />
> &gt;&gt; remainder &#61; time_delta % time_double interpolate &#61; (size_start *<br />
> &gt;&gt; 2^doublings * remainder) / time_double max_size &#61; size_start *<br />
> &gt;&gt; 2^doublings &#43; interpolate<br />
> &gt;&gt;<br />
> &gt;&gt; return max_size<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Deployment&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; Deployment shall be controlled by hash-power supermajority vote<br />
> &gt;&gt; (similar to the technique used in BIP34), but the earliest possible<br />
> &gt;&gt; activation time is 2016-01-11 00:00:00 UTC.<br />
> &gt;&gt;<br />
> &gt;&gt; Activation is achieved when 750 of 1,000 consecutive blocks in the<br />
> &gt;&gt; best chain have a version number with bits 3 and 14 set (0x20000004<br />
> &gt;&gt; in hex). The activation time will be the timestamp of the 750&#39;th<br />
> &gt;&gt; block plus a two week (1,209,600 second) grace period to give any<br />
> &gt;&gt; remaining miners or services time to upgrade to support larger<br />
> &gt;&gt; blocks. If a supermajority is achieved more than two weeks before<br />
> &gt;&gt; 2016-01-11 00:00:00 UTC, the activation time will be 2016-01-11<br />
> &gt;&gt; 00:00:00 UTC.<br />
> &gt;&gt;<br />
> &gt;&gt; Block version numbers are used only for activation; once activation<br />
> &gt;&gt; is achieved, the maximum block size shall be as described in the<br />
> &gt;&gt; specification section, regardless of the version number of the<br />
> &gt;&gt; block.<br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Rationale&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; The initial size of 8,000,000 bytes was chosen after testing the<br />
> &gt;&gt; current reference implementation code with larger block sizes and<br />
> &gt;&gt; receiving feedback from miners stuck behind bandwidth-constrained<br />
> &gt;&gt; networks (in particular, Chinese miners behind the Great Firewall<br />
> &gt;&gt; of China).<br />
> &gt;&gt;<br />
> &gt;&gt; The doubling interval was chosen based on long-term growth trends<br />
> &gt;&gt; for CPU power, storage, and Internet bandwidth. The 20-year limit<br />
> &gt;&gt; was chosen because exponential growth cannot continue forever.<br />
> &gt;&gt;<br />
> &gt;&gt; Calculations are based on timestamps and not blockchain height<br />
> &gt;&gt; because a timestamp is part of every block&#39;s header. This allows<br />
> &gt;&gt; implementations to know a block&#39;s maximum size after they have<br />
> &gt;&gt; downloaded it&#39;s header, but before downloading any transactions.<br />
> &gt;&gt;<br />
> &gt;&gt; The deployment plan is taken from Jeff Garzik&#39;s proposed BIP100<br />
> &gt;&gt; block size increase, and is designed to give miners, merchants,<br />
> &gt;&gt; and full-node-running-end-users sufficient time to upgrade to<br />
> &gt;&gt; software that supports bigger blocks. A 75% supermajority was<br />
> &gt;&gt; chosen so that one large mining pool does not have effective veto<br />
> &gt;&gt; power over a blocksize increase. The version number scheme is<br />
> &gt;&gt; designed to be compatible with Pieter&#39;s Wuille&#39;s proposed &#34;Version<br />
> &gt;&gt; bits&#34; BIP.<br />
> &gt;&gt;<br />
> &gt;&gt; TODO: summarize objections/arguments from<br />
> &gt;&gt; <a href="http://gavinandresen.ninja/time-to-roll-out-bigger-blocks">http://gavinandresen.ninja/time-to-roll-out-bigger-blocks</a>.<br />
> &gt;&gt;<br />
> &gt;&gt; TODO: describe other proposals and their advantages/disadvantages<br />
> &gt;&gt; over this proposal.<br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Compatibility&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; This is a hard-forking change to the Bitcoin protocol; anybody<br />
> &gt;&gt; running code that fully validates blocks must upgrade before the<br />
> &gt;&gt; activation time or they will risk rejecting a chain containing<br />
> &gt;&gt; larger-than-one-megabyte blocks.<br />
> &gt;&gt;<br />
> &gt;&gt; Simplified Payment Verification software is not affected, unless<br />
> &gt;&gt; it makes assumptions about the maximum depth of a transaction&#39;s<br />
> &gt;&gt; merkle branch based on the minimum size of a transaction and the<br />
> &gt;&gt; maximum block size.<br />
> &gt;&gt;<br />
> &gt;&gt; &#61;&#61;Implementation&#61;&#61;<br />
> &gt;&gt;<br />
> &gt;&gt; <a href="https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork">https://github.com/gavinandresen/bitcoinxt/tree/blocksize_fork</a><br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt;<br />
> &gt;&gt; _______________________________________________ bitcoin-dev mailing<br />
> &gt;&gt; list <a href="mailto:bitcoin-dev&#64;lists.linuxfoundation.org">bitcoin-dev&#64;lists.linuxfoundation.org</a><br />
> &gt;&gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br />
> &gt;&gt;<br />
> &gt;<br />
> &gt; - --<br />
> &gt; <a href="http://abis.io">http://abis.io</a> ~<br />
> &gt; &#34;a protocol concept to enable decentralization<br />
> &gt; and expansion of a giving economy, and a new social good&#34;<br />
> &gt; <a href="https://keybase.io/odinn">https://keybase.io/odinn</a><br />
> &gt; -----BEGIN PGP SIGNATURE-----<br />
> &gt; Version: GnuPG v1<br />
> &gt;<br />
> &gt; iQEcBAEBAgAGBQJVigtJAAoJEGxwq/inSG8CqZwIAIG3ZQzekfccPxBOMqtim175<br />
> &gt; Crov6hrO9FaIzbLljECpUi60RKuDM/fs09ZJsKKIaJPkB5dlJjs4huc206veAIO&#43;<br />
> &gt; K2h3DmAcA6W/Thk0C2cV3ewv&#43;OiELDOhpeoddBBLPadAfaBGr4l9ltqWLdBtMCmw<br />
> &gt; OtmiWstEuXTao9ApgoFOmybdmCjbfrfhejOOHs/pMiSn5xVE60RK4x2HFTFsHfAN<br />
> &gt; fZAeLCuwuN2qWMrVrr&#43;cbpCXjEuE1xZG3WEj7ppYoGR&#43;AgF/Y5/U1j7S4PVpk85s<br />
> &gt; CgMkpcWvLnBMmSCrllnRZy1Gfrwk36Pg0rXD/l/NNd0/KTpmPSvkX/bCyzFwbzo&#61;<br />
> &gt; &#61;ft62<br />
> &gt; -----END PGP SIGNATURE-----<br />
> &gt; _______________________________________________<br />
> &gt; bitcoin-dev mailing list<br />
> &gt; <a href="mailto:bitcoin-dev&#64;lists.linuxfoundation.org">bitcoin-dev&#64;lists.linuxfoundation.org</a><br />
> &gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br />
> &gt;<br />
> _______________________________________________<br />
> bitcoin-dev mailing list<br />
> <a href="mailto:bitcoin-dev&#64;lists.linuxfoundation.org">bitcoin-dev&#64;lists.linuxfoundation.org</a><br />
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br />
> </div></div></blockquote></div><br /></div>
> </blockquote></div><br />_______________________________________________<br />
> bitcoin-dev mailing list<br />
> <a href="mailto:bitcoin-dev&#64;lists.linuxfoundation.org">bitcoin-dev&#64;lists.linuxfoundation.org</a><br />
> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br />
> <br /></blockquote></div>
> </blockquote></div>

> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev