From: Gregory Maxwell <gmaxwell@gmail•com>
To: Tier Nolan <tier.nolan@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
Date: Fri, 11 Apr 2014 09:54:44 -0700 [thread overview]
Message-ID: <CAAS2fgS3cU4-yJMSMA4TSY4_mrw53d--543OVmize2BYVjUAqQ@mail.gmail.com> (raw)
In-Reply-To: <CAE-z3OV4w+vQ0b6h9E+7cSyxkKENduyfHenhdF3q3-0i2chnGQ@mail.gmail.com>
On Thu, Apr 10, 2014 at 10:30 AM, Tier Nolan <tier.nolan@gmail•com> wrote:
> Error correction is an interesting suggestion.
Though I mentioned it, it was in jest— I think right now it would be
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, then
> 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.
next prev parent reply other threads:[~2014-04-11 16:54 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 [this message]
2014-05-04 21:11 ` Tier Nolan
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=CAAS2fgS3cU4-yJMSMA4TSY4_mrw53d--543OVmize2BYVjUAqQ@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=tier.nolan@gmail$(echo .)com \
/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