Nice!

A very comprehensive list of questions and excellent response from ElMato!

If Charles has the answers to these questions for every project he has mentioned there is a fantastic opportunity for an industry wide report. An intense aggregation of project info.

That will be fantastic, Charles will you care to share? I have setup http://crypto20.org/ and https://github.com/Crypto20/Crypto20org it will be invaluable if some of your knowledge could be leaked there .

Quote

Those who can, do; those who can't, teach.

   

Generally speaking, academic papers are produced by those who can add more value by teaching than by doing.   More often than not academic papers are so formalized that they do a terrible job teaching.  In other words, academic papers are written by academics for academics and are usually useless for those who actually want to DO what the papers talk about.

The one thing academic papers do provide is "respect" whether or not it is deserved.   I give them about as much respect as I do a college degree.  They are meaningless predictors of the ability of someone to actually do a job.

I don't believe in academic papers, normally they are not easily accessible to everybody, this is the problem with Crypto, it has to be easily accessible for anybody to understand and invest their time and money.

Xeroc is right the focus should be on explaining and documenting.

BM, I have had the same attitude as you in the past, doing vs teaching, but I have come to realised that I have done many things, that due to my lack of teaching (and incapability to open source) they have been eventually wasted. So you need to do both, or delegate

"If a tree falls in a forest and no one is around to hear it, does it make a sound?"

I like the other thread that Charles has started and el mato answers... with code references.

Here's an important one that hasn't surfaced yet: provide API functionality to build shopping carts and account authentication / login, like the BitShares login was meant to to be in BitShares 0.9.x .

The addition of this would help anyone to sell products or services with tight integration to BitShares. Part of this is to complete the implementation of a secure websockets interface in the witness_node code. Although that aspect isn't as high a priority as the login / authentication API (or at least documentation for the API if such functionality is indeed already there), it just makes sense to finish what was started.

Oh and in the list above I would add "Implement a plugin architecture for the GUI" to allow integrators and power users to tailor colors / styles / logos more easily. Color / GUI look & feel items are already in your poll, but why not implement them in an extensible way, rather than just offer a few more choices.

I've gotta believe significant elements of a plugin UI architecture already exist, and if so adapting them would reduce the workload on the devs.

 

It should be multiple streams of work, BAU (issues, bugs, etc) and new value add, and yes the most important is to allow the integration, if you cannot build your business in Bitshares you will look at another alternatives.

This is a transcript of my remarks during the first of two panel discussions at the Shanghai Blockchain Summit on October 15, 2015.  It is taken from a pocket recorder which unfortunately only picked up my own powerful orator quality voice.  So the other panelists have not been transcribed and my recollection of the actual moderator questions is only approximate.

We were told what the questions would be during shortly before we went on stage, so my answers were mostly just making stuff up on the fly.  It's what I do.

Panel 1 - Scalability

Moderator:  Please introduce yourselves.

Stan:  My name is Stan Larimer, I’m substituting here for Dan Larimer the founder of BitShares who couldn’t be here because he was changing platforms and upgrading BitShares to our new Graphene operating system, so I’m going to pinch hit for him today.

Moderator:   Tell us a bit about what you have been doing.

Other Participants: (Unintelligible on my recording)

Stan: When a year ago we launched BitShares it was a new application that ran on top of a separate blockchain.  But just like Bitcoin is a currency application running on its own platform, we created a platform that would be an exchange on its own platform.  We have since formed a company called Cryptonomex to generalize that one step further into being a platform on which you can host multiple ledgers.  The idea is that, just like early computer programs didn’t have an operating system, they just took over the whole computer but the trend was to move toward a separate operating system and today we have Windows, MacOS, Linux and a number of others that people build their applications on top of and reap benefits from sharing common resources and not having to reinvent all that.  What we are doing now is providing one such operating system, I won’t say whether we’re “MacOS” or “Windows” but I consider Ethereum to be another example in that genre and that going forward I expect a lot of different [existing] applications to migrate to one of these platforms over time.  And platforms will be seeking and competing to provide better and better common services so that you don’t get 600 different coins all running on their separate operating systems, instead they can interact better.. and that’s what we’re aiming to produce.

Moderator follow-up:   Ok, so BitShares is basically a crypto exchange?

Stan: Yes!  The application that we did was to take an exchange and put it onto what amounts to a coin, and so people started thinking that “well, this is another coin that does more.”  We view it as a different use of a blockchain, that’s what it has in common with coins, but in this case it produces an exchange where you don’t have any counterparty risk. 

Moderator: There seem to be several different kinds of block chains, what trends to you see in these choices?

Other Participants: (Unintelligible on my recording)

Stan:  The big trend that I foresee and am trying to bring about is the idea that it is ok to separate your brand and your community from the platform on which you are operating.  Just to pick one at random, one of the top ten, Dogecoin.  It’s not popular because of its technology and the platform its running on, its popular because of its community and its whole ethos and how it works - it’s a brand.  An what we are going to see in the future is the thing that’s making these individual currencies popular is that they are a brand and as a brand are responsible for staying cutting edge.  And that means you are going to see more “platform surfing”, where people will move from wherever they are, the platform they were born on, and say, “Hey, I can leap in performance to more flexibility and have smart contracts and stuff if I move to Ethereum, or I can leap to a place where I’m a lot faster in operation if I run on the platform we’re producing — Graphene from Cryptonomex.  So I think that in the future well see that.  While I was flying over the north pole [to get here] BitShares was upgrading to Graphene becoming the first one to move onto that platform.  A number of other [applications] have announced their intention to join us and hopefully that will start a trend where [applications] are co-resident on a single ledger where smart contracts can have trading products back and forth between all the different brands that are out there and we get a lot less friction economically from being able to all [interact] on a common public ledger.

Moderator:   Tell us what trends you see.

Other Participants:  (Unintelligible on my recording)

Stan: Well, I guess I’ve already jumped the gun and said that I thought the trend would be moving toward general purpose operating systems that multiple applications can run on.  Since I’ve got an Ethereum guy up here [Nikolai Mushegian] I’ll use Ethereum as a compare and contrast.  Ethereum is an operating system, as we’ve already heard, designed to be flexible and allow a wonderful environment for developers to be able to [try] things very quickly.  So it is emphasizing the idea of speeding up the development cycle.  Graphene, our product that BitShares just jumped onto, is aiming for a different goal — a different axis — optimizing along a different axis.  This axis is for speed.  Industrial grade speed.  Blockchains that are only limited by the speed of light and the size of the planet.  Scalable up to the point where, instead of a 10 minute block time, we are talking about a one second block time.  A blockchain that can produce a new block every time a card is dealt, every time a tumbler on a slot machine is [stopped],  one that has enough throughput to host every transaction for all 600-plus currencies on coinmarketcap right now.  So we’re going for scale, for one environment where they could all interact without ever exiting to fiat or incur the counterparty risk of trading [on a traditional exchange].

If I were a developer and had to pick between those two, do you know what I would do?  I’d pick both!  Both is a good answer!  Microsoft Office runs on Windows, but it also runs on MacOS X.  Why did they do that?  Well, a developer who picked one to develop on doesn’t want to leave that other operating system to have a competitor show up on it.  So any developer, once they get something working — probably on Ethereum first because its a nice way to prototype — is going to say, well, regardless of whether Ethereum has 60% or 40% of the market share, I want to get my application on the other platform as well.  And so I think you’re going to see over a period of time exactly the same thing that happened in the operating system world  happen with the blockchain ledger world.  And so that’s my megatrend for the day.

Moderator follow up:  So we’ve got Android and IOS?

Stan:  Yeah, same exact thing.  And in fact that’s really good because [Apple] likes to sort of vet and control who gets on it.  For financial networks, we kind of like that.  Ethereum wants it to be wide open more like Android.  So I think there’s a place for both and people will naturally look at that and we’ll have competition to see who can make the best platforms and that benefits everybody — it’s like a rising tide lifting all boats — so that everybody that has a new application doesn’t have to worry about the low level operating system of the block chain. They can focus on their new application.

Moderator:   Tell us the issues you see about scalability.

Participant 1: (Stan's summary) The crucial design distinction is between “scale up” (faster computers, bigger block sizes) but also “scale out”  (exploit massive parallelism).

Participant 2:  (Stan's summary)  There’s also “scale off”, which is looking at whether a function should be on chain or off chain.

Stan:  This is great!  I totally agree.  I’m not contradicting anybody.  We can scale up, we can scale out, we can scale off or at some point we can quit scaling and change platforms.

I’m reminded of the story of Og, the Cave Man.  He discovered that you could ride a horse and because of that his brontosaurus pizza’s could be delivered to the nearby villages by horse. And so he scaled up by getting faster horses and he scaled out by getting more horses and he scaled off by loading some of the pizza into a wagon pulled by bigger horses and he built his business up and up until his descendants, when they finally got a truck didn’t scale any more — they jumped platforms.  And now that increased his reach for his pizzas by an order of magnitude because it was a new kind of platform better suited for reaching out.  And then he started the scaling process all over again - faster trucks, more trucks, bigger trucks until the airplane came along and the same process repeated — and someday his pizza company is going to be delivering pizzas interplanetary on a new platform - a starship.  The difference in scale [interruption from the audience something about cost of a starship, ignored temporarily as I was about to make my key point] the difference in speed between a horse and a starship is eight orders of magnitude.  The difference in cost effectiveness between Satoshi’s original blockchain and the one we just upgraded to is also eight orders of magnitude scalability.

That right there dramatizes it, I’d be happy to explain the technical details if I had Dan here, but if I could just get you to envision the difference between the speed of a horse and the speed of light, that’s how much cost effectiveness can change by switching and upgrading platforms. 

Moderator followup:   Question about how that was calculated.

Stan: Well, as you’ve mentioned, Bitcoin’s numbers right now are about 7 with a block time of 10 minutes.  We’ve demonstrated, when we don’t have to deal with the size of the planet or the speed of light, in the laboratory, the ability to scale to 1 second and 100,000 transactions per second.  Now, what are we doing for BitShares in the upgrade, well, we didn’t bite that all off at once.  So if Bitcoin can run at seven, well we just jumped to 100 to get started and so we have three second transaction times that we can dial down to one and by just applying the parallelism that you talked about, the cloud technology…

Moderator: Today BitShares can do 100 transactions per second, right?

Stan: That’s what we set it for to start, yes. 

Moderator: (Mentions that some others have demonstrated 5000, etc.)

Stan: Well yes, and I’ll just finish up very quickly, the only reason we’re not running at that speed is because you’ve gotta have faster hardware and you’ve got to pay for that hardware and until the load on the network grows to where its worth paying for that, right now we can get by cheap on little simple processors and do a hundred, and when the time comes we can upgrade.   

Other participants/audience:  (It’s probably simpler to just scale out into the cloud...)

Stan: The limits to scaling out into a cloud are of course based on the assumption of parallelizability, and in the case of a lot of types of transactions, specifically the types of exchanges you find in BitShares you can’t make a transaction in parallel without knowing the other things [in other threads].  That led us into “lets get the piece of the processing that’s not parallelizable optimized to run as fast as possible and then fan out what feeds it with all the rest of the processing".  But there’s always that bottleneck of ordering transactions that are interdependent, and the cost of figuring out what’s not dependent is a huge challenge. And so, that’s why we chose the opposite approach. 

Both are valid. 

Please release your products on both platforms! 



Note:  I realize I should have said "200" TPS is our current number, but somehow I dropped a bit somewhere.

Fantastic Stan, I am glad my current explanations on scalability, Ethereum and Graphene are remarkable similar to yours.

It takes 8 seconds after refresh, so not bad at all. Most of it is initialising the ui, getting my accounts, balances, etc. So not bad at all. Saying so I am on a 150 Mbit connection.

Now up to:  590,226  reduction in supply.

Do you (or any) have any model of the supply, based on average usage and number of users? If not is ok, I understand fees will also change, so it is difficult to predict.