Is this what you mean?

https://www.youtube.com/watch?v=F7933xvCFRQ

I won't argue with an idiot who doesn't even refute what I wrote. Read again and try to comprehend what I wrote.

The entire point is about economies-of-scale of capital gaining an advantage over lower levels capital.

The opportunity cost of a botnet farmer is less than perhaps a man-year. Construct a hydroelectric dam with 4 cent electricity with a nerd's 1 year opportunity cost.  

One possible retort is stream micro-hydropower, but locations are limited by head drop, you'd need to lease not own to make it profitable, and this is simply not as widely accessible as learning to be a botnet farmer.

Raise the demand, thus the economies-of-scale, thus the amount extracted by the fungible skill becomes quite a low, insignificant percentage. It is way free markets work.

Electricity is not a free market. ASICs are not a free market. Because they require very large fixed capital investments (which also makes them easy to regulate and to capture for free via political corruption). Acquiring the skills to farm botnets requires only a personal investment of time. This the price of that skill will be driven down to the opportunity cost of the person, not to the fixed capital cost of constructing a hydroelectric dam or creating a silicon fab.


Incorrect. Myopic. You apparently lack understanding of how markets function.

In case anyone missed my point. I am saying botnets are a free market thus we can all go rent one. This will raise the price which raise their availability. Which will raise the hashrate difficulty and this security. Botnets are great!

Which is precisely why instamining is a scam because it doesn't not allow people to have time to figure out how to compile.

You damn well know this, but force us to say it. Obfuscation through attrition of the readers attention span is your game. Dashtards are disingenuous.


Disingenuous bullshit obfuscation and you damn well know it.

Well if you are not hiding from the government and just want privacy, then we could just use a centralized mixer.

So perhaps what I mean is that first crypto-currency has to become popular and then we have to work out which forms of privacy are plausible, scalable, realistic, and which the government will allow us to have.

It is not clear to me yet that sophiscated on chain anonymity is going to have a big market. And if it does, perhaps Zcash's algorithm will be favored because afaics can protect better against IP address correlation.

Yet I think next year, Monero will be in the strongest position with mature technology for privacy and a liquid coin with centralized distribution. I doubt Zcash will be that mature by then.

Afair when I reviewed that paper when Zcash first mentioned it, that can only theoretically limit the parallelization speed up to a factor of around less than 10. But afaik that doesn't characterize entirely about the electricity consumption advantage for an ASIC which is the more important factor.

Afaik, an asymmetric algorithm like that is more likely to be broken (sped up or electrically optimized) by some number theoretic or algorithmic insight. I realize the Birthday problem is a very studied problem, but I trust that much less than a straightforward symmetric memory hard algorithm. I should spend some more time on that white paper in the future when I restudy my design for a CPU hash, so I can try to find more flaws in either approach. I'll wait (because I have other priorities), which will give us time to be sure that is the algorithm Zcash has chosen before investing more effort.

I fear ingrained investment more than botnets. Botnets don't have to fight you and sell you out to protect their vestment. They are just there to get some coins cheaper which drives the difficulty higher than it would be otherwise. If the botnets ever do dominate (which is unlikely) then they are competing with each other. We all can go buy a botnet too, which will drive the prices of botnets higher. In short, botnets are a decentralized resource, unlike cheap electricity which is centralized.

I think the key for Monero is remaining small enough. So the big win will be the stampede in if it comes (smaller market cap should far exceed Bitcoin's percentage gain), and that is the time I would be selling and waiting to see what is next for Monero in terms of where we are at that time in terms of state-of-the-art in sustaining decentralization.

Folks I don't share the 10 - 20 year plan viewpoint. These are not heirlooms because of the trend to centralization and the power law distribution of wealth. We go out and make our mark on society with something and it has a natural peak based on its fitness.

Disclaimer: I have no skin in this game. I realized I make my money being a creator and marketer, not as a speculator. I learned my lesson already.

I think the biggest unknown is whether privacy for crypto-currency really has a big potential market.

I think the upside for Monero may come more from its CPU-friendly hash and greater decentralization (compared to Bitcoin's trajectory) than for its privacy. In that case, Zcash seems to have the wrong philosophy about distribution and they have yet to announce their proof-of-work algorithm.

I view Zcash mostly has a technology incubator. Ditto Monero's privacy. The boots on the ground feature of Monero is its distribution and CPU hash.

You buy now preparing for the stampede into private assets coming next year.

The privacy feature may be a rationalization even if isn't really immune to the tax authorities. Remember the masses are very late to realize anything, so when they realize it is time to stampede, they will still be a long way from realizing which anonymity technologies are NSA-proof. And I am not about to scream from my rooftop in a futile attempt to inform them.

Scorched earth for crypto:

https://www.armstrongeconomics.com/products_services/socrates/new-bill-to-collect-taxes-outlawing-encryption/

Absolutely. That is the tragedy of inertia. Requires extreme cleverness or insightful identification of a wormhole perhaps to overcome.

Edit: but note I am creating a platform not just an App, so expediency is less important than staying power, which I think has been your point of Monero's strategy.

Good point and application of my theory about designed fitness. Thanks. Yeah everytime I imagine going back to C++ to get some low-level control married with generics and some fugly excuse for a first-class function, I decide I'd rather not code, lol. I think this extreme resistance to entering clusterfucks comes with past experience of them.  Some crypto-currencies have decided they are willing to be sacrificed at the altar for that marriage of features. Perhaps it is a pragmatic decision since crypto in a high level language kind of sucks.

I don't know if anyone could pay me enough to work on C++ code again, especially the complexity that ostensibly has been layered on top since I last used it in the late 1990s (which I haven't bothered to learn).  (btw another reason I wasn't excited to work on Monero)

Whereas, for the moment there is no alternative to C when you want portable lowest-level control.


I tried to think about using Javacript for my current plan, but there are just so many cases of tsuris and non-unification lurking. Why start another multi-year journey with a monkey patching expedient yet fundamental handicap.

However, there are many details remaining for me to analyze so it is possible I might conclude that not all objectives (e.g. JIT fast start compilation) can be achieved with a language alternative. Stay tuned.

That will happen first because it is headed towards a peaking (critical mass about now with everyone racing to switch from for example Silverlight to Javascript, Java to Node.js, C to ASM.js, etc.). But that peak will be quickly followed by a disruption because Javascript is being deployed in use cases where it is not best fit (merely because it is expedient and only choice) and this will result in disappointment, which is for example what happened with C and C++.

A better fit programming language and App platform will arise to challenge the Internet browser. I know because I am the one who is making it.


You don't seem to grasp yet how unifying the mobile device is coupled with how unfit the current options of HTML5 apps or App store apps are. Appearances can be deceiving. Dig down into what users are actually doing and not doing.

But I am not yet ready to reveal my entire plan. It will be in the JAMBOX crowdfund document when ever we decide to crowdfund. I am lately thinking of keeping it hidden a bit longer, because of potential copycats such as Synereo. I have enough funding to continue developing for now. No need to rush the crowdfund, especially if my health is improving.


I don't believe I have ever discussed anything about JAMBOX with you.


Just remember that the mobile device is eating (almost) everything.

C was designed to be exactly what it was used for, one step above the metal with portability abstraction.

That business applications didn't know they needed better (because better wasn't available), is irrelevant to the point of a language only being best for what it was designed for, which is my point. C died as a business application language very quickly because it was not best for that use case.

C was employed for a use case where it was not best because it had sort of a temporary monopoly due to circumstances.

Please make sure you understand that key distinction because I think it will be crucial for understanding about what is about to happen to Javascript.


Emphatically disagree. Everything the market has done has been entirely rational. Javascript is only being widely adopted because the Internet browser has an undeserved monopoly. Breaking that monopoly is going to open Javacript to the realization that Javascript is not the best language for the Apps people are using it for.

If Rust adds first-class asynchronous programming, and someone disrupts the Internet browser, this could be a very rapid waterfall collapse for Javascript.


I was around then and I remember the first magazine articles saying the VM could be implemented in hardware and thus it was going to be a new kind of computer or device. Again this was all targeted at Microsoft's growing monopoly which was threatening to cannibalize Sun's market from the bottom up. So Sun decided to attack at the bottom, but changed strategy mid-stream as some of the expectations didn't materialize.


No Javascript can't disrupt the non-browser Apps entirely, because it is not a best fit to applications. It is a scripting language. And transcoder hell is not a solution, but rather a stopgap monkey patching. It has all sorts of cascaded tsuris that will explode over time especially for working in decentralized development.


I disagree. The Internet browser and the W3C monopoly (oligarchy) has been standing in the way of a better general purpose programming language.

I understand this brought together huge economies-of-scale, but unfortunately they've been squandered on an ill fit design that is designed to funnel everything through the browser. Then we have Apple and Android trying to funnel everything through App stores. The choke points are the problem.


I see it. Stay tuned.

The reason it became popular is because of what I wrote before bolded, underlined above for emphasis. The reason C++ become popular is because it promised those benefits plus OOP.

I know because I coded WordUp in assembly then switched to C by version 3.0 and was amazed at the increase in my productivity. And the delayed switch away from assembly afair revolved around which good compilers were available for the Atari ST. Then for CoolPage I chose C++ for precisely that underlined reason and the integration with MSVC++ (Visual Studio) Model View framework for a Windows GUI application.

C was adopted for a use case for which it is not the best suited, because there was nothing better around and thus it was the best suited at that time. Language technology was very immature at that time. There was more out there as research which hadn't yet been absorbed into mainstream languages and experience.

We are in a different era now where we have a lot of experience with the different programming paradigms and programming language design is an art now of being able to distil all the existing technology and experience in the field to an ideal design.


Apparently you did not read my implied point that the mass market is not the only possible target market a language is designed for. As I wrote before, Haskell was design for an academic, math geek market. It is very popular and extremely successful within that tiny market.

It will be very difficult for you to find an Ivy league computer science graduate who hasn't learned Haskell and who doesn't wish to use it on some projects. That is what is called mindshare. Any language hoping to be the future of multi-paradigm has to capture some of that mindshare. Which Scala attempted to do, but it unfortuately bit down too hard on that anti-pattern subclassing.


And crashing my browser and transcoding hell of a non-unified typesystem which is headed to a clusterfuck. I have recognized how the Internet browser "App" will die. I will finally get my "I told you so" (in a positive way) on that totalitarian Ian Hickson and that rigor mortis of totalitarianism at the W3C.


Clearly Sun Microsystems was trying to disrupt Microsoft's challenge in server computing and so Java was designed to co-opt Microsoft Windows on the general client so Microsoft couldn't dictate their servers on everyone. What Sun didn't anticipate was Linus Torvalds and Tim Berners-Lee.


Windows is a dead man walking. Cross-platform, open source .Net (forgot the name) isn't gaining momentum. One good language to succeed the current crop, will put the final nail in the coffin.


It was an attempt to defeat Sun's strategy of co-opting the client. And it helped to do that, but the more salient disruption came from the Internet browser, Linux, and LAMP.


I think it is much more deterministic as explained above. The programming language designer really needs to understand his target market and also anticipate changes in the market from competing technologies and paradigm shifts.


The challenge we've had since graduating from C, has been to find a good language for expressing higher-level semantics. As you lamented upthread, all attempts have improved some aspects while worsening others. Python's main goal was to be very in tune with readability of the code and the semantics the programmer wants to express.

Thus it became a quick way to code with a high degree of expression. Even Eric Raymond raves about that aspect of Python.

But the downside of Python is the corner cases because afaik the type system is not sound and unified.

So it works for small programs but for large scale work it can become a clusterfuck of corner cases that are difficult to optimize and work out.

So I am arguing that Python was not designed solely for scripting but also for programmer ease-of-expression and readability and this has a natural application for some simpler applications, i.e. that aren't just scripts. This seems to have been a conscious design consideration.


Because that is what programmers were taught. So that is what they knew how to use. That doesn't apply anymore. My first programming was in BASIC on an Apple II because that was all that was available to me in 1983. I messed around some years before that with a TRS-80 but not programming (because I didn't know anyone who owned one and I could only play around with it for a few minutes at a time in the Radio Shack store). My first exposure to programming was reading the Radio Shack book on microprocessor design and programming when I was 13 in 1978 (afair due to being relegated to my bed for some days due to a high ankle sprain from football). Perhaps that is why I can program in my head, because I had to program only in my head from 1978 to 1983.

I must mea culpa that around that age my mother caught me (as we were leaving the mall) having stolen about $300 of electronic goods from inside the locked glass display case of Radio Shack. I had reached in when the clerk looked the other direction. (Later in teenage hood I became an employee of Radio Shack but I didn't steal). I had become quite the magician and I was eager to have virtually everything in Radio Shack to play with or take apart for parts (for my various projects and experiments in my room). She made me return everything to the store, but couldn't afford to buy any of it for me apparently. I think we were on food stamps and we were living in poverty stricken neighborhoods for example in Baton Rouge where my sister and I were the only non-negro kids in the entire elementary school. Then my mom got angry when my sister had a black boyfriend in high school.  


Agreed.

I sort of disagree with you at least in terms of the exemplary examples of greatest success if not entirely disagree.

C was definitely designed for low-level operating systems programming and it was the most popular language ever bar none because it provided just the necessary abstraction of assembly needed for portability and no more. For example, it didn't try to make pointers safe or other structure.

Haskell was designed to express math in programming tersely without extraneous syntax and thus the very high priority placed on global type inference, which is why they haven't implemented first-class disjunctions (aka unions) that happens to be the one feature missing from Haskell that makes it entirely unsuitable for my goals. Haskell forsaked practical issues such as the non-determinism of lazy evaluation and its impact on for example debugging (e.g. finding a memory leak). Haskell is by far the most successful language for its target use case.

Javascript was designed to be lightweight for the browser because you don't need a complex type system for such short scripts, and thus you can edit it with a text editor and don't even need a debugger (alert statements worked well enough). Javascript is the most popular language for web page scripts. But the problem is web pages changed to Apps and Javascript was ill designed for this use case. Transcoding to Javascript is a monkey patch that must die because it is a non-unified type system!

PHP was designed to render LAMP web pages on the server and became the most popular language for this use case, except the problem is server Apps need to scale and PHP can't sale, thus Node.js and Java, etc..

Java was designed write once, run everywhere, and it gained great popularity for this use case, but the problem was Java has some stupid design decisions which made it unsuitable as the language to use every where for applications.

C# was designed to be a better Java to run on Microsoft .Net and thus it died with .Net.

C++ was designed to be a marriage of C and OOP and it is dying with the realization that OOP (subclassing) is an anti-pattern and because C++ did not incorporate any elegance from functional programming languages.

All the other examples of languages had muddled use-cases for which they were designed and thus were not very popular.

So I think it is definitely relevant what a language was designed for.

C++ is a painful, fugly marriage of high-level and low-level, which loses the elegance of high-level semantics. I think it hasn't died because no other language could do C low-level combined generics (templates). Perhaps something like Rust (perhaps with my ideas of extensions to Rust) will be the death blow to C++ and also Java/Scala/C# (probably Python, Ruby, PHP, and Node.js as well). And also perhaps Javascript...


Which appears to me to be a great tragedy of inertia (it was originally designed to be for short inline scripts for simple DHTML on web pages ... then Google Maps and webmail clients arrived...). I am in the process of attempting to prove this.

I believe there is no reason we can't marry high-level, low-level, static typing, and fast JIT compilation and still be able to write programs with a text editor without tooling (for as long as tooling is in the debugger in the "browser").

This low degrees-of-freedom crap of being forced to fight with bloated IDEs such as Eclipse needs to be reverted.

This dilemma of needing to place the modules of your project all in the same Git repository needs to be replaced with a good package manager which knows how to build from specific changesets in orthogonal repositories, where the relevant changeset hashes from the referenced module are accumulated in this referencing module so that merging DVCS remains sane. In other words, the package manager (module system) needs to be DVCS aware.

The points of this thread are apparently making their way around the crypto-currency community: