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-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yz2hr-0001P0-2a for bitcoin-development@lists.sourceforge.net; Sun, 31 May 2015 12:51:11 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.169 as permitted sender) client-ip=209.85.214.169; envelope-from=gavinandresen@gmail.com; helo=mail-ob0-f169.google.com; Received: from mail-ob0-f169.google.com ([209.85.214.169]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yz2hp-00047A-SC for bitcoin-development@lists.sourceforge.net; Sun, 31 May 2015 12:51:11 +0000 Received: by obbea2 with SMTP id ea2so86459456obb.3 for ; Sun, 31 May 2015 05:51:04 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.136.139 with SMTP id k133mr13610012oid.7.1433076664312; Sun, 31 May 2015 05:51:04 -0700 (PDT) Received: by 10.60.28.65 with HTTP; Sun, 31 May 2015 05:51:04 -0700 (PDT) In-Reply-To: <20150531070530.GD12966@muck> References: <554BE0E1.5030001@bluematt.me> <20150531070530.GD12966@muck> Date: Sun, 31 May 2015 08:51:04 -0400 Message-ID: From: Gavin Andresen To: Peter Todd Content-Type: multipart/alternative; boundary=001a113e12b8835273051760295e X-Spam-Score: -0.6 (/) 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Yz2hp-00047A-SC Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Block Size Increase Requirements 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: Sun, 31 May 2015 12:51:11 -0000 --001a113e12b8835273051760295e Content-Type: text/plain; charset=UTF-8 On Sun, May 31, 2015 at 3:05 AM, Peter Todd wrote: > Yeah, I'm pretty surprised myself that Gavin never accepted the > compromises offered by others in this space for a slow growth solution > What compromise? I haven't seen a specific proposal that could be turned into a pull request. > Something important to note in Gavin Andresen's analysises of this issue > is that he's using quite optimistic scenarios for how nodes are > connected to each other. NO I AM NOT. I simulated a variety of connectivities; see the .cfg files at https://github.com/gavinandresen/bitcoin_miningsim The results I give in the "are bigger blocks better" blog post are for WORST CASE connectivity (one dominant big miner, multiple little miners, big miner connects to only 30% of little miners, but all the little miners connected directly to each other). > For instance, assuming that connections between > miners are direct is a very optimistic assumption Again, I did not simulate all miners directly connected to each other. I will note that miners are VERY HIGHLY connected today. It is in their best interest to be highly connected to each other. > that depends on a > permissive, unregulated, environment where miners co-operate with each > other - obviously that's easily subject to change! Really? How is that easily subject to change? If it is easily subject to change, do bigger blocks have any effect? Why are 1MB blocks not subject to change? I talk about "what if your government bans Bitcoin entirely" here: http://gavinandresen.ninja/big-blocks-and-tor ... and the issues are essentially the same, independent of block size. -- -- Gavin Andresen --001a113e12b8835273051760295e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, May 31, 2015 at 3:05 AM, Peter Todd <pete@petertodd.org> wrote:
Yeah, I'm pretty surprised myself that Gav= in never accepted the
compromises offered by others in this space for a slow growth solution
<= /blockquote>

What compromise? I haven't seen a speci= fic proposal that could be turned into a pull request.

=

=C2=A0
Something important to not= e in Gavin Andresen's analysises of this issue
is that he's using quite optimistic scenarios for how nodes are
connected to each other.

NO I AM NOT.
=

I simulated a variety of connectivities; see the .cfg f= iles at
=C2=A0=C2=A0https://github.com/gavinandresen/bitcoin_miningsim

The results I give in the "are bigger blocks be= tter" blog post are for WORST CASE connectivity (one dominant big mine= r, multiple little miners, big miner connects to only 30% of little miners,= but all the little miners connected directly to each other).
=C2= =A0
For instance, assuming that connections between<= br> miners are direct is a very optimistic assumption

Again, I did not simulate all miners directly connected to each othe= r.

I will note that miners are VERY HIGHLY connect= ed today. It is in their best interest to be highly connected to each other= .
=C2=A0
that depends on a
permissive, unregulated, environment where miners co-operate with each
other - obviously that's easily subject to change!
Really? How is that easily subject to change? If it is easily = subject to change, do bigger blocks have any effect? Why are 1MB blocks not= subject to change?

I talk about "what if you= r government bans Bitcoin entirely" here:

... and the issues are= essentially the same, independent of block size.


--
--
Gavin Andresen<= br>
--001a113e12b8835273051760295e--