{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-22\n📝 Original message:As Tier says, the current network message limit is 2MB (reduced from 32MB\nin the... uhh, 0.10? release).\n\nI think keeping the consensus rules distinct from limitations of the p2p\nnetwork makes sense-- we are already seeing different protocols for\nannouncing transactions and blocks (Matt's relay network is, essentially, a\nseparate protocol). I could write a separate BIP describing the change to\nthe p2p network protocol, but that feels like busy-work to me.\n\nRE: setting the DoS size check farther than 2 hours into the future: the\nblock, itself, will be rejected if it has a timestamp more than 2 hours in\nthe future. That is already a consensus rule.\n\nRE: what happens if block timestamps are not in chronological order:\nNothing.\n\nThe activation counting happens in block-height-order, so timestamps on all\nbut the \"activating\" block are all that matters.\n\nCode that looks for the activation condition must properly handle re-orgs\naround the activation block, of course.\n\n\nRE: testnet parameters:  big blocks can be tested in -regtest mode with\narbitrary timestamps in the past or future. Testing maximum-8MB-blocks\nmined \"in the past\" on testnet will just result in a testnet that is even\nmore useless for ordinary testing of products or services being developed\n-- part of what makes testnet useful for things like testing transaction\ncreation code is it syncs quickly.\n\nThat said, I have thought for a while now somebody should take a fresh look\nat the testnet, talk to people who might be customers for a reset testnet\nor testnets (we probably want separate testnets for people testing mining\nand people testing transaction creation, for example), and implement\ntestnets designed to make it easy to test what people need testing.\n\nRE: scraping together money to run a few hundred full-load full-nodes:\n hardware is cheap, people are expensive. You seem to expect that companies\nwill be willing to invest the time of their people testing something that\nmay never happen (8MB of transactions every ten minutes). Maybe they would,\nbut most companies are very busy trying to stay in business by attracting\ncustomers to their products or services. Scaling up is a good problem to\nhave, and, in my experience, the way to be successful scaling up is to\ntackle problems as they occur.\n\nBecause there's no use spending a bunch of person-hours hyper-optimizing\nfor 8MB blocks stored in MySQL if a year from now you find out your\ncustomers don't actually want your product or MySQL 5.11 comes out and is\n100 times faster....\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150622/72da223e/attachment-0001.html\u003e"}