Simon Liu [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-04 📝 Original message:Maybe grab some code from ...
📅 Original date posted:2015-09-04
📝 Original message:Maybe grab some code from BIP101 ? It permits block messages > 2MB,
while retaining the current limit of 2 MB imposed on other network
messages. The 32 MB limit was patched a few months ago.
Links to code:
https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_which_states/
On 09/04/2015 12:53 AM, Andy Chase via bitcoin-dev wrote:
> The 32Mb limit is
> here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25
>
> It's to keep the message size small enough that messages can be
> serialized in memory.
>
> Jeff if you decide to lift the 32MB limit (you really should, unless
> your plan is to potentially hard force another Blocksize discussion
> again which might be okay). I suggest having the 32MB ceiling auto-raise
> according to a exponential factor (1.5?) starting 1 year from now.
>
> Basically hard limit ceiling 2016-2017: 32 MB
> Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB
>
> The factor could be 2 like BIP-101 but I imagine you will want to be
> more conservative. The delay time could also be longer if you think it
> will take longer to fix the message size issue across all implementations.
>
📝 Original message:Maybe grab some code from BIP101 ? It permits block messages > 2MB,
while retaining the current limit of 2 MB imposed on other network
messages. The 32 MB limit was patched a few months ago.
Links to code:
https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_which_states/
On 09/04/2015 12:53 AM, Andy Chase via bitcoin-dev wrote:
> The 32Mb limit is
> here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25
>
> It's to keep the message size small enough that messages can be
> serialized in memory.
>
> Jeff if you decide to lift the 32MB limit (you really should, unless
> your plan is to potentially hard force another Blocksize discussion
> again which might be okay). I suggest having the 32MB ceiling auto-raise
> according to a exponential factor (1.5?) starting 1 year from now.
>
> Basically hard limit ceiling 2016-2017: 32 MB
> Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB
>
> The factor could be 2 like BIP-101 but I imagine you will want to be
> more conservative. The delay time could also be longer if you think it
> will take longer to fix the message size issue across all implementations.
>