From: Amir Taaki <zgenjix@yahoo•com>
To: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] BIP 33 - Stratized Nodes
Date: Wed, 16 May 2012 10:32:51 -0700 (PDT) [thread overview]
Message-ID: <1337189571.48816.YahooMailNeo@web121003.mail.ne1.yahoo.com> (raw)
In-Reply-To: <CANEZrP1t-xhHqJ0xGQwxxx-ddtRh7jtn9Yhcau2prKNt+PZHgw@mail.gmail.com>
A bloom filter seems like an interesting idea. However this proposal is concerned mainly with the initialisation stage, whereas this bloom filter is for pushed blocks.
This proposal still updates new transactions and blocks in the same way, and it's not inconceivable to later use a bloom filter to make that part more efficient (although it's questionable if pushing this server side would be a good idea as it would now need to track an additional client state).
________________________________
From: Mike Hearn <mike@plan99•net>
To: Amir Taaki <zgenjix@yahoo•com>
Cc: "bitcoin-development@lists•sourceforge.net" <bitcoin-development@lists•sourceforge.net>
Sent: Wednesday, May 16, 2012 5:46 PM
Subject: Re: [Bitcoin-development] BIP 33 - Stratized Nodes
Thanks for getting this started.
With regards to the specific proposal, I don't believe it's the best option and still plan to eventually implement the original design outlined more than a year ago in this thread:
https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285
Namely that you use a new protocol command to set a Bloom filter on a connection. Only transactions matching that filter will appear in relayed inventory. Blocks that are requested will arrive as a header plus transaction/merkle branch pairs. Clients are expected to maintain and track the block chain as per usual, but instead of downloading the whole chain and then dropping the irrelevant transactions, that filtering is done server side. By strengthening or weakening the Bloom filters you can choose your preferred point on the privacy/bandwidth-usage spectrum. It is a fairly simple change to the Satoshi and BitcoinJ codebases but still allows clients to gain confidence in their balance by examining the chain, and this is true even in the presence of a hijacked internet connection (you can't trust pending transactions that way, but you can still trust confirmed transactions).
The filters would be applied to each data block in each script rather than having a specific knowledge of addresses. In this way you can select for things like multisig outputs or outputs which don't use addresses / pubkeys to authenticate.
I could write a BIP for this alternative protocol if somebody else wants to implement it. I was going to wait until I had time to do both BIP and implementation, but I think some simple optimizations to BitcoinJ can keep its performance good enough for the short term.
next prev parent reply other threads:[~2012-05-16 17:32 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-16 16:34 Amir Taaki
2012-05-16 16:46 ` Mike Hearn
2012-05-16 17:32 ` Amir Taaki [this message]
2012-05-16 18:22 ` Jeff Garzik
2012-05-16 16:49 ` Peter Vessenes
2012-05-16 17:37 ` Amir Taaki
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=1337189571.48816.YahooMailNeo@web121003.mail.ne1.yahoo.com \
--to=zgenjix@yahoo$(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