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