public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99.net>
To: Andy Parkins <andyparkins@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Suggestion for enhancements to getblock
Date: Thu, 7 Jul 2011 17:42:12 +0200	[thread overview]
Message-ID: <CANEZrP0L-8PmwLma4DJdfoj+NefXS0kH8wvVFe-vuyRnpF-+mw@mail.gmail.com> (raw)
In-Reply-To: <201107071049.48131.andyparkins@gmail.com>

On Thu, Jul 7, 2011 at 11:49 AM, Andy Parkins <andyparkins@gmail.com> wrote:
> Imagine this situation though.  I am a light weight client.  I store the block
> headers only.  I am only interested in the history of my own wallet addresses.
> I receive a block broadcast with a transaction that sends coins to one of my
> addresses.  That transaction references other transactions (of course), but I
> haven't stored any transactions.  So; I want to request those transactions and
> ensure they are all valid and in blocks.  I can't.

Everyone writing an alternative client goes through this thought
process :-) There's no point in doing it, you cannot prove your
transaction is not a double spend. That requires knowledge (ie, an
index) of all transactions.

You have to treat appearing deep in the chain as ipso-facto proof of
validity. Lightweight/SPV clients simply must have that trust, it
cannot be done any other way. See this article:

http://code.google.com/p/bitcoinj/wiki/SecurityModel

Currently this is pretty safe due to the crazy speeds. In future when
speeds are likely to be lower, it will be less safe and you'd have to
wait longer or use a trusted node.

> It should be possible to request the current pending transaction list.

I think it'd be better to implement the filtering suggestions that
have been made. It doesn't scale to download the entire memory pool -
a better approach is to give the remote node a filter to match against
transactions then have it only relay those. After setting a filter,
transactions pending and matching would be sent in one big inv and you
can then keep the connection open to learn about new transactions
without needing to "drink from the firehose". Filters can be
probabilistic and set on many different nodes to reduce the privacy
implications.



  reply	other threads:[~2011-07-07 15:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-07  9:49 [Bitcoin-development] Suggestion for enhancements to getblock Andy Parkins
2011-07-07 15:42 ` Mike Hearn [this message]
2011-07-07 16:19   ` Andy Parkins
2011-07-07 16:44     ` Mike Hearn
2011-07-07 19:02       ` Andy Parkins
2011-07-07 17:45   ` Gregory Maxwell

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=CANEZrP0L-8PmwLma4DJdfoj+NefXS0kH8wvVFe-vuyRnpF-+mw@mail.gmail.com \
    --to=mike@plan99.net \
    --cc=andyparkins@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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