From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YqOxw-0005rT-7W for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 16:48:04 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of eigbox.net designates 66.96.187.10 as permitted sender) client-ip=66.96.187.10; envelope-from=SRS0=jOMUSZ=FS=thelibertyportal.com=matthewmitchell@eigbox.net; helo=bosmailout10.eigbox.net; Received: from bosmailout10.eigbox.net ([66.96.187.10]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YqOxt-00082i-PA for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 16:48:04 +0000 Received: from bosmailscan10.eigbox.net ([10.20.15.10]) by bosmailout10.eigbox.net with esmtp (Exim) id 1YqOxo-00070g-GH for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 12:47:56 -0400 Received: from [10.115.3.33] (helo=bosimpout13) by bosmailscan10.eigbox.net with esmtp (Exim) id 1YqOxo-0003yw-Ek for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 12:47:56 -0400 Received: from bosauthsmtp19.yourhostingaccount.com ([10.20.18.19]) by bosimpout13 with id R4nt1q00F0QhFXN014nwYK; Thu, 07 May 2015 12:47:56 -0400 X-Authority-Analysis: v=2.1 cv=YbUz5mhf c=1 sm=1 tr=0 a=9UqFsMnAB6EOkiq4MrOclQ==:117 a=z3zsPO1EquuvJlEroHUibA==:17 a=pq4jwCggAAAA:8 a=QPcu4mC3AAAA:8 a=kb-7UQSq9zUA:10 a=FurB0epzNeMA:10 a=82ocvhqlAAAA:8 a=0Bzu9jTXAAAA:8 a=h1PgugrvaO0A:10 a=13zjGPudsaEWiJwPRgMA:9 a=WbPmnYzAfxEA:10 a=i4fd7TR6sGcA:10 a=h5x1KQqIZxoA:10 a=ahaM9nHAOhcA:10 a=4EGDMaEJAAAA:8 a=JcT1meiOAAAA:8 a=FP58Ms26AAAA:8 a=6DveyWQyobaswSi2GcIA:9 a=whuVTW34MN39t-kz:21 a=8zdelEbR3A2txtmZ:21 a=pILNOxqGKmIA:10 a=vtQ3KtN-36qR94eNz5kA:9 Received: from 56.47.112.87.dyn.plus.net ([87.112.47.56]:56392 helo=[192.168.1.75]) by bosauthsmtp19.eigbox.net with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim) id 1YqOxk-0001oQ-25 for bitcoin-development@lists.sourceforge.net; Thu, 07 May 2015 12:47:52 -0400 Message-ID: <554B972D.7010405@thelibertyportal.com> Date: Thu, 07 May 2015 17:47:41 +0100 From: Matthew Mitchell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: <554A91BE.6060105@bluematt.me> <554B8B95.60905@thelibertyportal.com> In-Reply-To: <554B8B95.60905@thelibertyportal.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="QQq1d2Vg4heDVj5clMAwRiNVvk429Fi6U" X-EN-UserInfo: 3f46a65fee631b45f0f295c1b6eb286c:931c98230c6409dcc37fa7e93b490c27 X-EN-AuthUser: cbitcoin@thelibertyportal.com Sender: Matthew Mitchell X-EN-OrigIP: 87.112.47.56 X-EN-OrigHost: 56.47.112.87.dyn.plus.net X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [66.96.187.10 listed in list.dnswl.org] -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -0.0 SPF_PASS SPF: sender matches SPF record 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YqOxt-00082i-PA Subject: Re: [Bitcoin-development] Block Size Increase X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2015 16:48:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QQq1d2Vg4heDVj5clMAwRiNVvk429Fi6U Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable One thing to add is that perhaps in a future version of Bitcoin Core, there could be an option for users to continue using the old consensus rules, or an option to support the new rules (an option when they update and an ability to change in the settings). Both types of user can benefit from the software updates and choose with a single piece of software what they support. Information for whether or not a user is supporting the changes could be included in the version message. Possibly this information could be incorporated into transactions also. If they wish to support the new rules, then their client would support larger blocks when there is majority miner consensus, otherwise their clients will always only support the old rules. This way the decision is not being forced upon the user in any way. Just an idea. On 07/05/15 16:58, Matthew Mitchell wrote: > In my personal opinion, this does make some sense to me, assuming I > understood Gavin. >=20 > I suppose it could be done with a new flag (like the P2SH flag) which > displays miner support for larger blocks. The new rules would apply whe= n > a large majority of miners support the new rules by counting the number= > of flagged blocks over a certain number of blocks on the network in a > deterministic fashion. >=20 > This way miners can continue to produce blocks which are supported by > both old and new clients. When it appears most people have migrated to > the new client, miners can start flagging support for the new rules, an= d > when a large majority of miners agree, the new rules would kick in for > all miners/clients running the new software. Miners could therefore glu= e > together the network during the migration phase until enough people hav= e > updated to avoid severe fork scenarios. The only problem is ensuring > that miners will continue to support both networks for long enough to > enable successful migration. >=20 > And if too many people disagree to make a clean hard fork (too many > people stubbornly stick to the old rules), then it could be that the > hard fork is aborted and everyone goes back to the old rules, or quite > simply that the miners never give support for the new rules despite the= > mechanism being included in the new client. In those cases it would be > as if nothing changed. >=20 > This way the hard fork would be determined by user participation as > judged by the miners. >=20 > If it is done, I can't think of a fairer way. >=20 > Matthew Mitchell >=20 > On 07/05/15 15:52, Gavin Andresen wrote: >> For reference: the blog post that (re)-started this debate, and which >> links to individual issues, is here: >> http://gavinandresen.ninja/time-to-roll-out-bigger-blocks >> >> In it, I asked people to email me objections I might have missed. I >> would still appreciate it if people do that; it is impossible to keep = up >> with this mailing list, /r/bitcoin posts and comments, and >> #bitcoin-wizards and also have time to respond thoughtfully to the >> objections raised. >> >> I would very much like to find some concrete course of action that we >> can come to consensus on. Some compromise so we can tell entrepreneurs= >> "THIS is how much transaction volume the main Bitcoin blockchain will = be >> able to support over the next eleven years." >> >> I've been pretty clear on what I think is a reasonable compromise (a >> one-time increase scheduled for early next year), and I have tried to >> explain why I think it it is the right set of tradeoffs. >> >> There ARE tradeoffs here, and the hard question is what process do we >> use to decide those tradeoffs? How do we come to consensus? Is it wor= th >> my time to spend hours responding thoughtfully to every new objection >> raised here, or will the same thing happen that happened last year and= >> the year before-- everybody eventually gets tired of arguing >> angels-dancing-on-the-head-of-a-pin, and we're left with the status qu= o? >> >> I AM considering contributing some version of the bigger blocksize-lim= it >> hard-fork patch to the Bitcoin-Xt fork (probably "target a hobbyist >> with a fast Internet connection, and assume Nelson's law to increase >> over time), and then encouraging merchants and exchanges and web walle= ts >> and individuals who think it strikes a reasonable balance to run it. >> >> And then, assuming it became a super-majority of nodes on the network,= >> encourage miners to roll out a soft-fork to start producing bigger >> blocks and eventually trigger the hard fork. >> >> Because ultimately consensus comes down to what software people choose= >> to run. >> >> --=20 >> -- >> Gavin Andresen >> >> >> >> ----------------------------------------------------------------------= -------- >> One dashboard for servers and applications across Physical-Virtual-Clo= ud=20 >> Widest out-of-the-box monitoring support with 50+ applications >> Performance metrics, stats and reports that give you Actionable Insigh= ts >> Deep dive visibility with transaction tracing using APM Insight. >> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >> >> >> >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >=20 >=20 >=20 > -----------------------------------------------------------------------= ------- > One dashboard for servers and applications across Physical-Virtual-Clou= d=20 > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insight= s > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y >=20 >=20 >=20 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 --QQq1d2Vg4heDVj5clMAwRiNVvk429Fi6U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVS5ctAAoJEJHLtcap76MQN04P+wUcOAhsuad2MoYNLPSWQWjA /0VtJBf61YI56uPGicq0/gPxEM8bq6kXZu368+BnG7c38imJyT897pgDsjConlRM 3DEapUuiBazfM/aVJkmqOexJE/TFmYL8Z01zl8MfzJK9uNzNaFEFeYfPqaxJSqhX 2urLf4g7cbF/hei8cK5QjHA1UBb1GNVsEv2Xzlt3cfQpX+dPWTRT6dUX6lSuaDLw 6bJHX5BwJJpYjxC6GlEqOW6QCbOayzEnR8r2yd84ncL26JSEWnAkjIU+HwBjjAkg fILudBSLxj/kiVIPMbyWyxpCR9O2WBi4byU6grXa4jyVi7hv4KEVG0Lr5Vs+FEQK +2Cw0FY5fU5yVoAv4YUaEkBvB2C1TvUimRADqoaCPy4VJks2JPsNngwfkDKKKQ/3 Gsaf8+KwZxM6oI20s4wKiuIGBUtFl9faIVALnJEoTIGXEYCrFM4IJpumZJt9PPbW zeLqGn57ylJHDFk5+sf1zwltg4+BQlDAHxhay48ZOdkHpNYBohWs7lqsLC/c/If8 KfFaEfUnAs0PJojOdv6fdBgU6sUfoLBNiEVJaf3ZX/K8w70+1tgsmAvBBniug0G/ j3V6/du/40At68iHgholDD2BTAv8OBa6zk2Ch3LW5wiS8gsj2Dl9EX1UZrXGSU/p zhcBTx8mEjxLs94/D1rO =qTZ/ -----END PGP SIGNATURE----- --QQq1d2Vg4heDVj5clMAwRiNVvk429Fi6U--