diff options
| author | Jorge Timón <jtimon@jtimon.cc> | 2016-02-06 18:09:21 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-02-06 17:09:23 +0000 |
| commit | a1a796cf8127a5b6117dd2cfd0264386fb5f94e3 (patch) | |
| tree | 6bdac07be111b433361905a71fe7a05f59bc18cf | |
| parent | 1ddd17778c2bf5e41a52fdf7936c3906d79de3d3 (diff) | |
| download | pi-bitcoindev-a1a796cf8127a5b6117dd2cfd0264386fb5f94e3.tar.gz pi-bitcoindev-a1a796cf8127a5b6117dd2cfd0264386fb5f94e3.zip | |
Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 megabytes
| -rw-r--r-- | e4/740016fb767a75523f82b8ed7acc7dfc118d0f | 152 |
1 files changed, 152 insertions, 0 deletions
diff --git a/e4/740016fb767a75523f82b8ed7acc7dfc118d0f b/e4/740016fb767a75523f82b8ed7acc7dfc118d0f new file mode 100644 index 000000000..a7bdbf1d1 --- /dev/null +++ b/e4/740016fb767a75523f82b8ed7acc7dfc118d0f @@ -0,0 +1,152 @@ +Return-Path: <jtimon@jtimon.cc> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 3C97A10A4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 6 Feb 2016 17:09:23 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com + [209.85.213.46]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id ADB0013E + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 6 Feb 2016 17:09:22 +0000 (UTC) +Received: by mail-vk0-f46.google.com with SMTP id k196so7331848vka.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sat, 06 Feb 2016 09:09:22 -0800 (PST) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=jtimon-cc.20150623.gappssmtp.com; s=20150623; + h=mime-version:in-reply-to:references:date:message-id:subject:from:to + :cc:content-type; + bh=JiaQ5FIs3J2oI8E0pSMfnmp//v4ujE4AZF6P7Jz3JCM=; + b=XIWml1shD7Ie5g02qQ1QG3BMNcWXOd+zvM/h8ZdFrrvJb6HNP/hDFwMwLzWFzd2TTm + apVIa0StFabAO179v8dUK9FA0gEzVz/0/Akw7yivDtoNtgYaUtUh0Q8F3Zj9GgA39sUe + GjGaBUZCjaOx27ENrrweFSjUR/itIsafH89QcFAFLzKVj6y7jxCKCm4M3Y+S1JbBz/S8 + tX6FNw0U2nE93CXweEOKrnaFxyHcSOxnhDIZ8bYFEatORuZ7/HxCfA0RGAnEtehcJYLh + s0SV7TG4lClPmg6RQaBWoy7aPYx2mEeC2Ccy88op0SMHPz32wgmprreexUEX9xDERzTW + fWAg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:in-reply-to:references:date + :message-id:subject:from:to:cc:content-type; + bh=JiaQ5FIs3J2oI8E0pSMfnmp//v4ujE4AZF6P7Jz3JCM=; + b=IdxX47OtSyEZ62sDGRaSJoYb/GhUG03FtEskhxRc430Z044tfQmjOgeGyr5YI0wMVd + 4VieCyKm3whwAtzwmu4pLlHWsaA1eY+keMZHhIVXZBUEZQV7Esk3kwuPL9X92+z0Uhm3 + voa4dqRzNNQFalEdxP06pH5zThKlZbewfMe/2SVDfz1UxBSsX2wACdc7blGJbKmeWY8t + rNxbd00fr1Wx7X06r5LT84i20xq0a9HrdxsPq+7GJw1czzvnF5fsCL/3q5RJmT/Y6KtH + 30EME1AjyQjkk7yopGCu1r0tpZASySHk8WKsRA8dYv0yYwRUgx/1ajqJg2Pxf++yKOKh + bi9g== +X-Gm-Message-State: AG10YOSJIaw/oMC34cHkPek31RATqiECtS/yWv24yGF7pTztVvg2ZKMonqtItp78/XFWEFUtgzVIsRs03g8cwA== +MIME-Version: 1.0 +X-Received: by 10.31.16.153 with SMTP id 25mr13491501vkq.143.1454778561871; + Sat, 06 Feb 2016 09:09:21 -0800 (PST) +Received: by 10.31.141.73 with HTTP; Sat, 6 Feb 2016 09:09:21 -0800 (PST) +Received: by 10.31.141.73 with HTTP; Sat, 6 Feb 2016 09:09:21 -0800 (PST) +In-Reply-To: <CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com> +References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com> + <201602060012.26728.luke@dashjr.org> + <CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com> + <CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com> +Date: Sat, 6 Feb 2016 18:09:21 +0100 +Message-ID: <CABm2gDoungCbB22_SKHcedBKegWEPpjeM2woxLGchC4=om8BrA@mail.gmail.com> +From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc> +To: Gavin Andresen <gavinandresen@gmail.com> +Content-Type: multipart/alternative; boundary=001a11433b906855b1052b1d07df +X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2 + megabytes +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development 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: Sat, 06 Feb 2016 17:09:23 -0000 + +--001a11433b906855b1052b1d07df +Content-Type: text/plain; charset=UTF-8 + +On Feb 6, 2016 16:37, "Gavin Andresen" <gavinandresen@gmail.com> wrote: +> +> Responding to "28 days is not long enough" : + +Any thoughts on the "95% better than 75%" and "grace period before miner +coordination instead of after" comments ? + +> I suspect there ARE a significant percentage of un-maintained full +nodes-- probably 30 to 40%. Losing those nodes will not be a problem, for +three reasons: + +None of the reasons you list say anything about the fact that "being lost" +(kicked out of the network) is a problem for those node's users. + +> I strongly disagree with the statement that there is no cost to a longer +grace period. + +I didn't say that. + +> To bring it back to bitcoin-dev territory: are there any TECHNICAL +arguments why an upgrade would take a business or individual longer than 28 +days? + +Their own software stack may require more work to integrate the new rules +or their resources may not be immediately available to focus on this within +28 days they hadn't planned. + +I believe it wold be less controversial to chose something that nobody can +deny is more than plenty of time for everyone to implement the changes +like, say, 1 year. I wouldn't personally oppose to something shorter like 6 +months for really simple changes, but I don't see how 28 can ever be +considered uncontroversial and safe for everyone. Just trying to help in +removing controversy from the PR, but if you still think 28 can be safe and +uncontroversial, feel free to ignore these comments on the concrete length +and please let me know what you think about the other points I raised. + +--001a11433b906855b1052b1d07df +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<p dir=3D"ltr"><br> +On Feb 6, 2016 16:37, "Gavin Andresen" <<a href=3D"mailto:gavi= +nandresen@gmail.com">gavinandresen@gmail.com</a>> wrote:<br> +><br> +> Responding to "28 days is not long enough" :</p> +<p dir=3D"ltr">Any thoughts on the "95% better than 75%" and &quo= +t;grace period before miner coordination instead of after" comments ?<= +/p> +<p dir=3D"ltr">> I suspect there ARE a significant percentage of un-main= +tained full nodes-- probably 30 to 40%. Losing those nodes will not be a pr= +oblem, for three reasons:</p> +<p dir=3D"ltr">None of the reasons you list say anything about the fact tha= +t "being lost" (kicked out of the network) is a problem for those= + node's users.</p> +<p dir=3D"ltr">> I strongly disagree with the statement that there is no= + cost to a longer grace period.</p> +<p dir=3D"ltr">I didn't say that.</p> +<p dir=3D"ltr">> To bring it back to bitcoin-dev territory: =C2=A0are th= +ere any TECHNICAL arguments why an upgrade would take a business or individ= +ual longer than 28 days?</p> +<p dir=3D"ltr">Their own software stack may require more work to integrate = +the new rules or their resources may not be immediately available to focus = +on this within 28 days they hadn't planned.</p> +<p dir=3D"ltr">I believe it wold be less controversial to chose something t= +hat nobody can deny is more than plenty of time for everyone=C2=A0 to imple= +ment the changes like, say, 1 year. I wouldn't personally oppose to som= +ething shorter like 6 months for really simple changes, but I don't see= + how 28 can ever be considered uncontroversial and safe for everyone. Just = +trying to help in removing controversy from the PR, but if you still think = +28 can be safe and uncontroversial, feel free to ignore these comments on t= +he concrete length and please let me know what you think about the other po= +ints I raised.<br> +</p> + +--001a11433b906855b1052b1d07df-- + |