[bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments

Aymeric Vitte vitteaymeric at gmail.com
Thu Apr 6 22:29:51 UTC 2017


Not sure to get how you are answering the question

>  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).

destroys the whole thing

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

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

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


Le 06/04/2017 à 22:42, Sergio Demian Lerner via bitcoin-dev a écrit :
> The 95% miner signaling is important to prevent two Bitcoin forks,
> such as what happened with Ethereum HF and Ethereum Classic.
>
> 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%. 
> 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.
>
> 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. 
> 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).
>
>
> On Mon, Apr 3, 2017 at 11:40 AM, Btc Drak <btcdrak at gmail.com
> <mailto:btcdrak at gmail.com>> wrote:
>
>     On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via
>     bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
>     <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>
>         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)
>
>
>     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?
>
>     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.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

-- 
Zcash wallets made simple: https://github.com/Ayms/zcash-wallets
Bitcoin wallets made simple: https://github.com/Ayms/bitcoin-wallets
Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170407/b0414860/attachment.html>


More information about the bitcoin-dev mailing list