{"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-06-27\n📝 Original message:On Sat, Jun 27, 2015 at 12:19:04PM -0400, Michael Naber wrote:\n\u003e That test seems like a reasonable suggestion; 840GB is not prohibitive\n\u003e given today's computing costs. What other than the successful result of\n\u003e that test would you want to see before agreeing to increase the block size\n\u003e to 8MB?\n\nThe two main things you need to show is:\n\n1) Small, anonymous, miners remain approximately as profitable as large\nminers, regardless of whether they are in the world, and even when\nminers are under attack. Remember I'm talking about mining here, not\njust hashing - the process of selling your hashpower to someone else who\nis actually doing the mining.\n\nAs for \"approximately as profitable\", based on a 10% profit margin, a 5%\nprofitability difference between a negligable ~0% hashing power miner\nand a 50% hashing power miner is a good standard here.\n\nThe hard part here is basically keeping orphan rates low, as the %5\nprofitability different on %10 profit margin implies an orphan rate of\nabout 0.5% - roughly what we have right now if not actually a bit lower.\nThat also implies blocks propagate across the network in just a few\nseconds in the worst case, where blocks are being generated with\ntransactions in them that are not already in mempools - circumventing\npropagation optimization techniques. As we're talking about small\nminers, we can't assume the miners are directly conneted to each other.\n(which itself is dangerous from an attack point of view - if they're\ndirectly connected they can be DoS attacked)\n\n2) Medium to long term plan to pay for hashing power. Without scarcity\nof blockchain space there is no reason to think that transaction fees\nwon't fall to the marginal cost of including a transaction, which\ndoesn't leave anything to pay for proof-of-work security. A proposal\nmeeting this criteria will have to be clever if you don't keep the\nblocksize sufficiently limited that transaction fees are non-negligable.\nOne possible approach - if probably politically non-viable - would be to\nchange the inflation schedule so that the currency is inflated\nindefinitely.\n\n-- \n'peter'[:-1]@petertodd.org\n0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24\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/20150627/d8a83d28/attachment-0001.sig\u003e"}