From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SfV5Q-0003AQ-Jj for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 11:53:08 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.53 as permitted sender) client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com; helo=mail-wg0-f53.google.com; Received: from mail-wg0-f53.google.com ([74.125.82.53]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1SfV5L-0001Gj-2D for bitcoin-development@lists.sourceforge.net; Fri, 15 Jun 2012 11:53:08 +0000 Received: by wgbfm10 with SMTP id fm10so2512964wgb.10 for ; Fri, 15 Jun 2012 04:52:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.95.100 with SMTP id dj4mr3901430wib.17.1339761176869; Fri, 15 Jun 2012 04:52:56 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.216.254.232 with HTTP; Fri, 15 Jun 2012 04:52:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 15 Jun 2012 13:52:56 +0200 X-Google-Sender-Auth: 3b6ApgmxRqMv3TVj1dhlU0-OUx4 Message-ID: From: Mike Hearn To: Jeff Garzik Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.5 (-) 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 (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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 X-Headers-End: 1SfV5L-0001Gj-2D Cc: Bitcoin Development Subject: Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients 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, 15 Jun 2012 11:53:08 -0000 > Need to specify the format of how these arrive. It means that when a > new block is found instead of inv<->getdata<->block we'd see something > like =C2=A0inv<->getdata<->merkleblock where a "merkleblock" structure is= a > header + list of transactions + list of merkle branches linking them > to the root. Thinking about it some more and re-reading the Scalability wiki page, I remembered that a nice bandwidth optimization to the protocol is to distribute blocks as header+list of tx hashes. If a node has already seen that tx before (eg, it's in the mempool) there is no need to send it again. With the new command to download the contents of the mempool on startup, this means that blocks could potentially propagate across the network faster as download time is taken out of the equation, and indeed, with the signature cache the hard work of verifying is already done. So this could also help reduce orphan blocks and spurious chain splits. Are you planning on implementing any of this Jeff? I think we have the opportunity to kill a few birds with one or two stones.