Thanks for sharing your thoughts, good pointers and very interesting discussion.
biolizard89 wrote:So, having the code written in Javascript probably isn't necessary. If we did want it to run as JS, using Emscripten would probably be better than hand-writing a bunch of Javascript code.
I agree. No need to implement a full NameCoin client in JavaScript. That would be silly. That being said, altering the NameCoin protocol in such a way that lightweight clients written in JavaScript can reliably verify names using a trustless intermediary would open enormous possibilities.
I was thinking for a while and get increasingly convinced as I think more that the concept NameCoin client software being hard dependency for any application utilizing NameCoin severely restricts the use.
Pure JavaScript applications are easy to deliver through extension stores. I imagine some creative uses of reliable name lookup even in a context of HTML/JS pages/apps. All of that requires either pure JavaScript client or support for "lookup" in the browser. I'm not sure that mainstream browser support for NameCoin lookup is possible without mass adoption, which, in turn, seems to be best attainable through web apps and extensions.
biolizard89 wrote:
Generally, it's easier to modify Bitcoin code than to write Namecoin code from scratch. Given that maaku and others have been working on UTXO code, I think it's a good idea to let them handle those details. The worst possible outcome would be if we adopted something on our own, Bitcoin adopted something better 3 months later, and we had to hardfork to be able to merge Bitcoin's version.
Yes, it makes lots of sense... I wish the BitCoin UTXO was progressing faster. After I've looked at maaku blog I realized that I've seen it some time ago. It seems like the progress is quite slow. I should say that BitCoin UTXO is substantially more complex and pursues slightly different goal than the ultimate NameCoin UTXO:
a. from bitcoin perspective no transaction is ever expired, i.e. all unspent transactions need to be part of UTXO tree. That's not the case with NameCoin.
b. NameCoin has much higher standard of verification robustness. BitCoin SPV client can afford to be fooled assuming the potential loss is acceptable or if there are other, out-of-band mechanisms to recover from failure. Example: BitCoin SPV accepts payment of X coins to sell a video card. It is ok for SPV+UTXO client to mistakenly accept a spent output, assuming full validation is done later, before the card is shipped. With NameCoin the mistake is almost always not recoverable. Example: there is nothing I can do to recover from using the wrong PGP key to send an E-mail to someone due to SPV+UTXO weakness exploited by malicious third party. My main point is that what BitCoin community may adopt for SPV+UTXO is not necessarily and, in fact, likely, not to be "THE SOLUTION" for NameCoin. Would you agree?
Lastly, I should say that I did not mean to put up a proposal for someone else to implement. The idea was rather to build the proposed solution if the community is willing to take it in, assuming satisfactory quality and robustness.