<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-05-08&#xA;📝 Original message:On Fri, May 08, 2015 at 12:03:04PM +0200, Mike Hearn wrote:&#xA;&gt; &gt;&#xA;&gt; &gt;  * Though there are many proposals floating around which could&#xA;&gt; &gt; significantly decrease block propagation latency, none of them are&#xA;&gt; &gt; implemented today.&#xA;&gt; &#xA;&gt; &#xA;&gt; With a 20mb cap, miners still have the option of the soft limit.&#xA;&#xA;The soft-limit is there miners themselves produce smaller blocks; the&#xA;soft-limit does not prevent other miners from producing larger blocks.&#xA;&#xA;As we&#39;re talking about ways that other miners can use 20MB blocks to&#xA;harm the competition, talking about the soft-limit is irrelevant.&#xA;Similarly, as security engineers we must plan for the worst case; as&#xA;we&#39;ve seen before by your campaigns to raise the soft-limit(1) even at a&#xA;time when the vast majority of transaction volume was from one user&#xA;(SatoshiDice) soft-limits are an extremely weak form of control.&#xA;&#xA;For the proposes of discussing blocksize increase requirements we can&#xA;stop talking about the soft-limit.&#xA;&#xA;1) https://bitcointalk.org/index.php?topic=149668.0&#xA;&#xA;-- &#xA;&#39;peter&#39;[:-1]@petertodd.org&#xA;000000000000000009344ba165781ee352f93d657c8b098c8e518e6011753e59&#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/20150508/b669d9b9/attachment.sig&gt;</html></oembed>