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 --]
next prev 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 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$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jan.moller@gmail$(echo .)com \
--cc=justusranvier@riseup$(echo .)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