<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Not sure to get how you are answering the question</p>
<p>> 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't affect Bitcoin (the segwit2mb
fork).</p>
<p>destroys the whole thing<br>
</p>
<p>Because if the nodes don't upgrade and just implement the patch
to adjust the difficulty, what happens? You get a 95% mining power
chain with "no" nodes and a 5% one with "all" the nodes</p>
<p>I really don't get in all those discussions why the nodes are
always disconsidered compared to the miners, ie why they seem to
be of zero importance and are supposed to obey whatever you ask
them</p>
<p>And apparently the trend is not going to revert if we look at the
priority features sent in the asicboost thread where motivating
and scaling full nodes is still something you need very powerful
glasses to see coming<br>
</p>
<br>
<div class="moz-cite-prefix">Le 06/04/2017 à 22:42, Sergio Demian
Lerner via bitcoin-dev a écrit :<br>
</div>
<blockquote
cite="mid:CAKzdR-qYjK0WHL51x4wJGpBuqjUu-Q8nBEPcLfj_qao=b-ZzaA@mail.gmail.com"
type="cite">
<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'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't affect Bitcoin (the
segwit2mb fork).</div>
<div><br>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Apr 3, 2017 at 11:40 AM, Btc
Drak <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:btcdrak@gmail.com" target="_blank">btcdrak@gmail.com</a>></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 class="">On Fri, Mar 31,
2017 at 10:09 PM, Sergio Demian Lerner via
bitcoin-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:bitcoin-dev@lists.linuxfoundation.org"
target="_blank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>></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'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>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
bitcoin-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>
<a class="moz-txt-link-freetext" href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Zcash wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/zcash-wallets">https://github.com/Ayms/zcash-wallets</a>
Bitcoin wallets made simple: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/bitcoin-wallets">https://github.com/Ayms/bitcoin-wallets</a>
Get the torrent dynamic blocklist: <a class="moz-txt-link-freetext" href="http://peersm.com/getblocklist">http://peersm.com/getblocklist</a>
Check the 10 M passwords list: <a class="moz-txt-link-freetext" href="http://peersm.com/findmyass">http://peersm.com/findmyass</a>
Anti-spies and private torrents, dynamic blocklist: <a class="moz-txt-link-freetext" href="http://torrent-live.org">http://torrent-live.org</a>
Peersm : <a class="moz-txt-link-freetext" href="http://www.peersm.com">http://www.peersm.com</a>
torrent-live: <a class="moz-txt-link-freetext" href="https://github.com/Ayms/torrent-live">https://github.com/Ayms/torrent-live</a>
node-Tor : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms/node-Tor">https://www.github.com/Ayms/node-Tor</a>
GitHub : <a class="moz-txt-link-freetext" href="https://www.github.com/Ayms">https://www.github.com/Ayms</a></pre>
</body>
</html>