public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tier Nolan <tier.nolan@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
Date: Sun, 4 May 2014 22:11:27 +0100	[thread overview]
Message-ID: <CAE-z3OXw8-3ezMOL4ik1hgDJ1sXioXHot6KgRT6rx+U67Jxhng@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgS3cU4-yJMSMA4TSY4_mrw53d--543OVmize2BYVjUAqQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1250 bytes --]

On Fri, Apr 11, 2014 at 5:54 PM, Gregory Maxwell <gmaxwell@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 "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)

[-- Attachment #2: Type: text/html, Size: 1975 bytes --]

  reply	other threads:[~2014-05-04 21:11 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-09 15:29 Wladimir
2014-04-09 15:37 ` Tamas Blummer
2014-04-09 15:41 ` Natanael
2014-04-09 15:54   ` Gregory Maxwell
2014-04-09 16:09     ` Thomas Voegtlin
2014-04-09 19:25       ` Wladimir
2014-04-10  6:04         ` Tamas Blummer
2014-04-10 11:09           ` Wladimir
2014-04-10 11:29             ` Mike Hearn
2014-04-10 11:32             ` Pieter Wuille
2014-04-10 11:43               ` Peter Todd
2014-04-10 11:50               ` Gregory Maxwell
2014-04-10 11:54                 ` Peter Todd
2014-04-10 17:30                   ` Tier Nolan
2014-04-11 16:54                     ` Gregory Maxwell
2014-05-04 21:11                       ` Tier Nolan [this message]
2014-04-09 17:31   ` Wladimir
2014-04-09 15:42 ` Brian Hoffman
2014-04-09 15:57   ` Gregory Maxwell
2014-04-09 16:09     ` Tamas Blummer
2014-04-09 15:47       ` Mark Friedenbach
2014-04-09 16:27         ` Tamas Blummer
2014-04-09 17:46           ` Peter Todd
2014-04-09 17:50             ` Tamas Blummer
2014-04-09 18:00               ` Mike Hearn
2014-04-09 18:19                 ` Wladimir
2014-04-09 18:35                   ` Justus Ranvier
2014-04-09 18:46                     ` Wladimir
2014-04-09 18:50                     ` Gregory Maxwell
2014-04-09 18:58                       ` Justus Ranvier
2014-04-09 19:33                         ` Gregory Maxwell
2014-04-09 20:12                           ` slush
2014-04-09 20:31                             ` slush
2014-04-09 20:36                               ` Mark Friedenbach
2014-04-09 21:04                                 ` Gregory Maxwell
2014-04-09 20:37                               ` Wladimir
2014-04-09 20:35                             ` Wladimir
2014-04-09 20:50                               ` slush
2014-04-09 20:55                             ` Laszlo Hanyecz
2014-04-10  6:38                             ` Mike Hearn
2014-04-10  6:50                               ` Wladimir
2014-04-10  7:09                                 ` Mike Hearn
2014-04-10  9:33                                   ` Peter Todd
2014-04-10  7:10                                 ` Tamas Blummer
2014-04-10  9:17                                   ` Mike Hearn
2014-04-10  9:39                                     ` Tamas Blummer
2014-04-10 10:40                                       ` Mike Hearn
2014-04-10 10:44                                         ` Tamas Blummer
2014-04-10 11:36                                           ` Peter Todd
2014-04-10 11:45                                             ` Mike Hearn
2014-04-10 11:52                                               ` Peter Todd
2014-04-10  9:47                                     ` Peter Todd
2014-04-09 18:04               ` Peter Todd
     [not found]   ` <CA+s+GJBpvqqu=XEojyekx5su+JfYLwz+zsbo8L0=5t6s-_b33w@mail.gmail.com>
2014-04-09 17:35     ` [Bitcoin-development] Fwd: " Wladimir
2014-04-09 16:03 ` [Bitcoin-development] " Peter Todd
2014-04-09 17:33   ` Alex Mizrahi
2014-04-09 17:38     ` Wladimir
2014-04-09 17:38     ` Peter Todd
2014-04-09 18:35 ` Kevin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAE-z3OXw8-3ezMOL4ik1hgDJ1sXioXHot6KgRT6rx+U67Jxhng@mail.gmail.com \
    --to=tier.nolan@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox