From: Mike Hearn <mike@plan99•net>
To: John Dillon <john.dillon892@googlemail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
Date: Mon, 19 Aug 2013 11:16:12 +0200 [thread overview]
Message-ID: <CANEZrP297GJYJDVc939RxSeiKu1bWeCy3RZiN+=LPpaqyvqjFQ@mail.gmail.com> (raw)
In-Reply-To: <CAPaL=UXpitBWJOzY-TRGh4kaD2Mt6G92KTt307MfRnzygk6D3A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 1946 bytes --]
prev parent reply other threads:[~2013-08-19 9:16 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-16 1:00 Gavin Andresen
2013-08-16 4:06 ` Melvin Carvalho
2013-08-16 12:11 ` Mike Hearn
2013-08-16 12:24 ` Mike Hearn
2013-08-16 13:41 ` Warren Togami Jr.
2013-08-16 13:46 ` Mike Hearn
2013-08-16 13:53 ` Warren Togami Jr.
2013-08-16 14:06 ` Peter Todd
2013-08-16 14:56 ` Gregory Maxwell
2013-08-16 14:01 ` Peter Todd
2013-08-16 14:15 ` Peter Todd
2013-08-16 14:27 ` Warren Togami Jr.
2013-08-16 14:36 ` Mike Hearn
2013-08-16 14:59 ` Peter Todd
2013-08-16 15:06 ` Warren Togami Jr.
2013-08-16 15:11 ` Mike Hearn
2013-08-16 15:13 ` Mike Hearn
2013-08-16 15:59 ` Peter Todd
2013-08-17 0:08 ` Warren Togami Jr.
2013-08-17 12:35 ` Mike Hearn
2013-08-17 13:41 ` Jeff Garzik
2013-08-19 3:09 ` John Dillon
2013-08-19 3:17 ` Peter Todd
2013-08-19 5:00 ` John Dillon
2013-08-19 5:34 ` John Dillon
2013-08-19 5:11 ` Mark Friedenbach
2013-08-19 9:16 ` Mike Hearn [this message]
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='CANEZrP297GJYJDVc939RxSeiKu1bWeCy3RZiN+=LPpaqyvqjFQ@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=john.dillon892@googlemail$(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