📂BeyondBitcoin Archives with Dan Larimer and Fuzzy | Bitshares XT | Recorded on May 3, 2014 | w/Transcripts

Welcome to the BeyondBitcoin Archives

Over the coming weeks and months you will be introduced to the history of the BeyondBitcoin Community and the historical influence it had with the development and evolution of the Delegated Proof of Stake (DPOS) blockchain technology pioneered by Dan Larimer starting with Bitshares and STEEM.

You will be able to listen to the initial conversations between @OfficialFuzzy and @Dan (Bytemaster) and learn how the development process progressed over time guided by the weekly feedback from the BeyondBitcoin community members... many of who went on to become important contributors and leaders in the Bitshares and STEEM ecosystems.

I will be tapping into this treasure trove of knowledge and providing edited recordings and full transcripts for the most important and influential hangouts from the BeyondBitcoin Archives.

---

🔊Episode #4 : Recorded on May 3, 2014

In this episode, the Bitshares XT Blockchain Test was just launched with the initial trading speed set to one block every 30 seconds, with plans to increase it to be every 15 seconds "if we can" and the a Web Wallet GUI was just beginning to be created.

---

📝Hangout Transcript

Click play on the video above and follow along with the transcript below.

Fuzzy:
Welcome to another Beyond Bitcoin Dev Voice Hangout. Today is Saturday, the third of May, 2014. We have created the service to lower the barriers of entry for individuals in a cryptocurrency world who do not necessarily have the funds or the time to travel to meet-ups or to pay prohibitive entrance fees to conferences. We believe that the cryptocurrency community gains strength and therefore value from being as inclusive as possible of anyone interested in becoming involved.

The content created here is as open source as the community itself. If you cannot attend these sessions feel free to visit the Beyond Bitcoin show subreddit to find information on future Dev Voice Hangouts and to both post your own questions and vote on others. We rely on the votes to gauge the perceived importance of the questions asked, so the more questions and votes the better. With that said, it is our hope you will gain as much from the community's questions as you do from the developers answers now let us get on with the hangout.

Welcome Dan.

Dan:
Thank you.

Fuzzy:
How's everything going?

Dan:
This has been a very productive week. Yeah, on Friday I launched a test of the Bitshares XT blockchain, and it looks like people are having some success with it .

Fuzzy:
Really? So can you tell us a little bit more about this test chain and how people can get to be a part of it, or?

Dan:
This test chain is initialized with the snapshot of February 28th, or at least that's my intention. If there are any problems with the way it was initialized we should identify that now so I can make sure that it's properly initialized when we launch it for real. The status of this test is mainly to get in the hands of developers so that we can all fine tune the user interface and work on the common blockchain for testing purposes. I assume that most developers have some 'pts' or 'ats' from the snapshot if not, contact me and I'll send you some.

Fuzzy:
That sounds cool. How can they contact you?

Dan:
The easiest way to contact me is through BitsharesTalk.org.

Fuzzy:
Okay, so they can go in there just to to make it easy. They can go in search for your name, find you, click on your profile and there's little word bubble that they can click on that says 'PM you' and they can go through there, right?

Dan:
Yes, and I'm “Bytemaster” for those who don't know about BitsharesTalk.org.

Fuzzy:
Sounds Good.

Do you have anything else that you would like to speak about within? We have about five to ten minutes for updates on the project. If you don't, if you feel like there's anything else that you would like to talk about feel free to, otherwise we'll start opening it up to the community voice.

Dan:
The only other thing that's been going on this week is that Nikita has been making steady progress on the web interface. It uses the same RPC interface. I'm going to be producing instructions on how to setup the server and access the web interface here, early next week and I'm really looking forward to getting this out. The status of this chain is that it will be the trustee model, but it's going to be tracking the votes for delegated proof of stake. Now this means that you should be able to register names and become a delegate if you like

Fuzzy:
So people can actually start working on figuring out how to best accomplish/achieve the result that you guys are looking for. So they can kind of almost get at least a little bit of a head start on the competition whenever the delicate system comes out.

Dan:
Correct. We have a lot of things to do on the wallet. I believe that the blockchain itself is stable and functioning. We've got lots of unit tests to test that. The wallet itself is going to be evolving, but that can be done independently of the actual blockchain so we're not going to allow wallet features to hinder the launch of the chain. That's the main thing that's going on there. The other thing we did testing this week is a 50-node cluster using our broadcast peer-to-peer mode operation and I posted a chart that showed how it is all connected and it looked like a well-connected graph and that is exciting and we will be deploying the peer-to-peer version of everything shortly. Right now it's all client server for this testing phase.

Let's see here, yeah we have identified one bug that is frustrating. There seems to be a random memory leak that randomly applies to some nodes in our 50 node cluster. We need to figure out why about five to ten percent of the nodes end up with a large memory footprint when the rest rest all have very low memory footprints, but we are looking into it.

Fuzzy:
That sounds good. There was one thing that I wanted to ask you. You said something about the RPC.

Dan:
Yes.

Fuzzy:
We have a lot of people who are invested, not necessarily developers, I myself am not a developer. They may understand the concepts, but it would be interesting for me to see if you could expand upon that just a little bit.

Dan:
All right. RPC stands for “Remote Procedure Call”, and is the way that third-party developers and our web interface can communicate with the blockchain and the wallet. We are making our RPC interface as close to the Bitcoin interface as possible so that it can facilitate rapid integration with existing solutions out there.

Fuzzy:
So, basically, is it safe to say then that you are, that our PC is going to allow other developers to easily kind of plug in and utilize this technology?

Dan:
Yes. Now that we have an RPC interface that is robust we can add new features and make new things available to developers and hopefully we can get some parallel development where anyone in the community can create a web page and create their own custom wallet if they like. If they don't like the one that's provided by us they can provide it to others. Anyone who can do html5 and JavaScript has the ability to build a graphical wallet for our system.

Fuzzy:
And whenever this is in place will there be bounties that you guys have thought up as far as that or do you think that it will be better just to leave it kind of open to the community, kind of like most of the other open source projects do? As far as like mumble and tour and all these different GUI interfaces come.

Dan:
We have a full-time developer and two or three part-time volunteers working on a GUI.

Fuzzy:
Sounds good, and I want to bring it back to the memory leak real quick. I just wanted to kind of go in the order of what you spoke about and could you explain a little bit to the community what a memory leak is

Dan:
It's just a type of software bug where it attempts to allocate a lot of memory, in this case a couple hundred megabytes. It just uses up your computer's resources. It doesn't seem to crash unless you don't have enough memory, but we need to figure out what the root cause of it is it's definitely not a predictable or guaranteed thing so it's going to be take a little while to check it down. I do not think it would prevent us from launching, it's just a known issue that we are working to resolve.

Fuzzy:
So it's not necessarily a security issue or anything like that to your knowledge in this juncture?

Dan:
All bugs are potentially a security issue, particularly memory-related bugs. So it is a high priority bug. I don't think that you know you're likely to get hacked at this point in time just
because of the small size of the system, but I don't think this buck will persist for very long.

Fuzzy:
Okay, now if something were to happen, like attack were to happen, would people be losing their real pts, or Bitshares rather, or would it be possible to kind of go back in time after the fact and restart it from after the test phase is over?

Dan:
This is a very interesting dilemma we have going forward because the same private keys are being used for the test network as the final network. If your private keys are compromised they're compromise for everything. So please treat your private keys and the security of your system, as if it was the real network.

Fuzzy:
Roger that.

Well with that said, the updates on the project portion of our meetup is completed. I'm going to go ahead and open it up to community open voice. So anybody who has any questions feel free... we're going to give anywhere from 15 to 40 minutes for this open voice depending on how much the community has to say and how many members are in attendance. After that we will be moving into Beyond Bitcoin Show's subreddit questions

Well I'll tell you... Hey DeLillo, how's it going? Can you speak? Oh okay.

Well really quick, “HeyD” is chatting in the chat channel and he says it's midnight where he is at so he's not able to speak. He does have two questions.

One. Can you please tell me more about the web GUI? Is is it really the interface that is engaged in a web browser? and... well let's go with that one first.

Dan:
If I understand the question right, the way it will work is you type in a URL and I'll connect to a web server running on your local machine. So you will access it via chrome.

Fuzzy:
okay, and then number two. Once BTS XT network is launched, which it's almost launched, in what situations will it be rolled back?

Dan:
It will only be rolled back in the event that there is a catastrophic failure that allocates new shares that
shouldn't have been allocated. In that event I will only roll back to the block that had the problem. That way we minimize disruption on the network.

Fuzzy:
To me it's very good to see that we are making progress. I know that the rest of the community, that there have been people are always looking for progress and though the progress has always made whether it's finding a bug that you need to go back and fix or moving forward and actually getting to the final product, it's good to see that we are moving in that direction.

You're very welcome “HeyD”. And now let's go to “JoeyD”. Do you need to set, do they need people other than devs to set up full nodes to start up the network?

Dan:
We would always welcome people who to get involved and learn how to do that. The initial version probably does not have the ability punch through firewalls. We'll add that shortly thereafter. But, yeah having new more developers set up nodes just for testing and feedback would be helpful. We are going to have several nodes running ourselves. So you know we are also working with some third parties who want to be in the business of running these nodes, yeah, and becoming delegates.

Fuzzy:
So is it too early to ask what third parties or will that be coming later on or?

Dan:
I haven't gotten their permission to reveal their identities at this point.

Fuzzy:
Got ya. So we've got Batman working behind the scenes with you.

“Delulu” says here, I guess importing your private keys later is enough when Rio XT is launched? Meaning I'm assuming that you don't have to be part of the test net, you can actually wait until after the fact and import your private key, correct?

Dan:
That is correct.

Fuzzy:
Okay, so and of course anybody feel free... you're more than welcome to actually speak up. I'm glad to ask questions that you type below so that is always an avenue for you as well. What we might go ahead and do if no one else has any questions at this juncture...

Dan:
I would like to make one comment.

Fuzzy:
Sure.

Dan:
Part of this test network is to make sure that everyone got the balance they were expecting to get and that all the import features work as expected. So, if you do not participate in the test network then you will not identify any bugs in the importing or allocation of your initial balance and that is something that we would like to test.

Fuzzy:
Right, so is there going to be a thread or is there a thread that actually goes into depth with regard to how we can, the average user can go about like in a step-by-step process to accomplish this.

Dan:
I started a relatively light thread called 'Testing Bitshares XT Launched' and that's a place where you can go to read instruction how to get involved. There are definitely some usability issues on the command line wallet. Importing private keys by hand for example doesn't work with Bitcoin keys, that needs to be resolved. If you would just like to participate in the test without exposing your private keys you should still connect, and I'll send you some funds just to play with. But the other thing you can do is import your keys, check your balance and then destroy your wallet and start over now just to make sure you know what kind of balance you're going to get when you input your keys.

Fuzzy:
So when you say import your keys and destroy your wallet what does this mean?

Dan:
It just means that you minimize any exposure for security vulnerability by not having a Bitshares XT test client up with your real private keys for more than is required to scan the blocking for your balance.

Fuzzy:
Oh, so, so let me get this straight I think I understand what you're saying. You're saying that you can import these private keys into the Bitshares wallet and then after that you can keep your old wallet, like PTS, Bitshares PTS wallet. You keep that off to the side on like a USB or whatever and then when you import this in that wallet into the BTS you can actually destroy that wallet after you've got you're done doing the testing with it.

Dan:
That is correct.

Fuzzy:
And then that wouldn't keep them from re-importing it later on, correct?

Dan:
Correct.

There was a question I see on here about, Will the real XT launch with a GUI client? If you mean a web GUI, I am aiming to have that done. It's, I'm pushing and leaning on my web developer is really hard to make that happen and I expect that once it's out there there are enough web developers in the community that will be able to rapidly build a both a block explorer and a web GUI for it.

We are also looking into integrating a web browser into 'Keyhotee' and then having the wallet and the backend of 'Keyhotee' just render the web GUI natively so you have a native experience but it's still using the same interface code. I'm finding developers who can do QT GUI work is a lot more time consuming and expensive as my experience so far.

Fuzzy:
Okay, now out of curiosity with regard to the web GUI, are you guys, was the plan kind of to make it so it was more available depending regardless of the device that users wanted to choose like they could use a handheld tablet or laptop or desktop any of that stuff?

Dan:
By using a web GUI we have the ability to support both native, when I say web GUI it uses your web browser but all your private keys are stored on your computer with a server back-end running on your computer. This is not us hosting a server or managing your private keys. It's just another way of presenting the interface to the user that's slightly different then Bitcoin QT. Being a web GUI we might actually be slightly less secure than say Bitcoin QT, or Bitcoin Core they're calling it now, so I would. That's why I integrated into 'Keyhotee' a dedicated browser that can render and execute the same interface could provide greater security than using something like Chrome, which might have who knows what extensions installed into it, what kind of compromises. If you want the absolute security there is the command line version it has no web interface that you have. Eventually I would like a full desktop client because that will be the best user experience, but time to market is dictating what we do.

Fuzzy:
So there are plans in the future. The web GUI is as you see it is going to be, allow for more of an open source construction type of environment and it'll bring it to the market quicker. Which seems like it is a big thing to a lot of people who are looking at Bitshares.

Dan:
Right. The other thing we're doing with the web GUI is we're going to provide a JavaScript API that abstracts the difference between a local web GUI and one that's hosted on a server. So that you can have one interface that you develop and you can have a blockchain.info with the private keys managed in the browser and abstracting all the backend stuff. That same interface can be used local host with the key is being managed by the server running on your own computer. What this also means is that we can have your phone talk to your desktop computer to access your wallet using the same interface.

Someone asked, “What internet engine we were used to embed into 'Keyhotee'”? Because we're using cute we would be using WebKit to do everything.

Fuzzy:
And for... well let's go ahead and “Delulu” ask a question because he wants to it seems like he wants to get a little bit better answer as far as a little bit more clarity with his question. What I mean was, do I import my private keys with a GUI desktop or web or by command line?

Dan:
You can do it either way.

Fuzzy:
And what do you mean in the real next “Delulu”? The reason I asked is “javajavaone” said like next, NXT, whenever he was talking whenever you were speaking about how you're working with the GUI.

Dan:
I'm not familiar with next GUI. I haven't actually played with it yet. Yes, the web GUI will interface to a native app.

Fuzzy:
And for those people who are not here for this session I'll go ahead and I'll read it for everybody. “Next web GUI, NXT's web GUI uses Java and it blows up to five gigs after a week. Which is he's saying is horrible. I'm not sure, I'll leave that up to you.

Dan:
That is a huge memory leak if I saw one. We are sitting at I guess at our test Network, even what we're doing hundred transactions per block and blocks every 30 seconds. Staying well under 10 megabytes, so that's a lot more memory usage.

Fuzzy:
Okay so even with the current quote-unquote 'memory leak', you guys feel like you're you're getting really close to where you want to be and there are other projects that are having similar issues that they may or may not be getting to that point right now.

Dan:
Right, our particular memory leak is pretty bad and that it jumps from ten megabytes to eight hundred megabytes. Which is still twenty percent of what Next does over a week. Of course are's didn't take a week to do it. So we'll see how things play out in the longer run. Part of this test is just to see if there are any any bugs that crop up that only show up after a couple days, or a week of running, so these all things will discover shortly.

Fuzzy:
Roger that. Modprobe asks, Everything is a native app.. oh it says everything is a native app at some level. Good point.

“JoeyD”, Any estimates on hardware requirements to run a node or a delegate? That's a very good question Joey.

Dan:
I suspect that the hardware requirements will be similar to Bitcoin.

Fuzzy:
So what will be happening with regard to that ,as far as are you seeing? Would you give us a little bit more detail like what what somebody would be looking at the progression over time?

Dan:
I think any modern desktop will be fine the data rate is designed to increase fees automatically to prevent the block chain from growing at more than 100 gigabytes a year and if you are growing that fast we'd have a transaction volume much higher than Bitcoin's and we'd be worth billions of dollars, so I don't see that being a short-term problem.

Fuzzy:
Roger that. Now “javajava” makes a very good point he's saying, RaspberryPi plus storage?

Dan:
I have no idea how fast the CPU is on the RaspberryPi. The bottleneck is likely going to be signature verification and database look-ups. We have not done any optimizations at this point for the database performance. So, until I have benchmarks I can't really comment on performance. I can say that I do try to design everything to be as efficient as possible and follow some good practices in that respect. On the other hand, LevelDB is our third party library that stores all our data and I do not know how our use of LevelDB is going to play out in the long run whether or not yeah that's going to result in a performance problem.

Fuzzy:
So basically, this is a place where the more people attempt to use the test net the better you are for finding the baselines and figuring all these things out.

Dan:
Right, for a certain extent we're not going to be able to get enough people to really push the envelope on performance. But, that's why we have Eric who's creating a test simulation network. He's got 50 nodes all running on one machine and his one machine gets completely maxed out doing that. So, I can tell you you can't run 50 notes on one machine and process all the transactions, so he's actually limited there. We will probably grow his test to be a network of machines and these are all automated test and then we're going to integrate them into the nightly builds to identify problems as they come up.

So ideally what I would like to see, in the futures the possibility for a RaspberryPi type device that can have your entire blockchain on it. It can be your personal home server that then allows you to access your wallet from your phone without having to rely on a web wallet to manage your keys.

Fuzzy:
That sounds like an amazing solution. For anybody who doesn't know what RaspberryPI's are here, who are listening in the listening listening audience. It's basically just a little motherboard. Everything is attached to that needs to be attached to be able to run like a little PC. It's literally the size of a hand, a human hand, you can add memory via like SD cards and... yeah it actually does, I guess it is about the size of a credit card isn't it? It's a little bit smaller. It doesn't require a whole lot of money, you can buy one for about 30 bucks and it requires very less very little energy. Yeah, Joey.

“JoeyD” asks, “Are things like MultiSig to protect your stake integrity there already?

Dan:
The blockchain supports it, the wallet is not at this point.

Fuzzy:
And for people who do not know what MultiSig is could you explain a little bit for them?

Dan:
MultiSig, well let me just go ahead and describe the general structure of the Bitshares XT blockchain. Every transaction pulls balances from someplace, those are called the inputs, and sends them to the outputs. Every output can only have one be connected to one other input and so you end up with this list of balances that are linked back and forth through the blockchain. All the outputs are defined as in terms of what conditions they can be claimed and I have about six different conditions. One is you can claim them with a signature that's the normal operation. The other is that you can claim it provided that the transaction is signed by a certain number of signatures. So you can say three out of five or two out of three and that is configurable. Others enable cross-chain trading, using the atomic algorithm identified on the Bitcoin wiki. So there are a handful of different types of conditions that you can send an output, which is really just a balance in the blockchain. So we support MultiSig, straight transaction signatures and also atomic cross-chain trading, which is a mouthful to say.

Fuzzy:
And atomic cross-chain trading is actually one of the things that I read a lot about people are not sure how it's going to work. Is there any clarity that you could provide there?

Dan:
The way that works is, you create a series of transactions that are linked together and you have to pair your client with someone else. So setting up the infrastructure to find people that want to trade between chains is a separate issue from the blockchain technically supporting the transaction. And the way that works is, and normally I have to reference the thing, it's a little complicated I'll try to simplify it.

I create a transaction that says, I'll spend X amount to you on one chain and you spend X amount to me on another chain, but you can only claim the amount that I spent to you if you reveal the password and the active you revealing the password on one chain allows me to claim the funds on the other chain. So, you can't get your funds without giving me the information I need to get your funds and then you have a set of timeouts to make sure that if one person doesn't actually claim theirs in time that the whole thing unwinds and that one person is forced to reveal theirs before the other person can and the other person has an opportunity to take their funds out before they can be canceled.

So, that's the general algorithm for it. So it's a it's a multi-step thing involving two transactions per person. One to set up the initial trade. One to claim the funds on two different blockchains. It requires both clients to be online for a period of time in order to execute it securely.

In the Bitcoin case you'd want each transaction to get six confirmations, which means you're looking at at least two hours minimum. With our blockchain you can probably execute a cross-chain trade between two versions of our blockchain in less than an hour, maybe, maybe even 20 minutes.

Fuzzy:
Thank you for explaining it.

Dan:
The really interesting thing about cross-chain trading with our system is that BitAssets on Bitshares X, like BitGold, BitUSD, they're going to have the same value on all blockchains. So, it makes it really easy to move value and just set up the trade because you can set up... I'm going to give you one BitUSD on chain A for 1 BitUSD on chain B and that doesn't involve a bid or an ask. You don't have to worry about the price changing in the middle of your trade. Which if you're trading say, Bitcoin for Litecoin and you're trying to do this exact same thing, I could see people backing out of a trade if they start it and then the price moves against them. The really exciting thing is that this is a far superior alternative to the side-chains proposal that's been out there.

Fuzzy:
So basically the BitAsset, the same BitAsset is represented on multiple chains then effectively?

Dan:
Yes. I'm going to recommend that the market or community establish one BitAsset that is automatically included in every chain even if you're going to differ you want to differentiate BitAsset so you can get a variety of options out there. But as long as there's one in common, it really facilitates cross-chain trading my recommendation is that be BitGold or BitSilver, but it could be anything.

Fuzzy:
And out of curiosity, this is more from like an economic standpoint. How do you feel, what do you think is going to happen with the prices of well - I'll read a lot about for instance things like market manipulation using high-frequency trading and just whales being able to come in and infect the game. Do you think that this type of system is going to open up trading and actually make from what a lot of people believe is not necessarily true price reflections? Do you think that's going to change it at all? Or do you disagree with the premise?

Dan:
Well high-frequency trading is noise trading. So there's two types of things going on in the market these days and most of the trading is just noise. There's no new information that's being learned by the market participants. There's computers that are looking at historical data and making moves or looking at orders that are coming in before anyone else and positioning themselves in front of it. We have slowed down the process because we're on a blockchain. We don't want high frequency trading and be very costly and expensive in terms of submitting transactions to the network. So our market algorithm is more like a middleman, where both parties say, “hey I want to buy or I want to sell.” And the middleman, you know they're not talking to each other, the middleman says, “Oh okay, I'm going to buy from whoever is willing to sell the cheapest and sell to whoever was going to pay the most and anything in between is is kept as profits for the network”. This completely changes the game because now you can't walk the book, like you can an existing things, which makes attacks that attempt to push the price up and then back down in a rapid manner can't be executed as efficiently or as profitably. The downside to this from in some people's minds, is that it's going to cause there to be a wider spread, and the spread is the difference between the highest bid and the lowest ask. Which means that if all you did was buy and then turn around and sell you'd lose whatever that spread was. The result is that these markets will be based on more on information, the only time you're willing to jump the gap from the bid to the ask or the ask to the bid price is if you had information that suggested that it was worthwhile. I believe this will create richer markets, more meaningful markets and it will naturally keep trading down to a lower rate than the high frequency systems.

Fuzzy:
So you feel like it might, it's going to become a more rich environment than the relatively automated, current algorithmically-dictated markets?

Dan:
These markets will have a different feel to them. Anyone who's used to the behavior of current markets is going to have to relearn how market behaves in this environment of slightly slower trading.

Fuzzy:
So we're kind of going back to the old times when people actually had to lift up their hands and and sign cards to do the stocks.

Dan:
Yes,except will be much more efficient.

Fuzzy:
Wow! Very interesting, very interesting. I'm sure that there's a group of, a large group of people out there who'd be interested in it.

Let me go ahead and go in here while we were talking there were a few questions. They're talking about a 'Yuan' ban? JoeyD said it would be nice to see freely interchangeable persons worldwide probably like he why Bytemaster suggest BitGold. So you're are you are you suggesting BitGold and BitSilver because they've had that kind of like that historical peg?

Dan:
I'm suggesting them because they're the only currency i know that's not going to go to zero.

Fuzzy
Good point. Okay and with that, it's this is kind of a good place to talk about... I saw you posted on the forums something about Rand Paul speaking about equities and could you get a little bit into that?

Dan:
Well Rand Paul got very close. He suggested that bitcoin should be back by stocks,w hich has many interesting insights into where what he's thinking and how he views it. You know first of all he recognizes stocks have value intrinsically. That's good. Second of all he thinks that a crypto currency backed by a stock well he's suggesting that they be used for companies centralized companies so he's just a small step away from saying well what if the company could be completely automated. And the third thing is that he says that bitcoins should be backed. Well it's too late to back Bitcoin by anything, but he's using Bitcoin in this generic kind of sense as in bitcoin is a name for cryptocurrency, just another generic term yeah which is good and bad for Bitcoin. it kind of dilute the Bitcoin brand or concept and it means that under Rand Paul's perspective we are also Bitcoin

Fuzzy:
Very, very interesting. I'll leave it at that for if anybody has any questions with regard to that please let me know. Otherwise, I've been seeing kind of a slowing down of the questions in the chat channel so i'll give you guys about 10 seconds to ask question. If not we'll go ahead and we'll move into the third portion of the session.

Dan:
No the architecture for, someone asked the question, “Is the architecture for Bitshares exchange roughly the same as NXT?” Now they describe it as you find a pairing of two clients wanting to trade and then execute between the two. No, our trading engine is much more robust than any other trading engine. The user broadcasts the bid to the network and then the network, in the next sense, it be forgers in our sense the delegates whoever produces the block well deterministically match bids and asks to generate to perform that market maker feature. So you don't actually have to find someone with your client to pair with to trade. You just say “here's a bid”, submit it to the network, you can take your client offline go away on vacation come back and have your trade executed for you.

Fuzzy:
So it's kind of like an auction house, or you post it there and then you can walk away and that bid can be matched at another point.

Dan:
Earlier I described the claim conditions, the conditions you know you can sign by signature, by N of M signatures, or claimed by password for the cross chain trading. A bid is just a “you can claim this asset if you pay me this other asset at this ratio” and assuming those conditions are met in the transaction they get the asset you get the other asset so it's really a very simple process and then the only person that execute those trades is the it's the minor or the black producer.

Fuzzy:
Sounds Good.

Okay, I'm going to go ahead and I'm going to move over to the subreddit and over here, like I'm going to go, I'm going to go ahead and use this as a reminder for all people who are listening. You can go over to the Beyond Bitcoin Show subreddit and ask any of the developers questions in the future. You can also vote on, vote up or down the questions. I ask that you try to be careful how you vote. Going in and zerg voting zerg waiting down a specific question probably wouldn't be the greatest idea. We're looking at these possible problems at this juncture but we'll figure that out as we go.

The first one with four points is by “schlink583”. Do you think that fast confirmations in Bitshairs X will be important for traders? How important do you think the transaction speeds are for the Bitshares DEX?

Dan:
Alright, so in Bitshares X the trading speed is going to be one block every 30 seconds initially, and then it's going to be every 15 seconds if we can in the future. The importance of this speed, it's helpful in some sense, but I think it's definitely better for confirmation times and for the rate at which we can you can be sure that your transactions are final which minimizes the amount that a trade can change between the value of something can change because when you place your bid and when it's executed.

If you want to repeat the question? I'm not sure I fully answered it.

Fuzzy:
Well it's no problem. Do you think that fast confirmations in Bitshares X will be important for traders? How do you think the transaction speeds are for the other Bitshares DEX? So it's kind of a two-part.

Dan:
Do I think it's important? Yes, I think transaction speeds is always important to everyone and all of our DEX are going to try to be as fast as possible.

He says, Can depose are delegated proof of stake ever be as fast or faster than ripple confirmations in about five seconds to enable trading and micro payments or is their approach that might be faster? If so, when do you envision the changes to Bitshares X to reduce the transaction times from 15 to 30 seconds to times that rival the ripple consensus algorithm?

Dan:
In theory, I could set it to be faster than ripple. I don't think Ripples's confirmation times would be at five seconds if they were not effectively centralized on five servers all relatively the same location. If you were to scale ripple to be a hundred nodes the time it takes to get consensus would probably be much longer. So to answer your question, I think delegated proof of stake can be the fastest solution. It's faster than ripple consensus, in theory, because we already know who's going to produce the next block they just have to produce it and send it to the next person and the delegates could get really efficient and directly connected to each other in the order in which the blocks that they'll be producing blocks and therefore the only limit to the block production rate is the processing time in the network bandwidth. Which I don't think Ripple can rival.

So, when I set 30 seconds, or 15 seconds, I'm really trying to make sure that we minimize the potential of forks due to a delegate missing it until we've got the necessary infrastructure and other support in place to allow delegates to connect directly. Until we know what type of performance the nodes are going to have as far as processing these transactions, executing the market orders. I don't want the CPU or processing time for any given block to be a factor in the delay.

The other thing we have is a delegate that is slow could and misses their opportunity to produce a block could get penalized if they miss and it might not be their fault it might be a network issue.

So, in theory, delegated proof of stake can be faster than Ripple and I think in practice Ripple is only fast because right now it's effectively centralized. They're using the Trust model, like we're using right now.

Fuzzy:
Any questions with regard that to that from the voice community? If not we'll go ahead and we'll move on.

This is a question from “schlink583” to me. By the way collecting questions in advance is a great idea. Thank You. For the benefit of the people who can't join the meeting and aren't able to listen to a recording is there any way to post on here some brief summaries of answers given during the meeting?

I answered this on the actual subreddit, but for just to make sure everybody is aware. This is kind of a couple-man operation right now we're just starting out. I'm looking for representatives from multiple communities. I'm also looking to make sure that we can start getting representatives from other communities who can be part of this over time I think that we will begin having individuals step up. This is largely a volunteer effort though, so we'll see. I will always do our best to make sure that we can post these these audio recordings and I know that “legendphase” is planning on actually doing some things with us as well.

He's posted a few of the podcasts and I believe he's eventually going to be taking a big part, maybe the biggest part in hosting them.

And we'll hit up the third one in the list which is, Which of your competitors do you like more? Give us the order for example 1. Ethereum, 2. MasterCoin, 3. Counterparty, 4. Colored Coins, 5. MadeSafeCoin, etc? Which of them have the most possibilities to succeed in your opinion and why? Except the Bitshares which is obvious.

Dan:
Well that particular question is certainly loaded. Let's see here, the, I don't like MasterCoin or Counterparty because they're on the Bitcoin blockchain. I don't think they scale they're a nice toy. MadeSafe is not really competing with us and I've said on the forum that I don't think. The only system out there that is NXT, it's proof of stake. If every person participated in the mining process it'd be effectively like a dividend, because I want to get a cut of the fees proportional to their stake. So from that perspective, NXT has a lot going for it. I don't like that it's built on Java, but they did get it out there first and they're doing a pretty good job.

So, I think Colored Coins is a concept that has been around since the very beginning and they haven't gotten anywhere, so they don't have a business model there. It's also based upon the Bitcoin blockchain. Which leaves Ethereum. I think Ethereum is a great DAC concept. You could take their model, replace it with delegated proof of stake and have a great DAC. I think it's a special purpose DAC that focuses on a the problem of, well what do we do with all the little odds and ends of contracts you want to do for which there's not a dedicated DAC, it's the miscellaneous junk drawer of the cryptocurrencies.

Fuzzy:
Okay, now you made a couple points that I would like to see if we could talk about a little bit with regard to that question. You said NXT was your favorite of them. I've recently been paying attention to NXT, it has been forked quite a number of times and I was wanting to know if you thought there was any way of them utilizing that that fork the different forked chains to their advantage?

Dan:
You're going to have to expand on that.

Fuzzy:
It's interesting the whole concept of like cross-platform, cross-chain trading and things like that and I know that the chief complaint about NXT is generally what you see with a lot of of these technologies. Where you there you have to pretty much keep up to date on this technology at all times to see what opportunities there are to invest and if you're not one of the first person's aware of it the window of opportunity to invest is usually pretty low. So even though it might have been open to everybody, there was a large portion of people who got into it before before everybody else was aware of it so they pretty much have a huge stake in this. So with that said, I'm trying to figure out what are the kind of what what ways would you improve upon NXT if you could improve on it especially taking into account the the forks that have been coming along?

Dan:
I would just improve on their forging algorithm. They're working on this concept of transparent forging. You know I've actually found it extremely hard to find any information out about NXT, maybe that's the same problem people have with us. It's good to know that we're not alone, but transparent forging is something that they're moving toward and it's very similar to what we're trying to do. They've kind of gone to a delegated proof of stake if my understanding is correct and that you can delegate someone else to forge for you. So that's probably the only thing I do to improve their system is go to delegated proof of stake. Other than that, I can't speak to their internals of their implementation or the potential of implementing BitAssets on top of NXT.

Fuzzy:
Pretty much answers a lot of it. Does anybody have any questions with regard to this stuff, this particular question?

Fuzzy:
Jaime says, “I have a theory when Cryptsy takes days to withdraw NXT, I suspect Cryptsy wait for when they are going to forge a block and then put all their withdrawals on there to catch the transactions. Is that plausible”?

Dan:
Well you know that or they're doing things manually, because it's not a clone of everything else.

Fuzzy:
And this is very interesting because it brings into into the conversation something that's pretty dear to my heart if anybody want reads the forms they know. We have a lot of centralized exchanges that are quite literally the way everything seems to be working out, it seems like there can be a lot of opportunity for collusion in these exchanges it see the benefit of a few.

Dan:
Define Collusion.

Fuzzy:
Well, maybe let's say, you're able to vote for instance on Cryptsy right, to get a coin on there. You're everybody's given the ability to vote or they can pay the owner of Cryptsy in those cryptocurrencies to get onto the exchange.

Now if you're able to do that and get the information of when it's going to go on the exchange you know that you can actually pump up the coins value, using Twitter accounts, telling people that it's going through the roof, you know posting something that is really not true news, but it doesn't matter in the moment. It gets people going on to Cryptsy buying as its as its progressively going up and they are actually selling their initial shares. And then once it reaches a certain point as it always, does it drops, the price drops. So effectively, the people who've paid for the coin to be put on and potentially the owner of the exchange can profit greatly off of something like this.

Dan:
Well this gets into the whole discussion of insider trading which I think is more of a creation of the government and the media trying to differentiate it. If you think about it, all trades or internal trades, you know knowledge that causes you to disagree with the consensus and therefore you act on it.

So there's no way you can eliminate insider trading. It's best just to acknowledge that it exists and to make your purchasing decisions based upon what you know and what you know you don't know. In this particular instance, someone who buys a coin that is first released, unless they have reason to expect it to go up they should not be buying. I think a little bit of education here would help a lot, and it's not actually a problem no one is doing anything morally look wrong as long as all all trades are voluntary and you know people decide they want it they trade it. That's the only thing that matters. As soon as you start getting into well is that insider trading or not, it becomes impossible to define, impossible to have a clear rule and as a result it actually gives governments arbitrary power over all financial transactions.

Fuzzy:
Well that's a very good point. So leave the free market open and we need to get more people out there teaching other people how to actually trading the crypto currency markets.

With that said, does anybody have any final questions because we have reached about that point where it's an hour? After cutting some of this stuff out we probably will have a site that's about an hour, about 50 minutes.

Dan:
I thought this was a great session thank you very much for putting it on and I look forward to next Saturday.

Fuzzy:
Sounds Good.

I'll take this opportunity right here to thank everybody for showing up, including you Bytemaster. You bring the people to ask the questions man, so we're trying to do something for all crypto currencies but you are the first mover in this, so thank you.

We're going to just end the meetup now I'd like to remind anybody that we are looking for hosts from a Bitshares crypto community and all other crypto communities to moderate the hangouts in Q and A's. We're always looking for volunteers for we can always find something for you. Please email [email protected] with any questions concerns or ideas and I look forward to seeing this grow.

All of you guys here right now are part of something that's going to slowly grow. It might not seem like it at first but you'll see over time that if we're trying to produce something that's valuable for the community that we're all going to gain.

And I want to remind people that getting tips, and forcing people to pay isn't necessarily the only option. My take on it - pay to play conferences are great meet-ups are great but it's always nice to give another option to the people who don't have the means to access those. If we give to the communities we teach people about crypto in general we better prepare them like kind of like what Bytemaster just said with regard to the exchanges they're not going to get hurt as easily, they'll make better decisions on their own and in-turn is going to kind of help the system as a whole the gain real value and you guys are adding something right now so thank you for your time.

---

⭐ My favorite Bytemaster quote from this episode:

Ethereum - it's the miscellaneous junk drawer of the cryptocurrencies.

---

Let me know what you think, please leave your comments below.

As always, please upvote this post and follow me
if you like my work and want to see more.

If you think others will enjoy this
Please ReSteem it!

Thanks for reading!