MIME-Version: 1.0
In-Reply-To: <CAE-z3OWqiGPPNVxBVU0mx+TKFuysKrhXpwg6gOFcwGBQx26VtQ@mail.gmail.com>
References: <CABsx9T2HegqOBqd1jijk1bZBE6N+NH8x6nfwbaoLBACVf8-WBQ@mail.gmail.com>
	<55885DB0.9040709@gmail.com>
	<CAE-z3OWqiGPPNVxBVU0mx+TKFuysKrhXpwg6gOFcwGBQx26VtQ@mail.gmail.com>
Date: Mon, 22 Jun 2015 15:54:26 -0400
Message-ID: <CABsx9T0t=o9f6KxVDP01iPRErUCZS8nzO438T_bkLE-4kQV7hw@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c2588e1eee7b051920a499
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Precedence: list

--001a11c2588e1eee7b051920a499
Content-Type: text/plain; charset=UTF-8

As Tier says, the current network message limit is 2MB (reduced from 32MB
in the... uhh, 0.10? release).

I think keeping the consensus rules distinct from limitations of the p2p
network makes sense-- we are already seeing different protocols for
announcing transactions and blocks (Matt's relay network is, essentially, a
separate protocol). I could write a separate BIP describing the change to
the p2p network protocol, but that feels like busy-work to me.

RE: setting the DoS size check farther than 2 hours into the future: the
block, itself, will be rejected if it has a timestamp more than 2 hours in
the future. That is already a consensus rule.

RE: what happens if block timestamps are not in chronological order:
Nothing.

The activation counting happens in block-height-order, so timestamps on all
but the "activating" block are all that matters.

Code that looks for the activation condition must properly handle re-orgs
around the activation block, of course.


RE: testnet parameters:  big blocks can be tested in -regtest mode with
arbitrary timestamps in the past or future. Testing maximum-8MB-blocks
mined "in the past" on testnet will just result in a testnet that is even
more useless for ordinary testing of products or services being developed
-- part of what makes testnet useful for things like testing transaction
creation code is it syncs quickly.

That said, I have thought for a while now somebody should take a fresh look
at the testnet, talk to people who might be customers for a reset testnet
or testnets (we probably want separate testnets for people testing mining
and people testing transaction creation, for example), and implement
testnets designed to make it easy to test what people need testing.

RE: scraping together money to run a few hundred full-load full-nodes:
 hardware is cheap, people are expensive. You seem to expect that companies
will be willing to invest the time of their people testing something that
may never happen (8MB of transactions every ten minutes). Maybe they would,
but most companies are very busy trying to stay in business by attracting
customers to their products or services. Scaling up is a good problem to
have, and, in my experience, the way to be successful scaling up is to
tackle problems as they occur.

Because there's no use spending a bunch of person-hours hyper-optimizing
for 8MB blocks stored in MySQL if a year from now you find out your
customers don't actually want your product or MySQL 5.11 comes out and is
100 times faster....

-- 
--
Gavin Andresen

--001a11c2588e1eee7b051920a499
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">As Tier says, the current network message limit is 2MB (re=
duced from 32MB in the... uhh, 0.10? release).<div><br></div><div>I think k=
eeping the consensus rules distinct from limitations of the p2p network mak=
es sense-- we are already seeing different protocols for announcing transac=
tions and blocks (Matt&#39;s relay network is, essentially, a separate prot=
ocol). I could write a separate BIP describing the change to the p2p networ=
k protocol, but that feels like busy-work to me.<br><div><br></div><div>RE:=
 setting the DoS size check farther than 2 hours into the future: the block=
, itself, will be rejected if it has a timestamp more than 2 hours in the f=
uture. That is already a consensus rule.</div></div><div><br></div><div>RE:=
 what happens if block timestamps are not in chronological order: Nothing.<=
/div><div><br></div><div>The activation counting happens in block-height-or=
der, so timestamps on all but the &quot;activating&quot; block are all that=
 matters.</div><div><br></div><div>Code that looks for the activation condi=
tion must properly handle re-orgs around the activation block, of course.</=
div><div><br></div><div><br></div><div>RE: testnet parameters: =C2=A0big bl=
ocks can be tested in -regtest mode with arbitrary timestamps in the past o=
r future. Testing maximum-8MB-blocks mined &quot;in the past&quot; on testn=
et will just result in a testnet that is even more useless for ordinary tes=
ting of products or services being developed -- part of what makes testnet =
useful for things like testing transaction creation code is it syncs quickl=
y.</div><div><br></div><div>That said, I have thought for a while now someb=
ody should take a fresh look at the testnet, talk to people who might be cu=
stomers for a reset testnet or testnets (we probably want separate testnets=
 for people testing mining and people testing transaction creation, for exa=
mple), and implement testnets designed to make it easy to test what people =
need testing.</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><b=
r></div><div class=3D"gmail_quote">RE: scraping together money to run a few=
 hundred full-load full-nodes: =C2=A0hardware is cheap, people are expensiv=
e. You seem to expect that companies will be willing to invest the time of =
their people testing something that may never happen (8MB of transactions e=
very ten minutes). Maybe they would, but most companies are very busy tryin=
g to stay in business by attracting customers to their products or services=
. Scaling up is a good problem to have, and, in my experience, the way to b=
e successful scaling up is to tackle problems as they occur.</div><div clas=
s=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Because there&#39;s =
no use spending a bunch of person-hours hyper-optimizing for 8MB blocks sto=
red in MySQL if a year from now you find out your customers don&#39;t actua=
lly want your product or MySQL 5.11 comes out and is 100 times faster....</=
div><div class=3D"gmail_quote"><br></div>-- <br><div class=3D"gmail_signatu=
re">--<br>Gavin Andresen<br></div>
</div></div>

--001a11c2588e1eee7b051920a499--