Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F2D8B98C for ; Thu, 6 Apr 2017 02:27:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f178.google.com (mail-qt0-f178.google.com [209.85.216.178]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 52FB71BD for ; Thu, 6 Apr 2017 02:27:36 +0000 (UTC) Received: by mail-qt0-f178.google.com with SMTP id i34so26172235qtc.0 for ; Wed, 05 Apr 2017 19:27:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=GhKpY1Ec2eC42m6/iTj1bH02JGCIueD+lkTYiilRkAQ=; b=oVr+HQFWAZF6yXkEP3q3XjeI/DmLplkeWjg4Ew6O5iGIpMmHhoMmecO1JlMrRgirQV 1Pa2yKk7I7CkVVU7jd7T0pIU/sXpunaUdJ74pVp4uTr1h8Epc/13Vylrewnrwok51EED w8MuTnnmLDRWnKcrexax6Q+mTtlllL+kpRntdI1IjjzcdT2sVZhZkPj97AuYK2o2sJ+1 utHo9QZ53bI2g6sdn9qPE+QMLKcaZUqvNyWlc7+qDRvw9gc1hzFlkit2ID0i6QRPJWi/ Mh9jHOT48jy5YUlXIHIZbjEDg6obEK6m2Ze85X/iF6kxiWvOjRSAb1scOLRvQL7GEqr6 l5hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=GhKpY1Ec2eC42m6/iTj1bH02JGCIueD+lkTYiilRkAQ=; b=uXeDMJy1Ml3aG6m60RvAkFoRJKB2h0H7giNaoLm5PYAPTjTNvNNJ4zZEHYZbTA95IU 26OzUkGAGQFTNM7pcg3cW6VE5PGBn1W5sU7spJ0/eNwryb5U7xMoEd1+LdgyRDFbuhte 92HQrYYxkaKscWG1czd5qS0ficdaWmzFl6COqsT8kUZ2L1l3n4l5Vv7pQaqmjkG56qI3 sLV+tDlKhL5nJcDpuhlt2dVHUOdsFDBWz27msIQwsn+ApQSV8zGbp/0hoHpDU8EcD8cn JOGVArLVYBRcwIiWfFQPBB1qaedbjY2bVGoh6UBeEbqirO2ju5Bi7AjFoUxiTBNiuhzl 6TsA== X-Gm-Message-State: AFeK/H2lj7WQxZO6/tN7bPkKzRHAb4O6lnNF4g9pmFeN4qLRbqDVHkS9xvKnGt2PbeBAuY/YI9NiP/LxBKCF+w== X-Received: by 10.200.43.17 with SMTP id 17mr30006874qtu.199.1491445655421; Wed, 05 Apr 2017 19:27:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.200.55.113 with HTTP; Wed, 5 Apr 2017 19:27:34 -0700 (PDT) Received: by 10.200.55.113 with HTTP; Wed, 5 Apr 2017 19:27:34 -0700 (PDT) Reply-To: erik@q32.com In-Reply-To: References: From: Erik Aronesty Date: Wed, 5 Apr 2017 22:27:34 -0400 Message-ID: To: Btc Drak , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a11c0342a7e4ce3054c7640d0 X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 06 Apr 2017 02:29:17 +0000 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 02:27:37 -0000 --001a11c0342a7e4ce3054c7640d0 Content-Type: text/plain; charset=UTF-8 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? - maybe the proposal should be renamed segwit 8mb and be discussed solely in terms of block weights. - 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. - miners who currently object to segwit while pretending to like larger blocks will find some excuse to object to this too. - Given the challenges miners seem to have in flipping bits, I expect any fork that requires 95pct hash power to be vaporware. 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 > > --001a11c0342a7e4ce3054c7640d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I personally appreciate the minimal cha= nges, and often encourage development to be done this way - when it needs t= o be released quickly.=C2=A0 But does this need to be released quickly?
=

- maybe the proposal sh= ould be renamed segwit 8mb and be discussed solely in terms of block weight= s.

- a= high consensus hard fork is probably preferable to a low consensus soft fo= rk, however there is nothing to indicate that segwit as it stands isnt alre= ady very high consensus except for a handful of pool operators protecting f= ee income. =C2=A0

- miners who currently object to segwit while pretending to like l= arger blocks will find some excuse to object to this too.
<= div dir=3D"auto">
-=C2=A0Given the challenges miners seem to have i= n flipping bits, I expect any fork that requires 95pct hash power to be vap= orware.

On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev&qu= ot; <bitcoin-de= v@lists.linuxfoundation.org> wrote:
On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner v= ia bitcoin-dev <bitcoin-dev@lists.linuxfoundation= .org> wrote:
The hard-fork is conditional to 95% of the hashing power has approv= ed the segwit2mb soft-fork and the segwit soft-fork has been activated (whi= ch 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 i= nterested in the research that Johnson in particular is pioneering. However= , I have failed to understand your point about 95% miner signalling in rela= tion 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

--001a11c0342a7e4ce3054c7640d0--