Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1TRkUE-0004my-F2 for bitcoin-development@lists.sourceforge.net; Fri, 26 Oct 2012 14:02:10 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.82.53 as permitted sender) client-ip=74.125.82.53; envelope-from=mh.in.england@gmail.com; helo=mail-wg0-f53.google.com; Received: from mail-wg0-f53.google.com ([74.125.82.53]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1TRkU8-0004fG-Th for bitcoin-development@lists.sourceforge.net; Fri, 26 Oct 2012 14:02:10 +0000 Received: by mail-wg0-f53.google.com with SMTP id dr1so1732830wgb.10 for ; Fri, 26 Oct 2012 07:01:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.201.156 with SMTP id b28mr13881891weo.4.1351260118618; Fri, 26 Oct 2012 07:01:58 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.216.236.30 with HTTP; Fri, 26 Oct 2012 07:01:58 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Oct 2012 16:01:58 +0200 X-Google-Sender-Auth: Ijl1d1-hmEjxEMGDsmCQsH0Ki3o Message-ID: From: Mike Hearn To: Gregory Maxwell Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.4 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 AWL AWL: From: address is in the auto white-list X-Headers-End: 1TRkU8-0004fG-Th Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Draft BIP for Bloom filtering X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 14:02:10 -0000 > 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=E2=80=94 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=E2=80=94 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.