public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Aaron Voisine <voisine@gmail.com>
To: jan.moller@gmail.com
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Justus Ranvier <justusranvier@riseup.net>
Subject: Re: [Bitcoin-development] Criminal complaints against "network disruption as a service" startups
Date: Mon, 16 Mar 2015 12:33:06 -0700	[thread overview]
Message-ID: <CACq0ZD6LmGR+KCbWTBbbe0FDh5c8QvHkd1KqW2g0XWVh-a0pOw@mail.gmail.com> (raw)
In-Reply-To: <CABh=4qNwRqb3f+AM-PKB0F+Kaw02tAq2DsqLmeO87XxXZvTd4Q@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5396 bytes --]

Thanks Jan, we added several additional checks for non-standard protocol
responses, and also made the client revert to DNS seeding more quickly if
it runs into trouble, so it's now more robust against sybil/DOS attack. I
mentioned in the coindesk article that I didn't think what your nodes were
doing was intended to be malicious with respect to network disruption. It's
our job to better handle non-standard or even malicious behavior from
random p2p nodes.


Aaron Voisine
co-founder and CEO
breadwallet.com

On Mon, Mar 16, 2015 at 1:44 AM, Jan Møller <jan.moller@gmail.com> wrote:

> What we were trying to achieve was determining the flow of funds between
> countries by figuring out which country a transaction originates from.
> To do that with a certain accuracy you need many nodes. We chose a class C
> IP range as we knew that bitcoin core and others only connect to one node
> in any class C IP range. We were not aware that breadwallet didn't follow
> this practice. Breadwallet risked getting tar-pitted, but that was not our
> intention and we are sorry about that.
>
> Our nodes DID respond with valid blocks and merkle-blocks and allowed
> everyone connecting to track the blockchain. We did however not relay
> transactions. The 'service' bit in the version message is not meant for
> telling whether or how the node relays transactions, it tells whether you
> can ask for block headers only or full blocks.
>
> Many implementations enforce non standard rules for handling transactions;
> some nodes ignore transactions with address reuse, some nodes happily
> forward double spends, and some nodes forward neither blocks not
> transactions. We did blocks but not transactions.
>
> In hindsight we should have done two things:
> 1. relay transactions
> 2. advertise address from 'foreign' nodes
>
> Both would have fixed the problems that breadwallet experienced. My
> understanding is that breadwallet now has the same 'class C' rule as
> bitcoind, which would also fix it.
>
> Getting back on the topic of this thread and whether it is illegal, your
> guess is as good as mine. I don't think it is illegal to log incoming
> connections and make statistical analysis on it. That would more or less
> incriminate anyone who runs a web-server and looks into the access log.
> At lease one Bitcoin service has been collecting IP addresses for years
> and given them to anyone visiting their web-site (you know who) and I
> believe that this practise is very wrong. We have no intention of giving IP
> addresses away to anyone, but we believe that you are free to make
> statistics on connection logs when nodes connect to you.
>
> On a side note: When you make many connections to the network you see lots
> of strange nodes and suspicious patterns. You can be certain that we were
> not the only ones connected to many nodes.
>
> My takeaway from this: If nodes that do not relay transactions is a
> problem then there is stuff to fix.
>
> /Jan
>
> On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn <mike@plan99.net> wrote:
>
>> That would be rather new and tricky legal territory.
>>
>> But even putting the legal issues to one side, there are definitional
>> issues.
>>
>> For instance if the Chainalysis nodes started following the protocol
>> specs better and became just regular nodes that happen to keep logs, would
>> that still be a violation? If so, what about blockchain.info? It'd be
>> shooting ourselves in the foot to try and forbid block explorers given how
>> useful they are.
>>
>> If someone non-maliciously runs some nodes with debug logging turned on,
>> and makes full system backups every night, and keeps those backups for
>> years, are they in violation of whatever pseudo-law is involved?
>>
>> I think it's a bit early to think about these things right now. Michael
>> Grønager and Jan Møller have been Bitcoin hackers for a long time. I'd be
>> interested to know their thoughts on all of this.
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming The Go Parallel Website,
>> sponsored
>> by Intel and developed in partnership with Slashdot Media, is your hub
>> for all
>> things parallel software development, from weekly thought leadership
>> blogs to
>> news, videos, case studies, tutorials and more. Take a look and join the
>> conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

[-- Attachment #2: Type: text/html, Size: 7142 bytes --]

  parent reply	other threads:[~2015-03-16 19:33 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-13 20:01 [Bitcoin-development] Criminal complaints against "network disruption as a service" startups Justus Ranvier
2015-03-13 21:48 ` Mike Hearn
2015-03-13 22:03   ` Justus Ranvier
2015-03-13 22:08     ` Mike Hearn
2015-03-13 22:16       ` Justus Ranvier
2015-03-13 22:24         ` Mike Hearn
2015-03-13 22:38           ` Justus Ranvier
2015-03-16  8:44   ` Jan Møller
2015-03-16 16:29     ` [Bitcoin-development] "network disruption as a service" and proof of local storage Sergio Lerner
2015-03-24  5:14       ` Jeremy Spilman
2015-03-26 22:09         ` Sergio Lerner
2015-03-26 23:04           ` Matt Whitlock
2015-03-27 14:32             ` Robert McKay
2015-03-27 15:16               ` Matt Whitlock
2015-03-27 15:32                 ` Robert McKay
     [not found]                 ` <20150327155730.GB20754@amethyst.visucore.com>
2015-03-27 16:00                   ` Matt Whitlock
2015-03-27 16:08                   ` Matt Whitlock
2015-03-27 18:40                 ` Jeremy Spilman
2015-04-01  2:34                   ` Sergio Lerner
2015-03-16 19:33     ` Aaron Voisine [this message]
2015-03-23  2:44     ` [Bitcoin-development] Criminal complaints against "network disruption as a service" startups odinn
2015-03-23  3:38 Thy Shizzle
2015-03-23  5:50 ` odinn
2015-03-23  6:10 Thy Shizzle
2015-03-23  6:45 ` odinn

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=CACq0ZD6LmGR+KCbWTBbbe0FDh5c8QvHkd1KqW2g0XWVh-a0pOw@mail.gmail.com \
    --to=voisine@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=jan.moller@gmail.com \
    --cc=justusranvier@riseup.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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