Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 65A9A360 for ; Thu, 6 Apr 2017 22:29:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr0-f174.google.com (mail-wr0-f174.google.com [209.85.128.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 46944FC for ; Thu, 6 Apr 2017 22:29:50 +0000 (UTC) Received: by mail-wr0-f174.google.com with SMTP id o21so54801782wrb.2 for ; Thu, 06 Apr 2017 15:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=232JLPXKOBXUMhdDHiet/76nd6mz1dyTMu20cfSK4iU=; b=PDF9cYGTiz/TxhTWWnyzrUWuS7hqlEnkIlWZF59wFnRAh4qaBLzFFGcQgSeYXiE/JS XBsnm2LNwLm2oW7BzJqv5VPo3ugilqfvhXETC2lIlXfOz+siuCjD7g0orfMHm2bzcWFB uUlomn/Dlen5vUhCYQsNuPaMXCjrlshLZKS9Se0Nxv4JXWJnpir/Yysl6Zq8+FGJ2KSe DuPKKtKyLINC5IQn8fHqLJ9pHIhvrQVBg6/Y+EvMro7J7V5ymliOBpKjfzvOWir92RA7 QQP5CKP1OLB5e+o2pjD2VbEwQzgsn9t6IB23UgsKHeia1hQSoJ51ZhZW6ysN77ZtfYuj mS2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=232JLPXKOBXUMhdDHiet/76nd6mz1dyTMu20cfSK4iU=; b=MFAAzcqCcqtHqjmO+ePrrPPJmn9ZeyDp8s3A0+R60JjZxmsNYKiYwi4o5O64PQsVYs vRT+jjnEYo/twMBgf+R3v+LM/xXNxx13Bw6P3g3226Sg5NJxLTDnotLWX6nEeIV5za/7 71cNVCRLf+JwWd75C6FUK0REV775SDvtMA3x3SCzyeApHFYBsyerAJmrWVg+ojx3lp4U jYk4ikPmF7MhKbFcsp0fhFnnZV9p1c9kXVUOqY0e2WhF2K+6jcDIvNUoXrt/ymh5FBPp z0RaaEZtiXFwaCR0PDPKI1AXzmTAKV/Lafr/3ghIjLZQ6sHih8cPiZsur670eTSvcDBS f/Hg== X-Gm-Message-State: AFeK/H1DXWM9qO8JAHz7A+Sdyqy1d1xanGDmgL8v9wjlgJbj5sCGjJ3gBfTxBWsn5BWQfw== X-Received: by 10.223.139.146 with SMTP id o18mr32499417wra.61.1491517788683; Thu, 06 Apr 2017 15:29:48 -0700 (PDT) Received: from [192.168.1.10] (ANice-654-1-67-220.w83-201.abo.wanadoo.fr. [83.201.94.220]) by smtp.googlemail.com with ESMTPSA id m90sm3954460wmi.34.2017.04.06.15.29.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Apr 2017 15:29:48 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: From: Aymeric Vitte Message-ID: Date: Fri, 7 Apr 2017 00:29:51 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------20FA4C7190FCBB1FA9B5F193" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,FREEMAIL_REPLY,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Apr 2017 22:29:51 -0000 This is a multi-part message in MIME format. --------------20FA4C7190FCBB1FA9B5F193 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit 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 > wrote: > > On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via > bitcoin-dev > 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@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 --------------20FA4C7190FCBB1FA9B5F193 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

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@gmail.com> wrote:
On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@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@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
--------------20FA4C7190FCBB1FA9B5F193--