From: Mike Hearn <mike@plan99•net>
To: Elden Tyrell <tyrell.elden@gmail•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] does "stubbing" off Merkle trees reduce initial download bandwidth?
Date: Fri, 6 Jan 2012 00:30:16 +0100 [thread overview]
Message-ID: <CANEZrP1ZfSJGaRimJhJ-jCuarSMmJGi5+=vxngDgc6kOKTR8JA@mail.gmail.com> (raw)
In-Reply-To: <jdtm7t$4ed$1@dough.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]
This thread is discussing two unrelated things.
Your first email asked about transaction pruning ("stubbing"). You're
correct. This doesn't do anything for initial chain download bandwidth or
time. In fact it makes it slower because you have the overhead of deleting
the old transactions. It exists purely to save disk space.
Christians reply is about simplified payment verification (SPV) mode. It is
unrelated to transaction pruning. SPV clients can download only the chain
headers with no bodies all the way from the genesis block until the
creation time of their youngest key. This does reduce initial setup time
and in fact is now implemented in BitCoinJ, but it's still linear in the
length of Bitcoins life, so that's ultimately unsustainable. You need a
regular series of checkpoints signed by a trusted developer and a circular
block store to have truly bounded overheads. The merkle tree is still
useful because it allows for SPV clients to receive only the transactions
of interest yet have nearly the same assurances that downloading full
blocks would give - remote nodes can now hide transactions from you (dos)
but not invent new ones.
SPV clients do not use "number of blocks on top" as a way to decide
validity. They look for the best chain they can find, same as a regular
node does. As Satoshis paper says, if an SPV node has access to the P2P
network and is also talking to you, you can defraud it for as long as you
can dominate the networks hash power (51% attack) because you can create a
harder chain than everyone else can. However your invalid blocks won't be
accepted by the rest of the network regardless of how many there are or how
much work they represent, so as soon as you stop dominating the network the
correct chain will catch up and replace yours, resulting in the fraud being
detected and shown to the SPV user.
[-- Attachment #2: Type: text/html, Size: 1919 bytes --]
prev parent reply other threads:[~2012-01-05 23:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-02 5:04 Elden Tyrell
2012-01-02 13:31 ` Christian Decker
2012-01-02 22:23 ` Elden Tyrell
2012-01-02 22:41 ` Gregory Maxwell
2012-01-03 1:39 ` Elden Tyrell
2012-01-05 23:30 ` Mike Hearn [this message]
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='CANEZrP1ZfSJGaRimJhJ-jCuarSMmJGi5+=vxngDgc6kOKTR8JA@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=tyrell.elden@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