On Friday, September 29, 2017 at 4:08:30 PM UTC-5, Andreas Schildbach wrote: > > On 09/29/2017 09:39 PM, quantu...@gmail.com <javascript:> 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> > > > > > > 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. > > > > On Fri, Sep 29, 2017 at 4:59 AM, <quantu...@gmail.com> wrote: > > > > 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. > > > > -- > > 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+u...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout > > <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). > > 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. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
