(WIP) Add namecoinj-daemon.

[JeremyRand]

This PR adds a namecoinj-daemon module, which behaves identically to bitcoinj-daemon except that it uses the Namecoin network parameters from libdohj instead of the Bitcoin network parameters from BitcoinJ. I've tried to keep the changes as noninvasive as possible.

[JeremyRand]

Hmm, looks like the Travis checks failed. Wonder why that was... I'll check on it.

[JeremyRand]

Okay, the significant Travis fail is fixed. There's still a dependency fail because libdohj is intended to be loaded from mavenLocal, and Travis's Maven repo doesn't have libdohj manually installed into it.

@msgilligan feel free to review everything else in this PR, and if/when everything else looks ready to merge, I'll deal with the Travis libdohj fail.

[msgilligan]

Hey, @JeremyRand this looks like a great start! I think I can simplify this a little, but if this includes all the changes you need, this is going to be pretty easy to integrate -- and I can take it from here.

So, the only remaining issue to get this to build (on CI) and work is to find (or put) libdohj into a publicly-accessible Maven repo?

[msgilligan]

I've never used https://jitpack.io before, but it might be worth trying.

[msgilligan]

Also, I'd like to address Namecoin packaging with respect to Issue #29 -- I'll ask you some questions on that thread...

[JeremyRand]

Hi @msgilligan,

if this includes all the changes you need, this is going to be pretty easy to integrate

I should note that while this PR includes everything needed to use the Namecoin network parameters, there are additional changes that I'll submit as separate PR's that deal with things like the extra RPC methods for Namecoin, using a BlockStore to store the block headers, and Tor support. I expect that those subsequent PR's will be of a similar invasiveness (or lack thereof) to this PR. But yes, for the specific goal of supporting Namecoin's network parameters (with the same functionality that bitcoinj-daemon currently has), this PR is all that's needed.

So, the only remaining issue to get this to build (on CI) and work is to find (or put) libdohj into a publicly-accessible Maven repo?

As far as I know, that's correct. It builds and runs fine on my local machine that has libdohj pre-installed into the local Maven repo. Maybe there are other issues that CI will turn up after that's fixed, but if so they should be minor.

I've never used https://jitpack.io before, but it might be worth trying.

I'm a little bit conflicted on this. On one hand, the security engineer in me doesn't like adding additional trust anchors to the build process. On the other hand, the "right way" to build ConsensusJ securely is to build all of the transitive dependencies locally in a reproducible VM without Internet access, and since Namecoin intends to do that (once I have time to implement it), it doesn't really matter to me what package repos are listed in the build metadata, since none of those package repos will actually be trusted or used in our releases. So, if you (as the lead ConsensusJ maintainer) are okay with adding another repo to your build process, then I don't think I have any objection here.

[msgilligan]

yes, for the specific goal of supporting Namecoin's network parameters (with the same functionality that bitcoinj-daemon currently has), this PR is all that's needed.

OK, cool. I think I can get the equivalent of this functionality merged in, but in a way that is little less intrusive, with a little less redundant/boilerplate code, and that is more flexible for the namecoinj-daemon.

On one hand, the security engineer in me doesn't like adding additional trust anchors to the build process.

Yeah, that's a good point. It's definitely an issue that we need to solve (see #17, for example)

Also, @JeremyRand did you ever see my 2015 proposal Blockchain-based Trust for Software Components the proposed using Namecoin to solve software supply-chain issue?

[msgilligan]

@JeremyRand I think I can get a simplified version of this merged in this weekend. What I'll do is create a Namecoin-specific configuration that could use libdohj, but continue to use the bitcoinj NetworkParameters so we can get it to build on Travis. Once we have libdohj in a maven repo we can make that change.

Sound like a plan?

[JeremyRand]

@JeremyRand I think I can get a simplified version of this merged in this weekend. What I'll do is create a Namecoin-specific configuration that could use libdohj, but continue to use the bitcoinj NetworkParameters so we can get it to build on Travis. Once we have libdohj in a maven repo we can make that change.

@msgilligan Sounds good to me.

Also, @JeremyRand did you ever see my 2015 proposal Blockchain-based Trust for Software Components the proposed using Namecoin to solve software supply-chain issue?

I wasn't aware of your proposal, but I can recall (going back to circa 2014) informally throwing around the idea of using Namecoin as a component of a binary transparency mechanism. It seems like a cool idea, and I'd love to see more work in that area. Seems like it would be a great fit for a bright student, maybe as a GSoC project or a thesis or something. I'm unlikely to have any free time to pursue such an effort anytime soon -- way too many other dev priorities.

[msgilligan]

Sounds good to me.

I'm on it!

I can recall (going back to circa 2014) informally throwing around the idea of using Namecoin as a component of a binary transparency mechanism.

I actually mention this in the paper.

Hey @JeremyRand are you going to be at Decentralized Web Summit this year? (Maybe we should take this to e-mail...)

[JeremyRand]

Hey @JeremyRand are you going to be at Decentralized Web Summit this year? (Maybe we should take this to e-mail...)

@msgilligan Yep, indeed I will! Would be awesome to meet up again. :)

[msgilligan]

Well I tried to get fancy with a Git interactive rebase and pull the pieces of your PR that I wanted into a new PR, but I got in over my head with Git. But "namecoin-daemon" is in:

• 554d044
• a4df3d8

[msgilligan]

So, let me explain the rationale behind this approach. I think it is better to duplicate a handful of spring config files in the namecoin daemon project than to create two new modules and have the Namecoin daemon depend on the bitcoin daemon.

My intention was for the bitcoinj-daemon project to be a leaf node in the dependency tree and not have anything depend on it. If we end up with a significant amount of duplication between bitcoinj-daemon and the Namecoin daemon we can either put that code in bitcoinj-server or a new module that we create.

I'm also thinking that the Namecoin daemon module is the only one that is more likely to be useful to anyone at this point, so it may be the focus of more development -- at least in the short term.

Sorry, I really meant to make a Pull Request for my proposed changes and give you the chance to review it. If this doesn't make sense or you want change made, let's talk about it.

[msgilligan]

I'm going to do the package renaming I discussed above and then we can continue the conversation under a new or existing issue or a new PR if you want to create one.

[JeremyRand]

Sorry, I really meant to make a Pull Request for my proposed changes and give you the chance to review it. If this doesn't make sense or you want change made, let's talk about it.

I mean, you're the expert on this codebase, whereas I'm just fumbling around in the dark trying to make things work passably. If you think your approach is preferable, that's totally fine with me -- I'm more interested in getting the needed Namecoin functionality upstreamed in some form than in worrying about exactly what form it takes. So, by all means, carry on and tweak the code as much as you like. :)

[JeremyRand]

@msgilligan Am I correct in understanding that the next issue I should file is regarding adding libdohj as a dependency?

[msgilligan]

Let's leave #25 as our long-running issue/thread for getting this merged. And continue the conversation there...