diff options
author | Erik Aronesty <earonesty@gmail.com> | 2017-04-05 22:27:34 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2017-04-06 02:27:36 +0000 |
commit | 7ee4fe6bf5b15ed09bba7d5b977d9a08ecf1d7c1 (patch) | |
tree | 34e9d66e201182a21005bd0555365e1c91365d82 | |
parent | 47b9a8333004c95cc4a0b400a8d7397c92cdb5ec (diff) | |
download | pi-bitcoindev-7ee4fe6bf5b15ed09bba7d5b977d9a08ecf1d7c1.tar.gz pi-bitcoindev-7ee4fe6bf5b15ed09bba7d5b977d9a08ecf1d7c1.zip |
Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For Comments
-rw-r--r-- | b9/7385e3813fe92faeb88a3dad74faa1f4d5e868 | 178 |
1 files changed, 178 insertions, 0 deletions
diff --git a/b9/7385e3813fe92faeb88a3dad74faa1f4d5e868 b/b9/7385e3813fe92faeb88a3dad74faa1f4d5e868 new file mode 100644 index 000000000..7c66212a0 --- /dev/null +++ b/b9/7385e3813fe92faeb88a3dad74faa1f4d5e868 @@ -0,0 +1,178 @@ +Return-Path: <earonesty@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id F2D8B98C + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Thu, 6 Apr 2017 02:27:36 +0000 (UTC) +Received: by mail-qt0-f178.google.com with SMTP id i34so26172235qtc.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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: <CADJgMztpmcC_rv_oKYn_jRhLzx2FbtxgPUshcPDJpQVZYBcJzw@mail.gmail.com> +References: <CAKzdR-oN6tGvGSb04_awCf=Jsf3wgKJN5xUhCr8G2D2W9YgJww@mail.gmail.com> + <CADJgMztpmcC_rv_oKYn_jRhLzx2FbtxgPUshcPDJpQVZYBcJzw@mail.gmail.com> +From: Erik Aronesty <earonesty@gmail.com> +Date: Wed, 5 Apr 2017 22:27:34 -0400 +Message-ID: <CAJowKgLUrMR9XN2Sb9ZuXCZx3K8Jy65pOOYGVhYeisszPoWLdA@mail.gmail.com> +To: Btc Drak <btcdrak@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + +<div dir=3D"auto"><div dir=3D"auto">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?<br>= +</div><div dir=3D"auto"><br></div><div dir=3D"auto">- maybe the proposal sh= +ould be renamed segwit 8mb and be discussed solely in terms of block weight= +s.</div><div dir=3D"auto"><div dir=3D"auto"><br></div><div dir=3D"auto">- 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</div><div dir=3D"auto"><br><span style=3D"font-family:san= +s-serif">- miners who currently object to segwit while pretending to like l= +arger blocks will find some excuse to object to this too.</span><br></div><= +div dir=3D"auto"><span style=3D"font-family:sans-serif"><br></span></div><d= +iv dir=3D"auto"><span style=3D"font-family:sans-serif">-=C2=A0</span><span = +style=3D"font-family:sans-serif">Given the challenges miners seem to have i= +n flipping bits, I expect any fork that requires 95pct hash power to be vap= +orware.</span></div></div></div><div class=3D"gmail_extra"><br><div class= +=3D"gmail_quote">On Apr 3, 2017 11:02 AM, "Btc Drak via bitcoin-dev&qu= +ot; <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-de= +v@lists.linuxfoundation.org</a>> wrote:<br type=3D"attribution"><blockqu= +ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s= +olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla= +ss=3D"gmail_quote">On Fri, Mar 31, 2017 at 10:09 PM, Sergio Demian Lerner v= +ia bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bitcoin-dev@lists.li= +nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation= +.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma= +rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt= +r"><div>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)</div></div></blockquote= +><div><br></div><div>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?<br></div><div><br></div><div>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.</div></div>= +</div></div> +<br>______________________________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= +<wbr>linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-<wbr>dev</a><br> +<br></blockquote></div></div> + +--001a11c0342a7e4ce3054c7640d0-- + |