<unnamed>

Public Key

npub1vt9mgqkjw57ccqqp9kagu32tghtyt94urnr38sagmashfyw7xpcs64zu72

Profile Code

nprofile1qqsx9ja5qtf820vvqqqjmw5wg495t4j9j67pe3cncw5d7ct5j80rqugpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dslx4plf

Publishing to

relay.nostr.net

relay.damus.io

nos.lol

Last Notes

2023-06-07 17:44:36 UTC

- reply

📅 Original date posted:2015-11-13
📝 Original message:Revised spec below to put us back at 2 MB at next halving in 2016
(addressing Luke & Drak's points). This is more in line with intent of the
original proposal and provides sufficient time to gain consensus.
Specification
>
>
> * 2 MB, height 420,000 < 630,000; (fork active when 75% of last 1,000
blocks signal support and block 420,000 reached, ~July 2016)
* 4 MB, height 630,000 < 840,000; (year ~2020)
* 8 MB, height 840,000 < 1,050,000; (year ~2024)
* 16 MB, height 1,050,000 < 1,260,000; (year ~2028)
* 32 MB, height >= 1,260,000. (year ~2032)
On Fri, Nov 13, 2015 at 2:49 AM, Btc Drak <btcdrak at gmail.com> wrote:
> > * 2 MB, height 210,000 < 420,000; (when 75% of last 1,000 blocks signal
> support)
>
> This doesnt give anyone a chance to upgrade and would cause a hard fork
> the moment a miner created a >1MB block. Flag day (hard fork) upgrades must
> start the change at a sufficient time in the future (greater than the
> current block height) to give all nodes the chance to upgrade.
>
> On Fri, Nov 13, 2015 at 3:37 AM, John Sacco via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I like your suggestion for the continuity and it gets us up to 2 MB in
>> the shorter term. Also I just noticed the math error.
>>
>> Here is a revised spec (incorporating suggestions from Chun Wang):
>>
>> Specification
>>
>> * 1 MB, height < 210,000;
>> * 2 MB, height 210,000 < 420,000; (when 75% of last 1,000 blocks signal
>> support)
>> * 4 MB, height 420,000 < 630,000; (year 2016)
>> * 8 MB, height 630,000 < 840,000; (year ~2020)
>> * 16 MB, height 840,000 < 1,050,000; (year ~2024)
>> * 32 MB, height >= 1,050,000. (year ~2028)
>>
>>
>> On Thu, Nov 12, 2015 at 9:56 PM, Chun Wang <1240902 at gmail.com> wrote:
>>
>>> How about these specs:
>>> * 1 MB, height < 210000;
>>> * 2 MB, 210000 <= height < 420000;
>>> * 4 MB, 420000 <= height < 630000;
>>> * 8 MB, 630000 <= height < 840000;
>>> * 16 MB, 840000 <= height < 1050000;
>>> * 32 MB, height >= 1050000.
>>>
>>>
>>> On Fri, Nov 13, 2015 at 7:47 AM, John Sacco via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>> > Hi Devs,
>>> >
>>> >
>>> > Please consider the draft proposal below for peer review.
>>> >
>>> >
>>> > Thanks,
>>> >
>>> >
>>> > John
>>> >
>>> >
>>> > BIP
>>> >
>>> > BIP: ?
>>> >
>>> > Title: Block size doubles at each reward halving with max block size
>>> of
>>> > 32M
>>> >
>>> > Author: John Sacco <johnsock at gmail.com>
>>> >
>>> > Status: Draft
>>> >
>>> > Type: Standards Track
>>> >
>>> > Created: 2015-11-11
>>> >
>>> > Abstract
>>> >
>>> > Change max block size to 2MB at next block subsidy halving, and double
>>> the
>>> > block size at each subsidy halving until reaching 32MB.
>>> >
>>> > Copyright
>>> >
>>> > This proposal belongs in the public domain. Anyone can use this text
>>> for any
>>> > purpose with proper attribution to the author.
>>> >
>>> > Motivation
>>> >
>>> > 1. Gradually restores block size to the default 32 MB setting
>>> originally
>>> > implemented by Satoshi.
>>> >
>>> > 2. Initial increase to 2MB at block halving in July 2016 would have
>>> > minimal impact to existing nodes running on most hardware and networks.
>>> >
>>> > 3. Long term solution that does not make enthusiastic assumptions
>>> > regarding future bandwidth and storage availability estimates.
>>> >
>>> > 4. Maximum block size of 32MB allows peak usage of ~100 tx/sec by
>>> year
>>> > 2031.
>>> >
>>> > 5. Exercise network upgrade procedure during subsidy reward
>>> halving, a
>>> > milestone event with the goal of increasing awareness among miners and
>>> node
>>> > operators.
>>> >
>>> > Specification
>>> >
>>> > 1. Increase the maximum block size to 2MB when block 630,000 is
>>> reached
>>> > and 75% of the last 1,000 blocks have signaled support.
>>> >
>>> > 2. Increase maximum block size to 4MB at block 840,000.
>>> >
>>> > 3. Increase maximum block size to 8MB at block 1,050,000.
>>> >
>>> > 4. Increase maximum block size to 16MB at block 1,260,000.
>>> >
>>> > 5. Increase maximum block size to 32MB at block 1,470,000.
>>> >
>>> > Backward compatibility
>>> >
>>> > All older clients are not compatible with this change. The first block
>>> > larger than 1M will create a network partition excluding not-upgraded
>>> > network nodes and miners.
>>> >
>>> > Rationale
>>> >
>>> > While more comprehensive solutions are developed, an increase to the
>>> block
>>> > size is needed to continue network growth. A longer term solution is
>>> needed
>>> > to prevent complications associated with additional hard forks. It
>>> should
>>> > also increase at a gradual rate that retains and allows a large
>>> distribution
>>> > of full nodes. Scheduling this hard fork to occur no earlier than the
>>> > subsidy halving in 2016 has the goal of simplifying the communication
>>> > outreach needed to achieve consensus, while also providing a buffer of
>>> time
>>> > to make necessary preparations.
>>> >
>>> >
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev at lists.linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> >
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151113/f0652a2e/attachment-0001.html>

2023-06-07 17:44:35 UTC

- reply

📅 Original date posted:2015-11-13
📝 Original message:I like your suggestion for the continuity and it gets us up to 2 MB in the
shorter term. Also I just noticed the math error.
Here is a revised spec (incorporating suggestions from Chun Wang):
Specification
* 1 MB, height < 210,000;
* 2 MB, height 210,000 < 420,000; (when 75% of last 1,000 blocks signal
support)
* 4 MB, height 420,000 < 630,000; (year 2016)
* 8 MB, height 630,000 < 840,000; (year ~2020)
* 16 MB, height 840,000 < 1,050,000; (year ~2024)
* 32 MB, height >= 1,050,000. (year ~2028)
On Thu, Nov 12, 2015 at 9:56 PM, Chun Wang <1240902 at gmail.com> wrote:
> How about these specs:
> * 1 MB, height < 210000;
> * 2 MB, 210000 <= height < 420000;
> * 4 MB, 420000 <= height < 630000;
> * 8 MB, 630000 <= height < 840000;
> * 16 MB, 840000 <= height < 1050000;
> * 32 MB, height >= 1050000.
>
>
> On Fri, Nov 13, 2015 at 7:47 AM, John Sacco via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Hi Devs,
> >
> >
> > Please consider the draft proposal below for peer review.
> >
> >
> > Thanks,
> >
> >
> > John
> >
> >
> > BIP
> >
> > BIP: ?
> >
> > Title: Block size doubles at each reward halving with max block size of
> > 32M
> >
> > Author: John Sacco <johnsock at gmail.com>
> >
> > Status: Draft
> >
> > Type: Standards Track
> >
> > Created: 2015-11-11
> >
> > Abstract
> >
> > Change max block size to 2MB at next block subsidy halving, and double
> the
> > block size at each subsidy halving until reaching 32MB.
> >
> > Copyright
> >
> > This proposal belongs in the public domain. Anyone can use this text for
> any
> > purpose with proper attribution to the author.
> >
> > Motivation
> >
> > 1. Gradually restores block size to the default 32 MB setting
> originally
> > implemented by Satoshi.
> >
> > 2. Initial increase to 2MB at block halving in July 2016 would have
> > minimal impact to existing nodes running on most hardware and networks.
> >
> > 3. Long term solution that does not make enthusiastic assumptions
> > regarding future bandwidth and storage availability estimates.
> >
> > 4. Maximum block size of 32MB allows peak usage of ~100 tx/sec by year
> > 2031.
> >
> > 5. Exercise network upgrade procedure during subsidy reward halving, a
> > milestone event with the goal of increasing awareness among miners and
> node
> > operators.
> >
> > Specification
> >
> > 1. Increase the maximum block size to 2MB when block 630,000 is
> reached
> > and 75% of the last 1,000 blocks have signaled support.
> >
> > 2. Increase maximum block size to 4MB at block 840,000.
> >
> > 3. Increase maximum block size to 8MB at block 1,050,000.
> >
> > 4. Increase maximum block size to 16MB at block 1,260,000.
> >
> > 5. Increase maximum block size to 32MB at block 1,470,000.
> >
> > Backward compatibility
> >
> > All older clients are not compatible with this change. The first block
> > larger than 1M will create a network partition excluding not-upgraded
> > network nodes and miners.
> >
> > Rationale
> >
> > While more comprehensive solutions are developed, an increase to the
> block
> > size is needed to continue network growth. A longer term solution is
> needed
> > to prevent complications associated with additional hard forks. It should
> > also increase at a gradual rate that retains and allows a large
> distribution
> > of full nodes. Scheduling this hard fork to occur no earlier than the
> > subsidy halving in 2016 has the goal of simplifying the communication
> > outreach needed to achieve consensus, while also providing a buffer of
> time
> > to make necessary preparations.
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151112/4aa7457b/attachment.html>

2023-06-07 17:44:34 UTC

- reply

📅 Original date posted:2015-11-12
📝 Original message:Hi Devs,
Please consider the draft proposal below for peer review.
Thanks,
John
BIP
BIP: ?
Title: Block size doubles at each reward halving with max block size of
32M
Author: John Sacco <johnsock at gmail.com>
Status: Draft
Type: Standards Track
Created: 2015-11-11
Abstract
Change max block size to 2MB at next block subsidy halving, and double the
block size at each subsidy halving until reaching 32MB.
Copyright
This proposal belongs in the public domain. Anyone can use this text for
any purpose with proper attribution to the author.
Motivation
1. Gradually restores block size to the default 32 MB setting originally
implemented by Satoshi.
2. Initial increase to 2MB at block halving in July 2016 would have
minimal impact to existing nodes running on most hardware and networks.
3. Long term solution that does not make enthusiastic assumptions
regarding future bandwidth and storage availability estimates.
4. Maximum block size of 32MB allows peak usage of ~100 tx/sec by year
2031.
5. Exercise network upgrade procedure during subsidy reward halving, a
milestone event with the goal of increasing awareness among miners and node
operators.
Specification
1. Increase the maximum block size to 2MB when block 630,000 is reached
and 75% of the last 1,000 blocks have signaled support.
2. Increase maximum block size to 4MB at block 840,000.
3. Increase maximum block size to 8MB at block 1,050,000.
4. Increase maximum block size to 16MB at block 1,260,000.
5. Increase maximum block size to 32MB at block 1,470,000.
Backward compatibility
All older clients are not compatible with this change. The first block
larger than 1M will create a network partition excluding not-upgraded
network nodes and miners.
Rationale
While more comprehensive solutions are developed, an increase to the block
size is needed to continue network growth. A longer term solution is needed
to prevent complications associated with additional hard forks. It should
also increase at a gradual rate that retains and allows a large
distribution of full nodes. Scheduling this hard fork to occur no earlier
than the subsidy halving in 2016 has the goal of simplifying the
communication outreach needed to achieve consensus, while also providing a
buffer of time to make necessary preparations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151112/c00ed906/attachment-0001.html>