I've written a draft BIP describing the bloom filtering protocol
extension developed by myself and Matt.
https://en.bitcoin.it/wiki/BIP_0037
(yes I know there's some kind of process around getting allocated a
number - it seems overkill for this).
Please read it and let me know if there are any
Some questions:
* why limit the number of matching transactions to 255?
Copy/paste error in the does :(
* what does each hash and key in the output script mean exactly? what
about the output script in its entirety?
It's an informal way to say data elements. If you insert a key then it
On Wed, Oct 24, 2012 at 06:35:08PM +0200, Mike Hearn wrote:
* what does each hash and key in the output script mean exactly? what
about the output script in its entirety?
It's an informal way to say data elements. If you insert a key then it
matches both single and multi sig outputs
RE: sharing parts of the merkle branches when returning a 'merkleblock' :
I think I agree that complicating the BIP for what should be a very
rare case (more than a handful of transactions in a block match the
transactions in your wallet) is the right decision.
I want to make sure I'm
On Wed, 2012-10-24 at 14:54 -0400, Gavin Andresen wrote:
RE: sharing parts of the merkle branches when returning a 'merkleblock' :
I think I agree that complicating the BIP for what should be a very
rare case (more than a handful of transactions in a block match the
transactions in your
On Wed, Oct 24, 2012 at 3:10 PM, Mike Hearn m...@plan99.net wrote:
Bitcoin already keeps track of which nodes have seen what to avoid redundant
inv announcements.
Oops, right. That memory usage is bounded right now by bounds on the
memory pool size, though, right? (I'm being lazy and not
What is the worst-case for an attacker interested in trying to get you
to saturate your upstream bandwidth or use lots of memory? Set a
bloom filter that matches everything, and then start requesting old
blocks in the chain?
It would be slightly worse than shipping a full block but not
7 matches
Mail list logo
