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

From: Sergio Demian Lerner <sergio.d.lerner@gmail•com>
To: erik@q32•com
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments
Date: Thu, 6 Apr 2017 17:58:56 -0300	[thread overview]
Message-ID: <CAKzdR-qa3=3MioY7fSQ+EiQyfPWUgB9sLSrLpCK-WEnx8YxUBA@mail.gmail.com> (raw)
In-Reply-To: <CAJowKgLUrMR9XN2Sb9ZuXCZx3K8Jy65pOOYGVhYeisszPoWLdA@mail.gmail.com>

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

Responding between lines...

On Wed, Apr 5, 2017 at 11:27 PM, Erik Aronesty <earonesty@gmail•com> wrote:

> I personally appreciate the minimal changes, and often encourage
> development to be done this way - when it needs to be released quickly.
> But does this need to be released quickly?
>
>
Segwit2mb is a last resort option. It does not need to be released quickly.
Not at all. It just needs to be there in case no other option is chosen. I
put tentative dates. We can move them.

> - maybe the proposal should be renamed segwit 8mb and be discussed solely
> in terms of block weights.
>

The name does not matter much. The name means joining segwit with a 2Mb
hard-fork. It's a grammatical name.

I also disagree with the idea that segwit2mb is a 8mb increase. As stated
by in the Bitcon.org website [1] and backed up by scientific research, “a
block filled with standard single-signature P2PKH transactions would be
about 1.6MB and a block filled with 2-of-2 multisignature transactions
would be about 2.0MB.”. As standard blocks are a combination between P2PKH,
and 2-of-3 multisignatures, the actual average segwit block size will be
close to 2.0MB.

Because Segwit2Mb doubles the maximum size of a block, the average block
size for a block filed with average transactions is 4.0Mb.

[1] https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#segwit-size

I can explain in a following e-mail why creating 8Mb blocks on purpose is
generally is an irrational choice. And in the case where it could provide
an economic benefit, adding parallel block validation to Core nullifies any
adversary advantage.

> a high consensus hard fork is probably preferable to a low consensus soft
fork, however there is nothing to indicate that segwit as it stands isnt
already very high consensus except for a handful of pool operators
protecting fee income.

You and me may never know the reasons why these operators (or many many of
other users) prefer to increase the block-size. I suppose it has to do high
the high current transaction fees as compared to less than a year ago.
Anyway consensus can only be achieved if one understands the others may
have reasons that do not match ours.

Last, if this proposal is rejected by any side, then we'll definitively
learn that side is not looking for any consensual resolution of the
conflict.

> - miners who currently object to segwit while pretending to like larger
> blocks will find some excuse to object to this too.
>
>
If they do, we'll get a lot of public, verifiable information from that
fact. The cost to include this patch is low compared with the benefit it
can bring and the information we can gather in case one of the sides
rejects it.

However, I've received positive feedback from them until now.

> - Given the challenges miners seem to have in flipping bits, I expect any
> fork that requires 95pct hash power to be vaporware.
>

Then we'll learn a lot about hard-forks, the limits of miner "voting" and
the quorums we can expect.

Regards,
Sergio.

>
> On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev" <bitcoin-dev@lists.
> linuxfoundation.org> 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: 7106 bytes --]