Get the Namecoin daemon merged

[JeremyRand]

As you're aware, I made a Namecoin name lookup daemon, loosely based on bitcoinj-daemon. I'd like to work toward getting it upstreamed to bitcoinj-addons, the question is what the best way to do that is, without too much maintenance complexity and code duplication.

My initial inclination is to create a new Git branch of bitcoinj-addons for this purpose, so that changes made to bitcoinj-addons can easily be merged to the Namecoin branch via standard Git merging procedures. I'm pretty sure this is how Coinomi handles altcoin support (though I haven't actually looked at Coinomi's source code for a few months).

An alternative might be to make the bitcoinj-addons programs support network parameters from libdohj via a command-line flag, so that arbitrary libdohj-supported altcoins would work with bitcoinj-addons without any additional changes. (This would still require changes to support name operations in bitcoinj-daemon, either via a Git branch or via an extra module.)

Curious what your thoughts are.

Cheers!

[msgilligan]

Funny you should send this now. I've been thinking about the focus of this project and how to name, structure, and position it going forward. My original intention was to contribute it (or major parts of it) to the bitcoinj project. But bitcoinj is focused solely on Bitcoin and this project already is being used in and/or has components implemented for Bitcoin, Omni, Namecoin, and Ethereum.

Yesterday I was thinking about creating a new Github organization for the project and name it jCrypto or something similar that covers multiple currencies/chains. The goal would be to create reusable components that could be used by as many projects as possible and -- of perhaps greater importance -- attract as many contributions and contributors as possible. Maybe we could even merge in libdohj. I'd love to hear your thoughts on this.

Although, for this immediate issue of merging your code, we can certainly do it right here in this repository.

My suggestion would be to create a new submodule, called namecoin-daemon (or similar) for your daemon. bitcoinj-daemon is only 4 classes (a main Application class, and 3 configuration classes) so the namecoin-daemon could just have its own version of these files. The rest of the Namecoin functionality could be put in one or more Namecoin submodules. Any changes to the existing classes that you need can be addressed on a case-by-case basis, but I'm sure we'll be able to figure out how to create a nice, clean, modern OO architecture to maximize reusability and flexibility. And, yes, I should probably take another look at libdohj to refresh my memory.

[msgilligan]

See also #8 and #14.

[JeremyRand]

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hmm, so I think there are 2 different types of changes here, which might benefit from different treatment. One change is the ability to use altcoin network parameters with the existing bitcoinj-addons codebase. AFAICT most of the bitcoinj-addons codebase is relatively agnostic in nature to what Bitcoin-based network it's being used with, e.g. bitcoinj-daemon could work pretty much as-is if Namecoin, Litecoin, or Dogecoin network parameters (or the testnet or regtest parameters) were used instead of Bitcoin mainnet. I'm not sure whether this is best done as modifications to the existing codebase (e.g. command-line flags to choose network parameters) or if it could more easily be done by creating new submodules that simply subclass the existing classes and replace the network parameters. The other change is the ability to add `name_show` to bitcoinj-daemon. This is a Namecoin-specific feature, so it could indeed be better done as a separate submodule. Might be implementable via aggressively subclassing all the stuff in bitcoinj-daemon and bitcoinj-server, and just adding the needed `name_show` method implementation. Thoughts?

…

-----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJZd/vvAAoJELPy0WV4bWVwaCcP/AwjrpYuH2hQCZ6nWyvWdziM Jyp9+C4rLFKNOLwxH2eTPIIQR9cmxL5DMN5uubd2kPVo4W99wNZKeP6xYai9sOr4 2yndlsvWhwk0XkWhVZpvcVki7DW+po/3yCVvS9+8kzpZRi1gaPyGLM3fb8yAG67R RVQI0VAHhFgJjhF1YizQ1RqZZfsdJvXGNLhEUE1mIhNqpNtqzuFxwZjjF1NtHQWo zjjF8ia2oCdGi44qJfzFG9MQ213rjixbDhXVBAaKXuvwdY3YP+2RGT9jL48xsjTj r6iykW0JuorV2/qLdM6OrM8wgIT6wwD3BFBmw1JgZ3ZEUeXRy5GEcXzor9tV2W8O W92A84qi0cr6RQtLLwfRuLVhYnOxNo0IXCCB+pYO1KTjNXGwJiW4DX69w/vF1MkN 08YcUdl3wVsno5p7dW4tlz6uyrG6871p5wCBvhvYyGa4gtzpr9+H7m8wHF7k8Z9O Y/RBUWCxZntiLADqUrZW3CqzFqSThimhTunfcOUiW2DuHntHD5lep5gIHrmrxXVV ws0IfIMQDwpV9HRHJ8XsSat7Bc3YpMbdpk+ILiOMQuFkxtof4r5TqwiTmq9WWs16 v8C+0r5VkIRNzIGmgEKK8X66kUocfaw1ZYZO4K2y/8i0TOYLcdxxo7VB7in3xxt7 4EWqPJ967WsLXAyNb3+B =atEz -----END PGP SIGNATURE-----

[msgilligan]

Both of these changes sound reasonable. I've already dabbled a bit with (1). For (2) it might be better to use Java interfaces than subclassing and I think we should be able to make it work that way. I also think the Namecoin daemon should have it's own Gradle submodule that builds the final application.

I'm leaning towards renaming this project ConsensusJ, by the way...

[JeremyRand]

@msgilligan Is it okay for libdohj to be added as a dependency to the various existing submodules (so that non-Bitcoin network parameters can be used with them), or should extra submodules be added for this purpose?

[msgilligan]

In general, I believe that modules should have as few dependencies as possible. In fact, the module structure is largely about keeping overall dependencies minimized (and avoiding optional dependencies)

Which modules would need libdohj and what extra modules would need to be created when we add that dependency?

[JeremyRand]

Which modules would need libdohj and what extra modules would need to be created when we add that dependency?

@msgilligan I think it would be whichever modules currently access the Bitcoin mainnet and/or testnet network parameter classes. Libdohj provides alternate network parameters for a few altcoins; I don't think anything else would need libdohj (besides the Namecoin name lookup client, which is out of scope for this question).

[msgilligan]

@JeremyRand You see that we've moved the project to ConensusJ/consensusj -- would you like to be a contributor to/member of this new Github organization?

[JeremyRand]

@JeremyRand You see that we've moved the project to ConensusJ/consensusj -- would you like to be a contributor to/member of this new Github organization?

@msgilligan Sure, sounds good to me.

[msgilligan]

So there's been some activity in bitcoinj that is related to this issue.

First @marvin-we created Issue bitcoinj/bitcoinj#1486 on bitcoinj, then he created a thread Create a separate library that contains those parts which are useful for other Blockchains on the mailing list, and finally he created a project https://github.com/marvin-we/crypto-core to explore the idea.

I respond on his thread and created an issue on the project requesting that we get the changes merged into bitcoinj -- if possible. I think that would ultimately be the best solution for everyone.

[JeremyRand]

In terms of short-term strategy (say, the next few months), does it make sense for me to just continue maintaining my Namecoin fork of ConsensusJ without upstreaming things until we have a clearer picture of how we want things to look long-term? NLnet Foundation is willing to fund me to do some work on my Namecoin fork of ConsensusJ, and one of the things they'd like to fund is for me to get it upstreamed to ConsensusJ. If that's not doable short-term, that's totally fine, I'll just redirect the funding for that particular item to other Namecoin work (we have some flexibility in choosing which things NLnet funds). Thoughts?

[msgilligan]

I think there's a short-term solution to get it merged and we should pursue it.

Separately, it would be nice to see a longer-term solution that solves the deeper issues that @marvin-we and others would like to address.

[msgilligan]

OK, we've made some progress on this issue as of: b086d9b
This is based on the wok from @JeremyRand 's PR: #40 -- even though that PR was not directly merged.

The next step (I think) is to get the needed libdohj libraries published to a public Maven repo. Right @JeremyRand ?