Some of the bounties are not yet well defined so a post/pm with your plans ahead of time might help mutual understanding and clear specifications. Also if you have your own ideas you are welcome to suggest something.

NMDF will up bountysource bounties to what is promised here.

Done:1.0 BTC - P2P node SPV clientBountysourceForum thread
NMControl needs to be able to connect. Maintenance of the base code should be discussed up front.

phelix wrote:Ahh, what a nice time of the year... sit in the sun, fire up the grill, have a cool drink - but stop, there is no time to laze around you need to safe the world from becoming totalitarian hell.

More can be found here. Most of the bounties are not yet well defined so we will have to add detail as we go. Also if you have other ideas you are welcome to suggest something.

Both the amounts and projects are still open for community discussion.

As far as I know, there was not a consensus on the usefulness of a NMControl name op GUI, or an SPV client in NMControl. My view (and that of of some other people) is that these should be handled using Armory, BitcoinJ, and/or Multibit ports. We don't have a lot of money; we shouldn't be spending it on things that we don't completely agree are productive.

I fully agree with phelix, including the UI bounty. But if you like it better, what about setting the bounty for any usable name op UI (that can be run off a full node, so nothing that forces you to use an Electrum seed or a SPV client)? The goal is to add an alternative to Namecoin-Qt when we switch to Namecoin Core.

phelix wrote:If nobody disagrees strongly (biolizard? we could also remove both the nameGUI and Armory) I would activate this.

Hi phelix!

Sorry for the delay here -- just graduated last night, so I'm officially "back" now.

Here's my thoughts on it, copied from an IRC convo:

[13:41:14] <Jeremy_Rand> AuxPOW API calls -- I believe, but am not sure, that something like Electrum is a better implementation of this idea. Would be good to get confirmation / refutation of that from someone who knows the Electrum design better than I do
[13:41:33] <Jeremy_Rand> Rebranding Namecoin Core, no objection from me
[13:42:57] <Jeremy_Rand> Name GUI and Armory Port -- I would support replacing both of these with a generic bounty for "Name op GUI in any Bitcoin GUI mentioned on bitcoin.org"
[13:43:20] <Jeremy_Rand> (But I do think that Armory is the best way to accomplish that goal)
[13:46:04] <Jeremy_Rand> SPV for NMControl, I would support replacing with a generic bounty for "Implement name_show, name_scan, and name_filter in any Bitcoin client listed on bitcoin.org that supports RPC/REST calls and uses SPV blockchain validation"
[13:49:03] <Jeremy_Rand> TLS -- I would prefer to reword slightly: ".bit TLS certificate validation without Convergence (using NMControl's dns plugin API)"
[13:50:52] <Jeremy_Rand> File signing -- no objection in principle, I do think the spec should be carefully figured out before we offer money for an implementation. E.g. I think having a separate signature file is a worthwhile tradeoff given that it allows more signatures to be made with less blockchain usage
[13:53:02] <Jeremy_Rand> Bitmessage integration -- the bounty should include the requirement of getting a spec vetted before implementing, but other than that no objection

I've got $400 + 0.42 BTC + 21 NMC which I can use to partially reimburse NMDF for these bounties.

biolizard89 wrote:[13:46:04] <Jeremy_Rand> SPV for NMControl, I would support replacing with a generic bounty for "Implement name_show, name_scan, and name_filter in any Bitcoin client listed on bitcoin.org that supports RPC/REST calls and uses SPV blockchain validation"

I don't think that's the bounty we want. For actually adding name_show (name_scan and name_filter are even worse, since they need to know/query for the entire name database and not just a single name!), you need additional stuff like the UNO commitments or some other way to query an "API server" (or full node) for name data and verify it (at least partially) in the block headers. My original proposal for the bounty was to implement just an SPV node (or adapt existing code). Then we can implement such a scheme on top of it once we have it worked out. Also note that I would prefer something that can be integrated in NMControl directly. Even though you could use the external tool as RPC server for NMControl, it would force everyone to install yet another tool.

biolizard89 wrote:[13:50:52] <Jeremy_Rand> File signing -- no objection in principle, I do think the spec should be carefully figured out before we offer money for an implementation. E.g. I think having a separate signature file is a worthwhile tradeoff given that it allows more signatures to be made with less blockchain usage

If you have a separate signature file, you can just use GPG and do not need Namecoin at all.

biolizard89 wrote:[13:46:04] <Jeremy_Rand> SPV for NMControl, I would support replacing with a generic bounty for "Implement name_show, name_scan, and name_filter in any Bitcoin client listed on bitcoin.org that supports RPC/REST calls and uses SPV blockchain validation"

I don't think that's the bounty we want. For actually adding name_show (name_scan and name_filter are even worse, since they need to know/query for the entire name database and not just a single name!), you need additional stuff like the UNO commitments or some other way to query an "API server" (or full node) for name data and verify it (at least partially) in the block headers. My original proposal for the bounty was to implement just an SPV node (or adapt existing code). Then we can implement such a scheme on top of it once we have it worked out. Also note that I would prefer something that can be integrated in NMControl directly. Even though you could use the external tool as RPC server for NMControl, it would force everyone to install yet another tool.

Okay, how about just "Namecoin protocol support (not necessarily name support) for a Bitcoin client listed on bitcoin.org that supports RPC/REST calls and uses SPV blockchain validation"? I don't think it makes sense to require that it be in Python (which I guess is what you mean by "can be integrated in NMControl directly"), because I'm unable to find a currently-maintained Python Bitcoin SPV implementation, and it doesn't seem like a great usage of our resources to maintain one ourselves. It is a near-term goal to have package managers install all the relevant Namecoin tools at once, so I don't think it's a usability problem if the SPV client isn't part of NMControl.

domob wrote:

biolizard89 wrote:[13:50:52] <Jeremy_Rand> File signing -- no objection in principle, I do think the spec should be carefully figured out before we offer money for an implementation. E.g. I think having a separate signature file is a worthwhile tradeoff given that it allows more signatures to be made with less blockchain usage

If you have a separate signature file, you can just use GPG and do not need Namecoin at all.

Well, I think it would be useful to have an NMControl API call that fetches the latest GPG key for an id/ name and checks a file against that key. Otherwise the user has to manually import the key, and make sure that it hasn't been revoked each time he/she uses it.