From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WYej6-0006nK-1W for bitcoin-development@lists.sourceforge.net; Fri, 11 Apr 2014 16:54:52 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.51 as permitted sender) client-ip=209.85.215.51; envelope-from=gmaxwell@gmail.com; helo=mail-la0-f51.google.com; Received: from mail-la0-f51.google.com ([209.85.215.51]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WYej5-0001ML-5c for bitcoin-development@lists.sourceforge.net; Fri, 11 Apr 2014 16:54:51 +0000 Received: by mail-la0-f51.google.com with SMTP id pv20so3709314lab.38 for ; Fri, 11 Apr 2014 09:54:44 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.94.229 with SMTP id df5mr6812954lbb.36.1397235284404; Fri, 11 Apr 2014 09:54:44 -0700 (PDT) Received: by 10.112.89.68 with HTTP; Fri, 11 Apr 2014 09:54:44 -0700 (PDT) In-Reply-To: References: <534570A2.9090502@gmx.de> <0B038624-8861-438E-B7B1-566B4A8E126B@bitsofproof.com> Date: Fri, 11 Apr 2014 09:54:44 -0700 Message-ID: From: Gregory Maxwell To: Tier Nolan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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: 1WYej5-0001ML-5c Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets 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, 11 Apr 2014 16:54:52 -0000 On Thu, Apr 10, 2014 at 10:30 AM, Tier Nolan wrote: > Error correction is an interesting suggestion. Though I mentioned it, it was in jest=E2=80=94 I think right now it would b= e an over-design at least for the basic protocol. Also, storing 'random' blocks has some locality problems, when verifying blocks you need to obtain them contiguously, and so we can take advantage of the locality of reference. For the non-error-coded case I believe nodes with random spans of blocks works out asymptotically to the same failure rates as random. One thing that I like to point out is that there is absolutely no need for the entire network to use the same p2p protocol. Diversity here would be very good. I think it would be really good for someone to have an alternative p2p protocol using these techniques even though I think they aren't yet compelling enough to be table stakes in the basic protocol. There are some very helpful things you can do with forward error correction for faster and more efficient block relaying too: https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding (The conversation Peter Todd was referring to was one where I was pointing out that with suitable error coding you also get an anti-censorship effect where its very difficult to provide part of the data without potentially providing all of it) > If there was 10000 nodes and each stored 0.1% of the blocks, at random, t= hen > the odds of a block not being stored is 45 in a million. I think in the network we have today and for the foreseeable future we can reasonably count on there being a reasonable number of nodes that store all the blocks... quite likely not enough to satisfy the historical block demand from the network alone, but easily enough to supply blocks that have otherwise gone missing.