1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
|
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 <mh.in.england@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
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: <CAAS2fgScydOWz_eqnhWxQNVUOtzvSBwkj7tttP3_DLdW+=3CTQ@mail.gmail.com>
References: <CANEZrP0XALwBFJyZTzYd5xBp4MRrjv0s_y2tOXbO7UgjWF2HzA@mail.gmail.com>
<CAAS2fgScydOWz_eqnhWxQNVUOtzvSBwkj7tttP3_DLdW+=3CTQ@mail.gmail.com>
Date: Fri, 26 Oct 2012 16:01:58 +0200
X-Google-Sender-Auth: Ijl1d1-hmEjxEMGDsmCQsH0Ki3o
Message-ID: <CANEZrP2sBZL=UYAxtjU2Su13Z12wB7s04LxmcyUR2hH51tcN9g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Gregory Maxwell <gmaxwell@gmail.com>
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 <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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.
|
