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
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1VBLZV-0006wN-Ae
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Aug 2013 09:16:21 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.180 as permitted sender)
client-ip=209.85.214.180; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f180.google.com;
Received: from mail-ob0-f180.google.com ([209.85.214.180])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VBLZS-0003Aa-5C
for bitcoin-development@lists.sourceforge.net;
Mon, 19 Aug 2013 09:16:21 +0000
Received: by mail-ob0-f180.google.com with SMTP id up14so4843499obb.25
for <bitcoin-development@lists.sourceforge.net>;
Mon, 19 Aug 2013 02:16:12 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.46.232 with SMTP id y8mr11909017obm.13.1376903772763;
Mon, 19 Aug 2013 02:16:12 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.80.165 with HTTP; Mon, 19 Aug 2013 02:16:12 -0700 (PDT)
In-Reply-To: <CAPaL=UXpitBWJOzY-TRGh4kaD2Mt6G92KTt307MfRnzygk6D3A@mail.gmail.com>
References: <CABsx9T32q8mKgtmsaZgh7nuhHY5cExeW=FiadzXq3jXVP=NBTw@mail.gmail.com>
<CANEZrP0PEcP339MKRyrHXHCCsP3BxRHT-ZfKRQ7G2Ou+15CD7A@mail.gmail.com>
<CANEZrP3LAR0erjgmTHruLwPNDdx-OVyb9KK52E6UnmE4ZuBrvQ@mail.gmail.com>
<20130816140116.GB16201@petertodd.org>
<20130816141536.GD16201@petertodd.org>
<CAPaL=UXpitBWJOzY-TRGh4kaD2Mt6G92KTt307MfRnzygk6D3A@mail.gmail.com>
Date: Mon, 19 Aug 2013 11:16:12 +0200
X-Google-Sender-Auth: W2brLRU5Yr77jGW6E2n9UpM0x8g
Message-ID: <CANEZrP297GJYJDVc939RxSeiKu1bWeCy3RZiN+=LPpaqyvqjFQ@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: John Dillon <john.dillon892@googlemail.com>
Content-Type: multipart/alternative; boundary=047d7bfe97e043fc9a04e44964fa
X-Spam-Score: -0.5 (/)
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
1.0 HTML_MESSAGE BODY: HTML included in message
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
X-Headers-End: 1VBLZS-0003Aa-5C
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
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: Mon, 19 Aug 2013 09:16:21 -0000
--047d7bfe97e043fc9a04e44964fa
Content-Type: text/plain; charset=UTF-8
On Mon, Aug 19, 2013 at 5:09 AM, John Dillon
<john.dillon892@googlemail.com>wrote:
> > Here's another question for you Mike: So does bitcoinj have any
> > protections against peers flooding you with useless garbage? It'd be
> > easy to rack up a user's data bill for instance by just creating junk
> > unconfirmed transactions matching the bloom filter.
>
Unconfirmed transactions that are received show up as unspendable and in
most wallets they have a little graphic that changes as more peers announce
the tx. So if a peer sent non-existent transactions then they'd allow show
up as seen by only one peer, which would look different to how normal
broadcast transactions show up.
Whether users really notice this graphic or understand what it means is
debatable, of course, but all Bitcoin wallets have that problem. I've yet
to see any that would successfully communicate the notion of confidence to
new, untrained users. That's why the default is to not let you spend
unconfirmed transactions, unless they were created by yourself (you're
allowed to spend change).
bitcoinj does not attempt to handle DoS attacks by malicious remote peers
today, because such an attack has never been observed, has no obvious
profit motive and as you don't get to choose which nodes the wallets
connect to it'd be difficult to pull off. Unless you control the users
internet connection of course, but that's a well known caveat which is
documented on the website.
--047d7bfe97e043fc9a04e44964fa
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Aug 19, 2013 at 5:09 AM, John Dillon <span dir=3D"=
ltr"><<a href=3D"mailto:john.dillon892@googlemail.com" target=3D"_blank"=
>john.dillon892@googlemail.com</a>></span> wrote:<br><div class=3D"gmail=
_extra">
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"=
>> Here's another question for you Mike: So does bitcoinj have any<b=
r>
> protections against peers flooding you with useless garbage? It'd =
be<br>
> easy to rack up a user's data bill for instance by just creating j=
unk<br>
> unconfirmed transactions matching the bloom filter.<br></div></blockqu=
ote><div><br></div><div>Unconfirmed transactions that are received show up =
as unspendable and in most wallets they have a little graphic that changes =
as more peers announce the tx. So if a peer sent non-existent transactions =
then they'd allow show up as seen by only one peer, which would look di=
fferent to how normal broadcast transactions show up.</div>
<div><br></div><div>Whether users really notice this graphic or understand =
what it means is debatable, of course, but all Bitcoin wallets have that pr=
oblem. I've yet to see any that would successfully communicate the noti=
on of confidence to new, untrained users. That's why the default is to =
not let you spend unconfirmed transactions, unless they were created by you=
rself (you're allowed to spend change).</div>
<div><br></div><div>bitcoinj does not attempt to handle DoS attacks by mali=
cious remote peers today, because such an attack has never been observed, h=
as no obvious profit motive and as you don't get to choose which nodes =
the wallets connect to it'd be difficult to pull off. Unless you contro=
l the users internet connection of course, but that's a well known cave=
at which is documented on the website.</div>
<div><br></div><div><br></div></div></div></div>
--047d7bfe97e043fc9a04e44964fa--
|
