Get the Namecoin daemon merged #25
Comments
|
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 |
|
-----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-----
|
|
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... |
|
@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? |
|
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 |
@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). |
|
@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. |
|
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. |
|
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? |
|
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. |
|
OK, we've made some progress on this issue as of: b086d9b The next step (I think) is to get the needed libdohj libraries published to a public Maven repo. Right @JeremyRand ? |
msgilligan
changed the title
|
To be more specific: once libdohj is in a public Maven repo (easiest is probably bintray) it should be a roughly 10 line PR. |
|
Since this is not currently a priority for @msgilligan or @JeremyRand (see #69 (comment)) I am going to close this issue. If someone new decides they want to work on a Namecoin daemon, please feel free to open any issues for changes that are needed, etc. |
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!
The text was updated successfully, but these errors were encountered: