Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XCxv0-000556-QQ for bitcoin-development@lists.sourceforge.net; Thu, 31 Jul 2014 21:29:46 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.182 as permitted sender) client-ip=209.85.220.182; envelope-from=gmaxwell@gmail.com; helo=mail-vc0-f182.google.com; Received: from mail-vc0-f182.google.com ([209.85.220.182]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XCxv0-0001OZ-6A for bitcoin-development@lists.sourceforge.net; Thu, 31 Jul 2014 21:29:46 +0000 Received: by mail-vc0-f182.google.com with SMTP id hy4so5415863vcb.27 for ; Thu, 31 Jul 2014 14:29:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.52.28.231 with SMTP id e7mr1074120vdh.55.1406842180690; Thu, 31 Jul 2014 14:29:40 -0700 (PDT) Received: by 10.52.187.132 with HTTP; Thu, 31 Jul 2014 14:29:40 -0700 (PDT) In-Reply-To: References: Date: Thu, 31 Jul 2014 14:29:40 -0700 Message-ID: From: Gregory Maxwell To: Kaz Wesley Content-Type: text/plain; charset=UTF-8 X-Spam-Score: -1.6 (-) 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 X-Headers-End: 1XCxv0-0001OZ-6A Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Squashing redundant tx data in blocks on the wire 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: Thu, 31 Jul 2014 21:29:47 -0000 On Thu, Jul 31, 2014 at 1:47 PM, Kaz Wesley wrote: > trip to request the missing tx; if we could somehow get the "What's > the Difference" approach to effectively operate on full transactions > instead I explain how to do this on the network block coding page. Given that you know the sizes and orders of the transactions (e.g. from a reconciliation step first), the sender sends non-syndromic forward error correcting code data somewhat larger than their estimate of how much data the user is missing. Then you drop the data you know into place and then recover the missing blocks using the fec. There is no overhead in this approach except for FEC blocks that are incompletely missing (and so must be completely discarded), and the need to have the transmitted the transaction list and sizes first. (note, that just more bandwidth, not an additional round trip).