Discover Top Posts Tagged with #dev hangout

BitShares Dev Hangout : Plasma

Episode 124, December 18, 2015

On this weeks BitShares Developer Hangout, Dan Larimer of Cryptonomex discusses “Plasma”, the referral program, vesting, Fee Backed Assets, a new undisclosed feature that is scheduled to be rolled out mid-2016 and he answers Community questions.

Create a BitShares Account

Transcript

bytemaster: So it's been a crazy week with a couple of high priority security releases. The new hardfork went into effect, so I wanted to just give everyone a brief update of the things that we discovered and the things that we fixed this week.

As you know there was a scheduled hardfork that was planned for a month and launched and took effect on Wednesday. Despite all of our efforts to aggregate all hardforks into one upgrade event, we found a significant vulnerability that xeroc (Fabian) discovered in his testing. This vulnerability would cause a proposed transaction that failed to show up in the transactions history as if it had succeeded even though no balances were actually transferred. Which could have been devastating to exchanges that didn't upgrade.

So we released an emergency fix for that particular issue and gave all the exchanges about 24 hours advance notice before we published it to the forum. So the hardfork is out and we are happy that no money was lost and all records are updated. I'd like to thank all of the Witnesses that were very responsive as well as the exchanges for being responsive in getting their system's updated.

That's one thing we do need to keep in mind in everything that we do. This is software, it's got features that haven't been heavily used still baked in there and use of those features might expose things that our unit test have not covered. Just beware of that. But every day that goes by the software is getting more and more secure and the bugs are being worked out of it.

DataSecurityNode: Is there any benefit to leaving vested balances vested beyond the date that they can be withdrawn? Like for Witnesses, does it shorten the time it takes for the balance to be vested or is there any other benefits?

bytemaster: The way vesting works for everything except merger balances that you import, so Witness pay or anything that's vesting from cash-back or referral program or Worker Proposal pay, those all vest on a coin-day basis. Which means that if you've got a million BitShares that are vesting over a period of one year, you've got to have a million coin-days before you can withdraw a million BitShares.

So if you leave all million in there for one year, at the end of the year you'll be able to withdraw a million BitShares. After 6 months you will have accumulated 500,000 coin-days, which means you can withdraw 500,000 BitShares. That will lower the balance to zero and you still have another 500,000 coin-years to accumulate, but you've only got 500,000 coins left in the system, so it's going to take a year from there. So by withdrawing early, so if you withdraw at the halfway point it's going to take you a year to withdraw the remaining half. If you withdraw daily, you're going to get some money as soon as possible but it's going to take you the longest to withdraw it because you're reducing the rate at which things actually vest.

So bottom line is if you need the money now you can take it out but it's kind of like you're paying interest with time. No matter what, you have to have a million coin-years to get a million BitShares if it's a one year vesting term. And if you reduce the amount of money that's in the account it's going to take longer to earn the time. So it's like saying, if this was interest it says no matter what you have to pay $50 in interest. If you remove some of the principle the remaining principle is going to take longer to earn the same amount of interest. That's the basic concept there.

Thom: Did you say that is not the scheme that is being used for the things like Witness Worker pay?

bytemaster: Say that again.

Thom: Did you say that, what you just described in terms of vesting does not apply to the Witness and Worker pay or does still apply to those two categories?

bytemaster: It applies to everything except for the balances imported. The vesting balances imported from BitShares 1.0. Those are linearly vesting on a fixed amount every day.

Thom: Well my first take on it is it's kind of a good idea from the standpoint of encourage savings within the BitShares ecosystem. But it does have some impact, I actually just withdrew a sizable amount for all the reasons so it's going to perhaps impact my ability to pay some fees. So I'll need to consider what you just said in relation to that.

bytemaster: Basically if you withdraw your full balance the remaining balance will take the full year to withdraw. So every time you take everything you can out, what's left is going to take a year. If it's a year. I think most vesting balances are like 3 months for the cashback, in which case if you take everything out it's going to take 3 months from your last withdrawal to finish it off.

I would like to emphasize though that the security vulnerability that xeroc discovered would have been very difficult to exploit. It would require doing a custom build of the wallet with cherry picked updates. So most users wouldn't have been able to fix it. So we detected it and fixed it before anyone really had the ability to figure out what it was and or exploit it themselves.

fuzzy: Historically speaking we can say that this type of thing has happened in Bitcoin multiple times. Not necessarily this specific exploit, but there have been exploits that have been found that have required hardforks right?

bytemaster: It's sort of like the transaction malleability issue. You trick the exchange into thinking you sent a transaction that didn't actually go into the network. And it's just because we have an advanced feature with proposed transactions where you can propose something and fail. It wasn't even the core validation logic that was the problem, it was in how we were reporting what happened to the users of the wallet API. It wasn't even really a blockchain vulnerability per se. But it's all been taken care of. Everyone responded quickly. So that's very good.

fuzzy: Everybody give xeroc a HIGHFIVE.

bytemaster: I'd also like to give him a HIGHFIVE for his new service that he announced of 2-Factor Authentication for BitShares. I really like the initiative of using the advanced features we have with the hierarchical threshold multisig permissions to help BitShares users create a more secure wallet.

Thom: He's on fire with the BIPS [BSIP - BitShares Improvement Proposals] and everything.

bytemaster: Yes, so speaking of BIPS [BSIP’s], we have a new Worker Proposal that has been created called STEALTH. I guess someone can probably provide a link to it using CryptoFresh. This worker proposal will pay 100,000 BitShares, about $300 to xeroc for maintaining the Worker Proposal. And it's more of a poll / measurement of Community support for the hardfork required to implement the STEALTH features. It will create a Fee Backed Asset using the income from the blinded confidential transactions to buy back that asset.

The Fee Backed Asset will be allocated to onceuponatime in exchange for funding the development of the GUI to implement that feature. So for $300 the BitShares network gets the first Fee Backed Asset and it gets privacy features which I think are absolutely critical. There are features that we want to do where privacy is extremely important and there are lots of people that have avoided importing their balances from BitShares 1.0 because of the lack of privacy.

And it's rather disconcerting to have everyone follow you around. Maybe if no one knows who you are it's no big deal. But anyone who's a big name in the Community people watch their every move. People are constantly asking why'd you do this, why'd you do that and what's going on here. I didn't realize anyone was paying that close attention to every single transfer I do on the network. But there's a lot of things like that where I would like my privacy and anyone else who's vocal or a large stakeholder also wants their privacy.

Small stakeholders doesn't quite matter as much, you don't quite care if people know that you've got $100 and you transferred it to another account or whatnot. But anyone who's got millions of BitShares cares about privacy. So the privacy feature is something that I think is very important and it's actually a barrier to adoption by a lot of people particularly people with money. It's something we need, it's something that we've already invested the time in to implement the confidential transactions at the blockchain level. We just need to provide the incentive.

So this proposal helps fund Cryptonomex, it keeps all the guys employed with the revenue we need to do things, so it's a critical proposal in several different ways. They're having arguments that maybe we should work on something else first and that something else should be of higher priority, but the only way that we can work on other things is to have those other things actually funded. And that's a bit challenging.

I'd like to let everyone know about some of the other things that we are doing. A new guy Michael has been working with us the past two weeks and he's already implemented significant improvements to the API to be very similar to Poloniex's API for getting the order book as well as placing and submitting orders. We hope to roll out those API changes probably after Christmas, he's gone on Christmas break right now.

Early January the new API's should be available. Meanwhile Valentin and James have been working on a new wallet server backup process, so users can have their private keys stored on the server encrypted and can recover those keys from any device so long as they remember their username and password. And that includes all of the wallet settings for their wallet.

So you'll be able to migrate from machine to machine, device to device, login anywhere and have access to your funds, but your password will never leave your computer and even if the server is compromised and all the encrypted data on the server is leaked, they would still have to brute force not only your password but your email and your username which is not associated with the wallet in any way shape or form on the server. So effectively all wallet content is salted with username password and email and there's no way to guess the salt because the salt is not stored next to the file on the server. So that's some of the things that we've been doing to continue to enhance BitShares.

Now this new wallet infrastructure is part of actually the Plasma project and BitShares is going to benefit from the work we're doing there to simplify wallet management, so users will have to migrate from the current wallet to the new wallet. It will be completely seamless but you will have to upgrade your lightwallet and then do an email validation. That's how the server prevents spam. You do have to have your email validated to get a token to authorize you to store a wallet on the server.

And this will be opt-in, you don't have to use this, you can continue to use it in the current mode where it's only kept locally and not stored on the server. But we recognize the need to address ease of use for the majority of users. Users who don't want to have the responsibility of backing things up themselves. Even if you're responsible and back it up you can lose your backup and all kinds of other things, so this simplifies things. Currently it's very difficult to move your wallet from one machine to another, this will make that trivial. It gives people an experience with OpenLedger like any other centralized website, but still more secure. Those are the things we are doing there.

There's two other Worker Proposals that I would like to bring to your attention. Xeroc and svk have workers. They've been doing a great job working directly for BitShares improving the GUI, improving the documentation, providing tech support for all the exchanges. The work they're doing is irreplaceable and they've done so much of it for free for so long, anything we pay them now, we're still in their debt for a long time.

Svk produced the original BitShares block explorer for BitShares 1.0 with almost no compensation whatsoever from the network or from Cryptonomex or Invictus. He's contributed significant amount of work to the actual wallet without receiving any actual cash from Cryptonomex. So we really appreciate these people and I want to encourage a little bit of decentralization of development here. So xeroc and svk are operating at least half-time completely independent of Cryptonomex to benefit the BitShares Community and focus on BitShares.

Please support them. These people need the income to live and to continue to be a part of the Community and it would be shame to lose them if we don't do that. Cryptonomex would hire them but we'd just be a middleman and we'd have to fund [Dan's computer went to sleep].

Anyway we wanted to make sure Cryptonomex was not a middleman or seen as a gateway to all the developers so xeroc and svk can answer directly to the Community for what they're doing for these Worker Proposals. So please support them in what they're doing. I believe svk already has enough votes to get elected, but we can always use more votes just to show that we appreciate them.

fuzzy: Now real quick, something that popped into my head and bytemaster said it for the second time, only the second time that I recall hearing him talk about it, was that this was part of the Plasma project. I'm not going to go too deep into it, but I just wanted to say now it seems that this is more than an idea.

bytemaster: I wanted to actually take some time to talk about Plasma because lots of people have been contacting me privately asking for updates and information about it and I figured I might as well introduce some of the concepts here, particularly because Plasma is going to be an open platform. There's not going to be any licensing or anything and it's a technology we want to get broader consensus on things.

So the idea with Plasma is to break down the blockchain concept into layers. You can think of traditional blockchains as having the consensus, the business logic, the P2P protocol, all that stuff baked into a single app. If you wanted to use Graphene to build a blockchain you're automatically going to be doing Delegated Proof of Stake and you're going to have to have voting and you're going to have all these various rules. And you're also at risk of hardforks in the event different nodes in the network are running different versions of things.

So what we wanted to do is to reduce the cost of developing blockchain based applications and by reducing the cost of developing them more people can build these applications. The idea is this, every single website out there is better off on a blockchain. Every single business could use a blockchain to implement their own internal business processes whether it's timekeeping or accounting or inventory management or customer support or contracts or shareholder agreements, every single thing a business does.

They currently have a systems to automate it [and] could benefit by being on the blockchain. And the way they benefit is primarily through decentralization of authentication. Normally when you login to a website the server verifies who you are and then changes the database. After the fact there's no way to prove that the server actually verified who you were, and the server wasn't hacked and just modified the database.

There's no integrity of database content. There's a central point of failure in the authentication link and at that same place is where all evidence of authentication is lost. So we would like all websites to be powered by a blockchain. Now this concept creates an architecture that's very similar to the Flux architecture described by Facebook and ReactJS, where you have unidirectional data flow. User actions flow through a dispatcher, the dispatcher then drops to the various data stores which interpret the actions and update the application state and then all the user interface is doing is a read only view of the state.

That's the architecture that Facebook is using. The only thing we're changing is that the dispatcher becomes a blockchain and that the actions become signed by the users. But we wanted to go a step further and say the blockchain itself should not care what the actions are. It exist for one purpose only and that is to create an irreversible record of events. The interpretation of those events is separate, that's business logic.

When you separate those two concepts you can create a token-less blockchain, a blockchain that can be used for any application because it's consensus is nothing more than multisig production of blocks. You can have a single server that just sits there like an SQL database, logs it and records it or you can have it replicated and signed off by multiple parties. But the blockchain itself is a very simple straightforward system.

Let me step back a little bit here and say the main problem we have with people adopting blockchain technology is actually development time. Everyone needs customer smart contracts. To develop them requires specialized developers. You need developers that have either studied something like Ethereum or know C++ and can do encryption and then know about all the security of hashes and so on and so forth.

Blockchain technology is something that's very expensive to implement today. The goal of Plasma is to reduce the cost of implementing it so that anyone who knows JavaScript can create a fully functional cryptocurrency complete with user interface in one page of code. This is one page of code that can sit on your monitor at one time, it's like a complete cryptocurrency. You can transfer it, you can do everything you can do with Bitcoin, minus the scripting, but transfer from key to key balances. And you can implement all that knowing only Javascript and without knowing any cryptography. That's the goal of Plasma.

Thom: Isn't most of what [Thom's mic died]. It's a matter of API isn't it mostly?

bytemaster: Yes. So the wallet API is one thing that we're going to bring to BitShares and that's part of Plasma in the sense that it completely abstracts the storage and saving and management of private keys. So as a developer in Plasma you just have to say, the user wishes to take this action and you give it a JavaScript object. It passes it to the wallet, gets signed, sent out to the blockchain and then the blockchain (it's just a standard blockchain, generic, you don't' have to write a new one, you can just use the one we provide) will log your event with sub-second confirmations, because it will be a centralized blockchain. The event after the signature's verified will be passed to a JavaScript application, Node.js application, it just implements the state machine, it gets the action you just took, updates it's internal state and then communicates the state change back to the application.

So from a developer's perspective you write a little bit of JavaScript code on the server that manages your state machine. Which is just processing events of whatever structure you define. And you help combine it with the wallet on the server side, that is handling all the cryptography for you. That's the concept of Plasma and it's not targeted toward the same market as BitShares or even decentralized blockchains or public blockchains.

The idea is to take blockchain technology and to use it for every web application. But the goal, you should be able to build your next web application on a blockchain with Plasma cheaper and faster than you could using other web stacks. Ruby on Rails and so on and so forth. It's there to give you a more secure robust environment for rapidly deploying web applications. Because you can focus just on your business logic and it's very very robust.

So that's what we're doing with Plasma. It's just a set of technologies designed to break the blockchain down into this low level stuff. It uses a lot of lessons we've learned from Graphene, to make it all open. So what does this mean? This means that smart contracts become nothing but JavaScript. They become nothing but JavaScript modules. If you want to build an application that's a state machine, you just pull in all of the JavaScript modules from other smart contracts and they'll process the events that are relative and you can build your combined state. Which is the cumulative result of processing all events that are relevant to the set of smart contracts and their dependencies that you're using.

It's all written in JavaScript and it doesn't have to run on the server and it's not part of the validation. It's a deterministic result generated by processing an irreversible record of events. The goal here is to reduce developer cost so that anyone who knows JavaScript and can follow a few simple rules about avoiding the nondeterministic behavior of JavaScript can write simple applications that benefit from a blockchain structure.

xeroc: Essentially Plasma is nothing more than seeing the blockchain as an immutable database, that's it.

bytemaster: It's an immutable database for the blockchain combined with an API that allows rapid development for web applications.

ingenesist: I seem to recall something about infinite transactions per second?

bytemaster: Sure. By infinite transactions per second I mean you can have multiple Plasma blockchains and they just have to include the headers of each other into one another. And then the application logic can deterministically parse given one stream of blockchains, the subset of events that are relative to it, from all blockchains. So you can have an application that combines two or three different blockchains that pulls all the events in in a deterministic order and generates a state.

Which means any individual blockchain. First of all there's no validation at the blockchain level, so all the expensive computations that we're doing that slow down things, they disappear. The blockchain can be as fast as you can receive, log and record data. And then they can be combined so you can make it parallel by sharding it. After you determine the order by making them parallel and aggregating you can then apply your business logic after the fact to determine the conclusion. So yes.

The primary difference with Plasma is that inclusion in the blockchain merely means someone said this and sign this at this point in time. It does not mean that money was transferred or any other side effect was approved or valid. It's sort of like saying, "I wrote you this check", but it doesn't say whether or not the check cleared or bounced. That's an application level concept.

ingenesist: Do you have any comments on the other Open Ledger announcement from Overstock and IBM?

bytemaster: I haven't looked into it other than the fact that I noticed the name was the same.

bytemaster: Someone asked a question, "Under Plasma does that mean the contract is not fully trustless?". That's not the case. At the end of the day all blockchain technology is, is you take a public record and everyone agrees on a set of code to process it and the outcome of running the universally agreed on set of code on the universally agreed upon order of events is a universally agreed upon derived state.

In the case of Bitcoin that state is the unspent output set. In the case of BitShares it's all the account balances and everything else that's going on. So you can have the hash of the JavaScript, that is supposed to be used to interpret the state, part of the events that get broadcast. So you can document the code and record it and agree upon changes and updates and hardforks. A hardfork is nothing more than switching which interpretation of the order event you're using. An example of how we've applied this concept in BitShares is that we have the events in the blockchain for all the transactions that have occurred but there was a misinterpretation or a bug in how we were doing referral program fee calculations.

By fixing the bug and rerunning the software over the same set of events we got the correct balances and the derived state was now correct and we could continue forward. It's the same exact concept, it's just you eliminate the potential for forking because what you're actually agreeing on is a very small subset of rules. Those rules include things like, has it expired, does it link into the current chain and is it signed by the proper authorities. There's a few other things, but it's all very generic protocol level rules.

fuzzy: Have you heard of Taulant's white paper regarding Pactum?

bytemaster: Yes I've been talking with him about this and he's one of the people who wants to bring this discussion public, which is why I'm talking about it here today is to sort of get the ideas out there and people start thinking about it. Because there's really two philosophies out there. One is the philosophy that things have to be extremely rigged and all the code and all the validation is actually part of the protocol. And the other, the philosophy I'm taking is one of, let's log the intent of the users and then implement the code in such a way that it best expresses the intent of the users or the outcome of the various users actions.

It's sort of like separating it out. In software terms you define an interface and you leave the implementation interface separate. It can be implemented twenty different ways and there might be bug in the implementation and that bug doesn't change the intent of the API, it just means there's a bug in the implementation.

I guess it's kind of like in programming, you either have statically checked, compile time generated code or you have runtime dynamically typed code with polymorphic interface and all of that. I'm taking a more dynamic approach to blockchains with the mindset that at the end of the day it's people and consensus that matters. And two that when it comes to business processes things are inherently centralized. And they can and will change the code that interprets things at any time they need to in order to accomplish their business. They are the masters of the universe.

The blockchain record is still irreversible. Every action everyone took is logged and the old interpretation is still there. So you still have to have consensus on which version of the code to run for interpreting the data. We're just giving a little bit more freedom and with that freedom you make it a lot easier to develop applications. You lower the bar for getting 99.9% of the benefits of blockchain technology.

And it's because you're targeting a different market. We're not targeting people who are trying to create cryptocurrencies and decentralized ledgers that are censorship resistant and the powers that be can't take down. We're targeting people that want to build a more secure website. And if you tell the people, in order to build a more secure website you need to go all the way to the extreme complexities that Ethereum has gone to or you need to program your website business logic in C++ in Graphene. People aren't going to do it. It's too expensive to build websites that way.

So this is where we're hoping to take the technology. We're building the blockchain itself off of the parts of Graphene, the very low level parts. But we're doing all the serialization for everything in JSON rather than binary. Now we're recognizing that being developer friendly is the number one most important thing, which means you should be able to program your business logic in any programming language you like using any framework you like. And that the existence of the blockchain and public keys is just something that is behind the scenes, you don't have to think about it.

sxis: What prevents attacks, anyone from changing essentially the state?

bytemaster: The first step is the immutable ledger. Once you've logged everything everyone's done and you've publicly committed to the hash of the log with the merkle root of all actions you can't take it back without someone knowing. So you've got some accountability there. The second thing is if the code is open source then anyone can run the code themselves and come to the same conclusion. Which means it's now possible for people who develop websites to detect if their database has been modified.

If the database has been modified in an inconsistent way they can run multiple instances of the same state machine, come to independent conclusions of what the state should be and if there is any disagreement between anyone of their databases they know something has happened. Then they can go back and figure out which of their computers was compromised. So by having redundancy and interpretation and the log being immutable, you've actually prevented the permanent corruption of the state, of the derived state.

It's sort of like with Graphene. If someone compromised your computer and changed the file on disk that represents the blockchain state and then you started up your node and you read that in, your user interface is going to report that bogus state to you. But if you're comparing the data from your local server to something from OpenLedger and you got different results, you'd be able to detect that your local copy was hacked.

So what prevents change? Well first, everyone has a copy of the code, GitHub logs all changes to the code. Everyone can run the code and the actual ledger is public [and] signed off on. And in the case of Plasma, the transactions do implement TAPOS transactions as Proof of Stake.

Namely when you sign a transaction you're also signing the hash of a recent block produced. Which means you're action is only valid relative to the state of other actions that you've previously seen. And so if someone tries to give you a bogus state or bogus blockchain your actions will be invalid in the context of the real chain.

fuzzy: What incentives somebody to be a full node in this situation then?

bytemaster: First of all, the reason to be a full node is the same reason that Twitter provides full nodes and anyone who has a website provides a full node for their website application. These are for private blockchains for implementing websites. This is not for decentralized systems like BitShares and Graphene. It does not have the constraint of having to be completely trustless or distributed trust. It operates under the assumption, the trust model, that a company is going to want to own all the nodes and it might put different nodes in different datacenters managed by different IT employees. So it's decentralized internally and they use multisig on every block that's produced for their own internal records.

But for the outside world no one else even has to run the blockchain. This is about enabling people to use blockchain technology to give their users private key control over every action, so users of this website know that the company can't fake your actions. They can't say that you posted this tweet or that you posted this on the forum or that you made this commit to GitHub, because it won't have your signature on it and you can be in charge of your keys if you want to be.

So this is about giving multi-user websites the ability to use distributed authentication with private key cryptography seamlessly combined with the audit trail and everything else that it provides the company. So the company gets the audit trail and security and they run the full nodes. There is no mining process, there is no Delegated Proof of Stake, there is no token, it's just the people that setup the blockchain, they define who the signing keys are and the people who are in control of the chain can sign to change who's now going to be in control. So you can add and remove keys that can sign for the blockchain.

But it's certainly more centralized, but it's not trying to target the same problem that other cryptocurrencies and BitShares and Ethereum are trying to tackle. It's going after the much bigger market of every website out there.

fuzzy: bytemaster would you mind if I moved into a couple of forum questions here shortly?

bytemaster: Before we do that I do want to say something. BitShares is still our priority for the decentralized distributed market. That's why I was trying to let everyone know that Plasma is not a competitor to BitShares. Plasma can actually be used with BitShares with custom transactions. You can use BitShares as the ledger for logging all of the events and then Plasma can just pull those events from BitShares and pump them into the same state machine. So there's some overlap of course but BitShares is benefiting from the infrastructure we're building for Plasma in terms of wallet hosting and so on and so forth.

fuzzy: So it makes it possible for people to more easily create these user interfaces that have been considered by many to be one of the areas where we need to work on most. Is that a safe way of saying it?

bytemaster: It means you can use BitShares as your public ledger for any application you want as long as your application is completely self contained or only depends on read only access to the state of BitShares. If you want to have read write access to BitShares, and by that I mean the ability to receive coins, hold them in escrow and control where they go, you need a hardfork so you're part of the protocol. But things like Follow My Vote can implement all of their voting logic on BitShares without a hardfork. People can implement a forum on BitShares without a hardfork.

fuzzy: That's a beautiful idea.

xeroc: I have a question, not about Plasma and Graphene in particular it's about the Fee Backed Assets in general. When I was writing these BSIP for Fee Backed Assets I was wondering about the maintenance account. These accounts can not be created any time, they have to be created on a hardfork. And what I understood was that this hardfork also had to sharedrop the initial shares of that particular Fee Backed Assets. Is that about right?

bytemaster: Yes the hardfork, a Fee Backed Asset involves writing code to automatically buy it back according to some blockchain feature that didn't exist prior to the creation of the Fee Backed Asset. So there's already a hardfork going on and part of the hardforks overall process would be defining; it can be an existing account or an existing asset, it just has to define which asset it's going to be and which account it's going to be.

The idea is that that largest holders of a Fee Backed Asset would have multisig authority to; the issuer account of the Fee Backed Asset would be multisig authority set proportional to the largest shareholders in that asset. And that account may have additional privileges, not necessarily guaranteed, to set properties and things related to that such as fees.

So if you're going to implement a feature and you need some dynamic property that's going to affect the future revenue stream of that asset, the largest stakeholders in that asset can create and fine [or find?] a transaction like the Committee. It works just like the Committee only for that; and rather than doing voting of all the holders we just take the top 5 or top 7.

The reason not to do voting is just because it's the single biggest most expensive calculation we have to do on BitShares right now. And it's what slows down resyncing more than anything else. So doing that for a million Fee Backed Assets would just complicate things.

xeroc: Ok so it would be possible to; it's pretty much like share-dropping future fee revenue stream, correct?

bytemaster: Yes.

xeroc: Cool.

fuzzy: Welcome to the sharing economy.

bytemaster: So the way I've described this to people is, you can either go; if you have some idea that you want to implement like Auger or [inaudible] prediction markets or eBay, you can either go create your own blockchain, issue your own token and try to get people to adopt it and use it and pay in your token for that feature. Or you can do the same thing on BitShares and create a Fee Backed Asset. By implementing your other blockchain concept on BitShares you get the network effect and interoperability but you still get to keep the same revenue stream.

In the Ethereum world someone creates a contract, every time you use their contract they take a fee, is how it works there. So an Ethereum contract can be that. So an example of something that we could do for Fee Backed Assets is actually take the Ethereum VM and integrate it into BitShares and then the Fee Backed Asset would use a percentage of the gas would use to buy back that asset.

And if we did that then we could have a faster DPOS backed Ethereum and the people who fund the development of that would profit if that features actually used and generates revenue in the form of gas. Those are the types of things that are possible and just to think about.

fuzzy: I'm glad I asked this question, however I have to say that this is like betax said it's a lot to digest. It's definitely a pretty big deal if it works out as planned.

fav: It's impossible to explain LTM marketers how to get their revenue out via console. Is there an ETA on a GUI function that acts like a claim cashback functionality?

bytemaster: Yes. I was under the mistaken assumption that it had already been implemented. That's something that svk or James or Valentine could implement in half a day if they wanted to. I've asked it to be a high priority item to get implemented.

fuzzy: For smartcoins and UIA's whose value against BTS is known at any point in time, could we introduce a BTS value threshold below which the transfer fee is very low? So I'm assuming for the tokens that are not extremely valuable at any given point, maybe a new token that is used for something that is not necessarily monetarily valuable, at least directly, the transfer of which those tokens might be lower in terms of the transaction fee? Would you be able to get into that a little bit or answer the question as he asked it?

bytemaster: Yeah, it's a complicated subject to do percent based fees. I mentioned in the STEALTH case that you can't even do it because you don't know the amounts involved. So obviously if you're using STEALTH confidential transactions you can't do percent based transfer fees. If you want to lower the transfer fee then; if you want to make it percent based you need a very very solid sense of what something is worth. I think you could probably only do that for bitAssets that have a Committee fed price feed or a Committee fed, Witness fed price feeds.

The other thing that you could do is charge a high fee for transfers and then do cashback later after a vesting period. So the transaction is cheap except for it's kind of like a mail-in rebate. YOu get your money 6 months later. You pay 50 cents today and in 6 months you get most of it back. That provides value to the blockchain, because the value of a token is based on how long people hold it. It's how many coin days people hold it for and when you look at hyperinflation the period of time that people hold the coin of the currency decreases to almost zero. They get it and they immediately sell it. Whereas several people hold it and you encourage holding that provides value, because you're basically a continuous spy on the asset.

And that still prevents spam but from a referral program perspective lower transfer fees could undermine businesses. Going to a volume based thing for BitShares might make sense. But, yeah I don't have an easy answer to that I'm kind of rambling now.

I would like to say that I am working on something for BitShares that I think is going to be game changing in terms of driving demand from users within an outside of the cryptocurrency space and in particular driving demand for BTS. I'll provide more info on that as things progress but the concept is so big it's going to put the referral program on steroids and dramatically increase the amount of BTS that is held. And also going complete without any dilution.

I've some got some big things I'm planning for BitShares. I think it's huge. I've mentioned a little bit about it on the forums. You can guess what post where I was testing the waters on some concepts. But yes, I think that we can; the problem that BitShares faces is that exchanges, prediction markets, cryptocurrencies, confidential transfers, those are all things that exist everywhere. There's competition both from centralized solutions and other cryptocurrency tokens. We need to create something that doesn't exist anywhere else. And yet something that everyone wants and the value is not derived from transaction fees. I don't have a code name for it yet. Let's think of a code name here. "Project Christmas", there we go.

My main point of mentioning that is I'm really excited about it and I have a hard time keeping things I'm excited about to myself. But also to let everyone know that I'm still looking for ways to really bootstrap BitShares and ways to fund it without dilution and to grow the ecosystem. The whole stuff we talked about Plasma that's part of the Cryptonomex business plan to reach broader markets, but I still have my eye on BitShares and the things that we can do as a decentralized system.

I haven't gone over to the dark side of centralized solutions. I just am trying to make money so I can continue to innovate on behalf of BitShares. So no this will not be ready by Christmas. If I had to guess on the timeframe for this, we're talking 5 or 6 months. So don't go pumping or dumping BitShares as a result of this, that's not my intent in this. My intent is only to let you guys know that I've got some really cool ideas. I'm working it over with various people and trying to find funding and line things up.

Obviously if I can't have funding and I can't get buy ins the projects going to struggle. But yes, very exciting stuff coming and will probably cause lifetime memberships to increase in price from $100 to $1,000 because the value of each user that's brought to the system will be that much higher.

One of the things I want to do for the referral system, while I'm on it, is; users can start referring other users even before they upgrade to a lifetime member. The only restriction is they won't be able to claim their referral income until they themselves have generated that threshold of fees. Which means you can go and start referring people and do all kinds of stuff and see the money piling up before you even decide to upgrade. And that will hopefully bring down some barriers.

But that's not why the value is going to increase to $1,000, it's because I've got a new revenue source to fund it. So yes, and if they hit the threshold of fees themselves basically they've paid someone else, whoever referred them enough, then they can claim it. The whole reason for these thresholds is to prevent people from creating one account and then referring themselves without paying anyone any referral fee.

So that's one tweak I want to make to the referral program as part of my new idea, but yes there's some stuff here that self transfers will be beneficial for, but this I think is bigger than prediction markets. It's bigger than the smart contract platform. And in my opinion for BitShares perspective it's bigger than Plasma. Plasma might impact more businesses everywhere but the impact from this would be really exciting for BitShares.

fuzzy: You said earlier that you were talking to Taulant behind the scenes. Is that pretty much where this relationship ends or are you guys actually working together in any way shape or form with BitSapphire, can you talk about it?

bytemaster: The goal with Plasma is to work with as many people as possible. I wanted to try to get the ideas flushed out and described, but it seems like a lot of people have been coming to us and talking about it to make sure they weren't doing the same thing. Plasma is really a cool technology that we want to exist so that we can build things. But the challenge with Plasma that we've been trying to figure out is how to make money with it.

No one builds websites on proprietary software stacks. They use open platforms because they don't want to be locked in. Which means we can't charge anything for Plasma. Plasma chains are private so there's many different chains so there's no network effect from Plasma. The only reason we're building Plasma is the same reason Facebook built React, they needed it. They needed it to build further applications and to get developer support. So the reason I'm talking about it is because we recognize the more people that know about it and start working together; if someone else can fund and develop a competitor and we don't have to pay to develop Plasma we'd be more than happy to use it because it's going to be free for us too. So that's the basic concept there. [mic cut out] in the industry.

fuzzy: Sounds in many ways like it's the epic version of what SuperNet was trying to accomplish. Only I guess it brings in private blockchains to so that's different. It's pretty huge. I'm looking forward to seeing more about this stuff.

bytemaster: There should be updates to the GUI, I know the developers have been working on it. So it's just a matter of testing to make sure they didn't break anything before they release it, but I will check with Valentine to see if he can get a release out today. If he didn't release one on Wednesday. To be honest I don't pay attention to all of the releases of the GUI updates. So there's a team of people that are working on batches of features to release with the goal of doing it every Wednesday. If it didn't get out last Wednesday it will certainly be out next Wednesday.

This transcript was made possible by the following BitShares Community members donations :

onceuponatime (1000 BTS)

roadscape (1500 BTS)

dele-puppy (1000 BTS)

btswolf (1000 BTS)

stan (1000 BTS)

samupaha (2000 BTS)

alohacs (1000 BTS)

zapply81 (1000 BTS)

xeroc (1000 BTS)

fuzzy (300 BTS)

tuckfheman (4200 BTS)

#dev hangout

Trending Tags

Recently Viewed Tags

#dev hangout