[NMDF] Namecoin Bounty Cornucopia

[phelix]

Winter, what a nice time of the year... sit in front of the fireplace, have a hot cocoa - but stop, there is no time to laze around you need to safe the world from becoming totalitarian hell.

0.5 BTC - Namecoin File Signing
See here

0.5 BTC - Full Namecoin Bitmessage Integration
See GSoC 2015 projects

(0.5 BTC OpenPGP keyserver) phelix is working on it
Fetch GPG keys via id/ (ideally as a plugin to NMControl). thread with early working version

More can be found on the GSoC projects page and on the roadmap.

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 client
Bountysource
Forum thread
NMControl needs to be able to connect. Maintenance of the base code should be discussed up front.

~0.5 BTC - NMControl TLS
.bit TLS certificate validation without Convergence (using NMControl's dns plugin API)
Details on Bountysource


0.1 BTC - Rebrand Namecore (Namecoin Core client)
Replace "Bitcoin" by "Namecoin" (and similar) where appropriate, replace all logos with the new Namecoin logo
Thanks fsb4000! working

Solve the AUXPoW Puzzle
Help implement proof of work secured API calls. (NMC Dev team excluded)

Obsolete:
0.5 BTC - Finish the Armory Port
See GSoC 2015 projects

[biolizard89]

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.

0.1 BTC - Solve the AUXPoW Puzzle
Help implement proof of work secured API calls. (NMC Dev team excluded)

0.1 BTC - Rebrand Namecore (Namecoin Core client)
Replace "Bitcoin" by "Namecoin" (and similar) where appropriate, replace all logos with the new Namecoin logo

0.5 BTC - NMControl: Name GUI for Namecoin Core
This is one of the last building blocks to be able for end users to switch to Namecore (Namecoin Core client)

0.5 BTC - Finish the Armory Port
See GSoC 2015 projects

0.5 BTC - SPV client for NMControl

0.5 BTC - NMControl TLS without convergence

0.5 BTC - Namecoin File Signing
See here

0.5 BTC - Full Namecoin Bitmessage Integration
See GSoC 2015 projects


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.

[domob]

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]

From my point of view the Armory port is not the best way so I included both solutions as a compromise.

[phelix]

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

[biolizard89]

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.

Cheers!

[domob]

[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.

[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.

[domob]

Let me make another bounty suggestion: Implement a OpenPGP keyserver (ideally into NMControl) that can be used to fetch GPG keys via id/.

[biolizard89]

[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.

[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.

[biolizard89]

Let me make another bounty suggestion: Implement a OpenPGP keyserver (ideally into NMControl) that can be used to fetch GPG keys via id/.

ACK.