@ slaveforanunnak1
While we are still on the blog comments, here is a Szabo comment that made me realize a small difference of opinion between Szabo and Satoshi. It's about the use of the term Cryptocurrency.
*Satoshi used the term Cryptocurrency.
Quote from: satoshi on July 06, 2010, 06:32:35 PM
"Announcing version 0.3 of Bitcoin, the P2P cryptocurrency!"
*In 2011 Szabo still would not use the term Cryptocurrency.
Szabo Quote: from 2011
"And what's up with the term "cryptocurrency"? What is it supposed to mean? Cryptography is used to protect payments systems as radically different as credit cards, Chaumian digital cash, and Bitcoin. The term encourages the popular but profoundly naive view of Bitcoin as merely another form of digital cash."
Note: could be a misdirection by Szabo or maybe a sign of the doppelganger theory. It may not mean anything, just something I noticed.
While we are still on the blog comments, here is a Szabo comment that made me realize a small difference of opinion between Szabo and Satoshi. It's about the use of the term Cryptocurrency.
*Satoshi used the term Cryptocurrency.
Quote from: satoshi on July 06, 2010, 06:32:35 PM
"Announcing version 0.3 of Bitcoin, the P2P cryptocurrency!"
*In 2011 Szabo still would not use the term Cryptocurrency.
Szabo Quote: from 2011
"And what's up with the term "cryptocurrency"? What is it supposed to mean? Cryptography is used to protect payments systems as radically different as credit cards, Chaumian digital cash, and Bitcoin. The term encourages the popular but profoundly naive view of Bitcoin as merely another form of digital cash."
Note: could be a misdirection by Szabo or maybe a sign of the doppelganger theory. It may not mean anything, just something I noticed.
Interesting. I'm starting to look more closely at Zooko
That's why I'm thinking he may have been the coder only. He was definitely posting about BitCoin on January 26 2009. He had the time to do the work. He knew the right people. He lived and worked in that circle.
Note: Where was Jim McCoy located in 2008-2009? Still in Texas?
Szabo also seemed to be mentoring that young Blogger Byrne during the Times we have been looking at. In fact Szabo's call for help was in a response to Byrne's post.
http://unenumerated.blogspot.com/2008/04/bit-gold-markets.html?m=1
http://www.byrnehobart.com/blog/
http://financialcryptography.com/mt/archives/000571.html (with apologies for quoting all, found while on the hunt to address what's asked of us quoted above)
Quote
Financial Cryptography
Where the crypto rubber meets the Road of Finance...
« It's official - doing due diligence is a criminal offence! | Main | eBay migrates to the Payments business »
October 12, 2005
The Mojo Nation Story
[Guest post by Steve Schear] Mojo Nation was the brainchild of Jim McCoy (then formerly of Yahoo) and Doug Barnes (then formerly of C2Net). Their vision was a fully distributed peer-to-peer network with a financial mechanism that offered efficient cost recovery and discouraged the free-riding known to P2P people as leeching (a problem that continues to plague P2P).
The most radical element of MN was its method of pricing all activities in terms of network resources. It was also one of the first attempts at a P2P network using a fully distributed approach and a publishing versus a file sharing metaphor.
Unfortunately, MN was never fully operational. It never reached a point of deployment that allowed many of its novel architectural and technological assumptions, especially the mint, to be truly tested. It's not clear what economic lessons to draw from its operational vision, but here are some of the reasons behind its business failure:
- MN failed because it failed to get continued funding. It only received seed money from its founder, Jim McCoy. MN was in development before Napster but its greater complexity caused a delayed public release. Jim had the foresight to thoroughly investigate the legal aspects of P2P and architecture MN to segregate tracking and file storage and distance itself from either. Nevertheless, Napster's negative publicity closed the door on VC funding and development beyond beta testing.
- It failed because the UI never reached a point of maturity that enabled mostly automated meta-data tags (e.g., from mp3) to be generated from published content. This required users to tediously enter this data (and re-enter it when they were forced to republish, see below).
- It failed because software instabilities prevented its distributed servers from accumulating and retaining enough content and becoming stable (network effects). This instability required constant, manual, republishing of content by users who soon fatigued (user churn).
The most notable result from MN was Bram's Bit Torrent. Though, as we saw, Bram failed to heed warnings (and discussion at MN) about protecting the trackers until the MPAA/RIAA were able to shut many down. Its been reported that many of these shortcomings have been fixed but I still can't seem to get Azureus (the most popular BT client) to work as expected with the distributed tracking. Since the demise of eDonkey, et al, due to the MGM vs. Grokster BT has been given a shot at reassuming the P2P leadership mantle. I hope it succeeds. Or perhaps P2P's next growth will have to wait until enough its users discover the advantages of an anonymizing transport layers, like TOR and I2P.
Steve
Addendum: see Part 2 from Jim McCoy himself.
Posted by iang at October 12, 2005 08:22 AM | TrackBack
Comments
Bram didn't fail to heed warnings about attacks on trackers; he knew about them full well and would frequently explain them to people who wanted to use BitTorrent for illegal activities. Bram, as I understand it, didn't believe in making any software design changes for the sole purpose of supporting illegality.
Posted by: Aaron Swartz at October 18, 2005 05:30 PM
Where the crypto rubber meets the Road of Finance...
« It's official - doing due diligence is a criminal offence! | Main | eBay migrates to the Payments business »
October 12, 2005
The Mojo Nation Story
[Guest post by Steve Schear] Mojo Nation was the brainchild of Jim McCoy (then formerly of Yahoo) and Doug Barnes (then formerly of C2Net). Their vision was a fully distributed peer-to-peer network with a financial mechanism that offered efficient cost recovery and discouraged the free-riding known to P2P people as leeching (a problem that continues to plague P2P).
The most radical element of MN was its method of pricing all activities in terms of network resources. It was also one of the first attempts at a P2P network using a fully distributed approach and a publishing versus a file sharing metaphor.
Unfortunately, MN was never fully operational. It never reached a point of deployment that allowed many of its novel architectural and technological assumptions, especially the mint, to be truly tested. It's not clear what economic lessons to draw from its operational vision, but here are some of the reasons behind its business failure:
- MN failed because it failed to get continued funding. It only received seed money from its founder, Jim McCoy. MN was in development before Napster but its greater complexity caused a delayed public release. Jim had the foresight to thoroughly investigate the legal aspects of P2P and architecture MN to segregate tracking and file storage and distance itself from either. Nevertheless, Napster's negative publicity closed the door on VC funding and development beyond beta testing.
- It failed because the UI never reached a point of maturity that enabled mostly automated meta-data tags (e.g., from mp3) to be generated from published content. This required users to tediously enter this data (and re-enter it when they were forced to republish, see below).
- It failed because software instabilities prevented its distributed servers from accumulating and retaining enough content and becoming stable (network effects). This instability required constant, manual, republishing of content by users who soon fatigued (user churn).
The most notable result from MN was Bram's Bit Torrent. Though, as we saw, Bram failed to heed warnings (and discussion at MN) about protecting the trackers until the MPAA/RIAA were able to shut many down. Its been reported that many of these shortcomings have been fixed but I still can't seem to get Azureus (the most popular BT client) to work as expected with the distributed tracking. Since the demise of eDonkey, et al, due to the MGM vs. Grokster BT has been given a shot at reassuming the P2P leadership mantle. I hope it succeeds. Or perhaps P2P's next growth will have to wait until enough its users discover the advantages of an anonymizing transport layers, like TOR and I2P.
Steve
Addendum: see Part 2 from Jim McCoy himself.
Posted by iang at October 12, 2005 08:22 AM | TrackBack
Comments
Bram didn't fail to heed warnings about attacks on trackers; he knew about them full well and would frequently explain them to people who wanted to use BitTorrent for illegal activities. Bram, as I understand it, didn't believe in making any software design changes for the sole purpose of supporting illegality.
Posted by: Aaron Swartz at October 18, 2005 05:30 PM
http://financialcryptography.com/mt/archives/000572.html
Quote
October 12, 2005
The Mojo Nation Story - Part 2
[Jim McCoy himself writes in response to MN1] Hmmm..... I guess that I would agree with most of what Steve said, and would add a few more datapoints.
Contributing to the failure was a long-term vision that was too complex to be implemented in a stepwise fashion. It was a "we need these eight things to work" architecture when we were probably only capable of accomplishing three or four at any one time. Part of this was related to the fact the what became Mojo Nation was originally only supposed to be the distributed data storage layer of an anonymous email infrastructure (penet-style anonymous mailboxes using PIR combined with a form of secure distributed computation; your local POP proxy would create a retrieval ticket that would bounce around the network and collect your messages using multiple PIR calculations over the distributed storage network....yes, you can roll your eyes now at how much we underestimated the development complexity...)
As Bram has shown, stripping MN down to its core and eliminating the functionality that was required for persistent data storage turned out to create a pretty slick data distribution tool. I personally placed too much emphasis on the data persistence side of the story and the continuing complexity of maintaining this aspect was probably our achilles heel, if we had not focused on persistence as a design goal and let it develop as an emergent side-effect things might have worked but instead it became an expensive distraction.
In hindsight, it seems that a lot of our design and architecture goals were sound, since most of the remaining p2p apps are working on adding MN-like features to their systems (e.g. combine Tor with distributed-tracker-enabled BitTorrent and you are 85% of the way towards re-creating MN...) but the importance of keeping the short- term goal list small and attainable while maintaining a compelling application at each milestone was a lesson that I did not learn until it was too late.
I think that I disagree with Steve in terms of the UI issues though. Given the available choices at the time we could have either created an application for a single platform or use a web-based interface. The only cross-platform UI toolkit available to us at the time (Tk) was kinda ugly and we didn't have the resources to put a real UI team together. If we were doing this again today our options would include wxWidgets for native UI elements or AJAX for a dynamic web interface, but at the time a simple web browser interface seemed like a good choice. Of course, if we had re-focused on file-sharing instead of distributed persistent data storage we could have bailed on Linux & Mac versions and just created a native win32 UI...
The other point worth mentioning is that like most crypto wonks, we were far too concerned with security and anonymity. We cared about these features so we assumed our users would as well; while early adopters might care the vast majority of the potential user base doesn't really care as much as we might think. These features added complexity, development time, and a new source of bugs to deal with.
Jim
The Mojo Nation Story - Part 2
[Jim McCoy himself writes in response to MN1] Hmmm..... I guess that I would agree with most of what Steve said, and would add a few more datapoints.
Contributing to the failure was a long-term vision that was too complex to be implemented in a stepwise fashion. It was a "we need these eight things to work" architecture when we were probably only capable of accomplishing three or four at any one time. Part of this was related to the fact the what became Mojo Nation was originally only supposed to be the distributed data storage layer of an anonymous email infrastructure (penet-style anonymous mailboxes using PIR combined with a form of secure distributed computation; your local POP proxy would create a retrieval ticket that would bounce around the network and collect your messages using multiple PIR calculations over the distributed storage network....yes, you can roll your eyes now at how much we underestimated the development complexity...)
As Bram has shown, stripping MN down to its core and eliminating the functionality that was required for persistent data storage turned out to create a pretty slick data distribution tool. I personally placed too much emphasis on the data persistence side of the story and the continuing complexity of maintaining this aspect was probably our achilles heel, if we had not focused on persistence as a design goal and let it develop as an emergent side-effect things might have worked but instead it became an expensive distraction.
In hindsight, it seems that a lot of our design and architecture goals were sound, since most of the remaining p2p apps are working on adding MN-like features to their systems (e.g. combine Tor with distributed-tracker-enabled BitTorrent and you are 85% of the way towards re-creating MN...) but the importance of keeping the short- term goal list small and attainable while maintaining a compelling application at each milestone was a lesson that I did not learn until it was too late.
I think that I disagree with Steve in terms of the UI issues though. Given the available choices at the time we could have either created an application for a single platform or use a web-based interface. The only cross-platform UI toolkit available to us at the time (Tk) was kinda ugly and we didn't have the resources to put a real UI team together. If we were doing this again today our options would include wxWidgets for native UI elements or AJAX for a dynamic web interface, but at the time a simple web browser interface seemed like a good choice. Of course, if we had re-focused on file-sharing instead of distributed persistent data storage we could have bailed on Linux & Mac versions and just created a native win32 UI...
The other point worth mentioning is that like most crypto wonks, we were far too concerned with security and anonymity. We cared about these features so we assumed our users would as well; while early adopters might care the vast majority of the potential user base doesn't really care as much as we might think. These features added complexity, development time, and a new source of bugs to deal with.
Jim
, now I have to read the DonutLab White Paper: 