From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <20130816140116.GB16201@petertodd.org> <20130816141536.GD16201@petertodd.org> Date: Mon, 19 Aug 2013 11:16:12 +0200 X-Google-Sender-Auth: W2brLRU5Yr77jGW6E2n9UpM0x8g Message-ID: From: Mike Hearn To: John Dillon 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
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 j= unk
> 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 di= fferent 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 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).

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.


--047d7bfe97e043fc9a04e44964fa--