{"type":"rich","version":"1.0","author_name":"npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","author_url":"https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-09\n📝 Original message:On Fri, May 08, 2015 at 08:47:52PM +0100, Tier Nolan wrote:\n\u003e On Fri, May 8, 2015 at 5:37 PM, Peter Todd \u003cpete at petertodd.org\u003e wrote:\n\u003e \n\u003e \u003e The soft-limit is there miners themselves produce smaller blocks; the\n\u003e \u003e soft-limit does not prevent other miners from producing larger blocks.\n\u003e \u003e\n\u003e \n\u003e I wonder if having a \"miner\" flag would be good for the network.\n\nMakes it trivial to find miners and DoS attack them - a huge risk to the\nnetwork as a whole, as well as the miners.\n\nRight now pools already get DoSed all the time through their work\nsubmission systems; getting DoS attacked via their nodes as well would\nbe a disaster.\n\n\u003e When in \"miner mode\", the client would reject 4MB blocks and wouldn't build\n\u003e on them.  The reference client might even track the miner and the non-miner\n\u003e chain tip.\n\u003e \n\u003e Miners would refuse to build on 5MB blocks, but merchants and general users\n\u003e would accept them.\n\nThat'd be an excellent way to double-spend merchants, significantly\nincreasing the chance that the double-spend would succeed as you only\nhave to get sufficient hashing power to get the lucky blocks; you don't\nneed enough hashing power to *also* ensure those blocks don't become the\nlongest chain, removing the need to sybil attack your target.\n\n-- \n'peter'[:-1]@petertodd.org\n000000000000000004bd67400df7577a30e6f509b6bd82633efeabe6395eb65a\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 650 bytes\nDesc: Digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150508/b01ee01a/attachment.sig\u003e"}