From: "Warren Togami Jr." <wtogami@gmail•com>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Gavin's post-0.9 TODO list...
Date: Fri, 16 Aug 2013 14:08:22 -1000 [thread overview]
Message-ID: <CAEz79Pq87Bp-SZsadHaRPk9HuzoeYrCK7noHm+-0iqNP0DFKuA@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP3hHh3k5+ePGbqVeyo3oV=RTy36FA+8MbOZXg3yMqRxAw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4585 bytes --]
A sane default that better protects users could be...
If (plugged into power) && (wifi) then non-bloom peers are OK. It would
protect those users more than reliance upon on the smaller subset of bloom
nodes. Scale back to the less secure behavior when battery and bandwidth
matters.
Warren
On Fri, Aug 16, 2013 at 4:36 AM, Mike Hearn <mike@plan99•net> wrote:
> That change was made in response to user complaints. Heck we get
> complaints about battery life and bandwidth impact even with Bloom
> filtering. We can't just randomly start using peoples bandwidth for
> relaying blocks, especially as I guess most SPV nodes are behind NAT.
>
> If Gavin is right and the future is dominated by mobiles and tablets, then
> it will require a change of thinking in how P2P networks work. I think
> there are plenty of people with private servers who would be willing to run
> nodes though. I'm not too worried about this.
>
>
> On Fri, Aug 16, 2013 at 4:27 PM, Warren Togami Jr. <wtogami@gmail•com>wrote:
>
>> bitcoinj-0.10 release notes:
>>
>> - We now require Bloom-capable (0.8+) peers by default and will
>> disconnect from older nodes. This avoids accidental bandwidth saturation on
>> mobile devices.
>>
>> Given the user-security concern that Peter brings up, reconsideration of
>> this new default behavior in SPV clients may be warranted.
>>
>>
>>
>> On Fri, Aug 16, 2013 at 4:15 AM, Peter Todd <pete@petertodd•org> wrote:
>>
>>> On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote:
>>> > Doing this also makes it more difficult to sybil the network - for
>>> > instance right now you can create "SPV honeypots" that allow incoming
>>> > connections only from SPV nodes, thus attracting a disproportionate %
>>> of
>>> > the total SPV population given a relatively small number of nodes. You
>>> > can then use that to harm SPV nodes by, for instance, making a % of
>>> > transactions be dropped deterministicly, either by the bloom matching
>>> > code, or when sent. Users unlucky enough to be surrounded by sybil
>>> nodes
>>> > will have their transactions mysteriously fail to arrive in their
>>> > wallets, or have their transactions mysteriously never confirm. Given
>>> > how few full nodes there are, it probably won't take very many
>>> honeypots
>>> > to pull off this attack, especially if you combine it with a
>>> > simultaneous max connections or bloom io attack to degrade the capacity
>>> > of honest nodes.
>>>
>>> Oh, here's an even better way to do the "tx drop" attack: when you drop
>>> a transaction, make a fake one that pays the same scriptPubKeys with the
>>> same amount, and send it to the SPV peer instead. They'll see the
>>> transaction go through and show up in their wallet, but it'll look like
>>> it got stuck and never confirmed. They'll soon wind up with a wallet
>>> full of useless transactions, effectively locking them out of their
>>> money.
>>>
>>> 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.
>>>
>>> --
>>> 'peter'[:-1]@petertodd.org
>>> 0000000000000018dcf5bcc3f018a05517ba1c479b432ba422015d4506496e55
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>>> It's a free troubleshooting tool designed for production.
>>> Get down to code-level detail for bottlenecks, with <2% overhead.
>>> Download for free and get started troubleshooting in minutes.
>>>
>>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists•sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get 100% visibility into Java/.NET code with AppDynamics Lite!
>> It's a free troubleshooting tool designed for production.
>> Get down to code-level detail for bottlenecks, with <2% overhead.
>> Download for free and get started troubleshooting in minutes.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 6688 bytes --]
next prev parent reply other threads:[~2013-08-17 0:08 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. [this message]
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
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=CAEz79Pq87Bp-SZsadHaRPk9HuzoeYrCK7noHm+-0iqNP0DFKuA@mail.gmail.com \
--to=wtogami@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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