From: Andy Parkins <andyparkins@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Suggestion for enhancements to getblock
Date: Thu, 7 Jul 2011 17:19:39 +0100 [thread overview]
Message-ID: <201107071719.45416.andyparkins@gmail.com> (raw)
In-Reply-To: <CANEZrP0L-8PmwLma4DJdfoj+NefXS0kH8wvVFe-vuyRnpF-+mw@mail.gmail.com>
[-- Attachment #1: Type: Text/Plain, Size: 3029 bytes --]
On 2011 July 07 Thursday, Mike Hearn wrote:
> 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.
Ah; you mistake me. I'm not interested in double spend prevention, in this
case I'd be willing to trust the full node to return whatever block it thinks
contains that transaction, and that it has already done double spend
prevention.
What I want to be able to do though is calculate a balance for an aribtrary
address. Not every address; just the particular ones that the client is
interested in. It's complete overkill to require the whole block chain just
to calculate the balance of a few addresses.
> 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:
Not entirely. If I ask for "the block that contains transaction with hash
12345678abcd..." then when I get that full block, I can verify the merkle tree
myself. I do have to trust that the peer hasn't been adding double spends in,
but not that the transaction is actually in the chain.
> > 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 -
I'm sorry, I've only started watching this list in the last few days. I'm not
familiar with the filter suggestions.
I'm not entirely sure I see how a filter helps. If I've been offline for ten
minutes then I need all the transactions pending in the last ten minutes. No
amount of filtering makes that list any smaller.
> 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.
That would be fine. My reason for suggesting using getblocks was that it
didn't introduce a new command.
Andy
--
Dr Andy Parkins
andyparkins@gmail•com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2011-07-07 16:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-07 9:49 Andy Parkins
2011-07-07 15:42 ` Mike Hearn
2011-07-07 16:19 ` Andy Parkins [this message]
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=201107071719.45416.andyparkins@gmail.com \
--to=andyparkins@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