From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5AEF8A5E for ; Thu, 6 Apr 2017 20:59:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 857642C6 for ; Thu, 6 Apr 2017 20:59:37 +0000 (UTC) Received: by mail-qk0-f170.google.com with SMTP id p22so48293164qka.3 for ; Thu, 06 Apr 2017 13:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Qb2ej5Z//XzBpBR+5nCpJQNSbyDfIjiaOMYxq5YKjNE=; b=JTG9ia/ZKDSy5rvrGN8jsr29IYuYxYMdMWlphVXJS1oHVQQnhUjvCJ2U/InNjvp6dN wmHRTv7gsIiYlc6AUbimUTQr+uM6Uu3wKeaH9eaEAYq125xuSde+NzgmSvXZusf3FEQ2 7jJMgtRvhAf0I7nYZkkcXN/frTgNT6/+wTid++SZzhTuf+4al/dJuA478a7L5LUmYYVu WOzpdlawQIiwGaV5hAUrYv0jTRl1hUvEuBuKiwxorhZXmvrqK3puLezwq/b1UuJA6gcE FSvNMbyoL8KoqtUewR2GQqkpyBaMqy9gzFGxewPkxaZRFKFaAO5I+e6jhpZVkLOMGDnX K20A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Qb2ej5Z//XzBpBR+5nCpJQNSbyDfIjiaOMYxq5YKjNE=; b=OFU9OB6xkW/s2wGhV3Yp29mfLtHVMTbtKdR9xwq6YT1b8z78kV3vVrCYXR6teOFHg7 ZCXjUdEP6SPiHzSfmt6X6PZrU9xehlQNm+Nu18ZsDOWQWRiRzDWBvgiXUSWdTH16msi+ ra79v7Tj/yUj+PLE0CLDd8wBffGA0cb0dSIkGDYMWcEwvZM8YcEygx1NOhh0m2roXw0m aqHb/lux3OLsxuajRMLMiHaHqhfoP5LJLMmVssqCfWz47ghlT4o+uN1Uj7g9IK/2EbVB r7PxHs/3b3AdOsBOmUi49ryUe5POdJjpFxTiX9svMgJxMj72eWdccJlXqj2LvEVlQzNP DUEw== X-Gm-Message-State: AFeK/H0MqZBIocDivPtIuFp0KvoCGGQ//G2HPPkzYFL046kzHy2//0PWtYRPN5si7hhgA0cPpfrsr/TCoZ4FcQ== X-Received: by 10.55.148.71 with SMTP id w68mr36899412qkd.268.1491512376760; Thu, 06 Apr 2017 13:59:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.170.220 with HTTP; Thu, 6 Apr 2017 13:58:56 -0700 (PDT) In-Reply-To: References: From: Sergio Demian Lerner Date: Thu, 6 Apr 2017 17:58:56 -0300 Message-ID: To: erik@q32.com Content-Type: multipart/alternative; boundary=94eb2c085880652551054c85c9ec X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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 Cc: Bitcoin Protocol Discussion 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 20:59:38 -0000 --94eb2c085880652551054c85c9ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Responding between lines... On Wed, Apr 5, 2017 at 11:27 PM, Erik Aronesty 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, =E2= =80=9Ca 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.=E2=80=9D. As standard blocks are a combination betwee= n 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" 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 (wh= ich >>> 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, w= hat >> 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 poin= t >> 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 >> >> --94eb2c085880652551054c85c9ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Responding between lines...
=
On Wed, Apr 5, 2017 at 11:27 PM, Erik Arones= ty <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.=C2=A0 But does this need = to be released quickly?


Segwit2mb is a last resort option. It does not nee= d 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.
= =C2=A0
- maybe the proposal should = be renamed segwit 8mb and be discussed solely in terms of block weights.

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

I also disagree with the idea that segwit2mb i= s a 8mb increase.=C2=A0As stated by in the Bitcon.org website [1] and backe= d up by scientific research, =E2=80=9Ca block filled with standard single-s= ignature P2PKH transactions would be about 1.6MB and a block filled with 2-= of-2 multisignature transactions would be about 2.0MB.=E2=80=9D. As standar= d blocks are a combination between P2PKH, and 2-of-3 multisignatures, the a= ctual average segwit block size will be close to 2.0MB.

Because Segw= it2Mb doubles the maximum size of a block, the average block size for a blo= ck filed with average transactions is 4.0Mb.

[1] <= a href=3D"https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#segwit= -size">https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#segwit-si= ze

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



> a high consensus hard fork is prob= ably preferable to a low consensus soft fork, however there is nothing to i= ndicate that segwit as it stands isnt already very high consensus except fo= r a handful of pool operators protecting fee income. =C2=A0
=C2= =A0
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 understan= ds the others may have reasons that do not match ours.=C2=A0

=
Last, if this proposal is rejected by any side, then we'll d= efinitively learn that side is not looking for any consensual resolution of= the conflict.
=C2=A0
- miners who currently object to segwit while= pretending to like larger blocks will find some excuse to object to this t= oo.


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 an= d the information we can gather in case one of the sides rejects it.
<= div>
However, I've received positive feedback from them u= ntil now.
=C2=A0
-=C2=A0Gi= ven 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,=C2=A0
Sergio.
=C2=A0
=

On Apr 3, 201= 7 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> wr= ote:
=
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 has= h power indicates they are running this proposal, but the nodes don't u= pgrade, what will happen?

For the record, I ac= tually talk a lot about hard forks with various developers and am very inte= rested in the research that Johnson in particular is pioneering. However, I= have failed to understand your point about 95% miner signalling in relatio= n 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


--94eb2c085880652551054c85c9ec--