public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: R E Broadley <rebroad+linuxfoundation.org@gmail.com>
To: Sergio Demian Lerner <sergio.d.lerner@gmail.com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments
Date: Fri, 2 Jun 2017 14:29:19 +0200	[thread overview]
Message-ID: <CAFBxzAD4C_0DwzRw4M=e2bASPPT-wgD7jM=LVpnMzM3Ki+j0NQ@mail.gmail.com> (raw)
In-Reply-To: <CAKzdR-qYjK0WHL51x4wJGpBuqjUu-Q8nBEPcLfj_qao=b-ZzaA@mail.gmail.com>

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

Miner signalling is not enough to avoid two forks - as has been proven in
the past (e.g. when miners signaled they were fully validating blocks when
there we in fact only validating headers). To really protect against two
forks happening, the code needs to detect this happening (i.e. monitor the
other fork) and if it's clear that the signalling was dishonest, then it
needs to abort, IMHO.

On Thu, Apr 6, 2017 at 10:42 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

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

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

      parent reply	other threads:[~2017-06-02 12:29 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-31 21:09 [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments 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
2017-06-02 12:29     ` R E Broadley [this message]

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='CAFBxzAD4C_0DwzRw4M=e2bASPPT-wgD7jM=LVpnMzM3Ki+j0NQ@mail.gmail.com' \
    --to=rebroad+linuxfoundation.org@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=sergio.d.lerner@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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