Jump to: navigation, search

GSoC 2016 Project Ideas

Revision as of 15:15, 18 January 2016 by Josephbisch (Talk | contribs)

Namecoin intends to apply for Google Summer of Code 2016 as a mentor organization.

This Ideas Page is still under construction, and contains some relics from 2015. Check back soon for updates.

If you are interested in working on one of the following projects, get in touch with us! For low-latency discussion, many of our developers can be reached via #namecoin-dev on Freenode IRC (we also are present in #namecoin). If you're not able to get an answer on there (which is possible, since several of our developers won't be able to respond during class or work), please post in the forum. If you have your own ideas for good Namecoin projects, we would love to hear them and support you with those, too!

Should we remove domob from the "possible mentor" list? --Biolizard89 (talk) 06:40, 5 January 2016 (UTC)

Check whether we have additional mentors whom we can list. --Biolizard89 (talk) 08:42, 5 January 2016 (UTC)





Expected outcomes/Deliverables

Possible mentors

Light Client

Namecoin needs a light client, which can be used to get name values trustlessly but without the need to store the full blockchain. There are multiple possible ideas to tackle this, depending on your interests and likes. One is to implement an SPV client for Namecoin, similar to what is described already in the Bitcoin whitepaper and what is implemented by BitcoinJ. You may find HashEngineering's NamecoinJ helpful. Another idea is to ignore transactions and blocks older than 36,000 blocks, since those cannot have current name transactions. Adding wire protocol commands is totally fine if it helps you in accomplishing this. However, we do not wish to add coinbase commitments (e.g. the UTXO set) until Bitcoin does so. You are free to propose a programming language of your choice as well as your own ideas for implementing a light client and discuss your choice with the community. You may find the following writeups by Hugo interesting: Namecoin Node Types and State of Namecoin.

Should we remove the criticism of coinbase commitments? Daniel is doing UNO coinbase commitments without waiting for Bitcoin. --Biolizard89 (talk) 06:37, 5 January 2016 (UTC)

I would say so, given it is something we are going ahead with. --Josephbisch (talk) 15:15, 18 January 2016 (UTC)

Should we mention that BitcoinJ might be willing to merge altcoin-enabling abstractions? Should we mention Coinomi? --Biolizard89 (talk) 06:37, 5 January 2016 (UTC)

Might motivate some individuals if they know that their work may be merged into the larger BitcoinJ. So I think that should be mentioned. Looks like Coinomi supports Namecoin, but just currency transactions. I guess we could mention that too, but I don't know if Coinomi has much of a user base? Maybe we can get some idea of how popular it is. The GitHub numbers seem kind of low, but that isn't necessarily a good measure of usage of the software by end-users. --Josephbisch (talk) 15:15, 18 January 2016 (UTC)


Excellent understanding of how Bitcoin and Namecoin work, good ability to design your own software project architecture.

A light client that is installable and supports all Namecoin transaction types.

domob, Ryan?, Jeremy

Name/Value Encryption

Right now, all names and values are easily enumerable by the public, which is bad for privacy in certain applications (e.g. someone wants to link their email address with a GPG key without making that email address public). Develop a reliable protocol for encrypting and/or obfuscating names and/or values in the blockchain, to improve privacy, and implement it. Some first ideas were already given by gmaxwell, and others have been brought up in discussions, such as this proposal by Jeremy. We first need to decide on a good system based on your ideas and proposals, and then you need to implement that into Namecoin.

Note that if your proposal requires changes to the consensus rules (e.g. storing hashes of names instead of names), you will probably only be implementing them on a testnet (for merging into mainnet once sufficient review has occurred).

Can everyone confirm that this is still desirable? I believe that it is. --Biolizard89 (talk) 07:54, 5 January 2016 (UTC)

I will leave this for others to comment on. --Josephbisch (talk) 15:15, 18 January 2016 (UTC)


Good knowledge about cryptography. Depending on your proposal, excellent understanding of the Bitcoin/Namecoin code-base and internals may (or may not) be necessary. We expect that NMControl-based proposals will be easier for students than Namecoin Core-based proposals.

Should we rephrase the above to make clear that ncdns is okay as an alternative to NMControl? --Biolizard89 (talk) 07:54, 5 January 2016 (UTC)

Yes --Josephbisch (talk) 15:15, 18 January 2016 (UTC)

Your encryption system implemented into the Namecoin client or NMControl.

Should we rephrase the above to make clear that ncdns is okay as an alternative to NMControl? --Biolizard89 (talk) 07:54, 5 January 2016 (UTC)

Yes --Josephbisch (talk) 15:15, 18 January 2016 (UTC)

domob, Ryan?, Jeremy

Anonymity and Taint Analysis Tools

Namecoin suffers the same problems with traceability (lack of anonymity) of coin flows that Bitcoin does. When Namecoin is used for its stated purpose to provide censorship-resistant browsing and registration of domains for possibly controversial purposes (e.g. under repressive regimes), this may be even a bigger problem than with Bitcoin. Unfortunately, there is not a good way for these users to easily evaluate what information is leaking to statistical and graph theory attackers. You can think of ways to improve this, possibly by implementing "taint analysis" similar to what Blockchain.info does. Remember that names carry more data than currency transactions, and thus a Namecoin taint analyzer can be much more effective. For example, learning that the same individual probably controls two given names, one of which has publicly traceable ownership data in its value (e.g. an IP address), may reveal a lot. We are particularly interested in helping users learn about potential anonymity implications of their actions *before* they issue a transaction, although this is not a strict requirement for this project.

Are we in agreement that this is still desirable? I believe that it is. --Biolizard89 (talk) 08:02, 5 January 2016 (UTC)

The Open Bitcoin Privacy Project (mostly run by Kristov Atlas and Justus Ranvier) may be a relevant source of expertise. --Biolizard89 (talk) 08:02, 5 January 2016 (UTC)

Are we in agreement that Zerocash is sufficiently immature that it shouldn't be mentioned here? --Biolizard89 (talk) 08:02, 5 January 2016 (UTC)


Knowledge of Bitcoin's anonymity properties/attacks.

A working tool for helping Namecoin users analyze their anonymity or taint.

domob, Ryan?, Jeremy

Renewal Keys

Right now it is not possible to securely delegate renewal permissions for a name without also delegating alteration and transfer permissions for that name. This is because renewal is the same blockchain operation as alteration: name_update (which is analogous to spending a standard coin). You can fix this by creating, testing, and deploying pubkey scripts which allow two keys to spend a name, with one of the keys being restricted to spending the name in a way that produces the same pubkey script.

You may have to extend Namecoin's script system with an additional opcode; this is acceptable, as long as the result is a softfork (only 51% of miners have to upgrade), not a hardfork (100% of users must upgrade). Note that if your project requires changes to the consensus rules, you will be implementing on a testnet. Merging to mainnet will occur later after sufficient review has occurred.

Are we in agreement that this is still desired? I believe it is. --Biolizard89 (talk) 08:16, 5 January 2016 (UTC)

Should we make it clear that the implementation outlined at the end of the first paragraph is a suggestion and not a requirement? I.e. if someone can find another way to do renewal keys that is in some way superior, we shouldn't automatically reject it. --Biolizard89 (talk) 08:16, 5 January 2016 (UTC)

Is "no hardfork" a hard requirement, or just something that's highly desirable? IMHO if a compelling case can be made that a hardfork offers better functionality, we shouldn't automatically reject it. --Biolizard89 (talk) 08:16, 5 January 2016 (UTC)


Very good knowledge of Bitcoin or Namecoin's script system.

A working proof-of-concept of delegating renewal permissions.

domob, Ryan?

Armory Port

Finish implementing Namecoin support in Armory (including name operations), so that users can take advantage of its advanced features (in particular, cold storage / offline transactions) both for secure storage of NMC as well as names. Joseph Bisch did some preliminary basic Namecoin support (without any Namecoin-specific transaction types), so it can be helpful to take a look at his work.

I suggest removing this due to ATI indefinitely suspending free software development in August 2015. Maybe consider merging with the Light Client section and just say "port a Bitcoin client to Namecoin", with any currently unported client that's on bitcoin.org except for Armory being okay? --Biolizard89 (talk) 08:26, 5 January 2016 (UTC)


Good understanding of how Namecoin works (particularly names and the associated transaction types), C++ and Python experience for hacking on Armory. Some knowledge of the Armory codebase is helpful, but not necessary.

An installable version of Armory that supports Namecoin specific transaction types and the display/storage/transfer of names through the GUI. It is not necessary for the changes to be merged upstream.


Block Explorer

Create a Namecoin block explorer with support for names. This would preferably be done by modifying an existing Bitcoin block explorer. Ryan suggests Insight (source code here), but you're welcome to pick your own choice. By itself, this may be too small of a project, so you may wish to combine with parts of the taint analysis project listed above. A fork detector would also be a useful feature to add.

Opinions on whether this is still relevant? mhanne has a free software block explorer with name support. What's the effort level and benefit of Insight? --Biolizard89 (talk) 08:33, 5 January 2016 (UTC)


Experience with web development and design, possibly Ajax.

A deployable block explorer with support for names.

domob, Ryan?

File Signing & Verification

Namecoin can provide an excellent base for signing files (like software releases) and verifying their integrity, e.g. in combination with GPG. Implement a tool that handles this, both for signers and users just wanting to verify their downloads (should be easy to use for them). You can propose a programming language / toolkit to use for this project. There exists already some code to interface to the Namecoin API over JSON-RPC for some languages (C++, Python, PHP), and it is easy to do from others as well.

Is this still relevant? --Biolizard89 (talk) 08:40, 5 January 2016 (UTC)


Ability to design and develop your own software project, skills in designing an easy-to-use and cross-platform UI. Basic understanding of how Namecoin works.

Installable/runnable software in at least one programming language that handles the workflow for both signers and verifiers for the Namecoin-based signing/verification of files.

domob, phelix?

Secure Public Key Distribution

Namecoin is very well suited to distribute any type of "public key" for human-readable names / online identities. This has already been taken advantage of for Bitmessage, and a proof-of-concept implementation for OTR fingerprints in Pidgin exists, too. Think about other possible uses (e. g., Bitcoin addresses in wallet software like Electrum, or GPG keys) and implement them.

Is this still relevant? I vaguely recall that Phelix has been working on GPG stuff? --Biolizard89 (talk) 08:40, 5 January 2016 (UTC)


Knowledge about the particular use-case and tool where you want to add Namecoin support, and basic understanding of Namecoin and public key crypto systems.

Software that supports the distribution of public keys in a secure way using Namecoin.


Full Bitmessage Integration

Bitmessage has already some support for Namecoin IDs by Domob. It should be extended in a way that in the GUI all bitmessage addresses that have corresponding Namecoin IDs (/id namespace) will be replaced by the IDs. To do so it will be necessary to securely lookup both ways id-->address, address-->id so it will be necessary to do some cross signing and storing the signature in the id or an additional name that can be found directly via the address. To be accepted upstream it would be helpful if it could fall back to addresses only if no name data source can be found.

Is Bitmessage still maintained? I don't see any releases on their site in over a year. --Biolizard89 (talk) 08:40, 5 January 2016 (UTC)

Seems to not be maintained any more. I say we drop this idea. --Josephbisch (talk) 15:15, 18 January 2016 (UTC)


Python, PyQt GUI, scripting with signatures and namecoin

Bitmessage with Namecoin IDs


Your Own Namecoin Use or Enhancement

Namecoin can be used for lots of novel and interesting use cases, and existing use cases are open for improvement. Propose your own use case or improvement, and discuss it with us!





New 2016 project ideas: Tor hidden service naming. I2P hidden service naming. IP-based .bit naming while using Tor/I2P. TLS implementation improvements. Segregated name values. --Biolizard89 (talk) 06:57, 5 January 2016 (UTC)