public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Aymeric Vitte <vitteaymeric@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments
Date: Fri, 7 Apr 2017 00:29:51 +0200	[thread overview]
Message-ID: <ccf46d59-e6a1-a8a8-7e6a-dc6e8880992a@gmail.com> (raw)
In-Reply-To: <CAKzdR-qYjK0WHL51x4wJGpBuqjUu-Q8nBEPcLfj_qao=b-ZzaA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3984 bytes --]

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
> <mailto:btcdrak@gmail•com>> wrote:
>
>     On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner via
>     bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org
>     <mailto: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


[-- Attachment #2: Type: text/html, Size: 7346 bytes --]

  parent reply	other threads:[~2017-04-06 22:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-31 21:09 Sergio Demian Lerner
2017-03-31 21:18 ` Matt Corallo
2017-03-31 21:22 ` praxeology_guy
2017-03-31 21:50   ` Sergio Demian Lerner
2017-03-31 21:22 ` Matt Corallo
2017-03-31 22:13   ` Sergio Demian Lerner
2017-04-01  3:03     ` Samson Mow
2017-04-01  3:35       ` Sergio Demian Lerner
2017-06-02 20:04       ` Erik Aronesty
2017-04-01  6:55   ` Jared Lee Richardson
2017-04-01 11:44     ` Sergio Demian Lerner
2017-04-01 12:33       ` Jorge Timón
2017-04-01 13:15         ` Natanael
2017-04-01 14:07           ` Jorge Timón
     [not found]             ` <CAAt2M1_gDzEuDLSvVsJARvdCAtUyM3Yuu7TT25sbm3L-Zi6+0Q@mail.gmail.com>
     [not found]               ` <CAAt2M18=Tjw+05QCv6G7Abv=idB6ONgU9xvtrR=fn731452_mg@mail.gmail.com>
2017-04-01 15:34                 ` Natanael
2017-04-02  4:57                   ` Jorge Timón
2017-04-02 10:03                     ` Natanael
2017-04-02 11:43                       ` Jorge Timón
2017-06-02 20:04         ` Erik Aronesty
2017-06-02 21:51           ` Sergio Demian Lerner
2017-06-03  0:53             ` Erik Aronesty
2017-06-03  2:03               ` Oliver Petruzel
2017-06-03 21:05               ` Oliver Petruzel
2017-04-03 14:40 ` Btc Drak
2017-04-06  2:27   ` Erik Aronesty
2017-04-06 20:58     ` Sergio Demian Lerner
2017-04-06 20:42   ` Sergio Demian Lerner
2017-04-06 21:03     ` Sergio Demian Lerner
2017-04-06 22:29     ` Aymeric Vitte [this message]
2017-06-02 12:29     ` R E Broadley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ccf46d59-e6a1-a8a8-7e6a-dc6e8880992a@gmail.com \
    --to=vitteaymeric@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox