<div dir="ltr">Ups. My mistake:  the mempool will not grow 400 times, the is no square there.<br>I will initially grow 20 times. Multiplied by the number of times a transaction may need to be replaced with one with higher fees. Maybe 50 times, but not 400.<div><br><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 6, 2017 at 5:42 PM, Sergio Demian Lerner <span dir="ltr">&lt;<a href="mailto:sergio.d.lerner@gmail.com" target="_blank">sergio.d.lerner@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The 95% miner signaling is important to prevent two Bitcoin forks, such as what happened with Ethereum HF and Ethereum Classic.</div><div><br></div>Bitcoin has a very slow difficulty re-targeting algorithm. A fork that has just 95% miner support will initially (for 2016 blocks) be 5% slower (an average block every 10 minutes and 30 seconds). The transaction capacity of the new Bitcoin protocol is reduced only 5%. <div>However the chain with 5% if the hashing power not only has a 20x capacity reduction, but confirms transactions in 20x more time. So the mempool will grow 400 times. It must be noted that fees increased 10x from the moment blocks were half full, to the moment blocks became saturated. I&#39;m sure no Bitcoin (pre-fork) user will be willing to pay 100x times the transaction fees to use such a slow and insecure network.</div><div><br></div><div>So a 6-block confirmation will take 20 hours in the original chain and the original chain will be in this almost useless slow state for an average of 2016 blocks, or 280 days. <div>If the original blockchain hard-forks to re-adjust the difficulty, then it will just represent an alt-coin having 5% of Bitcoin community, and it can&#39;t affect Bitcoin (the segwit2mb fork).</div><div><br></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak <span dir="ltr">&lt;<a href="mailto:btcdrak@gmail.com" target="_blank">btcdrak@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfounda<wbr>tion.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>The hard-fork is conditional to 95% of the hashing power has approved the segwit2mb soft-fork and the segwit soft-fork has been activated (which should occur 2016 blocks after its lock-in time)</div></div></blockquote><div><br></div></span><div>Miners signalling they have upgraded by flipping a bit in the nVersion field has little relevance in a hard fork. If 100% of the hash power indicates they are running this proposal, but the nodes don&#39;t upgrade, what will happen?<br></div><div><br></div><div>For the record, I actually talk a lot about hard forks with various developers and am very interested in the research that Johnson in particular is pioneering. However, I have failed to understand your point about 95% miner signalling in relation to a hard fork, so I am eagerly awaiting your explanation.</div></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>