{"type":"rich","version":"1.0","author_name":"npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","author_url":"https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-08\n📝 Original message:On Fri, May 8, 2015 at 5:37 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\n\u003e The soft-limit is there miners themselves produce smaller blocks; the\n\u003e soft-limit does not prevent other miners from producing larger blocks.\n\u003e\n\nI wonder if having a \"miner\" flag would be good for the network.\n\nClients for general users and merchants would have a less strict rule than\nthe rule for miners.  Miners who don't set their miners flag might get\norphaned off the chain.\n\nFor example, the limits could be setup as follows.\n\nClients: 20MB\nMiners: 4MB\n\nWhen in \"miner mode\", the client would reject 4MB blocks and wouldn't build\non them.  The reference client might even track the miner and the non-miner\nchain tip.\n\nMiners would refuse to build on 5MB blocks, but merchants and general users\nwould accept them.\n\nThis allows the miners to soft fork the limit at some point in the future.\nIf 75% of miners decided to up the limit to 8MB, then all merchants and the\ngeneral users would accept the new blocks.  It could follow the standard\nsoft fork rules.\n\nThis is a more general version of the system where miners are allowed to\nvote on the block size (subject to a higher limit).\n\nA similar system is where clients track all header trees.  Your wallet\ncould warn you that there is an invalid tree that has \u003e 75% of the hashing\npower and you might want to upgrade.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/51802e38/attachment.html\u003e"}