<oembed><type>rich</type><version>1.0</version><author_name>npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd</author_name><author_url>https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-06-22&#xA;📝 Original message:On Mon, Jun 22, 2015 at 8:10 PM, Martin Schwarz &lt;martin.schwarz at gmail.com&gt;&#xA;wrote:&#xA;&#xA;&gt; Gavin,&#xA;&gt;&#xA;&gt; in 2022 your proposal (BIP as well as code) crosses the 32MB maximum&#xA;&gt; message size limit. In order to avoid deployment of code that&#xA;&gt; deterministically&#xA;&gt; fails fatally in 2022, I&#39;d propose to stop the doublings at 32MB for now&#xA;&gt; and fix&#xA;&gt; the message size limit in the mean time.&#xA;&#xA;&#xA;There is an exception in the code for &#34;block&#34; messages.&#xA;&#xA;https://github.com/gavinandresen/bitcoinxt/commit/c81898ec46e4962daf975e352931b848026fdc34#diff-7ec3c68a81efff79b6ca22ac1f1eabbaR3548&#xA;&#xA;This means 2MB limit for all other messages.  &#34;block&#34; messages are limited&#xA;to the max block size for 2 hours into the future.&#xA;&#xA;I think setting it to a week into the future might be better, since it is&#xA;only a DOS protection.  This would guarantee that message sizes are&#xA;reasonable.  The size check would still be done anyway.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/2457767e/attachment.html&gt;</html></oembed>