1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
|
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 <gmaxwell@gmail.com>) id 1TBAAM-0001KF-I1
for bitcoin-development@lists.sourceforge.net;
Mon, 10 Sep 2012 20:01:06 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.175 as permitted sender)
client-ip=209.85.223.175; envelope-from=gmaxwell@gmail.com;
helo=mail-ie0-f175.google.com;
Received: from mail-ie0-f175.google.com ([209.85.223.175])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TBAAI-00084w-GP
for bitcoin-development@lists.sourceforge.net;
Mon, 10 Sep 2012 20:01:06 +0000
Received: by iebc11 with SMTP id c11so4085100ieb.34
for <bitcoin-development@lists.sourceforge.net>;
Mon, 10 Sep 2012 13:00:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.50.159.130 with SMTP id xc2mr13215678igb.33.1347307257268;
Mon, 10 Sep 2012 13:00:57 -0700 (PDT)
Received: by 10.64.56.66 with HTTP; Mon, 10 Sep 2012 13:00:57 -0700 (PDT)
In-Reply-To: <1347306813.1419.20.camel@localhost.localdomain>
References: <BA7EEDEA-5A56-42F5-A43D-0D4C9CC99DBC@godofgod.co.uk>
<201209101859.05009.luke@dashjr.org>
<239CFE18-302F-47F1-8686-67297FDDFB3C@godofgod.co.uk>
<1347306813.1419.20.camel@localhost.localdomain>
Date: Mon, 10 Sep 2012 16:00:57 -0400
Message-ID: <CAAS2fgQcZsEy7bvc6e1Rz-z6B3hUkf_OEKrk79pR0QuCwqx-vA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Matt Corallo <bitcoin-list@bluematt.me>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.0 (-)
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
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-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.6 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1TBAAI-00084w-GP
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 10 Sep 2012 20:01:06 -0000
On Mon, Sep 10, 2012 at 3:53 PM, Matt Corallo <bitcoin-list@bluematt.me> wrote:
> It seems to me the whole idea of segmenting blocks would add very little
> (to nothing) with any sane block size. Sure, if a block were to be
> 10GB, it may make sense. However, even in that case, it would be easier
As you know there is a hard protocol limit of 1MB.
If you're going to talk about doing that you are screwing with the
core economic promises of the system. (in particular, removing the cap
eliminates the only armwave we have for long term security). But in
any case, removing it requires a complete and totally incompatible
hardfork, and at that point you can do whatever you want with the
protocol. Changing how blocks are fetched is almost incidental to the
number of other things that would be changed. I don't think it makes
sense to design for that especially when something far simpler (as you
pointed out) is prudent for the design of bitcoin.
|
