Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Wh3h7-0007mf-Se for bitcoin-development@lists.sourceforge.net; Sun, 04 May 2014 21:11:33 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.192.51 as permitted sender) client-ip=209.85.192.51; envelope-from=tier.nolan@gmail.com; helo=mail-qg0-f51.google.com; Received: from mail-qg0-f51.google.com ([209.85.192.51]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Wh3h6-0004ti-W2 for bitcoin-development@lists.sourceforge.net; Sun, 04 May 2014 21:11:33 +0000 Received: by mail-qg0-f51.google.com with SMTP id q107so2519037qgd.10 for ; Sun, 04 May 2014 14:11:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.229.112.5 with SMTP id u5mr39166804qcp.3.1399237887300; Sun, 04 May 2014 14:11:27 -0700 (PDT) Received: by 10.140.25.86 with HTTP; Sun, 4 May 2014 14:11:27 -0700 (PDT) In-Reply-To: References: <534570A2.9090502@gmx.de> <0B038624-8861-438E-B7B1-566B4A8E126B@bitsofproof.com> Date: Sun, 4 May 2014 22:11:27 +0100 Message-ID: From: Tier Nolan To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a11330a743ab37104f899751c X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.192.51 listed in list.dnswl.org] -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.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 X-Headers-End: 1Wh3h6-0004ti-W2 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: Sun, 04 May 2014 21:11:34 -0000 --001a11330a743ab37104f899751c Content-Type: text/plain; charset=UTF-8 On Fri, Apr 11, 2014 at 5:54 PM, Gregory Maxwell wrote: > For the non-error-coded case I believe nodes > with random spans of blocks works out asymptotically to the same > failure rates as random. > If each "block" is really 512 blocks in sequence, then each "slot" is more likely to be hit. It effectively reduces the number of blocks by the minimum run lengths. ECC seemed cooler though. > (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) > Interesting too. > > 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. > That's true. Scaling up the transactions per second increases the chance of data lost. With side/tree chains, the odds of data loss in the less important chains increases (though they are by definition lower value chains) --001a11330a743ab37104f899751c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 11, 2014 at 5:54 PM, Gregory Maxwell <gmaxwe= ll@gmail.com> wrote:
For the non-error-coded case I believe nodes
with random spans of blocks works out asymptotically to the same
failure rates as random.

If each=20 "block" is really 512 blocks in sequence, then each "slot&qu= ot; is more=20 likely to be hit.=C2=A0 It effectively reduces the number of blocks by the= =20 minimum run lengths.

ECC seemed cooler though.
<= div>=C2=A0
(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)

Interesting too.

I think in the network we have today and for the foreseeable future w= e
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.

That's true.=C2=A0 Scaling up the transactions per second incr= eases the chance of data lost.

With side/tree chains, the odds of data loss in the less important chains=20 increases (though they are by definition lower value chains)
--001a11330a743ab37104f899751c--