a0b96d504a51dcf16a2cdb8ef59db2e56b06bf
1 Return-Path: <alp.bitcoin@gmail.com> 2 Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org 3 [172.17.192.35]) 4 by mail.linuxfoundation.org (Postfix) with ESMTPS id 8717A8EE 5 for <bitcoin-dev@lists.linuxfoundation.org>; 6 Tue, 28 Mar 2017 17:23:33 +0000 (UTC) 7 X-Greylist: whitelisted by SQLgrey-1.7.6 8 Received: from mail-pg0-f66.google.com (mail-pg0-f66.google.com [74.125.83.66]) 9 by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1459623A 10 for <bitcoin-dev@lists.linuxfoundation.org>; 11 Tue, 28 Mar 2017 17:23:32 +0000 (UTC) 12 Received: by mail-pg0-f66.google.com with SMTP id 81so22788069pgh.3 13 for <bitcoin-dev@lists.linuxfoundation.org>; 14 Tue, 28 Mar 2017 10:23:32 -0700 (PDT) 15 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 16 h=mime-version:in-reply-to:references:from:date:message-id:subject:to; 17 bh=lfA7XXirNhsmE9ToxfExKdOApwQCTdkZPdoOmkXKCLE=; 18 b=gS9/txsKTkLHyolVqwK5iQCPTHd66kl/zMlijU2Ed368412b7Jdk3XTth9lhYyGzZA 19 oertwQAslBRfXBEqwectGz7V1XybNtPTfjsbV0fZ1Mdyookqgk9oaxwX0FDMv9D12yI5 20 9rcgShY6byTjDxutoDV3ye/TtPsvNGcSSSfmvHUZW1xlmFAT6LN8ligW+kKVfZA9QY2z 21 O1c0ywlX9lNjmp6EcoY9B7lCLv1FOdeOjZ6mL/3ee3ktfxrlbiWzKHu0rRXSEYgRyW/v 22 GPLRNWPlwnaqWADl2zXbsNPTFUcnSigZZ1j2JEz+8fJVQKkIPYLEKFE32XZsvgQL/aXE 23 HWhQ== 24 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 25 d=1e100.net; s=20161025; 26 h=x-gm-message-state:mime-version:in-reply-to:references:from:date 27 :message-id:subject:to; 28 bh=lfA7XXirNhsmE9ToxfExKdOApwQCTdkZPdoOmkXKCLE=; 29 b=Dwcq22z6FMCsC3piimjVI5zj6mkkh5Id4W/YImDttE4yhmQSmOrZiUXBwexiooXaoJ 30 72w4+2qLkpQJ1oeqkkkA+NxSVHUoFjp7nUeg+vgoSAqV2JHpZisv8CE0FmnrqEvSQ1oG 31 0RLV9C2R/x1VWShw5lFreIbGbLbXoKjMrDHo7cDpZ9JQHrbWYxD5hlI7kG2QvwXgvpWc 32 UwUiOgrIUXnGnu96bpDv0eCDIQGh1DxNWDI720xjalBO3lKpHr5FeGHxeQOM/fyMpAKm 33 icSVtNTgG/mvnuPRD6njvvQJ7/Qv+BMeunyaIHd2bNPL4dFCfqsefulch//67Lrf7NTT 34 9P4Q== 35 X-Gm-Message-State: AFeK/H3IjM0nxfTbSBi/uB3+dhnmpVOBcx6FPche51ZlmAjHOhBt8dmNmcoVWJTtJfS3dktsCLhNZRMZxNE5BQ== 36 X-Received: by 10.99.140.27 with SMTP id m27mr32009080pgd.174.1490721811890; 37 Tue, 28 Mar 2017 10:23:31 -0700 (PDT) 38 MIME-Version: 1.0 39 Received: by 10.100.128.19 with HTTP; Tue, 28 Mar 2017 10:23:31 -0700 (PDT) 40 In-Reply-To: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com> 41 References: <CAFzgq-xizPMNqfvW11nUhd6HmfZu8aGjcR9fshEsf6o5HOt_dA@mail.gmail.com> 42 From: Alphonse Pace <alp.bitcoin@gmail.com> 43 Date: Tue, 28 Mar 2017 12:23:31 -0500 44 Message-ID: <CAMBsKS8oSKS5g8UEyCu18bjzGJWpA+sJEaxBUV9FXAmXhX1ApA@mail.gmail.com> 45 To: Wang Chun <1240902@gmail.com>, 46 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> 47 Content-Type: multipart/alternative; boundary=94eb2c1b6a240e874b054bcdb865 48 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, 49 DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, 50 RCVD_IN_DNSWL_NONE, 51 RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 52 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on 53 smtp1.linux-foundation.org 54 Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting 55 X-BeenThere: bitcoin-dev@lists.linuxfoundation.org 56 X-Mailman-Version: 2.1.12 57 Precedence: list 58 List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> 59 List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 60 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> 61 List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> 62 List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> 63 List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> 64 List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 65 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> 66 X-List-Received-Date: Tue, 28 Mar 2017 17:23:33 -0000 67 68 --94eb2c1b6a240e874b054bcdb865 69 Content-Type: text/plain; charset=UTF-8 70 71 What meeting are you referring to? Who were the participants? 72 73 Removing the limit but relying on the p2p protocol is not really a true 74 32MiB limit, but a limit of whatever transport methods provide. This can 75 lead to differing consensus if alternative layers for relaying are used. 76 What you seem to be asking for is an unbound block size (or at least 77 determined by whatever miners produce). This has the possibility (and even 78 likelihood) of removing many participants from the network, including many 79 small miners. 80 81 32MB in less than 3 years also appears to be far beyond limits of safety 82 which are known to exist far sooner, and we cannot expect hardware and 83 networking layers to improve by those amounts in that time. 84 85 It also seems like it would be much better to wait until SegWit activates 86 in order to truly measure the effects on the network from this increased 87 capacity before committing to any additional increases. 88 89 -Alphonse 90 91 92 93 On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev < 94 bitcoin-dev@lists.linuxfoundation.org> wrote: 95 96 > I've proposed this hard fork approach last year in Hong Kong Consensus 97 > but immediately rejected by coredevs at that meeting, after more than 98 > one year it seems that lots of people haven't heard of it. So I would 99 > post this here again for comment. 100 > 101 > The basic idea is, as many of us agree, hard fork is risky and should 102 > be well prepared. We need a long time to deploy it. 103 > 104 > Despite spam tx on the network, the block capacity is approaching its 105 > limit, and we must think ahead. Shall we code a patch right now, to 106 > remove the block size limit of 1MB, but not activate it until far in 107 > the future. I would propose to remove the 1MB limit at the next block 108 > halving in spring 2020, only limit the block size to 32MiB which is 109 > the maximum size the current p2p protocol allows. This patch must be 110 > in the immediate next release of Bitcoin Core. 111 > 112 > With this patch in core's next release, Bitcoin works just as before, 113 > no fork will ever occur, until spring 2020. But everyone knows there 114 > will be a fork scheduled. Third party services, libraries, wallets and 115 > exchanges will have enough time to prepare for it over the next three 116 > years. 117 > 118 > We don't yet have an agreement on how to increase the block size 119 > limit. There have been many proposals over the past years, like 120 > BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so 121 > on. These hard fork proposals, with this patch already in Core's 122 > release, they all become soft fork. We'll have enough time to discuss 123 > all these proposals and decide which one to go. Take an example, if we 124 > choose to fork to only 2MB, since 32MiB already scheduled, reduce it 125 > from 32MiB to 2MB will be a soft fork. 126 > 127 > Anyway, we must code something right now, before it becomes too late. 128 > _______________________________________________ 129 > bitcoin-dev mailing list 130 > bitcoin-dev@lists.linuxfoundation.org 131 > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev 132 > 133 134 --94eb2c1b6a240e874b054bcdb865 135 Content-Type: text/html; charset=UTF-8 136 Content-Transfer-Encoding: quoted-printable 137 138 <div dir=3D"ltr">What meeting are you referring to?=C2=A0 Who were the part= 139 icipants?<div><br></div><div>Removing the limit but relying on the p2p prot= 140 ocol is not really a true 32MiB limit, but a limit of whatever transport me= 141 thods provide.=C2=A0 This can lead to differing consensus if alternative la= 142 yers for relaying are used.=C2=A0 What you seem to be asking for is an unbo= 143 und block size (or at least determined by whatever miners produce).=C2=A0 T= 144 his has the possibility (and even likelihood) of removing many participants= 145 from the network, including many small miners. =C2=A0</div><div><br></div>= 146 <div>32MB in less than 3 years also appears to be far beyond limits of safe= 147 ty which are known to exist far sooner, and we cannot expect hardware and n= 148 etworking layers to improve by those amounts in that time.</div><div><br></= 149 div><div>It also seems like it would be much better to wait until SegWit ac= 150 tivates in order to truly measure the effects on the network from this incr= 151 eased capacity before committing to any additional increases.</div><div><br= 152 ></div><div>-Alphonse</div><div><br></div><div><br></div></div><div class= 153 =3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, Mar 28, 2017 at 11:= 154 59 AM, Wang Chun via bitcoin-dev <span dir=3D"ltr"><<a href=3D"mailto:bi= 155 tcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.li= 156 nuxfoundation.org</a>></span> wrote:<br><blockquote class=3D"gmail_quote= 157 " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I= 158 've proposed this hard fork approach last year in Hong Kong Consensus<b= 159 r> 160 but immediately rejected by coredevs at that meeting, after more than<br> 161 one year it seems that lots of people haven't heard of it. So I would<b= 162 r> 163 post this here again for comment.<br> 164 <br> 165 The basic idea is, as many of us agree, hard fork is risky and should<br> 166 be well prepared. We need a long time to deploy it.<br> 167 <br> 168 Despite spam tx on the network, the block capacity is approaching its<br> 169 limit, and we must think ahead. Shall we code a patch right now, to<br> 170 remove the block size limit of 1MB, but not activate it until far in<br> 171 the future. I would propose to remove the 1MB limit at the next block<br> 172 halving in spring 2020, only limit the block size to 32MiB which is<br> 173 the maximum size the current p2p protocol allows. This patch must be<br> 174 in the immediate next release of Bitcoin Core.<br> 175 <br> 176 With this patch in core's next release, Bitcoin works just as before,<b= 177 r> 178 no fork will ever occur, until spring 2020. But everyone knows there<br> 179 will be a fork scheduled. Third party services, libraries, wallets and<br> 180 exchanges will have enough time to prepare for it over the next three<br> 181 years.<br> 182 <br> 183 We don't yet have an agreement on how to increase the block size<br> 184 limit. There have been many proposals over the past years, like<br> 185 BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so<br> 186 on. These hard fork proposals, with this patch already in Core's<br> 187 release, they all become soft fork. We'll have enough time to discuss<b= 188 r> 189 all these proposals and decide which one to go. Take an example, if we<br> 190 choose to fork to only 2MB, since 32MiB already scheduled, reduce it<br> 191 from 32MiB to 2MB will be a soft fork.<br> 192 <br> 193 Anyway, we must code something right now, before it becomes too late.<br> 194 ______________________________<wbr>_________________<br> 195 bitcoin-dev mailing list<br> 196 <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.= 197 <wbr>linuxfoundation.org</a><br> 198 <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = 199 rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= 200 /mailman/listinfo/bitcoin-<wbr>dev</a><br> 201 </blockquote></div><br></div> 202 203 --94eb2c1b6a240e874b054bcdb865-- 204