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
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <tier.nolan@gmail.com>) id 1YyIg4-0006V5-C1
for bitcoin-development@lists.sourceforge.net;
Fri, 29 May 2015 11:42:16 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.48 as permitted sender)
client-ip=209.85.192.48; envelope-from=tier.nolan@gmail.com;
helo=mail-qg0-f48.google.com;
Received: from mail-qg0-f48.google.com ([209.85.192.48])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YyIg3-0005XV-Br
for bitcoin-development@lists.sourceforge.net;
Fri, 29 May 2015 11:42:16 +0000
Received: by qgf2 with SMTP id 2so27855411qgf.3
for <bitcoin-development@lists.sourceforge.net>;
Fri, 29 May 2015 04:42:10 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.33.6 with SMTP id h6mr14389616qkh.99.1432899729950; Fri,
29 May 2015 04:42:09 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Fri, 29 May 2015 04:42:09 -0700 (PDT)
In-Reply-To: <CANEZrP1qH+zucYsGrMgnfi99e61Edxaj+xm=u_xYXga1g0WzJQ@mail.gmail.com>
References: <16096345.A1MpJQQkRW@crushinator>
<CABsx9T3-zxCAagAS0megd06xvG5n-3tUL9NUK9TT3vt7XNL9Tg@mail.gmail.com>
<CANEZrP3VCaFsW4+gPm2kCJ9z7oVUZYVaeNf=_cJWEWwh4ZxiPQ@mail.gmail.com>
<CABsx9T21zjHyO-nh1aSBM3z4Bg015O0rOfYq7=Sy4mf=QxUVQA@mail.gmail.com>
<CANEZrP2BaKwhpPgcUHWAHswOmUeFLgEk4ysrn4+73qNzWDJ=yQ@mail.gmail.com>
<CABsx9T3nCJ-w_v-yEbEE2Ytb+xC65mhYqhoAhoOHw9tkPpG0TA@mail.gmail.com>
<CANEZrP1qH+zucYsGrMgnfi99e61Edxaj+xm=u_xYXga1g0WzJQ@mail.gmail.com>
Date: Fri, 29 May 2015 12:42:09 +0100
Message-ID: <CAE-z3OVmw+0doCe0hmYE6A1D61h0AUh4Mtnf5Fg1e4zQBkpraQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1144bc42670c6e051736f727
X-Spam-Score: 3.3 (+++)
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
(tier.nolan[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.2 MISSING_HEADERS Missing To: header
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
2.7 MALFORMED_FREEMAIL Bad headers on message from free email service
X-Headers-End: 1YyIg3-0005XV-Br
Subject: Re: [Bitcoin-development] Proposed alternatives to the 20MB step
function
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: Fri, 29 May 2015 11:42:16 -0000
--001a1144bc42670c6e051736f727
Content-Type: text/plain; charset=UTF-8
On Fri, May 29, 2015 at 12:26 PM, Mike Hearn <mike@plan99.net> wrote:
> IMO it's not even clear there needs to be a size limit at all. Currently
> the 32mb message cap imposes one anyway
>
If the plan is a fix once and for all, then that should be changed too. It
could be set so that it is at least some multiple of the max block size
allowed.
Alternatively, the merkle block message already incorporates the required
functionality.
Send
- headers message (with 1 header)
- merkleblock messages (max 1MB per message)
The transactions for each merkleblock could be sent directly before each
merkleblock, as is currently the case.
That system can send a block of any size. It would require a change to the
processing of any merkleblocks received.
--001a1144bc42670c6e051736f727
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Fri, May 29, 2015 at 12:26 PM, Mike Hearn <span dir=3D"=
ltr"><<a href=3D"mailto:mike@plan99.net" target=3D"_blank">mike@plan99.n=
et</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_=
quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_=
extra">IMO it's not even clear there needs to be a size limit at all. C=
urrently the 32mb message cap imposes one anyway<br></div></div></blockquot=
e><div><br></div><div>If the plan is a fix once and for all, then that shou=
ld be changed too.=C2=A0 It could be set so that it is at least some multip=
le of the max block size allowed.<br><br></div><div>Alternatively, the merk=
le block message already incorporates the required functionality.<br><br></=
div><div>Send<br></div><div>- headers message (with 1 header)<br></div><div=
>- merkleblock messages (max 1MB per message)<br><br></div><div>The transac=
tions for each merkleblock could be sent directly before each merkleblock, =
as is currently the case.<br><br></div><div>That system can send a block of=
any size.=C2=A0 It would require a change to the processing of any merkleb=
locks received.<br></div></div></div></div>
--001a1144bc42670c6e051736f727--
|
