From: Jeff Garzik <jgarzik@exmulti•com>
To: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] New P2P commands for diagnostics, SPV clients
Date: Wed, 13 Jun 2012 16:46:37 -0400 [thread overview]
Message-ID: <CA+8xBpecVQcTTbPxUm_3_GWC99dEd4=-VFWb+QT6jUy4rg8U4w@mail.gmail.com> (raw)
An IRC discussion today covered additional needs of lightweight
clients. Here is a draft of proposed new P2P commands, and associated
behavior changes. This is not meant to be a formal, detailed
specification but rather rough picture of the preferred direction.
-----
filterinit(false positive rate, number of elements): initialize
per-connection bloom filter to the given parameters. if the
parameters create a too-large table, the operation fails. returns a
'filterparams' message, with bloom filter construction details.
filterload(data): input a serialized bloom filter table metadata and data.
filterclear(): remove any filtering associated with current connection.
filteradd(hash data): add a single hash to the bloom filter. WARNING:
although easier to use, has privacy implications. filterload shrouds
the hash list; filteradd does not. it is also less efficient to send
a stream of filteradd's to the remote node.
mempool(): list TX's in remote node's memory pool.
-----
'filterload' and 'filteradd' enable special behavior changes for
'mempool' and existing P2P commands, whereby only transactions
matching the bloom filter will be announced to the connection, and
only matching transactions will be sent inside serialized blocks.
A lightweight ("SPV") client would issue 'filterload', sync up with
blocks, then use 'mempool' to sync up to current TX's. The
'filterload' command also ensures that the client is only sent 'inv'
messages etc. for the TX's it is probably interested in.
The 'mempool' command is thought to be useful as a diagnostic, even if
a bloom filter is not applied to its output.
A bloom filter match would need to notice activity on existing coins
(via CTxIn->prevout) and activity on a bitcoin address (via CTxOut).
--
Jeff Garzik
exMULTI, Inc.
jgarzik@exmulti•com
next reply other threads:[~2012-06-13 20:46 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-13 20:46 Jeff Garzik [this message]
2012-06-14 11:52 ` Mike Hearn
2012-06-15 11:52 ` Mike Hearn
2012-06-15 13:19 ` Matt Corallo
2012-06-15 13:23 ` Mike Hearn
2012-06-15 14:39 ` Matt Corallo
2012-06-16 8:27 ` Mike Hearn
2012-06-19 19:09 ` Matt Corallo
2012-07-21 11:45 ` Mike Hearn
2012-07-23 7:54 ` Andreas Petersson
2012-07-23 16:40 ` Matt Corallo
2012-07-24 8:16 ` Mike Hearn
2012-06-15 13:26 ` Jeff Garzik
2012-06-15 13:43 ` Mike Hearn
2012-06-15 14:56 ` Matt Corallo
2012-06-15 15:32 ` Jeff Garzik
2012-06-15 16:20 ` Matt Corallo
2012-06-15 18:42 ` Amir Taaki
2012-06-16 8:25 ` Mike Hearn
2012-06-15 15:43 ` Simon Barber
2012-06-15 16:40 ` Jeff Garzik
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='CA+8xBpecVQcTTbPxUm_3_GWC99dEd4=-VFWb+QT6jUy4rg8U4w@mail.gmail.com' \
--to=jgarzik@exmulti$(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