Opening a mailing list thread on this BIP:

BIP PR:=C2=A0https://github.com/bitcoin/bips/pull/173

Code PR:=C2=A0https://github.com/bitcoin/bi= tcoin/pull/6451

The general intent of this BIP= is as a minimum viable alternative plan to my preferred proposal (BIP 100)= .

If agreement is not reached on a more comprehens= ive solution, then this solution is at least available and a known quantity= .=C2=A0 A good backup plan.

Benefits: =C2=A0conser= vative increase. =C2=A0proves network can upgrade. =C2=A0permits some added= growth, while the community & market gathers data on how an increased = block size impacts privacy, security, centralization, transaction throughpu= t and other metrics. =C2=A02MB seems to be a Least Common Denominator on an= increase.

Costs: =C2=A0requires a hard fork. =C2= =A0requires another hard fork down the road.

<= /div>

--001a11c28b62010f07051b14373b-- 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 98BC941C for ; Fri, 17 Jul 2015 16:11:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E808E63 for ; Fri, 17 Jul 2015 16:11:17 +0000 (UTC) Received: by ieik3 with SMTP id k3so80773307iei.3 for ; Fri, 17 Jul 2015 09:11:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=mTV9zYroF+gLQ3CMSpvza24bnQfq8lLcYHaha2hzOMM=; b=HyjPCQ8klKKlBWrlM/6kyPNQofHayMAtNJAwi63U1eVEboSwZh9uw5OR+/X/tHEpaF dyjOIh+WXZ8sx/unDAuaizwrMvuUFhsK7hhYXEoQf1U3nUmPZi4gOED6J23o66DwcOV1 Tx5dAxop1AC62YoU56ZFhdbNmmthLvy4SYhuTeakKyLfqIqfX+NyyoyDalKPhhqDkU7f OxxMbZa28qZfxTZxeebI4jH6+/GYdZbQ2PJ8RpyUVbTWqb2it/z54oMI8amjl0qWuZhY J+NdAvppPPuYWHCglTU8Zjk/ipiCGyJBB4X/+mNnwt5B1y9o5smNXE5TrmoFMbRl7MMU hOvA== MIME-Version: 1.0 X-Received: by 10.50.143.104 with SMTP id sd8mr11807777igb.34.1437149477326; Fri, 17 Jul 2015 09:11:17 -0700 (PDT) Sender: akaramaoun@gmail.com Received: by 10.107.134.196 with HTTP; Fri, 17 Jul 2015 09:11:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jul 2015 16:11:17 +0000 X-Google-Sender-Auth: gtVyPayRRaYpKM8bwSEUs3uvGkw Message-ID: From: Andrew To: Jeff Garzik Content-Type: multipart/alternative; boundary=001a1135f1a61606d5051b147052 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 16:11:18 -0000 --001a1135f1a61606d5051b147052 Content-Type: text/plain; charset=UTF-8 What are you trying to do? Break the ice with a hard fork so that later it becomes easier to do so, with people more complacent towards it? There are many solutions to the scaling problem that do not require a hard fork and are quite simple to implement actually, and don't come with the complications involved with a hard fork. I'm not a reputable developer on this list, so my opinion probably doesn't matter much, but I watched and analyzed this situation closely and I don't like this idea. On Fri, Jul 17, 2015 at 3:55 PM, Jeff Garzik via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > Code PR: https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative plan to > my preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then this > solution is at least available and a known quantity. A good backup plan. > > Benefits: conservative increase. proves network can upgrade. permits > some added growth, while the community & market gathers data on how an > increased block size impacts privacy, security, centralization, transaction > throughput and other metrics. 2MB seems to be a Least Common Denominator > on an increase. > > Costs: requires a hard fork. requires another hard fork down the road. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > -- PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647 --001a1135f1a61606d5051b147052 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

What are you trying to do? Break the ice with a hard fork = so that later it becomes easier to do so, with people more complacent towar= ds it? There are many solutions to the scaling problem that do not require = a hard fork and are quite simple to implement actually, and don't come = with the complications involved with a hard fork. I'm not a reputable d= eveloper on this list, so my opinion probably doesn't matter much, but = I watched and analyzed this situation closely and I don't like this ide= a.

On Fr= i, Jul 17, 2015 at 3:55 PM, Jeff Garzik via bitcoin-dev &= lt;bitcoin-dev@lists.linuxfoundation.org> wrote:

Opening a mailing list thread o= n this BIP:

BIP PR:=C2=A0https://github.com/bitcoin/bips/pu= ll/173

Code PR:=C2=A0https://github.com/bitcoin/bitcoin/pull/6451

The general intent of this BIP is as a minimum = viable alternative plan to my preferred proposal (BIP 100).

<= /div>

If agreement is not reached on a more comprehensive solution, the= n this solution is at least available and a known quantity.=C2=A0 A good ba= ckup plan.

Benefits: =C2=A0conservative increase. = =C2=A0proves network can upgrade. =C2=A0permits some added growth, while th= e community & market gathers data on how an increased block size impact= s privacy, security, centralization, transaction throughput and other metri= cs. =C2=A02MB seems to be a Least Common Denominator on an increase.

<= div>

Costs: =C2=A0requires a hard fork. =C2=A0requires anothe= r hard fork down the road.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647

--001a1135f1a61606d5051b147052-- 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 2EB11482 for ; Fri, 17 Jul 2015 16:12:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B7690121 for ; Fri, 17 Jul 2015 16:12:06 +0000 (UTC) Received: by qgep37 with SMTP id p37so49224145qge.1 for ; Fri, 17 Jul 2015 09:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=gu0uZs5XRjnI4Y6VV3tHhq0gdjQ860XCTixP77h7gNY=; b=uaXx5/XLExg6DWo+SYEHtRm6SDjehShiTIppbNBvqhHGA2/KtKBrwnZN6lvT6EGOYA 1f1o6ZIiuU6XLR3o2QcpC/CbAen4FRYkl9DEOmfjdwQ5IbBiMHbWBwRpzF4gw2/jVehd JhGhcd9vextYBBCOW/6OQ31rZjKT2bp4K3DsWRqFoVkO53bWW16dWyox9SA95gytaj65 nWk+Yu75a77vq9pbFrtPNevlJX7oEDinLT441jHMYqkJJOfDHemkt98o91i4pHgl6rKr YUogj75AYt0T8BQatQnl+L1j7fij7ZoyBgn4oVlP2ixSNup8yx0hXbS+9wAHQ4RRnVRp LKOw== MIME-Version: 1.0 X-Received: by 10.140.84.137 with SMTP id l9mr27019592qgd.94.1437149525938; Fri, 17 Jul 2015 09:12:05 -0700 (PDT) Received: by 10.140.93.162 with HTTP; Fri, 17 Jul 2015 09:12:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Jul 2015 17:12:05 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a11c1192afb97b5051b1472a8 X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MALFORMED_FREEMAIL, MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 16:12:07 -0000 --001a11c1192afb97b5051b1472a8 Content-Type: text/plain; charset=UTF-8 Transaction sizes are still limited to 1MB with this patch. While this isn't technically a change, it does mean that both are no longer linked together. Since this has no voting step, I assume the intention is that as a compromise suggestion, it would have full support. It establishes a precedent for hard forks not to require a vote though. On Fri, Jul 17, 2015 at 4:55 PM, Jeff Garzik via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > Code PR: https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative plan to > my preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then this > solution is at least available and a known quantity. A good backup plan. > > Benefits: conservative increase. proves network can upgrade. permits > some added growth, while the community & market gathers data on how an > increased block size impacts privacy, security, centralization, transaction > throughput and other metrics. 2MB seems to be a Least Common Denominator > on an increase. > > Costs: requires a hard fork. requires another hard fork down the road. > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a11c1192afb97b5051b1472a8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Transaction sizes are still limited to 1MB with = this patch.=C2=A0 While this isn't technically a change, it does mean t= hat both are no longer linked together.

Since this has no voti= ng step, I assume the intention is that as a compromise suggestion, it woul= d have full support.

It establishes a precedent for hard forks= not to require a vote though.

On Fri, Jul 17, 2015 at 4:55 PM, Jeff Garzik via bit= coin-dev <bitcoin-dev@lists.linuxfoundation.org>= ; wrote:

Ope= ning a mailing list thread on this BIP:

BIP PR:=C2=A0https:= //github.com/bitcoin/bips/pull/173
Code PR:=C2=A0https://github.com= /bitcoin/bitcoin/pull/6451

The general intent = of this BIP is as a minimum viable alternative plan to my preferred proposa= l (BIP 100).

If agreement is not reached on a more= comprehensive solution, then this solution is at least available and a kno= wn quantity.=C2=A0 A good backup plan.

Benefits: = =C2=A0conservative increase. =C2=A0proves network can upgrade. =C2=A0permit= s some added growth, while the community & market gathers data on how a= n increased block size impacts privacy, security, centralization, transacti= on throughput and other metrics. =C2=A02MB seems to be a Least Common Denom= inator on an increase.

Costs: =C2=A0requires a har= d fork. =C2=A0requires another hard fork down the road.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a11c1192afb97b5051b1472a8-- 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 82CD09C for ; Fri, 17 Jul 2015 16:14:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 26F861F2 for ; Fri, 17 Jul 2015 16:14:14 +0000 (UTC) Received: by qgep37 with SMTP id p37so49251931qge.1 for ; Fri, 17 Jul 2015 09:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=ErKXV+U46OjJJW23xwppJuz1Z4aRj9Pwl0mJeYs96bk=; b=WA2qmXyU4nfICq6zDxVx6YSl4q9Vrb28QFoNdxcVQuwebB/LrKXwMKq/bf5uxhCt5y 82EbcDvRl9nkWiDsnaXRtZII0cUYTtCHGVONpUweAVcgYDw2SvGOf/qiDcEA15Hs1yxf YmfNmVwvJNQWTgYL9yg1l0h7jOzNSIYOHh9QmbB8eug+hyoHe7nurX4FMgdlByicQzq3 dxiXK7oWtqJqwUZN53Y6W0FQb1vRmHefWVVic/kxuelaEgoIrZiiZxKXUN38OlDy5nJH P9nj3WONbs149OL/ZmApHfxm3BIl4F3bKlXgsci0BhwAkS7ouAnwi0mN9Ed7MfnpfhZO lJ6g== MIME-Version: 1.0 X-Received: by 10.140.217.149 with SMTP id n143mr21281812qhb.9.1437149653424; Fri, 17 Jul 2015 09:14:13 -0700 (PDT) Received: by 10.140.93.162 with HTTP; Fri, 17 Jul 2015 09:14:13 -0700 (PDT) In-Reply-To: References:

Date: Fri, 17 Jul 2015 17:14:13 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1137351894e161051b147a9d X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MALFORMED_FREEMAIL, MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 16:14:14 -0000 --001a1137351894e161051b147a9d Content-Type: text/plain; charset=UTF-8 On Fri, Jul 17, 2015 at 5:12 PM, Tier Nolan wrote: > While this isn't technically a change, it does mean that both are no > longer linked together. > I meant both block and transaction sizes are no longer linked together. --001a1137351894e161051b147a9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Jul 17, 2015 at 5:12 PM, Tier Nolan <tier.nolan@gmail.com> wrote:

While this isn't technically a change, it does mean that both ar= e no longer linked together.

=C2=A0<= /div>

I meant both block and transaction sizes are no longer linked tog= ether.

--001a1137351894e161051b147a9d-- 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 BFFB83C8 for ; Fri, 17 Jul 2015 17:57:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a60.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 1834D32 for ; Fri, 17 Jul 2015 17:57:47 +0000 (UTC) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 709043BC07B for ; Fri, 17 Jul 2015 10:57:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to :references:from:message-id:date:mime-version:in-reply-to: content-type; s=jrn.me.uk; bh=+g5GvaF7esXWbwXmo+okjt/Dfh0=; b=zZ HkwQVqNk0215WmJCkblGdy/9+xd0Yvcxs2i+wZQ7XLDgYOT3gF218kWBzVL4jATT wKbJH41XmJQaPR2LhKOm1AU1Ufnem+vq+w0nxOkzHh6MbN8/UmakUwmRV1H/KRoN xnmWKUCcukCDQhWvC1z9zq9Z1vw8YoCW+aUo7IEu0= Received: from [10.9.1.131] (unknown [89.238.129.18]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jrn@jrn.me.uk) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPSA id 083FE3BC07A for ; Fri, 17 Jul 2015 10:57:46 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: From: Ross Nicoll Message-ID: <55A9421B.6040605@jrn.me.uk> Date: Fri, 17 Jul 2015 18:57:47 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050707030505060108020400" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 17:57:48 -0000 This is a multi-part message in MIME format. --------------050707030505060108020400 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I'd back this if we can't find a permanent solution - 2MB gives us a lot more wiggle room in the interim at least; one of my concerns with block size is 3 transactions per second is absolutely tiny, and we need space for the network to search for an equilibrium between volume and pricing without risk of an adoption spike rendering it essentially unusable. I'd favour switching over by block height rather than time, and I'd suggest that given virtually every wallet/node out there will require testing (even if many do not currently enforce a limit and therefore do not need changing), 6 months should be considered a minimum target. I'd open with a suggestion of block 390k as a target. Ross On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: > Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > Code PR: https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative plan > to my preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then > this solution is at least available and a known quantity. A good > backup plan. > > Benefits: conservative increase. proves network can upgrade. > permits some added growth, while the community & market gathers data > on how an increased block size impacts privacy, security, > centralization, transaction throughput and other metrics. 2MB seems > to be a Least Common Denominator on an increase. > > Costs: requires a hard fork. requires another hard fork down the road. > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------050707030505060108020400 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'd back this if we can't find a permanent solution - 2MB gives us a lot more wiggle room in the interim at least; one of my concerns with block size is 3 transactions per second is absolutely tiny, and we need space for the network to search for an equilibrium between volume and pricing without risk of an adoption spike rendering it essentially unusable.

I'd favour switching over by block height rather than time, and I'd suggest that given virtually every wallet/node out there will require testing (even if many do not currently enforce a limit and therefore do not need changing), 6 months should be considered a minimum target. I'd open with a suggestion of block 390k as a target.

Ross

On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:

Opening a mailing list thread on this BIP:

BIP PR:=A0 https://githu= b.com/bitcoin/bips/pull/173
Code PR:=A0https:/= /github.com/bitcoin/bitcoin/pull/6451

The general intent of this BIP is as a minimum viable alternative plan to my preferred proposal (BIP 100).

If agreement is not reached on a more comprehensive solution, then this solution is at least available and a known quantity.=A0 A good backup plan.

Benefits: =A0conservative increase. =A0proves network can upgrade. =A0permits some added growth, while the community &= ; market gathers data on how an increased block size impacts privacy, security, centralization, transaction throughput and other metrics. =A02MB seems to be a Least Common Denominator on an increase.

Costs: =A0requires a hard fork. =A0requires another hard for= k down the road.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev

--------------050707030505060108020400-- 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 3926640C for ; Fri, 17 Jul 2015 19:06:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 71F4714F for ; Fri, 17 Jul 2015 19:06:34 +0000 (UTC) Received: by ykay190 with SMTP id y190so96979134yka.3 for ; Fri, 17 Jul 2015 12:06:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zMq1lxlHLzYb9RcHqFrZpjaLEtAuEyWFElReZXAytqA=; b=KEx/72Ku6bgapesbWTCwao/XhTMes0LAIgLeZfGmGJw4m/H2wyAA7j7n+Aa8o6DG51 Iizrkh5VkHo5OH8k5srN+cW4J3k132YksZ3rBd9HPZMtxWmP21pms4fYUyVJ+b6n83Jn kOGMVQGlTxxsVIOs99FEv9NFZaQ2N3+s2WKJX8/52re6G8//1lla6DnztdEBZHIoYmqx hS319HN3cWWA/e1uUnYSuIHrRhDKvRkV9sQGgMYSLEdsL+3MBcKzQMDLm2Vk0KnpRqXM UuGQATBjX6lXz0/ebKrOdjAqmkL/6u9Cw3ZzNYdQ8impB6DjTbEBk0em8enQ9+ZDMmFn WWSw== MIME-Version: 1.0 X-Received: by 10.170.143.213 with SMTP id k204mr16629363ykc.91.1437159993717; Fri, 17 Jul 2015 12:06:33 -0700 (PDT) Received: by 10.37.76.135 with HTTP; Fri, 17 Jul 2015 12:06:33 -0700 (PDT) In-Reply-To: <55A9421B.6040605@jrn.me.uk> References: <55A9421B.6040605@jrn.me.uk> Date: Fri, 17 Jul 2015 15:06:33 -0400 Message-ID: From: Chris Wardell To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a1139909ce93d58051b16e29d X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 19:06:35 -0000 --001a1139909ce93d58051b16e29d Content-Type: text/plain; charset=UTF-8 I would prefer a dynamic solution that did not necessitate a second hard fork down the road. I propose doubling the block size every 100k blocks (~2 years) block 400,000 = 2MB (2016) block 500,000 = 4MB (2017) block 600,000 = 8MB (2018) Chris On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I'd back this if we can't find a permanent solution - 2MB gives us a lot > more wiggle room in the interim at least; one of my concerns with block > size is 3 transactions per second is absolutely tiny, and we need space for > the network to search for an equilibrium between volume and pricing without > risk of an adoption spike rendering it essentially unusable. > > I'd favour switching over by block height rather than time, and I'd > suggest that given virtually every wallet/node out there will require > testing (even if many do not currently enforce a limit and therefore do not > need changing), 6 months should be considered a minimum target. I'd open > with a suggestion of block 390k as a target. > > Ross > > > On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: > > Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > Code PR: https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative plan > to my preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then this > solution is at least available and a known quantity. A good backup plan. > > Benefits: conservative increase. proves network can upgrade. permits > some added growth, while the community & market gathers data on how an > increased block size impacts privacy, security, centralization, transaction > throughput and other metrics. 2MB seems to be a Least Common Denominator > on an increase. > > Costs: requires a hard fork. requires another hard fork down the road. > > > > > _______________________________________________ > bitcoin-dev mailing listbitcoin-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a1139909ce93d58051b16e29d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I would prefer a dynamic solution= that did not necessitate a second hard fork down the road.

I = propose doubling the block size every 100k blocks (~2 years)

b= lock 400,000 =3D 2MB (2016)

block 500,000 =3D 4MB (2017)

= block 600,000 =3D 8MB (2018)

Chris

On Fri, J= ul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev <<= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">b= itcoin-dev@lists.linuxfoundation.org> wrote:

=20 =20 =20
I'd back this if we can't find a permanent solution - 2MB gives= us a lot more wiggle room in the interim at least; one of my concerns with block size is 3 transactions per second is absolutely tiny, and we need space for the network to search for an equilibrium between volume and pricing without risk of an adoption spike rendering it essentially unusable.

I'd favour switching over by block height rather than time, and I&#= 39;d suggest that given virtually every wallet/node out there will require testing (even if many do not currently enforce a limit and therefore do not need changing), 6 months should be considered a minimum target. I'd open with a suggestion of block 390k as a target.

Ross

On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
Opening a mailing list thread on this BIP:

BIP PR:=C2=A0https://github.com/bitcoin/bips/pull/173
Code PR:=C2=A0https://github.com/bitcoin/bitcoin/pull/6451=

The general intent of this BIP is as a minimum viable alternative plan to my preferred proposal (BIP 100).

If agreement is not reached on a more comprehensive solution, then this solution is at least available and a known quantity.=C2=A0 A good backup plan.

Benefits: =C2=A0conservative increase. =C2=A0proves network ca= n upgrade. =C2=A0permits some added growth, while the community &am= p; market gathers data on how an increased block size impacts privacy, security, centralization, transaction throughput and other metrics. =C2=A02MB seems to be a Least Common Denominator o= n an increase.

Costs: =C2=A0requires a hard fork. =C2=A0requires another hard= fork down the road.

___________________________________= ____________ bitcoin-dev mailing list = bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoi= n-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a1139909ce93d58051b16e29d-- 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 61F3740A for ; Fri, 17 Jul 2015 19:13:15 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a61.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id BC04A136 for ; Fri, 17 Jul 2015 19:13:14 +0000 (UTC) Received: from homiemail-a61.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTP id 38B82578078 for ; Fri, 17 Jul 2015 12:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to :references:from:message-id:date:mime-version:in-reply-to: content-type; s=jrn.me.uk; bh=N4ddyiKEYPvY2QirLWVOit1EbFo=; b=HJ kRK7+3DyKdlhgqd3XNcxf2yRzH/O3dF7A68y5G/vQcyEytOj6X+adHva1Mb9AN3e J3gEQOA2rJR8i4idbINocaPoFSgasliHxv2qZYOZMt4IxfdTpu+yO7TU7FIIsyFm ik6e/nMmoDM0qiUY/fr0sHqSEJ0RZCT3ZwHVV1PHI= Received: from [10.9.1.131] (unknown [89.238.129.18]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jrn@jrn.me.uk) by homiemail-a61.g.dreamhost.com (Postfix) with ESMTPSA id 9ABC557806E for ; Fri, 17 Jul 2015 12:13:13 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <55A9421B.6040605@jrn.me.uk> From: Ross Nicoll Message-ID: <55A953CA.7020701@jrn.me.uk> Date: Fri, 17 Jul 2015 20:13:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------000807080405030507060300" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 19:13:15 -0000 This is a multi-part message in MIME format. --------------000807080405030507060300 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I'll leave others to comment on whether we can get consensus on that, but your years listed are inconsistent with everything else you've written. Should be: block 400,000 = 2MB (2016) block 500,000 = 4MB (2018) block 600,000 = 8MB (2020) On 17/07/2015 20:06, Chris Wardell via bitcoin-dev wrote: > I would prefer a dynamic solution that did not necessitate a second > hard fork down the road. > > I propose doubling the block size every 100k blocks (~2 years) > > block 400,000 = 2MB (2016) > block 500,000 = 4MB (2017) > block 600,000 = 8MB (2018) > > Chris > > > On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev >

> wrote: > > I'd back this if we can't find a permanent solution - 2MB gives us > a lot more wiggle room in the interim at least; one of my concerns > with block size is 3 transactions per second is absolutely tiny, > and we need space for the network to search for an equilibrium > between volume and pricing without risk of an adoption spike > rendering it essentially unusable. > > I'd favour switching over by block height rather than time, and > I'd suggest that given virtually every wallet/node out there will > require testing (even if many do not currently enforce a limit and > therefore do not need changing), 6 months should be considered a > minimum target. I'd open with a suggestion of block 390k as a target. > > Ross > > > On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: >> Opening a mailing list thread on this BIP: >> >> BIP PR: https://github.com/bitcoin/bips/pull/173 >> Code PR: https://github.com/bitcoin/bitcoin/pull/6451 >> >> The general intent of this BIP is as a minimum viable alternative >> plan to my preferred proposal (BIP 100). >> >> If agreement is not reached on a more comprehensive solution, >> then this solution is at least available and a known quantity. A >> good backup plan. >> >> Benefits: conservative increase. proves network can upgrade. >> permits some added growth, while the community & market gathers >> data on how an increased block size impacts privacy, security, >> centralization, transaction throughput and other metrics. 2MB >> seems to be a Least Common Denominator on an increase. >> >> Costs: requires a hard fork. requires another hard fork down >> the road. >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------000807080405030507060300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'll leave others to comment on whether we can get consensus on that, but your years listed are inconsistent with everything else you've written. Should be:

block 400,000 =3D 2MB (2016)
block 500,000 =3D 4MB (2018)
block 600,000 =3D 8MB (2020)

On 17/07/2015 20:06, Chris Wardell via bitcoin-dev wrote:

I would prefer a dynamic solution that did not necessitate a second hard fork down the road.

I propose doubling the block size every 100k blocks (~2 years)

block 400,000 =3D 2MB (2016)

block 500,000 =3D 4MB (2017)

block 600,000 =3D 8MB (2018)

Chris
On Fri, Jul 17, 2015 at 1:57 PM, Ross Nicoll via bitcoin-dev <bitcoin-dev@lists.linu= xfoundation.org> wrote:
I'd back this if w= e can't find a permanent solution - 2MB gives us a lot more wiggle room in the interim at least; one of my concerns with block size is 3 transactions per second is absolutely tiny, and we need space for the network to search for an equilibrium between volume and pricing without risk of an adoption spike rendering it essentially unusable.

I'd favour switching over by block height rather than time, and I'd suggest that given virtually every wallet/node out there will require testing (even if many do not currently enforce a limit and therefore do not need changing), 6 months should be considered a minimum target. I'd open with a suggestion of block 390k as a target.

Ross

On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
Opening a mailing list thread on this BIP:

BIP PR:=A0https://github.com/bitcoin/bips= /pull/173
Code PR:=A0https://github.com/bitcoin/bi= tcoin/pull/6451

The general intent of this BIP is as a minimum viable alternative plan to my preferred proposal (BIP 100).

If agreement is not reached on a more comprehensive solution, then this solution is at least available and a known quantity.=A0 A good backup plan.

Benefits: =A0conservative increase. =A0proves network can upgrade. =A0permits some added growth= , while the community & market gathers data on how an increased block size impacts privacy, security, centralization, transaction throughput and other metrics. =A02MB seems to be a Least Common Denominator on an increase.

Costs: =A0requires a hard fork. =A0requires another hard fork down the road.

_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundatio= n.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitco= in-dev@lists.linuxfoundation.org
https://lists.linuxfou= ndation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev

--------------000807080405030507060300-- 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 41719305 for ; Fri, 17 Jul 2015 20:30:20 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id DC53EA7 for ; Fri, 17 Jul 2015 20:30:19 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 2E59210836D1; Fri, 17 Jul 2015 20:29:18 +0000 (UTC) X-Hashcash: 1:25:150717:bitcoin-dev@lists.linuxfoundation.org::WF//tMag6lv2qcdf:Nq0Q X-Hashcash: 1:25:150717:jgarzik@gmail.com::/sG=KI=JaZ9FlbOA:dgo3o From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Jeff Garzik Date: Fri, 17 Jul 2015 20:29:16 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.1-gentoo-r1; KDE/4.14.8; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201507172029.17056.luke@dashjr.org> X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 20:30:20 -0000 On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote: > BIP PR: https://github.com/bitcoin/bips/pull/173 I'm concerned that miners are prematurely bumping their soft limit to 1 MB lately. The only reason block size limit lifting is remotely reasonable is if we can trust miners to at the very least keep their soft limits set at a manageable size, but this assumption appears to already be failing in practice. We are unlikely to approach 1 MB of actual volume by November, so I would prefer to see the activation date on this moved later - maybe November 2016, if not 2017. It would also be an improvement to try to follow reasonably- expected bandwidth increases, so 15% (1.15 MB) rather than doubling. Doubling in only a few months seems to be far from a "conservative" increase. If we can get some kind of commitment from miners not to move their soft limits beyond 1 MB until some future-agreed-on point, maybe the BIP is acceptable as-is. On Friday, July 17, 2015 4:12:05 PM Tier Nolan via bitcoin-dev wrote: > It establishes a precedent for hard forks not to require a vote though. Hardforks are not something where voting makes sense. They need consensus among /nodes/, not majority among /miners/. No hardfork has ever had such a vote. Luke 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 0DC7C308 for ; Fri, 17 Jul 2015 21:13:47 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 03FADB0 for ; Fri, 17 Jul 2015 21:13:45 +0000 (UTC) Received: by igbpg9 with SMTP id pg9so45863962igb.0 for ; Fri, 17 Jul 2015 14:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ecImNnJNA4YR06rjZ+Htu+uxwFCiKbugDJJ624ADP6A=; b=pTDWwNDJRVLsWvXerJ0NxOag7tfPA5ZRKzUsJzFtRu+PrX48LOmIJWGP4udzjwAq1T yqFLOToPjk3rl2I54SBHc7drQHEMbXuFRZtDtUVl1sCKwJI1WDYZ7W8ZpL32I1EcIPXO 3JT29rn9rN7iHVH+9+/+MZvTAXFhioGACFRxpGAT6tOrgPR0SuHWb8bbovTpnKTuSJw/ p5oYPDdSD69AzxwX46TgvvXXvTECuJt6cRHYl8vPzwDdjLRqP74p88YV6A1DTXqK+kBt Ex2dLuVwyWyPETpPIWoGZqZdx/ZxEpV+4a4qgQ9vMYCmMW9iTj9tox5jXBhE9EVZcZkc AAgA== X-Received: by 10.107.156.203 with SMTP id f194mr20097549ioe.164.1437167625336; Fri, 17 Jul 2015 14:13:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.122.144 with HTTP; Fri, 17 Jul 2015 14:13:25 -0700 (PDT) In-Reply-To: <201507172029.17056.luke@dashjr.org> References: <201507172029.17056.luke@dashjr.org> From: Angel Leon Date: Fri, 17 Jul 2015 17:13:25 -0400 Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary=001a1140cd00ca7cd1051b18a913 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 21:13:47 -0000 --001a1140cd00ca7cd1051b18a913 Content-Type: text/plain; charset=UTF-8 When blocks are found under or over the 10 minute threshold, hashing difficulty is raised or reduced dinamically to keep a balance. This intelligent measure has avoided us having discussions and kept a balance. The same way you can't assume how much hashpower there will be to find the next blocks, why can't we have a function that adapts to the transactional volume on the blockchain, one which allows us to grow/shrink an acceptable maximum block size. We're not putting caps on processing, why should we put a date based cap on transactional volume per block? You can't predict the future, but you can look at what's happened recently to correct these limits. Such function/filter should be able to recognize real sustained growth in transactional volume and let us adjust the maximum accepted blocksize to allow for the organic growth that will come due to real activity from things like distributed market-places, decentralized bitcoin based services (and all the things the community dreams about and might be building already), truly decentralized technological breakthroughs that geniunely need to use the blockchain. It should be able to adapt fast enough so that we don't have episodes where people need to wait 4 hours to days for transactions to get on the blockchain and be confirmed. I believe proposals that include "every 100,000 blocks" are out of touch with reality, the blocksize needs to adapt the same way blockdifficulty already adapts to growth or lack of hashing power. I'm not a statistician/mathematician, but I'm sure if we propose the parameters that need to be considered for a realistic blocksize that reflects the needs of the Bitcoin network users, there's plenty of crypto/statistician/mathematician brain power to propose such filtering function here. Things that could be considered: - median number of transactions per block (between 6 to 12 hours, you should be able to adjust to a real shopping sprint for instance, or huge pop band/artist decides to sell concert tickets on Bitcoin) - median fees offered per transaction (can we detect spammers) - median blocksizes - median size per transaction - number of new addresses signing off transactions, number of addresses we've already seen in the blockchain before (are these spammers creating lots of new addresses to move around the same outputs, is there an efficient way to detect the likelyhood of a transaction being spam? Bayes? No clue, no mathematician) - median velocity between which an address receives an input and sends it to another one? - more things I've no knowledge of since I'm not familiar with the details, but could immediatly come to mind to the experts. Mining Centralization is already happening due to its competitive nature, we don't complain or try to force hashing limits, we shouldn't do the same for storage. There will be no shortage of blockchain mirrors, and those interested in running full nodes, will surely find a way to do so. Angel http://twitter.com/gubatron On Fri, Jul 17, 2015 at 4:29 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Friday, July 17, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > > I'm concerned that miners are prematurely bumping their soft limit to 1 MB > lately. The only reason block size limit lifting is remotely reasonable is > if > we can trust miners to at the very least keep their soft limits set at a > manageable size, but this assumption appears to already be failing in > practice. > > We are unlikely to approach 1 MB of actual volume by November, so I would > prefer to see the activation date on this moved later - maybe November > 2016, > if not 2017. It would also be an improvement to try to follow reasonably- > expected bandwidth increases, so 15% (1.15 MB) rather than doubling. > Doubling > in only a few months seems to be far from a "conservative" increase. > > If we can get some kind of commitment from miners not to move their soft > limits beyond 1 MB until some future-agreed-on point, maybe the BIP is > acceptable as-is. > > On Friday, July 17, 2015 4:12:05 PM Tier Nolan via bitcoin-dev wrote: > > It establishes a precedent for hard forks not to require a vote though. > > Hardforks are not something where voting makes sense. They need consensus > among /nodes/, not majority among /miners/. No hardfork has ever had such a > vote. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a1140cd00ca7cd1051b18a913 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

When blocks are found under or over the 10 minute thr= eshold, hashing difficulty is raised or reduced dinamically to keep a balan= ce. This intelligent measure has avoided us having discussions and kept a b= alance.

The same way you can't assume how much= hashpower there will be to find the next blocks, why can't we have a

function that adapts to the transactional volume on the blockchain= , one which allows us to grow/shrink an acceptable maximum block size. We&#= 39;re not putting caps on processing, why should we put a date based cap on= transactional volume per block? You can't predict the future, but you = can look at what's happened recently to correct these limits.

Such function/filter should be able to recognize real susta= ined growth in transactional volume and let us adjust the maximum accepted = blocksize to allow for the organic growth that will come due to real activi= ty from things like distributed market-places, decentralized bitcoin based = services (and all the things the community dreams about and might be buildi= ng already), truly decentralized technological breakthroughs that geniunely= need to use the blockchain. <Going the off-chain way only leads to cent= ralization and personal/corporate agendas, which to me goes against the Bit= coin ethos>=C2=A0

It should be able to adapt fa= st enough so that we don't have episodes where people need to wait 4 ho= urs to days for transactions to get on the blockchain and be confirmed. I b= elieve proposals that include "every 100,000 blocks" are out of t= ouch with reality, the blocksize needs to adapt the same way blockdifficult= y already adapts to growth or lack of hashing power.

I'm not a statistician/mathematician, but I'm sure if we propose= the parameters that need to be considered for a realistic blocksize that r= eflects the needs of the Bitcoin network users, there's plenty of crypt= o/statistician/mathematician brain power to propose such filtering function= here.

Things that could be considered:

= - median number of transactions per block (between 6 to 12 hours, you shoul= d be able to adjust to a real shopping sprint for instance, or huge pop ban= d/artist decides to sell concert tickets on Bitcoin)

- median fee= s offered per transaction (can we detect spammers)

- median block= sizes

- median size per transaction

- number of new add= resses signing off transactions, number of addresses we've already seen= in the blockchain before (are these spammers creating lots of new addresse= s to move around the same outputs, is there an efficient way to detect the = likelyhood of a transaction being spam? Bayes? No clue, no mathematician)

- median velocity between which an address receives an input and s= ends it to another one?

- more things I've no knowledge of si= nce I'm not familiar with the details, but could immediatly come to min= d to the experts.

Mining Centralization is already= happening due to its competitive nature, we don't complain or try to f= orce hashing limits, we shouldn't do the same for storage. There will b= e no shortage of blockchain mirrors, and those interested in running full n= odes, will surely find a way to do so.=C2=A0

Angel

= http://twitter.co= m/gubatron

On Fri, Jul 17, 2015 at 4:29 PM, Luke Dashjr= via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.or= g> wrote:

On Friday, July 1= 7, 2015 3:55:19 PM Jeff Garzik via bitcoin-dev wrote:
> BIP PR: https://github.com/bitcoin/bips/pull/173
I'm concerned that miners are prematurely bumping their soft limit to 1= MB
lately. The only reason block size limit lifting is remotely reasonable is = if
we can trust miners to at the very least keep their soft limits set at a manageable size, but this assumption appears to already be failing in
practice.

We are unlikely to approach 1 MB of actual volume by November, so I would prefer to see the activation date on this moved later - maybe November 2016= ,
if not 2017. It would also be an improvement to try to follow reasonably- expected bandwidth increases, so 15% (1.15 MB) rather than doubling. Doubli= ng
in only a few months seems to be far from a "conservative" increa= se.

If we can get some kind of commitment from miners not to move their soft limits beyond 1 MB until some future-agreed-on point, maybe the BIP is
acceptable as-is.

On Friday, July 17, 2015 4:12:05 PM Tier Nolan via bitcoin-dev wrote:
> It establishes a precedent for hard forks not to require a vote though= .

Hardforks are not something where voting makes sense. They need consensus among /nodes/, not majority among /miners/. No hardfork has ever had such a=
vote.

Luke
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

--001a1140cd00ca7cd1051b18a913-- 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 18B05279 for ; Fri, 17 Jul 2015 22:25:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f41.google.com (mail-qg0-f41.google.com [209.85.192.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 88F30143 for ; Fri, 17 Jul 2015 22:25:07 +0000 (UTC) Received: by qgy5 with SMTP id 5so53690491qgy.3 for ; Fri, 17 Jul 2015 15:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=WCUwof2gfO4gJfGhS9wqqpSWkakVBZXqWXOT0Dy4tU4=; b=pkao9sSivVYFe4CWF0jM4yAsE+eA8ekm8j0q9Lv/S0wduXkpMNvghsjg/NOQ4YruK3 xa/mVYhvqPDFC/MZ7e0X84DxwByJqGkSAlYMRAnRcqqsBQQcEmpXN+kuUL0nyIJn3c+U RN7HGuZxAlzLQsxFUUhWZq8nv+xDdMzUj22zYm2F9B3S6jdF7L8s8L2v/g3jeLUiyFke LHd3aOgsCiNNXmQIurl4ef+E5liyKWwU2aeA5iFY+ROd109Qw/DAiPHaaQ3NVSug/Oqq Uw2ORIR8ey59f/BD4/131pZ9bcUeM+YNirQHJlyOwoflGBuDgplVo9OWFIFrTiYiVdoR mC9Q== MIME-Version: 1.0 X-Received: by 10.140.217.149 with SMTP id n143mr23754441qhb.9.1437171906745; Fri, 17 Jul 2015 15:25:06 -0700 (PDT) Received: by 10.140.93.162 with HTTP; Fri, 17 Jul 2015 15:25:06 -0700 (PDT) In-Reply-To: <201507172029.17056.luke@dashjr.org> References: <201507172029.17056.luke@dashjr.org> Date: Fri, 17 Jul 2015 23:25:06 +0100 Message-ID: From: Tier Nolan Cc: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary=001a11373518fb9ea5051b19a853 X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, MALFORMED_FREEMAIL, MISSING_HEADERS,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 22:25:08 -0000 --001a11373518fb9ea5051b19a853 Content-Type: text/plain; charset=UTF-8 On Fri, Jul 17, 2015 at 9:29 PM, Luke Dashjr wrote: > Hardforks are not something where voting makes sense. They need consensus > among /nodes/, not majority among /miners/. No hardfork has ever had such a > vote. > Agreed. I meant that since some of the new hard fork proposals use a voting system for activation, they may not want to establish that precedent. --001a11373518fb9ea5051b19a853 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On F= ri, Jul 17, 2015 at 9:29 PM, Luke Dashjr <luke@dashjr.org> wro= te:

Hardforks are not something where vot= ing makes sense. They need consensus
among /nodes/, not majority among /miners/. No hardfork has ever had such a=
vote.

Agreed.

I meant that since= some of the new hard fork proposals use a voting system for activation, th= ey may not want to establish that precedent.

--001a11373518fb9ea5051b19a853-- 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 3BA94273 for ; Fri, 17 Jul 2015 22:41:07 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from COL004-OMC3S15.hotmail.com (col004-omc3s15.hotmail.com [65.55.34.153]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CCB2D1D7 for ; Fri, 17 Jul 2015 22:41:03 +0000 (UTC) Received: from COL402-EAS204 ([65.55.34.136]) by COL004-OMC3S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 17 Jul 2015 15:41:03 -0700 X-TMN: [nliFiLSMHEzEZhxIJB0QJutQDqiUKjYi] X-Originating-Email: [raystonn@hotmail.com] Message-ID: Date: Fri, 17 Jul 2015 15:40:58 -0700 From: Raystonn To: Luke Dashjr MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 X-OriginalArrivalTime: 17 Jul 2015 22:41:03.0770 (UTC) FILETIME=[A980A7A0:01D0C0E1] X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,HTML_MIME_NO_HTML_TAG,MIME_HTML_ONLY,RCVD_IN_DNSWL_LOW, RP_MATCHES_RCVD 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 22:41:07 -0000 PHAgZGlyPSJsdHIiPiZndDsgSSdtIGNvbmNlcm5lZCB0aGF0IG1pbmVycyBhcmUgcHJlbWF0dXJl bHkgYnVtcGluZyB0aGVpciBzb2Z0IGxpbWl0IHRvIDEgTUIgbGF0ZWx5LjwvcD4KPHAgZGlyPSJs dHIiPkJ5IHdoYXQgbWVhc3VyZSBkbyB5b3UgY2FsbCB0aGlzIHByZW1hdHVyZT88YnI+CjwvcD4K PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIDE3IEp1bCAyMDE1IDE6MzAgcG0sIEx1a2UgRGFz aGpyIHZpYSBiaXRjb2luLWRldiAmbHQ7Yml0Y29pbi1kZXZAbGlzdHMubGludXhmb3VuZGF0aW9u Lm9yZyZndDsgd3JvdGU6PGJyIHR5cGU9J2F0dHJpYnV0aW9uJz48YmxvY2txdW90ZSBjbGFzcz0i cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp ZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCg0KDQoNCjxkaXY+DQo8ZGl2Pk9uIEZyaWRheSwgSnVseSAx NywgMjAxNSAzOjU1OjE5IFBNIEplZmYgR2FyemlrIHZpYSBiaXRjb2luLWRldiB3cm90ZTo8YnIg Lz4NCiZndDsgQklQIFBSOiA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vYml0Y29pbi9iaXBz L3B1bGwvMTczIj5odHRwczovL2dpdGh1Yi5jb20vYml0Y29pbi9iaXBzL3B1bGwvMTczPC9hPjxi ciAvPg0KPGJyIC8+DQpJJiMzOTttIGNvbmNlcm5lZCB0aGF0IG1pbmVycyBhcmUgcHJlbWF0dXJl bHkgYnVtcGluZyB0aGVpciBzb2Z0IGxpbWl0IHRvIDEgTUIgPGJyIC8+DQpsYXRlbHkuIFRoZSBv bmx5IHJlYXNvbiBibG9jayBzaXplIGxpbWl0IGxpZnRpbmcgaXMgcmVtb3RlbHkgcmVhc29uYWJs ZSBpcyBpZiA8YnIgLz4NCndlIGNhbiB0cnVzdCBtaW5lcnMgdG8gYXQgdGhlIHZlcnkgbGVhc3Qg a2VlcCB0aGVpciBzb2Z0IGxpbWl0cyBzZXQgYXQgYSA8YnIgLz4NCm1hbmFnZWFibGUgc2l6ZSwg YnV0IHRoaXMgYXNzdW1wdGlvbiBhcHBlYXJzIHRvIGFscmVhZHkgYmUgZmFpbGluZyBpbiA8YnIg Lz4NCnByYWN0aWNlLjxiciAvPg0KPGJyIC8+DQpXZSBhcmUgdW5saWtlbHkgdG8gYXBwcm9hY2gg MSBNQiBvZiBhY3R1YWwgdm9sdW1lIGJ5IE5vdmVtYmVyLCBzbyBJIHdvdWxkIDxiciAvPg0KcHJl ZmVyIHRvIHNlZSB0aGUgYWN0aXZhdGlvbiBkYXRlIG9uIHRoaXMgbW92ZWQgbGF0ZXIgLSBtYXli ZSBOb3ZlbWJlciAyMDE2LCA8YnIgLz4NCmlmIG5vdCAyMDE3LiBJdCB3b3VsZCBhbHNvIGJlIGFu IGltcHJvdmVtZW50IHRvIHRyeSB0byBmb2xsb3cgcmVhc29uYWJseS08YnIgLz4NCmV4cGVjdGVk IGJhbmR3aWR0aCBpbmNyZWFzZXMsIHNvIDE1JSAoMS4xNSBNQikgcmF0aGVyIHRoYW4gZG91Ymxp bmcuIERvdWJsaW5nIDxiciAvPg0KaW4gb25seSBhIGZldyBtb250aHMgc2VlbXMgdG8gYmUgZmFy IGZyb20gYSAmIzM0O2NvbnNlcnZhdGl2ZSYjMzQ7IGluY3JlYXNlLjxiciAvPg0KPGJyIC8+DQpJ ZiB3ZSBjYW4gZ2V0IHNvbWUga2luZCBvZiBjb21taXRtZW50IGZyb20gbWluZXJzIG5vdCB0byBt b3ZlIHRoZWlyIHNvZnQgPGJyIC8+DQpsaW1pdHMgYmV5b25kIDEgTUIgdW50aWwgc29tZSBmdXR1 cmUtYWdyZWVkLW9uIHBvaW50LCBtYXliZSB0aGUgQklQIGlzIDxiciAvPg0KYWNjZXB0YWJsZSBh cy1pcy48YnIgLz4NCjxiciAvPg0KT24gRnJpZGF5LCBKdWx5IDE3LCAyMDE1IDQ6MTI6MDUgUE0g VGllciBOb2xhbiB2aWEgYml0Y29pbi1kZXYgd3JvdGU6PGJyIC8+DQomZ3Q7IEl0IGVzdGFibGlz aGVzIGEgcHJlY2VkZW50IGZvciBoYXJkIGZvcmtzIG5vdCB0byByZXF1aXJlIGEgdm90ZSB0aG91 Z2guPGJyIC8+DQo8YnIgLz4NCkhhcmRmb3JrcyBhcmUgbm90IHNvbWV0aGluZyB3aGVyZSB2b3Rp bmcgbWFrZXMgc2Vuc2UuIFRoZXkgbmVlZCBjb25zZW5zdXMgPGJyIC8+DQphbW9uZyAvbm9kZXMv LCBub3QgbWFqb3JpdHkgYW1vbmcgL21pbmVycy8uIE5vIGhhcmRmb3JrIGhhcyBldmVyIGhhZCBz dWNoIGEgPGJyIC8+DQp2b3RlLjxiciAvPg0KPGJyIC8+DQpMdWtlPGJyIC8+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciAvPg0KYml0Y29pbi1kZXYg bWFpbGluZyBsaXN0PGJyIC8+DQpiaXRjb2luLWRldiYjNjQ7bGlzdHMubGludXhmb3VuZGF0aW9u Lm9yZzxiciAvPg0KPGEgaHJlZj0iaHR0cHM6Ly9saXN0cy5saW51eGZvdW5kYXRpb24ub3JnL21h aWxtYW4vbGlzdGluZm8vYml0Y29pbi1kZXYiPmh0dHBzOi8vbGlzdHMubGludXhmb3VuZGF0aW9u Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2JpdGNvaW4tZGV2PC9hPjxiciAvPg0KPC9kaXY+DQo8L2Rp dj4NCg0KPC9ibG9ja3F1b3RlPjwvZGl2Pg== 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 25202407 for ; Sat, 18 Jul 2015 04:33:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bihthai.net (unknown [5.255.87.165]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D0979EB for ; Sat, 18 Jul 2015 04:33:24 +0000 (UTC) Received: from [10.8.0.10] (unknown [10.8.0.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: venzen) by mail.bihthai.net (Postfix) with ESMTPSA id 0AD4D20721; Sat, 18 Jul 2015 06:34:37 +0200 (CEST) Message-ID: <55A9D6F0.5090303@mail.bihthai.net> Date: Sat, 18 Jul 2015 11:32:48 +0700 From: Venzen Khaosan Reply-To: venzen@mail.bihthai.net Organization: Bihthai Bai Mai User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: bitcoin-dev@lists.linuxfoundation.org, Jeff Garzik References: In-Reply-To: OpenPGP: id=1CF07D66; url=pool.sks-keyservers.net Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 04:33:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As an alternative to the preferred BIP100 this proposal is good because it establishes a plan of action for dealing with the recent ramp-up (100% increase) in number of transactions and transaction size. Arguably, a transitory spam attack, yes, but with a speculative rally brewing (and implied increases in network usage) this BIP may prove to be just-in-time. Solutions favoring dynamic vs. scheduled increases in blocksize (and by how much) are interesting and the proponents should explore and map out their proposal with data sets, trend projections and future scenarios. It will require labor and time, but convince the list about the scientific merit of your proposal. In the meantime, the current "sufficient" state of network capacity may soon experience "insufficient" moments. Developer confluence around a workable plan and testing should, reasonably, begin now. Jeff's proposal addresses an approaching capacity crunch whilst honoring decentralization and providing time for testing and alternative future innovations. It's the best solution the user base and developers currently have for all the reasons Jeff gives: conservative blocksize increase, added capacity, low impact and minimal implication for the network and its users. Then, many of the more far-reaching proposals being offered can be tested, formalized, and fleshed out with scenario data. On 07/17/2015 10:55 PM, Jeff Garzik via bitcoin-dev wrote: > Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 Code PR: > https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative > plan to my preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then > this solution is at least available and a known quantity. A good > backup plan. > > Benefits: conservative increase. proves network can upgrade. > permits some added growth, while the community & market gathers > data on how an increased block size impacts privacy, security, > centralization, transaction throughput and other metrics. 2MB > seems to be a Least Common Denominator on an increase. > > Costs: requires a hard fork. requires another hard fork down the > road. > > > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVqdbsAAoJEGwAhlQc8H1m3LIIAJeBKYp0HYWYONlBxFNeQfa8 4EpYmMxwTSsDZ62CxdinxEGY3eQTqQo0GGAjpfSict4hq9ivSy74eHRb7AZihdYm znEVGMnedyMtSDvfyaUdIj/kkUX4k9mrcLyAAJB//E2e2BYQgs3esTAYx2ScCBiR t/UQ9gIolezasUIEmEovaQG4vOXtwMEtlzXrYy7EiAGhtoBvb1w3CJ3xa8iuF4e7 aXsleE98e44wjs0T/xLbuV4d8lBpnb0i0laOH4rpl77plpTc1HlDzjjqibourPb7 SPZhfwnk5f++3PlNc/dtwEJLFw8p578S5aDWZhUX7h+DfRXSqF6WCxYvv6XdUGQ= =eoPX -----END PGP SIGNATURE----- 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 0803B40F for ; Sat, 18 Jul 2015 09:22:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 632501AA for ; Sat, 18 Jul 2015 09:22:16 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so55263916wib.0 for ; Sat, 18 Jul 2015 02:22:15 -0700 (PDT) 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=w+VYFDO+yv7QMradZwF9Vw3e2w8aM2fzbctKpeqCO4E=; b=Htu4Rq3py9fiarC74m+rtlXvpQuHEe7CVHqrORUx0C6uKFdiJDOUbqgzbM9Qc+EPP5 ldGm4jHD+udJ0A8csA+i7O/4MetP5Gpohwaa7h1+YD7vzkAZAybrSpVLrSB9tzncFa9+ nN3rgzSTCQWC83cttyu5m3Ie+s8/O/0NcIhPHuR3XYJmG89LD9nkonYcCgSmRj2qzKzb qwFxaSrsNM7fz2mfAz79H2yucYzHqGdRy1Sb/ui5RFHI86iL6R83RgVwtHgRM2LQYLqa axpM/hPHv8+3ZNKF7hIlz2TQWp+2buwGvuKu79XVK5liQ7nakxYe0Er6o0cyPx+1P69S S2JQ== X-Gm-Message-State: ALoCoQlfu3AM88+khu/Lql87E9KLgrRwWFaNyu3yyCq3JajLPlNZlCixRf/TjUhK/ujD0PUXCQJT MIME-Version: 1.0 X-Received: by 10.194.120.198 with SMTP id le6mr37695705wjb.133.1437211334889; Sat, 18 Jul 2015 02:22:14 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Sat, 18 Jul 2015 02:22:14 -0700 (PDT) In-Reply-To: References: <201507172029.17056.luke@dashjr.org> Date: Sat, 18 Jul 2015 11:22:14 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Tier Nolan Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 09:22:17 -0000 On Sat, Jul 18, 2015 at 12:25 AM, Tier Nolan via bitcoin-dev wrote: > On Fri, Jul 17, 2015 at 9:29 PM, Luke Dashjr wrote: >> >> Hardforks are not something where voting makes sense. They need consensus >> among /nodes/, not majority among /miners/. No hardfork has ever had such >> a >> vote. > > > Agreed. > > I meant that since some of the new hard fork proposals use a voting system > for activation, they may not want to establish that precedent. I wonder how many people read http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.html apart from you... 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 5B18640F for ; Sat, 18 Jul 2015 09:24:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1BDDF140 for ; Sat, 18 Jul 2015 09:24:48 +0000 (UTC) Received: by wicmv11 with SMTP id mv11so59303022wic.1 for ; Sat, 18 Jul 2015 02:24:46 -0700 (PDT) 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 :content-transfer-encoding; bh=Y4hv5kFZjkykJcXrCRyWL/tm7d5x9kR/3Mwmde2Nav4=; b=JKXF4s+87m35765d3RCDYjjUQRTSAwYITMJR/ilBxzUPW0cVioi9Lhm/Dqoc1ye6KC tzB8/PenklO/T0QZUPOU2sH5TCYcFAYJma5ob3kVLIF6iT5dyqjJAiiY3jiFM9FVt7cz L4eCApIEJRXq89J7MOWFg+c8JlgzcZmShL/wuSFkOZT6/CdkbcJwupUWYunbI6pHKDXK gTNqdVSY3byRlSY2NIKhYGIpSTltJ97d4yuojP5vzrMxjP4CFQiMl2MlvNrlUBFhBiL3 XzNyZ5gN6UBKXLU+VGsLWspU2OyGyl7D7JGY76UG/tmnkw5unLhO3ERCP+P0Y0wiKrA6 6F4w== X-Gm-Message-State: ALoCoQkFMigB0B5xXP6qOjVuRIG3pwC7cpBj1PKRH+ZyWyrj0BVJ7XLq2Cak91I9vFSR4zdqCKfL MIME-Version: 1.0 X-Received: by 10.180.92.40 with SMTP id cj8mr3233332wib.92.1437211486830; Sat, 18 Jul 2015 02:24:46 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Sat, 18 Jul 2015 02:24:46 -0700 (PDT) In-Reply-To: References: <201507172029.17056.luke@dashjr.org>

Date: Sat, 18 Jul 2015 11:24:46 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Tier Nolan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 09:24:49 -0000 Sorry... More specifically, how many people made it to https://github.com/jtimon/bips/blob/bip-forks/bip-forks.org#uncontroversial= -hardforks On Sat, Jul 18, 2015 at 11:22 AM, Jorge Tim=C3=B3n wrote= : > On Sat, Jul 18, 2015 at 12:25 AM, Tier Nolan via bitcoin-dev > wrote: >> On Fri, Jul 17, 2015 at 9:29 PM, Luke Dashjr wrote: >>> >>> Hardforks are not something where voting makes sense. They need consens= us >>> among /nodes/, not majority among /miners/. No hardfork has ever had su= ch >>> a >>> vote. >> >> >> Agreed. >> >> I meant that since some of the new hard fork proposals use a voting syst= em >> for activation, they may not want to establish that precedent. > > I wonder how many people read > http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.h= tml > apart from you... 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 C0C17279 for ; Sun, 19 Jul 2015 22:51:10 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a7.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0802FE9 for ; Sun, 19 Jul 2015 22:51:09 +0000 (UTC) Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id 61B2125C072 for ; Sun, 19 Jul 2015 15:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to :references:from:message-id:date:mime-version:in-reply-to: content-type; s=jrn.me.uk; bh=YS2dfpktmsvp9zIH1fXDVGX0M3A=; b=sL gGDs8h7TvS1R9cmWoLgdb8zAY+xDBHjk0LcpgOm7Q+2jcdwPpmjX9ul4jkPtcDL1 AccI/oa6lezRoZbNFqJaT/+RL+rHILcgR//PWEOWF9DveVErfl5UU2tAE6pNJMil uAvABgybtPAlLvYb2LlemAVhRjaGnIaGYozc5L54E= Received: from [192.168.0.4] (cpc12-cmbg17-2-0-cust830.5-4.cable.virginm.net [86.30.131.63]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jrn@jrn.me.uk) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id D9B7B25C075 for ; Sun, 19 Jul 2015 15:51:08 -0700 (PDT) To: bitcoin-dev@lists.linuxfoundation.org References: <55A9421B.6040605@jrn.me.uk> From: Ross Nicoll Message-ID: <55AC29DB.4060800@jrn.me.uk> Date: Sun, 19 Jul 2015 23:51:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <55A9421B.6040605@jrn.me.uk> Content-Type: multipart/alternative; boundary="------------090007010103030407090103" X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Jul 2015 22:51:10 -0000 This is a multi-part message in MIME format. --------------090007010103030407090103 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Further to that - please disregard what I said about using block height. Had failed to realise that in using contextual information (block height) it complicates block validation (i.e. it would be impossible to tell if a block is too big, without having all previous blocks first). Block time is in fact the better option. Ross On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev wrote: > I'd back this if we can't find a permanent solution - 2MB gives us a > lot more wiggle room in the interim at least; one of my concerns with > block size is 3 transactions per second is absolutely tiny, and we > need space for the network to search for an equilibrium between volume > and pricing without risk of an adoption spike rendering it essentially > unusable. > > I'd favour switching over by block height rather than time, and I'd > suggest that given virtually every wallet/node out there will require > testing (even if many do not currently enforce a limit and therefore > do not need changing), 6 months should be considered a minimum target. > I'd open with a suggestion of block 390k as a target. > > Ross > > On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: >> Opening a mailing list thread on this BIP: >> >> BIP PR: https://github.com/bitcoin/bips/pull/173 >> Code PR: https://github.com/bitcoin/bitcoin/pull/6451 >> >> The general intent of this BIP is as a minimum viable alternative >> plan to my preferred proposal (BIP 100). >> >> If agreement is not reached on a more comprehensive solution, then >> this solution is at least available and a known quantity. A good >> backup plan. >> >> Benefits: conservative increase. proves network can upgrade. >> permits some added growth, while the community & market gathers data >> on how an increased block size impacts privacy, security, >> centralization, transaction throughput and other metrics. 2MB seems >> to be a Least Common Denominator on an increase. >> >> Costs: requires a hard fork. requires another hard fork down the road. >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------090007010103030407090103 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Further to that - please disregard what I said about using block height. Had failed to realise that in using contextual information (block height) it complicates block validation (i.e. it would be impossible to tell if a block is too big, without having all previous blocks first). Block time is in fact the better option.

Ross

On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev wrote:

I'd back this if we can't find a permanent solution - 2MB gives us a lot more wiggle room in the interim at least; one of my concerns with block size is 3 transactions per second is absolutely tiny, and we need space for the network to search for an equilibrium between volume and pricing without risk of an adoption spike rendering it essentially unusable.

I'd favour switching over by block height rather than time, and I'd suggest that given virtually every wallet/node out there will require testing (even if many do not currently enforce a limit and therefore do not need changing), 6 months should be considered a minimum target. I'd open with a suggestion of block 390k as a target.

Ross

On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote:
Opening a mailing list thread on this BIP:

BIP PR:=A0https://git= hub.com/bitcoin/bips/pull/173
Code PR:=A0https= ://github.com/bitcoin/bitcoin/pull/6451

The general intent of this BIP is as a minimum viable alternative plan to my preferred proposal (BIP 100).

If agreement is not reached on a more comprehensive solution, then this solution is at least available and a known quantity.=A0 A good backup plan.

Benefits: =A0conservative increase. =A0proves network can upgrade. =A0permits some added growth, while the community & market gathers data on how an increased block size impacts privacy, security, centralization, transaction throughput and other metrics. =A02MB seems to be a Least Common Denominator on an increase.

Costs: =A0requires a hard fork. =A0requires another hard f= ork down the road.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfounda=
tion.org
https://lists.=
linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev

--------------090007010103030407090103-- 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 26E09360 for ; Tue, 21 Jul 2015 09:26:39 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 915D5184 for ; Tue, 21 Jul 2015 09:26:37 +0000 (UTC) Received: by wibud3 with SMTP id ud3so121113007wib.0 for ; Tue, 21 Jul 2015 02:26:36 -0700 (PDT) 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=zEyWmkeieicYzVTYmWNFwmkEXDFA878TAr2atMsv+DM=; b=l2k1Xg0UjtK81aurJjU9pTi817BuGFTYft6ql+f+nVd/x6t4Dflc9hI/O8uwIXpUOx 7pxWDgspsrCt9JVjFBrquDGeUZAXjU6bZVv97V0udq9hw2quwhzi1eD7pqXOxObaU0zh iH9VUQuS5NXKRJWd+GIhD32ki8DXZeJbt9mUPJFs0mhTh4M2JTR/kfAYpp+1QSLcwyah VJa372HFhaMHDAlhoAiFjxebwaQv9QPXadsRoN4UFzABJRkmuB6zERHqzb8dZ2L+fnKu fUi6Y7O2AkXJJcDCOORuf1GLiO4/0gWkj7tTc7bErzyA3o5G533ZCNbD5EUQKe1Cru0e /haQ== X-Gm-Message-State: ALoCoQnhb6kBogziMdAd5uOoBLL7hsWKWXm1TQblPiDaae7ynVeN18cbT5He6+R6UsftR1WRnmgq MIME-Version: 1.0 X-Received: by 10.194.120.198 with SMTP id le6mr65411281wjb.133.1437470795970; Tue, 21 Jul 2015 02:26:35 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Tue, 21 Jul 2015 02:26:35 -0700 (PDT) In-Reply-To: <55AC29DB.4060800@jrn.me.uk> References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> Date: Tue, 21 Jul 2015 11:26:35 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Ross Nicoll Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 09:26:39 -0000 I still disagree. Using height instead of time may make the implementation more complex by requiring some additional preparations but using height is in fact a simpler design. Why relay on clocks that we know will differ in different computers and places when we have a universal tick with every block? Btw, BIP16 and BIP34 could be changed to height-based activation already. BIP16 simply should have used height instead of time from the beginning. On Mon, Jul 20, 2015 at 12:51 AM, Ross Nicoll via bitcoin-dev wrote: > Further to that - please disregard what I said about using block height. Had > failed to realise that in using contextual information (block height) it > complicates block validation (i.e. it would be impossible to tell if a block > is too big, without having all previous blocks first). Block time is in fact > the better option. > > Ross > > > On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev wrote: > > I'd back this if we can't find a permanent solution - 2MB gives us a lot > more wiggle room in the interim at least; one of my concerns with block size > is 3 transactions per second is absolutely tiny, and we need space for the > network to search for an equilibrium between volume and pricing without risk > of an adoption spike rendering it essentially unusable. > > I'd favour switching over by block height rather than time, and I'd suggest > that given virtually every wallet/node out there will require testing (even > if many do not currently enforce a limit and therefore do not need > changing), 6 months should be considered a minimum target. I'd open with a > suggestion of block 390k as a target. > > Ross > > On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: > > Opening a mailing list thread on this BIP: > > BIP PR: https://github.com/bitcoin/bips/pull/173 > Code PR: https://github.com/bitcoin/bitcoin/pull/6451 > > The general intent of this BIP is as a minimum viable alternative plan to my > preferred proposal (BIP 100). > > If agreement is not reached on a more comprehensive solution, then this > solution is at least available and a known quantity. A good backup plan. > > Benefits: conservative increase. proves network can upgrade. permits some > added growth, while the community & market gathers data on how an increased > block size impacts privacy, security, centralization, transaction throughput > and other metrics. 2MB seems to be a Least Common Denominator on an > increase. > > Costs: requires a hard fork. requires another hard fork down the road. > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > 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 E29CC268 for ; Tue, 21 Jul 2015 13:04:23 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148101.authsmtp.com (outmail148101.authsmtp.com [62.13.148.101]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id CFB418B for ; Tue, 21 Jul 2015 13:04:22 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6LD4H3M043744; Tue, 21 Jul 2015 14:04:17 +0100 (BST) Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6LD4DhI048012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Jul 2015 14:04:15 +0100 (BST) Date: Tue, 21 Jul 2015 09:04:12 -0400 From: Peter Todd To: Jorge =?iso-8859-1?Q?Tim=F3n?= Message-ID: <20150721130412.GA4551@savin.petertodd.org> References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: fdc1675e-2fa8-11e5-b397-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAMUEkAYAgsB AmMbWlBeUFl7WGU7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRp9 chpqCmBycw1GeXw+ ZEJgWHAVChApdEB6 RxtJFztXbXphaTUa TRJbfgRJcANIexZF O1F6ACIKLwdSbGoL FQ4vNDcwO3BTJTpg CissFRpLGRxDW3Y/ RhsBVSkvEAUOTiN7 Ixs5LBYAHEtZKEI7 PRM9XhpCFjV6 X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 13:04:24 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 21, 2015 at 11:26:35AM +0200, Jorge Tim=F3n via bitcoin-dev wro= te: > I still disagree. Using height instead of time may make the > implementation more complex by requiring some additional preparations > but using height is in fact a simpler design. Why relay on clocks that > we know will differ in different computers and places when we have a > universal tick with every block? The Bitcoin protocol fundementally uses time in a consensus-critical manner anyway; miners vote on what time it is via the median time mechanism. Triggering events based on median time is compatable with consensus and gives more human scale predictability as to when events may happen. In addition the median time is guaranteed to be monotonic by the consensus rules. See the version bits proposal for an example of its use: https://gist.github.com/sipa/bf69659f43e763540550#Specification Having said that, in general triggering events without verifying a supermajority of miner support can be very dangerous. Without miner support the chain is insecure, and can be attacked. For instance a blocksize limit increase that a majority of miners choose not to implement raises huge risks of reorg for any miners who attempt to create large blocks, and huge risks of payment reversal for any merchants accepting transactions in such blocks. Note how with BIP102, extending the original Bitcoin chain is inherently an attack on the Garzik chain. For that reason I think BIP102 is extremely poorly designed. I can only conclude that Jeff Garzik is either deliberately trolling us and/or manipulating discussion with a badly designed proposal that he doesn't actually expect to be adopted verbatim, or is incompetent. --=20 'peter'[:-1]@petertodd.org 0000000000000000031c12b6af038524fd5dd28115b7f5591e046423cebaf6d1 --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVrkNIXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwMTZmNzNkMTE1OWIwYTcwNTJiNDljZjNjYjgyOWZmYTRh NDdiZTM4NjhkYjZiMjkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftPfAf/dDREDW+AFkXfHhtfJeAfWngl oJwCAEmxCAewnv7tR8xOrTo5hXde2Z79Q7P48rNq+5mpWrrX+e4n3ji22nJJUXgn oXdjMS/uEugfNczqAmyA+5iU6UwDnVTPVoYH/HQleQiA9WklklwVg/fajQwq8xnr adLrpIr22ErUQjrDb+rvmg3uSEmnsH54P+SIYcV4kxF3mfte+HVs9we7d8p3J3HR lptpIJzPmKL0O+ak0wKcAkEgkdHtPHLRJnDglKlctDHE5w81iY+CbUch3qTErVZY wq+BevuGcYi5HhSa0qD0mdthf53Qng4UJ93/YDLiPPd1DIoBsShU9Kakgb2SGw== =g6Aw -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3-- 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 EA14940C for ; Tue, 21 Jul 2015 13:58:53 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148110.authsmtp.com (outmail148110.authsmtp.com [62.13.148.110]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 4029B153 for ; Tue, 21 Jul 2015 13:58:53 +0000 (UTC) Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6LDwoRH072323; Tue, 21 Jul 2015 14:58:50 +0100 (BST) Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6LDwkvf004887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 21 Jul 2015 14:58:49 +0100 (BST) Date: Tue, 21 Jul 2015 09:58:46 -0400 From: Peter Todd To: Jorge =?iso-8859-1?Q?Tim=F3n?= , bitcoin-dev@lists.linuxfoundation.org Message-ID: <20150721135846.GB13429@savin.petertodd.org> References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> <20150721130412.GA4551@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eJnRUKwClWJh1Khz" Content-Disposition: inline In-Reply-To: <20150721130412.GA4551@savin.petertodd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 9cdd020a-2fb0-11e5-9f75-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAMUEkAYAgsB AmMbWlBeVVV7XWo7 bA9PbARUfEhLXhtr VklWR1pVCwQmRRp9 cllFFE9ydwFOcHk+ ZERnWXMVVRcuIUZ/ Qh9JFztUZXphaTUa TUkOcAZJcANIexZF O1F8UScOLwdSbGoL FQ4vNDcwO3BTJTpg CissFRpLGRxDW3Y/ RhsBVSkvEAUOTiN7 Ixs5LBYAHEtZKEI7 PRM9XhpCFjV6 X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 13:58:54 -0000 --eJnRUKwClWJh1Khz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 21, 2015 at 09:04:12AM -0400, Peter Todd via bitcoin-dev wrote: > For that reason I think BIP102 is extremely poorly designed. I can only > conclude that Jeff Garzik is either deliberately trolling us and/or > manipulating discussion with a badly designed proposal that he doesn't > actually expect to be adopted verbatim, or is incompetent. Expanding on that a bit: On Tue, Jul 21, 2015 at 09:14:26PM +0800, Jeremy Rubin wrote: > unsolicited feedback: > > I'd send a quick apology for this bit > > """ > For that reason I think BIP102 is extremely poorly designed. I can only > conclude that Jeff Garzik is either deliberately trolling us and/or > manipulating discussion with a badly designed proposal that he doesn't > actually expect to be adopted verbatim, or is incompetent. > """ > > it's a little over the top. > > I think that Garzik is probably releasing it in reaction to the fact > certain people are only looking at something with code attached. > > No need to call someone stupid for sharing a proposal... although it seems > sketchy that he got a BIP # for this. You want to foster a less hostile > community... I don't agree with you at all. This is a case where if Jeff doesn't understand that issue, he's proposing changes that he's not competent enough to understand, and it'd save us a lot of review effort if he left that discussion. Equally, Jeff is in a position in the dev community where he should be that competent; if he actually isn't it does a lot of good for the broader community to change that opinion. I personally *don't* think he's doing that, rather I believe he knows full well it's a bad patch and is proposing it because he wants to push discussion towards a solution. Often trolling the a audience with bad patches is an effective way to motivate people to respond by writing better ones; Jeff has told me he often does exactly that. I think in this case we shouldn't do anything, so short-circuiting that process by pointing out what he's doing publicly makes sense. Re: BIP #'s, we explicitly have a policy of allocating them for stupid ideas, to avoid having to be gatekeepers. Ironically that makes it harder to get a BIP # if you know what you're doing, because Gregory Maxwell will argue against you in private and delay actually allocating one if he knows you should know better. :) --=20 'peter'[:-1]@petertodd.org 00000000000000000d9cad4228c0396ff49c1de60f8ee155928eee22705f6619 --eJnRUKwClWJh1Khz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJVrlARXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwZDljYWQ0MjI4YzAzOTZmZjQ5YzFkZTYwZjhlZTE1NTky OGVlZTIyNzA1ZjY2MTkvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfuIGAgArJ1VDJqr9VoeTqHrDBy/kpUp tbsAxunKm2XdqM30US4h1WNQ+epAFG39MOdWxYmFhYvyQBbuML2gPJJ+dYhVdgKu CHIMqd/+Eksu5kZ+SBXW8QKZA5XnM86mp9tQlQgWCkPEc3riD5panYIVI9pn/BeH lLRRfbKTYu7MAe89D2su0Gjt09VGH3rT7e9rW4tY/Ok7T56zNmiSD8kvJVXHCyQa C1p8DvWUs1PpVL/S3hlWZpzlJFOz1GyysgmXJQJ2bG/44EPMAt/wB/I47eGCqLY6 dxAr25vrKMN/x0wslQjGp+EVUgPu8AxpJYe+VTai06TQ33o6mlkfFkPu8/HuUw== =Kfo6 -----END PGP SIGNATURE----- --eJnRUKwClWJh1Khz-- 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 290CF3C8 for ; Tue, 21 Jul 2015 22:05:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from homiemail-a60.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id F1BF4112 for ; Tue, 21 Jul 2015 22:05:15 +0000 (UTC) Received: from homiemail-a60.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTP id 48B4F3BC078; Tue, 21 Jul 2015 15:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to :references:cc:from:message-id:date:mime-version:in-reply-to :content-type:content-transfer-encoding; s=jrn.me.uk; bh=Vj+bjNa 9wVW+MP0VgMS2umS8Ers=; b=1ehMldXj71+aT1K1AqHxtuNSy9guFjZkQwHHOns qJOWmyhmQ5VziHWtT6iZwymeNt084TPPe91Li9Skz046QRJvlg95F6V5Mlns1Bz/ ab4XKmm548hmAD6BVtitvpOq/AyAO3kVCpF1EcMYyOJE4RMN4IgMaIC/bQ08jOe2 I0jk= Received: from [192.168.0.4] (cpc12-cmbg17-2-0-cust830.5-4.cable.virginm.net [86.30.131.63]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jrn@jrn.me.uk) by homiemail-a60.g.dreamhost.com (Postfix) with ESMTPSA id A9DC53BC073; Tue, 21 Jul 2015 15:05:14 -0700 (PDT) To: =?UTF-8?Q?Jorge_Tim=c3=b3n?= References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> From: Ross Nicoll Message-ID: <55AEC21A.3090302@jrn.me.uk> Date: Tue, 21 Jul 2015 23:05:14 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 22:05:17 -0000 Not so much that the implementation is difficult, as it requires context=20 to validate a block size, rather than being able to validate it without=20 requiring the preceeding blocks. Yes, time on different machines may=20 vary, but block time is safe to use for this, because it's a=20 straight-forward test of "if block time is acceptable and block time is=20 after then maximum block size allowed is n MB otherwise m MB". Ross On 21/07/2015 10:26, Jorge Tim=C3=B3n wrote: > I still disagree. Using height instead of time may make the > implementation more complex by requiring some additional preparations > but using height is in fact a simpler design. Why relay on clocks that > we know will differ in different computers and places when we have a > universal tick with every block? > > Btw, BIP16 and BIP34 could be changed to height-based activation > already. BIP16 simply should have used height instead of time from the > beginning. > > On Mon, Jul 20, 2015 at 12:51 AM, Ross Nicoll via bitcoin-dev > wrote: >> Further to that - please disregard what I said about using block heigh= t. Had >> failed to realise that in using contextual information (block height) = it >> complicates block validation (i.e. it would be impossible to tell if a= block >> is too big, without having all previous blocks first). Block time is i= n fact >> the better option. >> >> Ross >> >> >> On 17/07/2015 18:57, Ross Nicoll via bitcoin-dev wrote: >> >> I'd back this if we can't find a permanent solution - 2MB gives us a l= ot >> more wiggle room in the interim at least; one of my concerns with bloc= k size >> is 3 transactions per second is absolutely tiny, and we need space for= the >> network to search for an equilibrium between volume and pricing withou= t risk >> of an adoption spike rendering it essentially unusable. >> >> I'd favour switching over by block height rather than time, and I'd su= ggest >> that given virtually every wallet/node out there will require testing = (even >> if many do not currently enforce a limit and therefore do not need >> changing), 6 months should be considered a minimum target. I'd open wi= th a >> suggestion of block 390k as a target. >> >> Ross >> >> On 17/07/2015 16:55, Jeff Garzik via bitcoin-dev wrote: >> >> Opening a mailing list thread on this BIP: >> >> BIP PR: https://github.com/bitcoin/bips/pull/173 >> Code PR: https://github.com/bitcoin/bitcoin/pull/6451 >> >> The general intent of this BIP is as a minimum viable alternative plan= to my >> preferred proposal (BIP 100). >> >> If agreement is not reached on a more comprehensive solution, then thi= s >> solution is at least available and a known quantity. A good backup pl= an. >> >> Benefits: conservative increase. proves network can upgrade. permit= s some >> added growth, while the community & market gathers data on how an incr= eased >> block size impacts privacy, security, centralization, transaction thro= ughput >> and other metrics. 2MB seems to be a Least Common Denominator on an >> increase. >> >> Costs: requires a hard fork. requires another hard fork down the roa= d. >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >> >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> 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 11153482 for ; Wed, 22 Jul 2015 15:51:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f41.google.com (mail-oi0-f41.google.com [209.85.218.41]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 749E516B for ; Wed, 22 Jul 2015 15:51:34 +0000 (UTC) Received: by oigd21 with SMTP id d21so104182281oig.1 for ; Wed, 22 Jul 2015 08:51:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=abRE5I06tQL+wtnuwqsTQpvHxTjN65DrZ9eNbD6b6uk=; b=RnMzVUvDZ+8m7BKdYqOPGZg4VYkHFUuTKrZ2TjPH1a1Bw/c3aN9Nyxsib6zjcpkC7k 2TaDSkIFnh93PYgyWVbxt4a3qh8FeZytrPtwyPTI23G7KlAJvdaqTIiVzIsNQ2V5IyHo TiNItN/JKj3TAlqwP6qobsc023u4A2/J3AeScfKGdIjzwJxn9k7j2eRRlPJPUpAveIlS 1TJgA2W75ipKz8bMjc8ZeSOFYASp9r29PuFAPYcrchBJqbeLUgRydf+0tEn6dCUqH2l5 n3DThKAmUu0p/LCQORzqCM48U0tKH6ViMhVl7u73cvsm/oqveeb6O1Ug4Lnx7soC503D CfIA== X-Gm-Message-State: ALoCoQn9zyyyssGG3rvTJ4oUQGuog3FxyaLoahB9xBw+H2OWBkH4sXLMBhJzKZTbCdObzYJc35oa X-Received: by 10.60.174.39 with SMTP id bp7mr3508616oec.70.1437580293949; Wed, 22 Jul 2015 08:51:33 -0700 (PDT) Received: from [10.100.1.239] ([204.58.254.99]) by smtp.googlemail.com with ESMTPSA id j2sm976280obh.16.2015.07.22.08.51.32 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jul 2015 08:51:32 -0700 (PDT) From: Tom Harding To: bitcoin-dev@lists.linuxfoundation.org References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> <20150721130412.GA4551@savin.petertodd.org> <20150721135846.GB13429@savin.petertodd.org> Message-ID: <55AFBBFB.5040101@thinlink.com> Date: Wed, 22 Jul 2015 08:51:23 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <20150721135846.GB13429@savin.petertodd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_SORBS_WEB autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:51:35 -0000 On 7/21/2015 6:58 AM, Peter Todd via bitcoin-dev wrote: > Re: BIP #'s, we explicitly have a policy of allocating them for stupid > ideas, to avoid having to be gatekeepers. Ironically that makes it > harder to get a BIP # if you know what you're doing, because Gregory > Maxwell will argue against you in private and delay actually > allocating one if he knows you should know better. :) Kalle asked for a BIP# for his PoP standardization proposal one month ago. Should he have known better? 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 EA5364A4 for ; Wed, 22 Jul 2015 17:02:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pd0-f172.google.com (mail-pd0-f172.google.com [209.85.192.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AB74E1A5 for ; Wed, 22 Jul 2015 17:02:49 +0000 (UTC) Received: by pdbnt7 with SMTP id nt7so70518240pdb.0 for ; Wed, 22 Jul 2015 10:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1TBZ0reGmW+psHcdy5yUeqAJvwd4XkFuD+tzDg8TVos=; b=j8KksSt44UMspCMWtRb1/e80ZZekAj1MPtPsVBkcPEnSF+JSniooKG350oFDPgXlYa aywOBh7uazl0/p8JqjVBk5fClKRaN4Q5VEpSaCTMLDK8s6AMIzzGPWD5vHrOML/ZnpNr +Csv6X/t6OmW8tt14IrIb3bN+NZOKR8uiyHvDntya2vjIAIUAGLfxthOxkdd0LMPw7mV KyN0WV7gXeiGTPZPCG7HlrMgXCyVjCeGThPdw9j8sj6eKhONITMbiheIqfnw9wIy2gCe wDDXBjm8DMiL6p5Sd0XfzSY1GliLY7uP4lcO/96iWL4LTWTS/T7J20B31jRYalBVbBuM r7Mg== MIME-Version: 1.0 X-Received: by 10.70.1.102 with SMTP id 6mr7933788pdl.32.1437584569296; Wed, 22 Jul 2015 10:02:49 -0700 (PDT) Received: by 10.66.83.7 with HTTP; Wed, 22 Jul 2015 10:02:49 -0700 (PDT) In-Reply-To: <20150721135846.GB13429@savin.petertodd.org> References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> <20150721130412.GA4551@savin.petertodd.org> <20150721135846.GB13429@savin.petertodd.org> Date: Wed, 22 Jul 2015 22:32:49 +0530 Message-ID: From: Sriram Karra To: Peter Todd Content-Type: multipart/alternative; boundary=047d7b6d7d84966d35051b79bd5d X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 17:02:50 -0000 --047d7b6d7d84966d35051b79bd5d Content-Type: text/plain; charset=UTF-8 On Tue, Jul 21, 2015 at 7:28 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I personally *don't* think he's doing that, rather I believe he knows > full well it's a bad patch and is proposing it because he wants to push > discussion towards a solution. Often trolling the a audience with bad > patches is an effective way to motivate people to respond by writing > better ones; Jeff has told me he often does exactly that. > > I think in this case we shouldn't do anything, so short-circuiting that > process by pointing out what he's doing publicly makes sense. > Assuming that's what Jeff is doing, how does preventing better solutions from emerging 'make sense'? --047d7b6d7d84966d35051b79bd5d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Jul 21, 2015 at 7:28 PM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

= =C2=A0

I personally *don't* think he's doing that, rather I believe he kno= ws
full well it's a bad patch and is proposing it because he wants to push=
discussion towards a solution. Often trolling the a audience with bad
patches is an effective way to motivate people to respond by writing
better ones; Jeff has told me he often does exactly that.

I think in this case we shouldn't do anything, so short-circuiting that=
process by pointing out what he's doing publicly makes sense.

Assuming that's what Jeff is doing, how does= preventing better solutions from emerging 'make sense'?
<= /div>

--047d7b6d7d84966d35051b79bd5d-- 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 A23E75AE for ; Wed, 22 Jul 2015 17:37:13 +0000 (UTC) X-Greylist: delayed 00:36:30 by SQLgrey-1.7.6 Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0DED01BF for ; Wed, 22 Jul 2015 17:37:13 +0000 (UTC) Received: from localhost ([::1]:46555 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1ZHxNq-000AIs-0o for bitcoin-dev@lists.linuxfoundation.org; Wed, 22 Jul 2015 13:00:42 -0400 Received: from 119.246.245.241 ([119.246.245.241]) by server47.web-hosting.com (Horde Framework) with HTTP; Wed, 22 Jul 2015 17:00:41 +0000 Date: Wed, 22 Jul 2015 17:00:41 +0000 Message-ID: <20150722170041.Horde.N2psXR0k1XYN4_s0phBwGg1@server47.web-hosting.com> From: jl2012@xbt.hk To: bitcoin-dev@lists.linuxfoundation.org References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> <20150721130412.GA4551@savin.petertodd.org> In-Reply-To: <20150721130412.GA4551@savin.petertodd.org> User-Agent: Internet Messaging Program (IMP) H5 (6.1.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server47.web-hosting.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - xbt.hk X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 17:37:13 -0000 Quoting Peter Todd via bitcoin-dev : > > Having said that, in general triggering events without verifying a > supermajority of miner support can be very dangerous. Without miner > support the chain is insecure, and can be attacked. For instance a > blocksize limit increase that a majority of miners choose not to > implement raises huge risks of reorg for any miners who attempt to > create large blocks, and huge risks of payment reversal for any > merchants accepting transactions in such blocks. Note how with BIP102, > extending the original Bitcoin chain is inherently an attack on the > Garzik chain. > > For that reason I think BIP102 is extremely poorly designed. I can only > conclude that Jeff Garzik is either deliberately trolling us and/or > manipulating discussion with a badly designed proposal that he doesn't > actually expect to be adopted verbatim, or is incompetent. > > -- > 'peter'[:-1]@petertodd.org > 0000000000000000031c12b6af038524fd5dd28115b7f5591e046423cebaf6d1 To avoid any risk of reorg, the hardfork may require that the first block with GetMedianTimePast() after a pre-determined time (the "flag block") MUST be version 0. The exception is applied ONLY to the flag block. Alternatively, the hardfork may require that the flag block MUST be larger than 1MB. Comparing with exploiting the block version, this does not require additional exceptions in consensus rules. However, miner may need to artificially inflate the size of the flag block and that could be trouble in coding. I don't have any preference. Old nodes will not accept the new chain because it violates BIP66 / block size limit. New nodes will not accept the old chain because its flag block is not version 0 / not larger than 1MB. This is actually checkpointing in a decentralized way. In that case, we can say goodbye to the old chain forever, as long as all major merchants and exchanges agree to upgrade. Miner support is less relevant. It is a no-brainer for miners to support the new chain, unless they don't want to sell or spend their bitcoin, or just give up mining after heavily investing in ASIC. jl2012 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 1D2405AD for ; Wed, 22 Jul 2015 17:40:59 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pa0-f45.google.com (mail-pa0-f45.google.com [209.85.220.45]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C681923A for ; Wed, 22 Jul 2015 17:40:58 +0000 (UTC) Received: by pacan13 with SMTP id an13so143289396pac.1 for ; Wed, 22 Jul 2015 10:40:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nZO0pr7vWaIFtZ3SICiHYm5WGXXOi8GOmEfGZfK2Ll0=; b=Mi8njxGrQkKLrr7WWBidSgdBDAV1JIjVf8SLa3YmtfVF8VMeWm7YPfvTQ7rVDPr8WG Gjs72guqb8fB0bit0c+R2ueooKNnKwWuhsd5Yx02ZkcoxlNhFx3zP50AxyKjrOWXyxO4 tnmjxr9Pd0ra5sNMBZmnwCzAxK/W3dodbkFlQIuWdMZr7pybVAktxgXoFzETX83dxxEK rwuMGb8t3uDmqLAIL5t++QkxUVKmZ7E+60LBxh4fK7RY9Jwi2wMQV8/ZV/E+ccpQwCa5 8wkQWxwz1nDL449KppwdkLP3NneR/sHdOOZymsK6uhWN6Pogni6VJhOQgJ6SBfXGiqPD wZww== MIME-Version: 1.0 X-Received: by 10.66.217.138 with SMTP id oy10mr8284147pac.83.1437586858471; Wed, 22 Jul 2015 10:40:58 -0700 (PDT) Received: by 10.66.83.7 with HTTP; Wed, 22 Jul 2015 10:40:58 -0700 (PDT) In-Reply-To: References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> <20150721130412.GA4551@savin.petertodd.org> <20150721135846.GB13429@savin.petertodd.org> Date: Wed, 22 Jul 2015 23:10:58 +0530 Message-ID: From: Sriram Karra To: Peter Todd Content-Type: multipart/alternative; boundary=e89a8f83aa7b08790c051b7a4619 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 17:40:59 -0000 --e89a8f83aa7b08790c051b7a4619 Content-Type: text/plain; charset=UTF-8 On Wed, Jul 22, 2015 at 10:32 PM, Sriram Karra wrote: > > On Tue, Jul 21, 2015 at 7:28 PM, Peter Todd via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > >> I personally *don't* think he's doing that, rather I believe he knows >> full well it's a bad patch and is proposing it because he wants to push >> discussion towards a solution. Often trolling the a audience with bad >> patches is an effective way to motivate people to respond by writing >> better ones; Jeff has told me he often does exactly that. >> >> I think in this case we shouldn't do anything, so short-circuiting that >> process by pointing out what he's doing publicly makes sense. >> > > Assuming that's what Jeff is doing, how does preventing better solutions > from emerging 'make sense'? > Peter, sorry, scratch that. --e89a8f83aa7b08790c051b7a4619 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Jul 22, 2015 at 10:32 PM, Sriram Karra <karra.etc@gmail.com&= gt; wrote:

On Tue= , Jul 21, 2015 at 7:28 PM, Peter Todd via bitcoin-dev <= ;bitcoin-dev@lists.linuxfoundation.org> wrote:
=C2=A0=
I personally *don't* think he's doing that, rather I believe he kno= ws
full well it's a bad patch and is proposing it because he wants to push=
discussion towards a solution. Often trolling the a audience with bad
patches is an effective way to motivate people to respond by writing
better ones; Jeff has told me he often does exactly that.

I think in this case we shouldn't do anything, so short-circuiting that=
process by pointing out what he's doing publicly makes sense.

Assuming that's what Jeff is doing, h= ow does preventing better solutions from emerging 'make sense'?
=

Peter, sorry,=C2=A0= scratch that.

--e89a8f83aa7b08790c051b7a4619-- 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 43E545AE for ; Wed, 22 Jul 2015 17:45:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ie0-f170.google.com (mail-ie0-f170.google.com [209.85.223.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 93089143 for ; Wed, 22 Jul 2015 17:45:31 +0000 (UTC) Received: by iehx8 with SMTP id x8so93226707ieh.3 for ; Wed, 22 Jul 2015 10:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CstGkpa0P5IpBs25RnFcnDRYD3Wsp9q93/aM6EnWdoQ=; b=eDkzlecgI0xf2peHcgg71SPHOdJeHO/Uab6cWHg195VxX3s3knJ9yMdSsji76+oZFN wHDCeyO/2o27ZfoLSkkhwXNZsDruOPbVoZdm9Whay6V50l8FJjJryTT4S6QVW+XfCS7K FbaC/bZuM9IjQ4Oi1AJ9Y8YSpwv6V7bW+WSCWtLYRgFXEP+sT47iTSOJXV/i5YEXCYYU jxuqG+0EJvhJn9ZsuvOmaBLPmlkJPnM/X6DqjLlQLvJ+eHFCTg2+N9nVdcwhR3c/Vjvq VNzz+h4YRwpU6Hxu+WSCYo8b49bNZ7b/r1V7GJz2u9njCtIzXh/vcn5uMRin1Y41Kt4s fNjQ== MIME-Version: 1.0 X-Received: by 10.50.3.6 with SMTP id 6mr34227211igy.28.1437586999381; Wed, 22 Jul 2015 10:43:19 -0700 (PDT) Received: by 10.79.38.79 with HTTP; Wed, 22 Jul 2015 10:43:19 -0700 (PDT) In-Reply-To: <20150721135846.GB13429@savin.petertodd.org> References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> <20150721130412.GA4551@savin.petertodd.org> <20150721135846.GB13429@savin.petertodd.org> Date: Wed, 22 Jul 2015 10:43:19 -0700 Message-ID: From: Jeff Garzik To: Peter Todd Content-Type: multipart/alternative; boundary=089e0122aa626ed54e051b7a4eb9 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 17:45:32 -0000 --089e0122aa626ed54e051b7a4eb9 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I don't agree with you at all. > > This is a case where if Jeff doesn't understand that issue, he's > proposing changes that he's not competent enough to understand, and it'd > save us a lot of review effort if he left that discussion. Equally, Jeff > is in a position in the dev community where he should be that competent; > if he actually isn't it does a lot of good for the broader community to > change that opinion. > > I personally *don't* think he's doing that, rather I believe he knows > full well it's a bad patch and is proposing it because he wants to push > discussion towards a solution. Often trolling the a audience with bad > patches is an effective way to motivate people to respond by writing > better ones; Jeff has told me he often does exactly that. > > mmmm kay. Let's try to keep it technical, please. 2MB is a limit that has been discussed as a viable next-step, meeting with the most consensus. 2MB gets beyond the 1MB hard fork issue, while still remaining within a safety cap that should ensure the system does not go "off the rails" as some has predicted. Security, privacy and centralization are not going to disappear at 2MB. Further, a limited step gains valuable field data for judging whether further steps are warranted - thus informing the "better block size solution" development process. Finally, as stated in the initial PR, it is intended as a viable fallback should we reach a point of criticality where the user community feels a block size increase is warranted, yet cannot reach consensus on a fancy, all-consuming solution be it 20MB, flexcap, BIP 100, BIP 102, etc. I am open to suggestions for improving BIP 102. The goal is a minimum complexity fallback that others have previously agreed was a useful kick-the-can compromise - a static 2MB cap. --089e0122aa626ed54e051b7a4eb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-de= v <bitcoin-dev@lists.linuxfoundation.org> wrote:

I don't agree with you at all.

This is a case where if Jeff doesn't understand that issue, he's proposing changes that he's not competent enough to understand, and it&= #39;d
save us a lot of review effort if he left that discussion. Equally, Jeff is in a position in the dev community where he should be that competent; if he actually isn't it does a lot of good for the broader community to=
change that opinion.

I personally *don't* think he's doing that, rather I believe he kno= ws
full well it's a bad patch and is proposing it because he wants to push=
discussion towards a solution. Often trolling the a audience with bad
patches is an effective way to motivate people to respond by writing
better ones; Jeff has told me he often does exactly that.

mmmm kay.=C2=A0 Let's try to keep it technical, = please.

2MB is a limit that has been discussed as = a viable next-step, meeting with the most consensus.

2MB gets beyond the 1MB hard fork issue, while still remaining within a = safety cap that should ensure the system does not go "off the rails&qu= ot; as some has predicted.

Security, privacy and c= entralization are not going to disappear at 2MB.

F= urther, a limited step gains valuable field data for judging whether furthe= r steps are warranted - thus informing the "better block size solution= " development process.

Finally, as stated in = the initial PR, it is intended as a viable fallback should we reach a point= of criticality where the user community feels a block size increase is war= ranted, yet cannot reach consensus on a fancy, all-consuming solution be it= 20MB, flexcap, BIP 100, BIP 102, etc.

I am open t= o suggestions for improving BIP 102.=C2=A0 The goal is a minimum complexity= fallback that others have previously agreed was a useful kick-the-can comp= romise - a static 2MB cap.

--089e0122aa626ed54e051b7a4eb9-- 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 B7EF449D for ; Wed, 22 Jul 2015 22:30:36 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148110.authsmtp.com (outmail148110.authsmtp.com [62.13.148.110]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id E4C9BEA for ; Wed, 22 Jul 2015 22:30:35 +0000 (UTC) Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6MMUWdX062696; Wed, 22 Jul 2015 23:30:32 +0100 (BST) Received: from [25.157.251.156] ([24.114.64.222]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6MMUSmM005580 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Jul 2015 23:30:29 +0100 (BST) In-Reply-To: References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> <20150721130412.GA4551@savin.petertodd.org> <20150721135846.GB13429@savin.petertodd.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Peter Todd Date: Wed, 22 Jul 2015 22:30:25 +0000 To: Jeff Garzik Message-ID: X-Server-Quench: 4284a6a2-30c1-11e5-b397-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAAUEkAYAgsB AmMbWVdeU117WmM7 aQ5PbARZfExKQQdo UldNRFdNFUssB2F8 Y31DLxlycgBOeDBx YUFiVj5fXkx+JEAs QFNXFT4HeGZhPWUC AkNRcB5UcAFPdx8U a1UrBXRDAzANdhEy HhM4ODE3eDlSNhEd aCA1ZQtKGw5OVj09 TBNKATUiVUYMQW0/ KAMgYkIcEQ4LNUw+ eUcmEQg9GXc8 X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 24.114.64.222/465 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 22:30:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Sorry, but I think you need to re-read my first message. What you've written below has nothing to do with what I actually said re: how you're BIP102 and associated pull-req doesn't measure miner consensus. On 22 July 2015 13:43:19 GMT-04:00, Jeff Garzik wrote: >On Tue, Jul 21, 2015 at 6:58 AM, Peter Todd via bitcoin-dev < >bitcoin-dev@lists.linuxfoundation.org> wrote: > >> I don't agree with you at all. >> >> This is a case where if Jeff doesn't understand that issue, he's >> proposing changes that he's not competent enough to understand, and >it'd >> save us a lot of review effort if he left that discussion. Equally, >Jeff >> is in a position in the dev community where he should be that >competent; >> if he actually isn't it does a lot of good for the broader community >to >> change that opinion. >> >> I personally *don't* think he's doing that, rather I believe he knows >> full well it's a bad patch and is proposing it because he wants to >push >> discussion towards a solution. Often trolling the a audience with bad >> patches is an effective way to motivate people to respond by writing >> better ones; Jeff has told me he often does exactly that. >> >> >mmmm kay. Let's try to keep it technical, please. > >2MB is a limit that has been discussed as a viable next-step, meeting >with >the most consensus. > >2MB gets beyond the 1MB hard fork issue, while still remaining within a >safety cap that should ensure the system does not go "off the rails" as >some has predicted. > >Security, privacy and centralization are not going to disappear at 2MB. > >Further, a limited step gains valuable field data for judging whether >further steps are warranted - thus informing the "better block size >solution" development process. > >Finally, as stated in the initial PR, it is intended as a viable >fallback >should we reach a point of criticality where the user community feels a >block size increase is warranted, yet cannot reach consensus on a >fancy, >all-consuming solution be it 20MB, flexcap, BIP 100, BIP 102, etc. > >I am open to suggestions for improving BIP 102. The goal is a minimum >complexity fallback that others have previously agreed was a useful >kick-the-can compromise - a static 2MB cap. -----BEGIN PGP SIGNATURE----- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsBl2 AAoJEMCF8hzn9Lnc47AIAICM9pA+Jc6rkJ14U0vYqzhwTHmxuaNTXodmI1z88OKM zCCJQHNw/Xhy339/ZGFeUuVS/Csw275dtzZutLoZamnGnQLh9LllxYFzN8eGJkCL Ecfo0JcyhduwUihgDfzgE++z5/Q0z5sIo+pZBNipqXW1+N0P/GAvYlHqeb9r0uXG ccJghZUTwqzm6aySfvXVveTmp0AtjVko1jP1sTxF2pI/RIqBdMY4wEsZvmEhX7Tk g2iRiPWiEIYR1qETm6e5aQ/tj8W73932s15ozIM35nD5QId5qotQHTVttLAruQvl 2Z35F79TIYDvYtnnRNWIsOyiwreH/y5c0kSUIgrjASA= =+jTv -----END PGP SIGNATURE----- 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 C4DD4411 for ; Thu, 23 Jul 2015 05:39:22 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 43AF38B for ; Thu, 23 Jul 2015 05:39:22 +0000 (UTC) Received: from localhost ([::1]:43719 helo=server47.web-hosting.com) by server47.web-hosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from ) id 1ZI9E0-002TJq-GZ for bitcoin-dev@lists.linuxfoundation.org; Thu, 23 Jul 2015 01:39:20 -0400 Received: from 119.246.245.241 ([119.246.245.241]) by server47.web-hosting.com (Horde Framework) with HTTP; Thu, 23 Jul 2015 05:39:20 +0000 Date: Thu, 23 Jul 2015 05:39:20 +0000 Message-ID: <20150723053920.Horde.NFnYiomFYphgmxoOpN4phA3@server47.web-hosting.com> From: jl2012@xbt.hk To: bitcoin-dev@lists.linuxfoundation.org References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> <20150721130412.GA4551@savin.petertodd.org> <20150721135846.GB13429@savin.petertodd.org>

In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.1.4) Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server47.web-hosting.com X-AntiAbuse: Original Domain - lists.linuxfoundation.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - xbt.hk X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id: jl2012@xbt.hk X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 05:39:22 -0000 Quoting Peter Todd via bitcoin-dev : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Sorry, but I think you need to re-read my first message. What you've > written below has nothing to do with what I actually said re: how > you're BIP102 and associated pull-req doesn't measure miner consensus. > > I think I have already answered this with my previous mail. If there is consensus among major exchanges and merchants, the preference of miners are not particularly relevant. A checkpoint could be implemented in a decentralized way to make sure miners of the original chain won't be able to overtake the new chain. Bitcoin has no intrinsic value. Bitcoin has value because people are willing to exchange it with something really valuable (e.g. a pizza; or USD which could buy a pizza). If most bitcoin-accepting business agree to follow BIP102 and ONLY BIP102, then BIP102 is THE Bitcoin, and the original chain is just a dSHA256 alt-coin which one can't even merge mine with BIP102. Switching to BIP102 is the only economically viable choice for miners. Having said that, a miner voting may still be useful. It is just to make sure enough miners are ready for the change, instead of measuring their consensus. For example, the new rule will be implemented 1) 1 week after 70% of miners are ready; or 2) on 1 Feb 2016, whichever happens first. For SPV wallets, they have to strengthen their security model after the BIP66 fork, anyway. They should be able to identify potential consensus fork in the network and stop accepting incoming txs when it is in doubt. My "version 0 flag block" proposal could be a good generic way to indicate a hardfork to SPV wallets. (see my previous email on this topic) 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 A22C5416 for ; Thu, 23 Jul 2015 11:24:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com [209.85.212.181]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7E63417B for ; Thu, 23 Jul 2015 11:24:54 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so144230583wib.1 for ; Thu, 23 Jul 2015 04:24:53 -0700 (PDT) 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 :content-transfer-encoding; bh=EYq1dXBGu6YDGff2c+c/CjkCP+cmpD7xRdwyTBBrl6Y=; b=MY+CA1sZh4P9pCd64hLF0OY9cWjP9hFjw0mvF1UhoCjsVts2Zlbgf9tjUowoycsUOV 4KRw7sFoSTQ88OFHajx9Qfq1bnC84CPjmkBJjgKSX2prr3O64ASo/59tu4BYn693c/ph QnuGEoRcQRXZl2G8bNhEZxz2dzYIs8+nGUwfK5YF+lZE2+Fjx0DqgsMKo/RV3SNEuhNY gUNE18XENUfpu9eIWNHtu8t+ASN6gdASJyWcI/2C6Z4mUxjAShQk61JM9ncUn/+x3Ak2 MM7zDKx7edIppdOxKhWxW374A4SNwcItIDBWkWP6Xyu7z9tBGUdUKXYmccP3AjV8FcI4 IZYQ== X-Gm-Message-State: ALoCoQlas84myeZm/lnhtg9Hvjl0mkNXPVt0jKNwaadGARFFbEGyBFk6ION55JGOP0O9FEUAHVhv MIME-Version: 1.0 X-Received: by 10.180.109.6 with SMTP id ho6mr52213703wib.58.1437650692936; Thu, 23 Jul 2015 04:24:52 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Thu, 23 Jul 2015 04:24:52 -0700 (PDT) In-Reply-To: <55AEC21A.3090302@jrn.me.uk> References: <55A9421B.6040605@jrn.me.uk> <55AC29DB.4060800@jrn.me.uk> <55AEC21A.3090302@jrn.me.uk> Date: Thu, 23 Jul 2015 13:24:52 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Ross Nicoll Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 11:24:55 -0000 Peter Todd, as discussed on IRC, I'm not opposed to median time, which has many of the properties nheight has, I'm just opposed to just using nTime which is what all "hardfork proposals" I've seen so far (including this one) do. On Wed, Jul 22, 2015 at 12:05 AM, Ross Nicoll wrote: > On 21/07/2015 10:26, Jorge Tim=C3=B3n wrote: >> >> I still disagree. Using height instead of time may make the >> implementation more complex by requiring some additional preparations >> but using height is in fact a simpler design. Why relay on clocks that >> we know will differ in different computers and places when we have a >> universal tick with every block? > > Not so much that the implementation is difficult, as it requires context = to > validate a block size, rather than being able to validate it without > requiring the preceeding blocks. Yes, time on different machines may vary= , > but block time is safe to use for this, because it's a straight-forward t= est > of "if block time is acceptable and block time is after then maxim= um > block size allowed is n MB otherwise m MB". No, the height is in the current block after bip34, no context required. In any case, you already have the nHeight in most functions that would require it (for example, main::ConnectBlock). The median time actually needs a context (the last 10 headers), but it's not hard to calculate and pass around either. But simply using nTime is not a good idea. Leaving aside time zones, einstein and all that it introduces edge cases and weird incentives for no good reason. If the goal is to make it "human-schedule-friendly", median time should be good enough. If we're going to make miners 95% confirm after the date/height, I still prefer the height, but as said median time seems a reasonable compromise. Can we move the "height/medianTime/nTime" and "is it good to confirm that the change is uncontroversial to miners by requiring 95% to activate the consensus change, like we do with uncontroversial softforks?" discussions to the thread with my bip draft ( http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008936.htm= l ) on precisely this subject? I have requested a bip number. Let's please have an uncontroversial hardfork to set a precedent. Hopefully that way we may decouple some parts of the blocksize discussion. 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 7E226416 for ; Fri, 24 Jul 2015 08:52:28 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from pmx.vmail.no (pmx.vmail.no [193.75.16.11]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id E6759E9 for ; Fri, 24 Jul 2015 08:52:27 +0000 (UTC) Received: from pmx.vmail.no (localhost [127.0.0.1]) by localhost (pmx.isp.as2116.net) with SMTP id E64DA4432B for ; Fri, 24 Jul 2015 10:52:25 +0200 (CEST) Received: from smtp.bluecom.no (smtp.bluecom.no [193.75.75.28]) by pmx.vmail.no (pmx.isp.as2116.net) with ESMTP id 6AE3444312 for ; Fri, 24 Jul 2015 10:52:25 +0200 (CEST) Received: from coldstorage.localnet (unknown [81.191.185.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.bluecom.no (Postfix) with ESMTPS id 56DD21F54F for ; Fri, 24 Jul 2015 10:52:25 +0200 (CEST) From: Thomas Zander To: bitcoin-dev@lists.linuxfoundation.org Date: Fri, 24 Jul 2015 10:52:24 +0200 Message-ID: <1536871.OeviznBiyx@coldstorage> User-Agent: KMail/4.14.1 (Linux/3.16.0-4-amd64; KDE/4.14.2; x86_64; ; ) In-Reply-To: <201507172029.17056.luke@dashjr.org> References: <201507172029.17056.luke@dashjr.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jul 2015 08:52:28 -0000 On Friday 17. July 2015 20.29.16 Luke Dashjr via bitcoin-dev wrote: > We are unlikely to approach 1 MB of actual volume by November, so I would > prefer to see the activation date on this moved later - maybe November > 2016, if not 2017. It would also be an improvement to try to follow > reasonably- expected bandwidth increases, so 15% (1.15 MB) rather than > doubling. Doubling in only a few months seems to be far from a > "conservative" increase. The reference to bandwidth increases makes no sense, the bandwidth in most of the world is already far exceeding the 8Mb limit. Not everyone lives where you live :) In Germany you buy a 150Mbit connection for a flatrate and a cheap monthly rate, for instance. Not saying that Germany is where all the miners are, but since 150Mbit allows one to comfortably have 16 megabyte blocks, it is a good example of how far off Luke's calculations are from real-world. I don't belief your argument to push forward holds. -- Thomas Zander 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 DA49A489 for ; Fri, 24 Jul 2015 09:43:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 45EE1172 for ; Fri, 24 Jul 2015 09:43:03 +0000 (UTC) Received: from [115.187.143.132] by 3capp-mailcom-bs01.server.lan (via HTTP); Fri, 24 Jul 2015 11:43:00 +0200 MIME-Version: 1.0 Message-ID: From: "Slurms MacKenzie" To: thomas@thomaszander.se Content-Type: text/plain; charset=UTF-8 Date: Fri, 24 Jul 2015 11:43:00 +0200 Importance: normal Sensitivity: Normal In-Reply-To: <1536871.OeviznBiyx@coldstorage> References: <201507172029.17056.luke@dashjr.org>, <1536871.OeviznBiyx@coldstorage> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:aGoDnlBOjHfe7G2WC2pNz2vr4thPYbarhA+2TZSOs4K PGURrvGc8G8wz0pF5GV6009E35lRPpLXc6Q53nzawDdqvrvrlp tR5gqXmx/g+Vsj1jBqTmdxmOrVmEgwPAJTelKpsH8JvsKVPxpo DNXLg2cVN3kP3va36pFhiJ3MfHFFbvBbI58hYWLRSblChFwJ9b r6E+hR/9jI9CcIR20Of3oalGNysh4heoRqZZmV8SYJ7nSteX3I If/7Fzdrvr9bJhy9Q4csQ4Uam+cTawf+EYaR+IPe96S8M9K+UU oOoOnA9RYeW8bfFEoXTzOelSIgn X-UI-Out-Filterresults: notjunk:1;V01:K0:4+CywGh/Xhg=:1ggJMFJi17qj0wBwXORcKy lxX2e4OxmeQIOTNCYyeX9bHp/sP2UcMepLoxVqYuja7EaNgd7wAWchTMXOVgylEK50y+PgFmz Zude2XRasfOi7UBwnsz3XHAdKIOlNX1fcngIUyAdYh5wbryPKT0T6TGJU2PBOA7ph/EU6b95G 8wqS0SeA74nVpQhkd5jl8fxgvFZmrb6qVZdRsIEEgfLARHnQ06gDCWAug9pSGwfwzet8Tz3Gt NDzEVAd7yoQLvQ05EjRXCK4FcUJhHNugMgpNPT9F44RxCDuuihOqkcE26zvAWHwW143RBfkQA KXdNGqEH0znuPcxrJ/LcvA9BWkUqyaxbhbnX9o3U/gCG1emD9GnW/gkpI+6AnLhN2M4ES4buu S0KlB8bFKVqp1YsRVKBSOOu/NQFZUz4E2BwsObMLaJu6vDS2in10xyWw8gmTn4O+6uH6phyVf 1jR8/rvDWQ== X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] BIP 102 - kick the can down the road to 2MB X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion