Page 1 of 1

Proposal for bounty: SPV client in NMControl

Posted: Wed Apr 15, 2015 7:35 pm
by domob
(Not sure if this should be public instead, feel free to move it.)

I propose to put up a development bounty for a NMControl module/plugin/whatever that implements an "SPV client" - i. e., is able to connect to the P2P network and determine the longest chain with verified proof-of-work. This can then be used as a basis for "safer" API queries, e. g. by verifying the Merkle branch of returned name_update transactions and, in the future, the UNO commitment. (These could be separate bounties added on top.) In particular, I suggest that the following tasks must be fulfilled:
  • Ideally implemented in Python, should at least be easily added to NMControl. The user must be able to turn the new functionality on by something simple and without much configuration, like just adding a command-line flag to nmcontrol.
  • The code must be released under a free license and, in particular, be compatible with NMControl's licensing.
  • Discovery of new peers from the existing DNS seeds.
  • Handshake with nodes, including not setting the "network" service bit.
  • Exchange of node IPs so that more peers can be discovered without the DNS seeds. These should be saved locally to avoid the DNS seeds in the future, like the core client does.
  • Client must sync and stay up-to-date with respect to all block headers seen on the network, and be able to verify proof-of-work (including auxpow) to determine the longest chain.
  • For these block headers (and blocks), the client must be able to find basic information. In particular, at least the Merkle root hash and the coinbase tx. (The latter is not part of the block header and should be queried from the network (at least on demand), including verification of its Merkle branch.)
  • It must be possible to configure the client to do everything over Tor.
I'm not really experienced with the networking side of the client, so I can't fully judge how much work that is. But I think there should already be something available to adapt from Bitcoin, and even writing everything from scratch should not be too hard. On the other hand, I think that such a feature would be tremendously useful for future light clients. (Including API servers that return a Merkle branch that can be verified, which would work already now without any fancy changes to the network!) I suggest to use some of the NMDF / FSM or other funds to put up a bounty. Thoughts?

Re: Proposal for bounty: SPV client in NMControl

Posted: Wed Apr 15, 2015 9:43 pm
by biolizard89
There is a Python Bitcoin SPV client: https://github.com/sarchar/pyspv. However, it is unmaintained, which I think is a dealbreaker.

I would suggest NamecoinJ by HashEngineering as a starting point. https://github.com/HashEngineering/namecoinj

Adding a JSON-RPC server using NamecoinJ would probably not be too hard, and there is an example implementation for BitcoinJ: https://github.com/TBoehm/bitcoinj-service. NMControl could access NamecoinJ via RPC. (You could also use Jython, which BitcoinJ devs suggest. However I'd prefer to remain agnostic on Python implementation.)

I believe NamecoinJ/BitcoinJ supports most or all of the requirements you listed.

I would be potentially willing to put up a bounty with FSM funds for a NamecoinJ JSON-RPC server that implements name_show, which seems to be the main thing we're going for. If funds are leftover, I'd be potentially willing to put up a bounty for checking coinbase commitments in NamecoinJ with name_show.

(I think this thread should be in the main forum.)

Re: Proposal for bounty: SPV client in NMControl

Posted: Thu Apr 16, 2015 5:17 am
by domob
Sounds good, although NamecoinJ seems to be a bit "heavy" for the task ... running a JVM is not really "thin". Most of NamecoinJ is unnecessary to "just" check PoW. However, I'm not objecting if others agree that this is the way to go and that it will be a good basis to implement light resolvers and all that (that's your expertise). Maybe the bounty should then be to package NamecoinJ in such a way that it can be easily distributed and hooked onto NMControl? (If that's not already the case.) Plus, of course, name_show as you mention - without a local database, but instead requesting and verifying the corresponding Merkle branch.

Re: Proposal for bounty: SPV client in NMControl

Posted: Fri Apr 17, 2015 12:27 pm
by phelix
There certainly should be something that one can fork from:

https://github.com/jgarzik/pynode
https://github.com/amiller/pynode/tree/spv

Re: Proposal for bounty: SPV client in NMControl

Posted: Mon Apr 20, 2015 4:38 am
by biolizard89
phelix wrote:There certainly should be something that one can fork from:

https://github.com/jgarzik/pynode
https://github.com/amiller/pynode/tree/spv
Like PySPV (which I mentioned above), both of those repos are unmaintained (last commit is in 2013). BitcoinJ is very actively maintained and is used in existing major wallets, which reduces the effort we would need to put into it compared to PySPV or PyNode. I would not be comfortable entrusting our end users' security to PySPV or PyNode.

Re: Proposal for bounty: SPV client in NMControl

Posted: Mon Feb 29, 2016 9:07 am
by somename
What is the status of this (SPV in NMControl or standalone) bounty?

Re: Proposal for bounty: SPV client in NMControl

Posted: Tue Mar 01, 2016 12:39 pm
by biolizard89
somename wrote:What is the status of this (SPV in NMControl or standalone) bounty?
See the Cornucopia thread for the bounty on this subject. It is likely that I will claim it soon, as I basically have a BitcoinJ port working.