From: Mike Hearn <mike@plan99•net>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering
Date: Fri, 26 Oct 2012 16:01:58 +0200 [thread overview]
Message-ID: <CANEZrP2sBZL=UYAxtjU2Su13Z12wB7s04LxmcyUR2hH51tcN9g@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgScydOWz_eqnhWxQNVUOtzvSBwkj7tttP3_DLdW+=3CTQ@mail.gmail.com>
> Presumably these components will just get implemented a few times in
> some carefully constructed library code, so I don't see an
> implementation complexity argument here— except the fact that it isn't
> what Matt has implemented so far.
Well, yes, that is basically the implementation complexity argument :)
Engineering time isn't free.
I don't feel I understand the effort required to do some kind of
partial tree encoding. Having a kind of custom compression whereby
branches are represented as varint indexes into a dictionary, I can
feel how much work that involves and maybe I can make time over the
next few weeks to implement it. Has anyone got example code for
representing partial Merkle trees?
> Also, it's not mentioned in the page— but the hash function used is
> not cryptographically strong, so what prevents a complexity (well,
> bandwidth in this case) attack? someone could start using txids and
> txouts that collide with the maximum number of other existing txouts
> in order to waste bandwidth for people. Is this avenue of attack not
> a concern?
If you just want to waste bandwidth of nodes you can connect to nodes
and repeatedly download blocks, or fill the network with fake nodes
that spam random generated transactions to whoever connects. I don't
see how to avoid that so it seems odd to worry about a much more
complicated attack.
next prev parent reply other threads:[~2012-10-26 14:02 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-24 15:56 Mike Hearn
2012-10-24 16:22 ` Pieter Wuille
2012-10-24 16:35 ` Mike Hearn
2012-10-24 17:11 ` Pieter Wuille
2012-10-24 18:54 ` Gavin Andresen
2012-10-24 19:00 ` Matt Corallo
2012-10-24 19:10 ` Mike Hearn
2012-10-24 20:29 ` Gavin Andresen
2012-10-24 20:58 ` Mike Hearn
2012-10-24 21:55 ` Jeff Garzik
2012-10-25 16:56 ` Gregory Maxwell
2012-10-25 17:01 ` Gregory Maxwell
2012-10-26 14:01 ` Mike Hearn [this message]
2012-10-26 14:17 ` Gregory Maxwell
2012-10-26 14:21 ` Mike Hearn
2012-10-26 14:34 ` Gregory Maxwell
2012-11-06 19:14 ` Pieter Wuille
2012-11-21 15:15 ` Pieter Wuille
2012-11-21 18:38 ` Matt Corallo
2012-11-27 21:10 ` Pieter Wuille
2013-01-10 15:21 ` Mike Hearn
2013-01-11 3:59 ` Matt Corallo
2013-01-11 5:02 ` Jeff Garzik
2013-01-11 14:11 ` Mike Hearn
2013-01-11 14:13 ` Mike Hearn
2013-01-16 10:43 ` Mike Hearn
2013-01-16 15:00 ` Matt Corallo
2013-01-18 16:38 ` Mike Hearn
2013-01-19 9:51 ` Andreas Schildbach
2013-01-30 11:09 ` Mike Hearn
2013-01-30 11:13 ` Mike Hearn
2013-02-06 16:33 ` Mike Hearn
2013-02-06 16:45 ` Gregory Maxwell
2013-02-20 12:44 ` Mike Hearn
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='CANEZrP2sBZL=UYAxtjU2Su13Z12wB7s04LxmcyUR2hH51tcN9g@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@gmail$(echo .)com \
/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