<oembed><type>rich</type><version>1.0</version><author_name>npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_name><author_url>https://nostr.ae/npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-06-27&#xA;📝 Original message:On Sat, Jun 27, 2015 at 12:19:04PM -0400, Michael Naber wrote:&#xA;&gt; That test seems like a reasonable suggestion; 840GB is not prohibitive&#xA;&gt; given today&#39;s computing costs. What other than the successful result of&#xA;&gt; that test would you want to see before agreeing to increase the block size&#xA;&gt; to 8MB?&#xA;&#xA;The two main things you need to show is:&#xA;&#xA;1) Small, anonymous, miners remain approximately as profitable as large&#xA;miners, regardless of whether they are in the world, and even when&#xA;miners are under attack. Remember I&#39;m talking about mining here, not&#xA;just hashing - the process of selling your hashpower to someone else who&#xA;is actually doing the mining.&#xA;&#xA;As for &#34;approximately as profitable&#34;, based on a 10% profit margin, a 5%&#xA;profitability difference between a negligable ~0% hashing power miner&#xA;and a 50% hashing power miner is a good standard here.&#xA;&#xA;The hard part here is basically keeping orphan rates low, as the %5&#xA;profitability different on %10 profit margin implies an orphan rate of&#xA;about 0.5% - roughly what we have right now if not actually a bit lower.&#xA;That also implies blocks propagate across the network in just a few&#xA;seconds in the worst case, where blocks are being generated with&#xA;transactions in them that are not already in mempools - circumventing&#xA;propagation optimization techniques. As we&#39;re talking about small&#xA;miners, we can&#39;t assume the miners are directly conneted to each other.&#xA;(which itself is dangerous from an attack point of view - if they&#39;re&#xA;directly connected they can be DoS attacked)&#xA;&#xA;2) Medium to long term plan to pay for hashing power. Without scarcity&#xA;of blockchain space there is no reason to think that transaction fees&#xA;won&#39;t fall to the marginal cost of including a transaction, which&#xA;doesn&#39;t leave anything to pay for proof-of-work security. A proposal&#xA;meeting this criteria will have to be clever if you don&#39;t keep the&#xA;blocksize sufficiently limited that transaction fees are non-negligable.&#xA;One possible approach - if probably politically non-viable - would be to&#xA;change the inflation schedule so that the currency is inflated&#xA;indefinitely.&#xA;&#xA;-- &#xA;&#39;peter&#39;[:-1]@petertodd.org&#xA;0000000000000000007fc13ce02072d9cb2a6d51fae41fefcde7b3b283803d24&#xA;-------------- next part --------------&#xA;A non-text attachment was scrubbed...&#xA;Name: signature.asc&#xA;Type: application/pgp-signature&#xA;Size: 650 bytes&#xA;Desc: Digital signature&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/d8a83d28/attachment-0001.sig&gt;</html></oembed>