<oembed><type>rich</type><version>1.0</version><author_name>npub1du3xh5wgds32a5fweqkd9k45kh30wl7kv2kyu8ugz9c2ztdg00tqqvyg93</author_name><author_url>https://nostr.ae/npub1du3xh5wgds32a5fweqkd9k45kh30wl7kv2kyu8ugz9c2ztdg00tqqvyg93</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2015-08-12&#xA;📝 Original message:On Tuesday 11. August 2015 21.51.59 Pieter Wuille via bitcoin-dev wrote:&#xA;&gt;  If people are doing transactions despite being unreliable, there&#xA;&gt; must be a use for them.&#xA;&#xA;Thats one usage of the form unreliable.&#xA;Yes, if people start getting their transactions thrown out because of full &#xA;blocks or full memory pools, then its unreliable to send stuff.&#xA;&#xA;Much more importantly is the software is unreliable at such loads. Bitcoin &#xA;core will continue to grow in memory consumption, and eventually crash. Or, &#xA;worse, crash the system its running on.&#xA;We know of some issues in the software with regards to running at &gt; 100% &#xA;capacity, I&#39;m sure we&#39;ll find more when it actually happens.&#xA;&#xA;IT experts are serious when they say that they avoid maxing out a system like &#xA;the plague.&#xA;&#xA;This, btw, is a good scenario where more centralization ends up happening when &#xA;blocks are always full and people need to upgrade their client every week to &#xA;keep up with the bugfixes.</html></oembed>