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 ) 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 ; 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: References: <16096345.A1MpJQQkRW@crushinator> Date: Fri, 29 May 2015 12:42:09 +0100 Message-ID: From: Tier Nolan Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
On Fri, May 29, 2015 at 12:26 PM, Mike Hearn <mike@plan99.n= et> wrote:
IMO it's not even clear there needs to be a size limit at all. C= urrently the 32mb message cap imposes one anyway

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.

Alternatively, the merk= le block message already incorporates the required functionality.

Send
- headers message (with 1 header)
- merkleblock messages (max 1MB per message)

The transac= tions for each merkleblock could be sent directly before each merkleblock, = as is currently the case.

That system can send a block of= any size.=C2=A0 It would require a change to the processing of any merkleb= locks received.
--001a1144bc42670c6e051736f727--