From: Christian Decker <decker.christian@gmail•com>
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: Mon, 2 Jan 2012 14:31:19 +0100 [thread overview]
Message-ID: <CALxbBHU7f1m+p45RHLhN-VGBoXJEi62x5mZUiAe_d5D-5Ga7yA@mail.gmail.com> (raw)
In-Reply-To: <jdrds3$3tf$1@dough.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]
It can speed up the initial chain download. A newly created wallet will
have only new key-pairs, hence no incoming transactions (unless we have a
key collision, which is unlikely). So there is no need for a bootstrapping
node to download the chain with transactions. The chain itself can be
verified without the transactions. Later full blocks would be required to
detect usable inputs for future outgoing transactions. As long as you
verify the very last blocks in the chain you can be sure that all
preceeding blocks were also valid.
HTH,
Chris
On Mon, Jan 2, 2012 at 6:04 AM, Elden Tyrell <tyrell.elden@gmail•com> wrote:
> Satoshi's paper mentions that storage requirements for the blockchain
> can be reduced by deleting transactions whose outputs have been spent.
>
> If I understand correctly, this technique can only be used for reducing
> *storage* requirements, not *bandwidth* needed for the initial chain
> download by a high-security client that doesn't trust any of its peers
> -- right?
>
> The rule is "trust the longest valid chain of blocks". Part of a block
> being "valid" is that each transaction's inputs are unspent and their
> sum exceeds the transaction's outputs unless it is a coinbase. This
> cannot be verified for "stubbed out" transactions -- they have outputs
> but no inputs, and aren't coinbases. So a paranoid client booting up
> for the first time needs to be given an un-stubbed chain, right?
>
> Of course, if a client decided to accept a stubbed blocks only when the
> sum of the difficulties in the blocks after it exceeds some number N,
> then attacking it could be made very expensive by picking a large
> enough N.
>
> Please let me know if I have misunderstood something.
>
>
>
>
> ------------------------------------------------------------------------------
> Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
> infrastructure or vast IT resources to deliver seamless, secure access to
> virtual desktops. With this all-in-one solution, easily deploy virtual
> desktops for less than the cost of PCs and save 60% on VDI infrastructure
> costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 3002 bytes --]
next prev parent reply other threads:[~2012-01-02 13:32 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 [this message]
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
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=CALxbBHU7f1m+p45RHLhN-VGBoXJEi62x5mZUiAe_d5D-5Ga7yA@mail.gmail.com \
--to=decker.christian@gmail$(echo .)com \
--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