Bitcoinj's DNS Seed Addresses

[quantu...@gmail.com]

I was recently made aware on Twitter than Bitcoinj updated its DNS seed node list to include Jeff Garzik's and Bloq's nodes. I would like to know why these were added, and why other 2x seed nodes were not. This bothers me both because of the(though a leap to a degree) concerns over Bloq's investment in Skry and acquiring its analytics software and techniques, and the fact that these seed nodes are running BTC1. 

This creates two problems in my mind. 1) It opens up all users of wallets basing off your version of Bitcoinj to be tagged and identified on a network level by a company that has directly invested in chain analytics company. This is a huge privacy risk for users. It also opens up the potential to be compromised in terms of the Bitcoin network as well as the seed nodes would decide what nodes to pass the new wallet off to.

Which leads me to my next issue. These new seed nodes operating BTC1 creates a huge systemic risk for users in the event the NY Agreement is fulfilled and there is a fork in November. These new DNS seed additions could be guaranteeing wallets are connected to both network post-fork and cause unpredicted/detrimental behavior for users.

I would ask that these additions be removed, and would like to know why they were added in the first place, as they introduce two different risk surfaces for your userbase that would not exist without them. 

Thank you for taking the time to read my concerns. 

[Jameson Lopp]

The PR in question: https://github.com/bitcoinj/bitcoinj/pull/1408

Probably worth noting that Andreas is employed by Bloq... http://bloq.com/bloq-expands-team-and-announces-board-of-advisors.html

Regarding the privacy issue: perhaps, though there's no guarantee that other seed nodes aren't also keeping some sort of information for analytics. If you really care about network privacy then your BitcoinJ apps should only be connecting to full nodes that you (or your users) control.

I suspect the answer regarding SegWit2X is that from BitcoinJ's point of view it will follow whatever chain has the most cumulative proof of work and isn't concerned about replay protection issues. Thus BitcoinJ would want to be as well-connected as possible.

--
You received this message because you are subscribed to the Google Groups "bitcoinj" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[quantu...@gmail.com]

To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Well I would like to hear the rationale from the Bitcoinj developers, who still have not responded. But, despite being a leap as I said myself, I think the issue of privacy is more pressing comparing a company with analytics investments nodes versus developers personal seed nodes. As well, I think it is absolutely in no way a wallet developer's place to make a decision such as "The longest POW chain regardless of validity or rules is Bitcoin" on behalf of their users. That choice should be left with the users, not made by the developers. 

[Andreas Schildbach]

On 09/29/2017 09:39 PM, quantu...@gmail.com wrote:
>
>
> On Friday, September 29, 2017 at 9:23:10 AM UTC-5, Jameson Lopp wrote:
>
> The PR in question: https://github.com/bitcoinj/bitcoinj/pull/1408
> <https://github.com/bitcoinj/bitcoinj/pull/1408>
>
> Probably worth noting that Andreas is employed by
> Bloq... http://bloq.com/bloq-expands-team-and-announces-board-of-advisors.html

> <http://www.google.com/url?q=http%3A%2F%2Fbloq.com%2Fbloq-expands-team-and-announces-board-of-advisors.html&sa=D&sntz=1&usg=AFQjCNH1H-dZbuuvTnuQaUjCf60fvaEv-w>

> <https://groups.google.com/d/optout>.

>
>
>
> Well I would like to hear the rationale from the Bitcoinj developers,
> who still have not responded. But, despite being a leap as I said
> myself, I think the issue of privacy is more pressing comparing a
> company with analytics investments nodes versus developers personal seed
> nodes. As well, I think it is absolutely in no way a wallet developer's
> place to make a decision such as "The longest POW chain regardless of
> validity or rules is Bitcoin" on behalf of their users. That choice
> should be left with the users, not made by the developers. 

Jameson has contributed to bitcoinj so he is a bitcoinj developer.

I added Bloqs seed when I didn't know about other seeds to add. Like
Jameson said, the rationale is diversity of connected peers. PR welcome
if you want the other seeds to be added as well.

If you're concerned about privacy the low hanging fruit is implementing
the handling of addr messages and persisting the list of known peers.
Then seeds are not necessary any more after the first bootstrap. PR welcome.

You can switch bitcoinj to full verifying mode in which case it will try
to validate transactions. However, be prepared there will be some diff
between bitcoinj and Bitcoin Core so you will need to work on that (or
with that).

[quantu...@gmail.com]

I think that is completely sidestepping any response to the issue of compatibility problems resulting from the 2x fork. As well it ignores the entire concern I highlighted regarding privacy, which is leaking network information identifying someone as a Bitcoin user upon first starting a new wallet.  The entire privacy concern I have is specific to Bloq's seeds as a company invested in a chain analytics company. My second issue, again _specifically_ with Bloq's seed nodes is they are running a consensus incompatible client. Now, to be clear I am not interested in starting a political shit fit over what is Bitcoin, we are both entitled to our opinions on that matter. But so are all the users utilizing your own wallet or wallets building off Bitcoinj. 

I find it highly irresponsible to be including a seednode that to my knowledge is guaranteeing your users will be peered with two client implementations with conflicting consensus rules, with one of them coded to initiate a hardfork in November, without a mechanism in the client for it to allow it to distinguish between these chains (whether automated logic or based on user input). Not every user has the capability or technical knowledge to run a trusted full node to connect to, and not everyone in that category knows someone running a node they trust. This is not related to a project I am engaged in, this is me coming to you with my concerns over the situation this creates for the entire userbase of this codebase to potentially lose money. The responsible thing to do would be to either remove the seed node, or implement a mechanism for users to be able to distinguish peers and ensure they are not connected to both networks at the time BTC1 clients hardfork in November. 

The privacy issue is definitely a concern, although as I said is a leap over a few assumptions on my part, but I believe the peering to two clients with incompatible consensus rules is a much greater concern.

[Manfred Karrer]

I had the same concerns regarding Bloq's seed node addition and removed it from Bisq's BitcoinJ fork (https://github.com/bisq-network/bitcoinj/commit/7b2ed972fa09237a79388d39c49f51ee6aa17ac3).

Though there are much more problematic privacy issues with the broken Bloom filter implementation and design. Any full node (operated by a surveillance company like Skry) can find out that all wallet addresses belong to one user and if you don't use Tor they even know your IP address.

Unfortunately nobody is working on that to fix that.

The chain blindness of BitcoinJ is another major concern not addressed as far I know and will set BitcoinJ users at risk to spend their Bitcoin on a chain which they don't want to support and/or get exposed to replay attacks. Very concerning IMO!

[Manfred Karrer]

Regarding privacy issue with Bloom filters, here are a few references:

https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/

https://eprint.iacr.org/2014/763.pdf

https://github.com/bisq-network/exchange/issues/487

https://bisq.network/blog/privacy-in-bitsquare/

[Manfred Karrer]

Background about Bloq's acquisition of Skry:

http://www.nasdaq.com/article/bloq-acquires-skry-supercharges-blockchain-analytics-with-ai-and-machine-learning-cm754603

[Andreas Schildbach]

On 10/12/2017 02:08 AM, Manfred Karrer wrote:

> I had the same concerns regarding Bloq's seed node addition and removed
> it from Bisq's BitcoinJ fork
> (https://github.com/bisq-network/bitcoinj/commit/7b2ed972fa09237a79388d39c49f51ee6aa17ac3).

Perhaps we should add methods for removing and adding DNS seeds from
NetworkParameters. NetworkParameters is meant to be constant, but we
could have a configuration phase before it is actually being used.

> Though there are much more problematic privacy issues with the broken
> Bloom filter implementation and design. Any full node (operated by a
> surveillance company like Skry) can find out that all wallet addresses
> belong to one user and if you don't use Tor they even know your IP address.
>
> Unfortunately nobody is working on that to fix that.

The current plan to fix this is by full nodes offering reverse bloom
filters (or similar), if I remember this correctly. Instead of lite
clients sending their custom bloom filter to the full node, full nodes
would construct filters from their blocks and send them to the lite
clients. They would be committed to the blockchain so full nodes could
not lie.

One unsolved problem with this is this idea would not work with pending
transactions.

> The chain blindness of BitcoinJ is another major concern not addressed
> as far I know and will set BitcoinJ users at risk to spend their Bitcoin
> on a chain which they don't want to support and/or get exposed to replay
> attacks. Very concerning IMO!

I would not say bitcoinj is blind to the chain. It always follows the
chain with most accumulated work, which is a very specific chain from a
users point of view.

[Manfred Karrer]

Am Donnerstag, 12. Oktober 2017 12:49:25 UTC-5 schrieb Andreas Schildbach:

On 10/12/2017 02:08 AM, Manfred Karrer wrote:

> I had the same concerns regarding Bloq's seed node addition and removed
> it from Bisq's BitcoinJ fork
> (https://github.com/bisq-network/bitcoinj/commit/7b2ed972fa09237a79388d39c49f51ee6aa17ac3).

Perhaps we should add methods for removing and adding DNS seeds from
NetworkParameters. NetworkParameters is meant to be constant, but we
could have a configuration phase before it is actually being used.

Yes that would be a good idea. Also to make usage of http seed optional (there are some concerns with http seed regarding privacy as well - See Peter Todd’s replies when Mike was suggesting that).

 

> Though there are much more problematic privacy issues with the broken
> Bloom filter implementation and design. Any full node (operated by a
> surveillance company like Skry) can find out that all wallet addresses
> belong to one user and if you don't use Tor they even know your IP address.
>
> Unfortunately nobody is working on that to fix that.

The current plan to fix this is by full nodes offering reverse bloom
filters (or similar), if I remember this correctly. Instead of lite
clients sending their custom bloom filter to the full node, full nodes
would construct filters from their blocks and send them to the lite
clients. They would be committed to the blockchain so full nodes could
not lie.

One unsolved problem with this is this idea would not work with pending
transactions.

I would be happy if the low hanging fruits would get fixed like:
- persisting the nonce
- not adding both pukKey and pukKeyHash as that reveals the real addresses

I am aware that this would also not lead to perfect privacy, but it would be at least better as the current state.

 

> The chain blindness of BitcoinJ is another major concern not addressed
> as far I know and will set BitcoinJ users at risk to spend their Bitcoin
> on a chain which they don't want to support and/or get exposed to replay
> attacks. Very concerning IMO!

I would not say bitcoinj is blind to the chain. It always follows the
chain with most accumulated work, which is a very specific chain from a
users point of view.

A big problem with that is, that if miners switch between chains (as we saw with BCH/BTC) the longest PoW chain might change as well, leading to security risks and potential losses. So if today I am following the BTC chain and sending you coins and tomorrow the longest PoW chain becomes B2X then BitcoinJ will not recognise that tx anymore. In Bisq the deposit tx might get renders invalid after a chain switch and the exchange loses its primary security mechanism.

I am tired of those fork attacks and don’t assume they will succeed (as all the past attempts) but it consumes valuable dev time to prepare strategies how to deal with that menace…

Best would be if there would be some option in BitcoinJ to guarantee to stay on one chain (Luke DashJr has recommended one solution a few months ago at the last fork attempt. Don’t remember the details but as far I remember it was not a huge change, just a small extra check when accepting blocks/nodes).

Otherwise we need to setup own BTC full nodes and use those instead of the public network. But that would render the SPV model obsolete and would turn BitcoinJ to a Electrum federated server model. To move to Bitcoin Core SPV mode is our preferred strategy to get rid of those attacks (and the latest features instantly like SegWit), but that requires much more effort and time and I am not sure how good that SPV model really works. Not looked closer so far into it...

So all in all it would be great to get some solid protection from the BitcoinJ library.
And forking off from Bitcoin without proper separation as an altcoin seems to be something we will see more often in future as long it is hurting the ecosystem and therefore serves as an efficient attack.

Br,

Manfred 

[Andreas Schildbach]

On 10/12/2017 08:15 PM, Manfred Karrer wrote:

> > The chain blindness of BitcoinJ is another major concern not
> addressed
> > as far I know and will set BitcoinJ users at risk to spend their
> Bitcoin
> > on a chain which they don't want to support and/or get exposed to
> replay
> > attacks. Very concerning IMO!
>
> I would not say bitcoinj is blind to the chain. It always follows the
> chain with most accumulated work, which is a very specific chain from a
> users point of view.
>
>
> A big problem with that is, that if miners switch between chains (as we
> saw with BCH/BTC) the longest PoW chain might change as well, leading to
> security risks and potential losses. So if today I am following the BTC
> chain and sending you coins and tomorrow the longest PoW chain becomes
> B2X then BitcoinJ will not recognise that tx anymore.

At no point in time has the BCH chain accumulated more work than the
Bitcoin chain (except maybe the first one or two blocks).

> I am tired of those fork attacks and don’t assume they will succeed (as
> all the past attempts) but it consumes valuable dev time to prepare
> strategies how to deal with that menace…

Forks are an important democratic instrument. My personal opinion: We
should not do away with it, even if we could.

> Best would be if there would be some option in BitcoinJ to guarantee to
> stay on one chain

You can enable full verifying mode if you want that, and
implement/bugfix the rules you are concerned about. But anyway, it's
always only one chain.

> (Luke DashJr has recommended one solution a few months
> ago at the last fork attempt. Don’t remember the details but as far I
> remember it was not a huge change, just a small extra check when
> accepting blocks/nodes).

As far as I can remember, his idea is very specialized in that you could
stay with max 1M blocks but you could not use it to stay with max 2M blocks.

A more generalized approach would be to implement detection of a fork
and offer the user to continue to block X or Y ("block pinning"). The
big problem with this is if her decision is wrong, she will end up on a
dying chain and recovery is difficult and costly. I think Electrum has
this implemented recently, we'll see how it plays out.

[Manfred Karrer]

At no point in time has the BCH chain accumulated more work than the
Bitcoin chain (except maybe the first one or two blocks).

Yes, right. But that is not said that it can happen that both chains gets nearly same hash power and miners switch what is more profitable or them (that happened in BCH). And that would render BitcoinJ unusable/insecure. 

> I am tired of those fork attacks and don’t assume they will succeed (as
> all the past attempts) but it consumes valuable dev time to prepare
> strategies how to deal with that menace…

Forks are an important democratic instrument. My personal opinion: We
should not do away with it, even if we could.

Proper forks are ok. Attempts to hijack a brand and a network are a different story. 

Anyone is free to start an altcoin. That is the proper way to do it.

> Best would be if there would be some option in BitcoinJ to guarantee to
> stay on one chain

You can enable full verifying mode if you want that, and
implement/bugfix the rules you are concerned about. But anyway, it's
always only one chain.

That would render SPV pointless to download the full blockchain.

 

> (Luke DashJr has recommended one solution a few months
> ago at the last fork attempt. Don’t remember the details but as far I
> remember it was not a huge change, just a small extra check when
> accepting blocks/nodes).

As far as I can remember, his idea is very specialized in that you could
stay with max 1M blocks but you could not use it to stay with max 2M blocks.

A more generalized approach would be to implement detection of a fork
and offer the user to continue to block X or Y ("block pinning"). The
big problem with this is if her decision is wrong, she will end up on a
dying chain and recovery is difficult and costly. I think Electrum has
this implemented recently, we'll see how it plays out.

How do you deal in Android wallet with it?

[Andreas Schildbach]

On 10/13/2017 03:56 AM, Manfred Karrer wrote:

> How do you deal in Android wallet with it?

Bitcoin Wallet follows the chain with the most accumulated proof of
work. Users can configure a trusted peer if they want to follow a
specific ruleset.