[NMDF] Namecoin Bounty Cornucopia

phelix
Posts: 1631
Joined: Thu Aug 18, 2011 6:59 am

Re: [NMDF] Namecoin Spring Bounty Cornucopia [definition]

Post by phelix » Fri May 15, 2015 3:59 pm

biolizard89 wrote: Sorry for the delay here -- just graduated last night, so I'm officially "back" now.
Congratulations!
biolizard89 wrote:
domob wrote:Let me make another bounty suggestion: Implement a OpenPGP keyserver (ideally into NMControl) that can be used to fetch GPG keys via id/.
ACK.
Hmm.. I would prefer a deeper integration so that I only have to deal with IDs.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

phelix
Posts: 1631
Joined: Thu Aug 18, 2011 6:59 am

Re: [NMDF] Namecoin Bounty Cornucopia

Post by phelix » Tue May 19, 2015 3:31 pm

I included the id/ to gpg idea and took this one out as I started working on it myself:
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)
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 1999
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: [NMDF] Namecoin Bounty Cornucopia

Post by biolizard89 » Tue May 19, 2015 3:45 pm

Just a reminder that as far as I can tell, the majority of my feedback from the past few posts has not been addressed.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

phelix
Posts: 1631
Joined: Thu Aug 18, 2011 6:59 am

Re: [NMDF] Namecoin Bounty Cornucopia

Post by phelix » Tue May 19, 2015 4:48 pm

biolizard89 wrote:Just a reminder that as far as I can tell, the majority of my feedback from the past few posts has not been addressed.
oops, I thought everybody was just waiting for me to go forward.

I changed the TLS wording per your suggestion.

SPV - was not my suggestion, but I think there are old but well working implementations in Python

file signing - I know you disagree on this issue but I don't see the problems you described. Please note that I also did compromise on the Armory port. Even the NameGUI is removed now.

Anything else?
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 1999
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: [NMDF] Namecoin Bounty Cornucopia

Post by biolizard89 » Tue May 19, 2015 5:14 pm

phelix wrote:
biolizard89 wrote:Just a reminder that as far as I can tell, the majority of my feedback from the past few posts has not been addressed.
oops, I thought everybody was just waiting for me to go forward.

I changed the TLS wording per your suggestion.
Thanks.
phelix wrote:SPV - was not my suggestion, but I think there are old but well working implementations in Python
Generally, I think using unmaintained code is problematic, particularly when dealing with security-critical and/or consensus-critical systems. What happens when a security bug is found in such an implementation? Have those implementations even gotten any serious security review? (They're not being actively used right now to handle much money, so my guess is they haven't gotten much security review.) What happens when Bitcoin makes changes to their protocol? Would we want to take on the responsibility of modifying those implementations to accommodate Bitcoin's upstream changes? I really think that it would be much better in terms of both security and long term time investment on our part to require that it be based on any non-mobile Bitcoin implementation listed on bitcoin.org. I'm open to making exceptions on a limited, case by case, consensus basis.

As an aside (not strictly relevant to the above point), have you looked at NamecoinJ? It may satisfy the requirements we have (not certain on this), and it's already in use by the Android Namecoin Wallet. BitcoinJ is one of the most well-maintained Bitcoin implementations around, and HashEngineering did the Namecoin port basically as volunteer work. (And I speak as someone who strongly dislikes Java.)
phelix wrote:file signing - I know you disagree on this issue but I don't see the problems you described. Please note that I also did compromise on the Armory port. Even the NameGUI is removed now.
I won't be able to reimburse NMDF on this one, but if Daniel endorses this one I won't object to it being included by NMDF.
phelix wrote:Anything else?
Regarding the auxpow API, I'm curious how the proposal compares to Electrum's current implementation. My understanding is that Electrum uses an API-based system that is backed by PoW as well (including querying multiple API servers to compare). I'd like some confirmation of whether or not Electrum can satisfy the desired use case prior to putting up a bounty for it. See https://forum.namecoin.info/viewtopic.php?f=9&t=2210

Totally as an aside, there's no requirement that we put up all these bounties at once, is there? If there are only a few that still need consensus, we might consider taking the ones that have reached consensus and putting them up sooner.
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

biolizard89
Posts: 1999
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: [NMDF] Namecoin Bounty Cornucopia

Post by biolizard89 » Tue May 19, 2015 11:15 pm

Oh, and just to avoid duplicated effort from anyone who's looking at these bounties -- I am working on the TLS bounty. (Hugo contributed some code that I'm using, so if I claim the bounty, Hugo should get a cut too.)
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

phelix
Posts: 1631
Joined: Thu Aug 18, 2011 6:59 am

Re: [NMDF] Namecoin Bounty Cornucopia

Post by phelix » Wed May 20, 2015 8:33 am

biolizard89 wrote:Oh, and just to avoid duplicated effort from anyone who's looking at these bounties -- I am working on the TLS bounty. (Hugo contributed some code that I'm using, so if I claim the bounty, Hugo should get a cut too.)
Great, noted in OP.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

phelix
Posts: 1631
Joined: Thu Aug 18, 2011 6:59 am

Re: [NMDF] Namecoin Bounty Cornucopia

Post by phelix » Wed May 20, 2015 8:43 am

biolizard89 wrote:
phelix wrote:SPV - was not my suggestion, but I think there are old but well working implementations in Python
Generally, I think using unmaintained code is problematic, particularly when dealing with security-critical and/or consensus-critical systems. What happens when a security bug is found in such an implementation? Have those implementations even gotten any serious security review? (They're not being actively used right now to handle much money, so my guess is they haven't gotten much security review.) What happens when Bitcoin makes changes to their protocol? Would we want to take on the responsibility of modifying those implementations to accommodate Bitcoin's upstream changes? I really think that it would be much better in terms of both security and long term time investment on our part to require that it be based on any non-mobile Bitcoin implementation listed on bitcoin.org. I'm open to making exceptions on a limited, case by case, consensus basis.

As an aside (not strictly relevant to the above point), have you looked at NamecoinJ? It may satisfy the requirements we have (not certain on this), and it's already in use by the Android Namecoin Wallet. BitcoinJ is one of the most well-maintained Bitcoin implementations around, and HashEngineering did the Namecoin port basically as volunteer work. (And I speak as someone who strongly dislikes Java.)
Obviously it would be an advantage to base on well maintained code. What about we say that NMControl needs to be able to somehow connect to the SPV client and that maintenance of the base code needs to be discussed up front?

edit: In the proposal domob does not say it must be in Python.
phelix wrote:file signing - I know you disagree on this issue but I don't see the problems you described. Please note that I also did compromise on the Armory port. Even the NameGUI is removed now.
I won't be able to reimburse NMDF on this one, but if Daniel endorses this one I won't object to it being included by NMDF.
:)
phelix wrote:Anything else?
Regarding the auxpow API, I'm curious how the proposal compares to Electrum's current implementation. My understanding is that Electrum uses an API-based system that is backed by PoW as well (including querying multiple API servers to compare). I'd like some confirmation of whether or not Electrum can satisfy the desired use case prior to putting up a bounty for it. See https://forum.namecoin.info/viewtopic.php?f=9&t=2210
The AuxPOW API would be way lighter than Electrum. Electrum does SPV. (maybe it could be used for the other bounty). Also it's a small bounty only.
Totally as an aside, there's no requirement that we put up all these bounties at once, is there? If there are only a few that still need consensus, we might consider taking the ones that have reached consensus and putting them up sooner.
Nope. But we did not put up bounties for so long I would like to get out a couple. Also I hope that a fancy name and a bunch of bounties gets more attention. :mrgreen:
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

biolizard89
Posts: 1999
Joined: Tue Jun 05, 2012 6:25 am
os: linux

Re: [NMDF] Namecoin Bounty Cornucopia

Post by biolizard89 » Thu May 21, 2015 9:08 am

Sorry for delayed reply -- my house partially flooded with sewage during a rainstorm, so I've been preoccupied with unpleasant things. :(
phelix wrote:
biolizard89 wrote:
phelix wrote:SPV - was not my suggestion, but I think there are old but well working implementations in Python
Generally, I think using unmaintained code is problematic, particularly when dealing with security-critical and/or consensus-critical systems. What happens when a security bug is found in such an implementation? Have those implementations even gotten any serious security review? (They're not being actively used right now to handle much money, so my guess is they haven't gotten much security review.) What happens when Bitcoin makes changes to their protocol? Would we want to take on the responsibility of modifying those implementations to accommodate Bitcoin's upstream changes? I really think that it would be much better in terms of both security and long term time investment on our part to require that it be based on any non-mobile Bitcoin implementation listed on bitcoin.org. I'm open to making exceptions on a limited, case by case, consensus basis.

As an aside (not strictly relevant to the above point), have you looked at NamecoinJ? It may satisfy the requirements we have (not certain on this), and it's already in use by the Android Namecoin Wallet. BitcoinJ is one of the most well-maintained Bitcoin implementations around, and HashEngineering did the Namecoin port basically as volunteer work. (And I speak as someone who strongly dislikes Java.)
Obviously it would be an advantage to base on well maintained code. What about we say that NMControl needs to be able to somehow connect to the SPV client and that maintenance of the base code needs to be discussed up front?

edit: In the proposal domob does not say it must be in Python.
That sounds fine to me.
phelix wrote:
phelix wrote:Anything else?
Regarding the auxpow API, I'm curious how the proposal compares to Electrum's current implementation. My understanding is that Electrum uses an API-based system that is backed by PoW as well (including querying multiple API servers to compare). I'd like some confirmation of whether or not Electrum can satisfy the desired use case prior to putting up a bounty for it. See https://forum.namecoin.info/viewtopic.php?f=9&t=2210
The AuxPOW API would be way lighter than Electrum. Electrum does SPV. (maybe it could be used for the other bounty). Also it's a small bounty only.
Electrum uses an API server to provide the SPV proofs. One of the major objections that was made to the use of standard SPV was that it would require a P2P node, which isn't the case for Electrum. So while Electrum's security level is approximately SPV, I'm not convinced that it's substantially heavier in resource use than the API that you're proposing. Can we get someone knowledgeable with the Electrum codebase/protocol to comment on this?
Jeremy Rand, Lead Namecoin Application Engineer
NameID: id/jeremy
DyName: Dynamic DNS update client for .bit domains.

Donations: BTC 1EcUWRa9H6ZuWPkF3BDj6k4k1vCgv41ab8 ; NMC NFqbaS7ReiQ9MBmsowwcDSmp4iDznjmEh5

phelix
Posts: 1631
Joined: Thu Aug 18, 2011 6:59 am

Re: [NMDF] Namecoin Bounty Cornucopia

Post by phelix » Thu May 21, 2015 12:08 pm

biolizard89 wrote:Sorry for delayed reply -- my house partially flooded with sewage during a rainstorm, so I've been preoccupied with unpleasant things. :(
phelix wrote:
biolizard89 wrote:
phelix wrote:SPV - was not my suggestion, but I think there are old but well working implementations in Python
Generally, I think using unmaintained code is problematic, particularly when dealing with security-critical and/or consensus-critical systems. What happens when a security bug is found in such an implementation? Have those implementations even gotten any serious security review? (They're not being actively used right now to handle much money, so my guess is they haven't gotten much security review.) What happens when Bitcoin makes changes to their protocol? Would we want to take on the responsibility of modifying those implementations to accommodate Bitcoin's upstream changes? I really think that it would be much better in terms of both security and long term time investment on our part to require that it be based on any non-mobile Bitcoin implementation listed on bitcoin.org. I'm open to making exceptions on a limited, case by case, consensus basis.

As an aside (not strictly relevant to the above point), have you looked at NamecoinJ? It may satisfy the requirements we have (not certain on this), and it's already in use by the Android Namecoin Wallet. BitcoinJ is one of the most well-maintained Bitcoin implementations around, and HashEngineering did the Namecoin port basically as volunteer work. (And I speak as someone who strongly dislikes Java.)
Obviously it would be an advantage to base on well maintained code. What about we say that NMControl needs to be able to somehow connect to the SPV client and that maintenance of the base code needs to be discussed up front?

edit: In the proposal domob does not say it must be in Python.
That sounds fine to me.
Changed the OP. I called it P2P SPV that is what Domob originally suggested and because of the discussion below.
phelix wrote:
phelix wrote:Anything else?
Regarding the auxpow API, I'm curious how the proposal compares to Electrum's current implementation. My understanding is that Electrum uses an API-based system that is backed by PoW as well (including querying multiple API servers to compare). I'd like some confirmation of whether or not Electrum can satisfy the desired use case prior to putting up a bounty for it. See https://forum.namecoin.info/viewtopic.php?f=9&t=2210
The AuxPOW API would be way lighter than Electrum. Electrum does SPV. (maybe it could be used for the other bounty). Also it's a small bounty only.
Electrum uses an API server to provide the SPV proofs. One of the major objections that was made to the use of standard SPV was that it would require a P2P node, which isn't the case for Electrum. So while Electrum's security level is approximately SPV, I'm not convinced that it's substantially heavier in resource use than the API that you're proposing. Can we get someone knowledgeable with the Electrum codebase/protocol to comment on this?
By lighter I did not mean resource use but complexity of the implementation.

But I learned something: Is Electrum's SPV (thin-client) implementation not P2P (as opposed to Multibit's)? - turns out also Electrum's SPV is not P2P. Electrum does API server SPV whereas Multibit does P2P node SPV. Hmm...

edit:
Sorry to hear about the flood. Sounds horrible.

BTW: Solving the AuxPOW puzzle would also help the Electrum-NMC implementation.
nx.bit - some namecoin stats
nf.bit - shortcut to this forum

Post Reply