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