<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-05-29&#xA;📝 Original message:On Fri, May 29, 2015 at 12:26 PM, Mike Hearn &lt;mike at plan99.net&gt; wrote:&#xA;&#xA;&gt; IMO it&#39;s not even clear there needs to be a size limit at all. Currently&#xA;&gt; the 32mb message cap imposes one anyway&#xA;&gt;&#xA;&#xA;If the plan is a fix once and for all, then that should be changed too.  It&#xA;could be set so that it is at least some multiple of the max block size&#xA;allowed.&#xA;&#xA;Alternatively, the merkle block message already incorporates the required&#xA;functionality.&#xA;&#xA;Send&#xA;- headers message (with 1 header)&#xA;- merkleblock messages (max 1MB per message)&#xA;&#xA;The transactions for each merkleblock could be sent directly before each&#xA;merkleblock, as is currently the case.&#xA;&#xA;That system can send a block of any size.  It would require a change to the&#xA;processing of any merkleblocks received.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150529/21895008/attachment.html&gt;</html></oembed>