<oembed><type>rich</type><version>1.0</version><author_name>npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrs</author_name><author_url>https://nostr.ae/npub1dtr22xd42nv07un2xq0rmtkqkjylgsmexau0anxxafa9xmmn2ncshu7wrs</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2013-03-13&#xA;📝 Original message:Here&#39;s a simple proposal to start discussion from...&#xA;&#xA;BEFORE block 262144:&#xA;- Never make a block that, combined with the previous 4 blocks, results in &#xA;over 4500 transaction modifications.&#xA;- Reject any block that includes more than 4500 transaction modifications on &#xA;its own (slight soft-fork)&#xA;- (these rules should make older clients safe under most circumstances)&#xA;&#xA;FROM block 262144 to block 393216 (hard fork #1):&#xA;- Never make, and reject any block that includes more than 24391 transaction &#xA;modifications on its own (this *should* be equivalent to 1 MB)&#xA;- (this rules can make older client backports safe unless a reorg is more than &#xA;6 blocks deep)&#xA;&#xA;FROM block 393216 onward (hard fork #2):&#xA;- Never make, and reject any block that includes more than 48781 transaction &#xA;modifications on its own (this *should* be equivalent to 2 MB)&#xA;- Accept blocks up to 2 MB in data size&#xA;- Discontinue support for clients prior to 0.8.1&#xA;&#xA;I intentionally set the block numbers conservatively to try to account for the &#xA;yet-unseen ASIC upgrade.&#xA;&#xA;Thoughts?</html></oembed>