From: Gavin Andresen <gavinandresen@gmail•com>
To: Tier Nolan <tier.nolan@gmail•com>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Draft BIP : fixed-schedule block size increase
Date: Mon, 22 Jun 2015 15:54:26 -0400 [thread overview]
Message-ID: <CABsx9T0t=o9f6KxVDP01iPRErUCZS8nzO438T_bkLE-4kQV7hw@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OWqiGPPNVxBVU0mx+TKFuysKrhXpwg6gOFcwGBQx26VtQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2545 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 3026 bytes --]
next prev parent reply other threads:[~2015-06-22 19:54 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-22 18:18 Gavin Andresen
2015-06-22 18:33 ` Tier Nolan
2015-06-22 18:46 ` Gavin Andresen
2015-06-22 19:10 ` Martin Schwarz
2015-06-22 19:28 ` Tier Nolan
2015-06-22 19:54 ` Gavin Andresen [this message]
2015-06-22 20:12 ` Peter Todd
2015-06-22 19:23 ` Peter Todd
2015-06-23 7:35 ` Ross Nicoll
2015-08-17 15:58 ` Jorge Timón
2015-06-23 19:16 ` Peter Todd
2015-06-22 20:27 ` Kalle Rosenbaum
2015-06-22 20:46 ` Gavin Andresen
2015-06-22 20:51 ` Gavin Andresen
2015-06-22 21:52 ` Mark Friedenbach
2015-06-23 19:28 ` Peter Todd
2015-06-23 20:12 ` Gavin Andresen
2015-06-23 20:26 ` Pieter Wuille
2015-06-23 20:50 ` Peter Todd
2015-06-24 6:14 ` grarpamp
2015-06-23 20:46 ` Peter Todd
2015-06-23 21:24 ` Gavin Andresen
2015-06-26 19:08 ` Peter Todd
2015-06-26 22:01 ` Ivan Brightly
2015-06-26 19:25 ` Peter Todd
2015-06-26 22:16 ` Simon Liu
2015-06-27 2:14 ` Milly Bitcoin
2015-06-23 20:55 ` Roy Badami
2015-06-24 1:43 ` odinn
2015-06-24 3:05 ` William Madden
2015-06-24 3:49 ` Jeff Garzik
2015-06-24 13:06 ` Will
2015-06-24 13:44 ` Gavin Andresen
2015-06-25 0:32 ` Pindar Wong
2015-06-25 13:50 ` Gareth Williams
2015-06-25 14:07 ` Adam Back
2015-06-26 13:47 ` Tier Nolan
2015-06-26 15:13 ` Will
2015-06-26 17:39 ` Gavin Andresen
2015-06-26 19:07 ` Will
2015-07-01 22:49 ` odinn
2015-08-17 13:15 ` Tier Nolan
2015-08-17 13:18 ` Clément Elbaz
2015-08-19 3:45 ` odinn
2015-08-17 16:11 ` Jorge Timón
2015-06-26 21:07 ` Carsten Otto
2015-06-22 19:32 Jean-Paul Kogelman
2015-06-22 20:43 ` Tier Nolan
2015-06-22 20:54 ` Peter Todd
2015-06-22 21:04 ` Stephen Morse
2015-06-22 21:32 ` Ross Nicoll
2015-08-17 15:54 ` Jorge Timón
2015-06-22 21:21 ` Gavin Andresen
2015-06-22 21:39 ` Patrick Strateman
2015-06-22 21:48 ` Tier Nolan
2015-06-23 7:59 Ross Nicoll
2015-06-24 4:31 Raystonn
2015-06-24 17:05 ` Mark Friedenbach
2015-06-24 17:24 ` Roy Badami
2015-06-24 17:23 Raystonn
2015-06-24 17:24 ` Allen Piscitello
2015-06-24 17:28 ` Roy Badami
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABsx9T0t=o9f6KxVDP01iPRErUCZS8nzO438T_bkLE-4kQV7hw@mail.gmail.com' \
--to=gavinandresen@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=tier.nolan@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox