I think this could be attract devs like bees to honey.We're all familiar with counterparty free
Market Pegged Assets (MPA)
and
issuer backed
User Issued Assets (UIA).
Theoretically, there could be a third type:
Fee Backed Assets (FBA).
A developer installs a new function that charges fees for its service and pays those fees to holders of a UIA she creates for that purpose.
She naturally starts out as the owner of those revenue producing assets.
She is free to sell them since each one is a revenue generating counterparty free asset backed solely by the blockchain.
Since they have no counterparty, they are not a security. They are simply capital equipment, like selling a mining machine.
This new kind of digital asset trades like any of the others but has fascinating new properties.
There could be a new asset for every new revenue generating feature in the whole ecosystem. Developers recoup their costs by selling (or pre-selling) these revenue generating software devices (or keeping them to earn the revenue they produce.)
Thoughts?
This is very long, but I think a very good discussion question to see how BM, Stan, and Dev Core are approaching the referral system. I think it has great potential. But I see the referral system having more longwithstanding success if smart contract developers can earn referral fees for the contracts they make. My concern is in the long-run, initial referrers don't provide innovative developments as much as developers do. Referrers can just squat on the capital effort that brought them all the users in the first place and still earn fees without providing any new value-add as compared to a developer. They in some ways get the public to squat as many accounts as they can for them. At least that's one way this would work.
Last week BM spoke about specialized contracts being made for BTS. This will allow curation and through testing and takes a "soft update" each time. And afterwards, Cryptosile brought up a good idea that I've been pondering myself. In one of the posts he asks:
https://bitsharestalk.org/index.php/topic,17801.0.html
"I'm curious if we could provide these two things:
1. Allow a specific smart contract to pay 10% of fees to the creator of said smart contract.
- This would incentivize a lot of developers to submit smart contracts and compete for inclusion into the blockchain."
To me this would spur use of smart contracts, experimentation and new products for the general public. Sure it would be in the interest of the first referrers to create new types of contracts. But I see this as further incentivizing development on the Bitshares blockchain and bring tools and smartcoin programs that mesh in the bitshares network. A pie in the sky hypothetical example: someone wants to build a decentralized Uber on Bitshares can do so and profit. But in short, incentives and rewards are further brought together.
Not to mention it would allow the little guy to profit for bringing something new to do table. He will be able to build a better business model to compete with the veterans and not be squatted out like the current method has it.
Is this something that is currently being discussed or considered? Do you think this is feasible or even possible for Bitshares under the current structure of the referral system?
I hope you guys are finally coming around to what I've been probing you guys on. Of course I think inevitability this Fee Backed Asset will have to be used. Augur is one of the first to do this in the Bitcoin 2.0 iterations. Can Bitshares follow the same act succesfully?
Flashback:This is very long, but I think a very good discussion question to see how BM, Stan, and Dev Core are approaching the referral system. I think it has great potential. But I see the referral system having more longwithstanding success if smart contract developers can earn referral fees for the contracts they make. My concern is in the long-run, initial referrers don't provide innovative developments as much as developers do. Referrers can just squat on the capital effort that brought them all the users in the first place and still earn fees without providing any new value-add as compared to a developer. They in some ways get the public to squat as many accounts as they can for them. At least that's one way this would work.
Last week BM spoke about specialized contracts being made for BTS. This will allow curation and through testing and takes a "soft update" each time. And afterwards, Cryptosile brought up a good idea that I've been pondering myself. In one of the posts he asks:
https://bitsharestalk.org/index.php/topic,17801.0.html
"I'm curious if we could provide these two things:
1. Allow a specific smart contract to pay 10% of fees to the creator of said smart contract.
- This would incentivize a lot of developers to submit smart contracts and compete for inclusion into the blockchain."
To me this would spur use of smart contracts, experimentation and new products for the general public. Sure it would be in the interest of the first referrers to create new types of contracts. But I see this as further incentivizing development on the Bitshares blockchain and bring tools and smartcoin programs that mesh in the bitshares network. A pie in the sky hypothetical example: someone wants to build a decentralized Uber on Bitshares can do so and profit. But in short, incentives and rewards are further brought together.
Not to mention it would allow the little guy to profit for bringing something new to do table. He will be able to build a better business model to compete with the veterans and not be squatted out like the current method has it.
Is this something that is currently being discussed or considered? Do you think this is feasible or even possible for Bitshares under the current structure of the referral system?
one of the ideas proposed, or at least how i understood it, was creating a worker proposal that states that a UIA and the funds the sales of this UIA would be used to pay the developer for a particular feature. see : https://bitsharestalk.org/index.php/topic,20207.0.html .
what stan proposes is essentially the a sophisticated version of this idea, marketed with a pretty bow (not to say that we shouldn't consider marketing when presenting ideas), but presented as his own.
essentially, features that we want developed can be funded by fee backed assets, and over time provide income by charging shareholders who use such features. those who invest and own said fba's profit.
the reference to the origins of this idea (or at least when i first encountered it) actually included in this post.
Revenue sharing model to allow crowdfunding major BTS blockchain additions
BTS could potentially enjoy major blockchain improvements without having to pay for them or take the risk that they are duds by creating a revenue sharing model that incentivises external developers and investors.
We're all familiar with counterparty free
Market Pegged Assets (MPA)
and
issuer backed
User Issued Assets (UIA).
Theoretically, there could be a third type:
Fee Backed Assets (FBA).
A developer installs a new function that charges fees for its service and pays those fees to holders of a UIA she creates for that purpose.
She naturally starts out as the owner of those revenue producing assets.
She is free to sell them since each one is a revenue generating counterparty free asset backed solely by the blockchain.
Since they have no counterparty, they are not a security. They are simply capital equipment, like selling a mining machine.
This new kind of digital asset trades like any of the others but has fascinating new properties.
There could be a new asset for every new revenue generating feature in the whole ecosystem. Developers recoup their costs by selling (or pre-selling) these revenue generating software devices (or keeping them to earn the revenue they produce.)
Thoughts?
one of the ideas proposed, or at least how i understood it, was creating a worker proposal that states that a UIA and the funds the sales of this UIA would be used to pay the developer for a particular feature. see : https://bitsharestalk.org/index.php/topic,20207.0.html .
what stan proposes is essentially the a sophisticated version of this idea, marketed with a pretty bow (not to say that we shouldn't consider marketing when presenting ideas), but presented as his own.
essentially, features that we want developed can be funded by fee backed assets, and over time provide income by charging shareholders who use such features. those who invest and own said fba's profit.
the reference to the origins of this idea (or at least when i first encountered it) actually included in this post.
Yes it's a good idea. I came up with a similar base concept a while ago but didn't receive any replies at the time.Revenue sharing model to allow crowdfunding major BTS blockchain additions
BTS could potentially enjoy major blockchain improvements without having to pay for them or take the risk that they are duds by creating a revenue sharing model that incentivises external developers and investors.
Edit: Well Bitcoinfan also came up with stuff in that vein.
...
My initial thought is that the liability then is in the hands of the issuer. Those that are buying are buying it with the expectation of future profit and therefore is issuing a type of security.
Perhaps the dev is in a country where this might not be the case.. but then it gets dicey in regards to who buys it where.
I think you have to remove 'she' from the equation, and let it be decentralized. She can create the FBA, set the price per share, and issue it.. and when that's done that's done. It moves to committee-member control. It can either be fully bought up and funded by the maker, or the market is open to buy it.
I think the key element here is that once the FBA is created, it really belongs to the blockchain after that. This removes all liabilities in my estimation as far as offering securities is concerned.
Thoughts?
My initial thought is that the liability then is in the hands of the issuer. Those that are buying are buying it with the expectation of future profit and therefore is issuing a type of security.
Perhaps the dev is in a country where this might not be the case.. but then it gets dicey in regards to who buys it where.
I think you have to remove 'she' from the equation, and let it be decentralized. She can create the FBA, set the price per share, and issue it.. and when that's done that's done. It moves to committee-member control. It can either be fully bought up and funded by the maker, or the market is open to buy it.
I think the key element here is that once the FBA is created, it really belongs to the blockchain after that. This removes all liabilities in my estimation as far as offering securities is concerned.
Thoughts?
I think a security is a security no matter how you dress it up. And there is no point dragging in the committee members to front the deal. If you want to stay out of trouble with the law, look at how kickstarter works.
How does this fit into a discussion people had a long time ago, where smart contracts would be created to each feature developer would earn from each feature they would implement? Maybe I'm confusing things? I don't know why the dev would need to sell those assets created from fees, when fees could just be paid in BTS and he could just get part of the fees.
That way people would have one more incentive to develop stuff. Referral program + earning from each use of their feature.
Don't know why there's the need to create a FBA when BTS can be used already to simplify things. And would give BTS more importance instead of splitting money through countless different assets.
This would be the same as when people buys apps on the playstore or apple store
How does this fit into a discussion people had a long time ago, where smart contracts would be created to each feature developer would earn from each feature they would implement? Maybe I'm confusing things? I don't know why the dev would need to sell those assets created from fees, when fees could just be paid in BTS and he could just get part of the fees.
That way people would have one more incentive to develop stuff. Referral program + earning from each use of their feature.
Don't know why there's the need to create a FBA when BTS can be used already to simplify things. And would give BTS more importance instead of splitting money through countless different assets.
This would be the same as when people buys apps on the playstore or apple store
There are lots of different business models that will get the job done.
Pick one that doesn't violate any of the tests that governments routinely use to determine if something is a security.
I'm intrigued by the applicability of the Uber model for a privately operated taxi.
Build 100 robotic software taxi cabs that deliver private packages for hire.
Program them via blockchain logic to take turns delivering packages.
Sell the cabs to the network in exchange for a set of tickets good for rental minutes on a cab.
Resell/trade those tickets on the open market.
This way, anyone can rent time on any of the limited supply of "cabs" and earn fees for performing delivery services.
So the STEALTH FPA could represent all available minutes on a network-owned fleet of robotic taxi cabs.
Buy up as many minutes of their time as you want and you have your own revenue generating business with no counter parties.
Meanwhile, the GUI for doing STEALTH transfers doesn't need to reflect any details at all about how the transfers are taking place metaphorically under the hood, whether by robotic cab or C++ function call. They just specify the amount and destination and pay the fee and their funds are automagically teleported somewhere else.
Poof!
Would you be able to have funds automatically returned if a minimum isn't reached? For example, LottoShares could say if 150,000 worth of investment is not reached in 60 days, return funds to original sender.
There are lots of different business models that will get the job done.
Pick one that doesn't violate any of the tests that governments routinely use to determine if something is a security.
I'm intrigued by the applicability of the Uber model for a privately operated taxi.
Build 100 robotic software taxi cabs that deliver private packages for hire.
Program them via blockchain logic to take turns delivering packages.
Sell the cabs to the network in exchange for a set of tickets good for rental minutes on a cab.
Resell/trade those tickets on the open market.
This way, anyone can rent time on any of the limited supply of "cabs" and earn fees for performing delivery services.
So the STEALTH FPA could represent all available minutes on a network-owned fleet of robotic taxi cabs.
Buy up as many minutes of their time as you want and you have your own revenue generating business with no counter parties.
Meanwhile, the GUI for doing STEALTH transfers doesn't need to reflect any details at all about how the transfers are taking place metaphorically under the hood, whether by robotic cab or C++ function call. They just specify the amount and destination and pay the fee and their funds are automagically teleported somewhere else.
Poof!
One thought I had: If a committee controlled account is not involved in the issuance of said FBA somehow... it would be wise to create a multi-sig mechanism to guard against various unfortunate events which could occur, such that should an issuer of the FBA die, or lose their owner key, or become compromised somehow, all would not be lost. The issuer could choose a number of trusted parties with whom to vouchsafe control over the FBA. There's probably a really uncomplicated way to achieve this, conceptually it makes sense to me, not sure of the best mechanics. Food for thought.
I think perhaps initially though in the creation of an FBA.. having it available the same way other assets can be created might not be ideal..
I think an FBA Proposal needs to be submitted first.. make clear the parameters of what it is how it works etc.. then once that is all clear submit it to the committee to create it. If the committee members .. they can then vote to have it enabled.
Great idea. @Stan do I understand you right, that all those features with their "feature coins" have to be approved by the shareholders still?
I assume yes. How should it work differently in Bitshares currated apps model...
So it could be that dev1 gets feature 1.1 approved (e.g. stealth tx). Then dev2 gets feature 1.2 (ring sign) approved. Then comes 1.3... With 1.3 shareholders decide to take 1.1. and 1.3 out again (not anymore part of the bitshares code).
That would be a possible cenario right?
Just thinking out loud a bit...
In how I further described the process it requires no approval by the community. It's done through the committee members. Every FBA should have the opportunity for fight or flight based on its own merits. Prior to issuing an FBA the committee holds the vote to determine if the FBA was done with due diligence. I thought about having it run through the Worker proposal for this function, but then we are back to community members at large voting down features that they 'feel' is not important or should not be focused on. The beauty and point of the FBA is that if an entity or people are willing to invest their own money to create something then it should be give the opportunity by those that want to see it succeed.
What if the FBA that is created and issued into the market for sale for funding, all the funds will be submitted into the RESERVE POOL (same pool that Worker Funds come from) and inside of Worker pay methods there is a new type of Worker pay method that can be paid via the FBA supporting the feature?
A wish list item might be to have the FBA created be able to have the initial funding specified in the Asset of choice. In other words if someone says it will cost 20,000 CNY to get done, then the sale of the FBA Asset wlll be in CNY and passed through to the Worker as such. This to me will eliminate some market variable waste, and also help the project managers/developers with their own tax reporting/accounting.
I like this method better.. it will keep our funding method for new features in the same place under Worker.
In how I further described the process it requires no approval by the community. It's done through the committee members. Every FBA should have the opportunity for fight or flight based on its own merits. Prior to issuing an FBA the committee holds the vote to determine if the FBA was done with due diligence. I thought about having it run through the Worker proposal for this function, but then we are back to community members at large voting down features that they 'feel' is not important or should not be focused on. The beauty and point of the FBA is that if an entity or people are willing to invest their own money to create something then it should be give the opportunity by those that want to see it succeed.
Approval from committee members isn't enough, it has to be worker proposal. Or we could create new kind of worker proposal that is meant only for FBAs. But the point is that if the new feature will require a hardfork, it should be approved by the shareholders. Just like it is now.
I don't think that the problem of shareholders voting down FBA-proposals will last very long. It is problem only for a short period when only party that has enough skills and knowledge is Cryptonomex. When there are other developers who can be hired to implement features, they will be voted in without any problems because they don't consume any manpower from more important features that are funded by DAC.
What if the FBA that is created and issued into the market for sale for funding, all the funds will be submitted into the RESERVE POOL (same pool that Worker Funds come from) and inside of Worker pay methods there is a new type of Worker pay method that can be paid via the FBA supporting the feature?
I think this is too limiting way for funding. Remember, we are trying to get privatized funding here. There can be many different kind of developers, companies, investors and crowdfunders and not all of them are interested in having the funding go through reserve pool. Simpler way is just to give them the FBA and they can do whatever they think is best and suitable for their business plan.
A wish list item might be to have the FBA created be able to have the initial funding specified in the Asset of choice. In other words if someone says it will cost 20,000 CNY to get done, then the sale of the FBA Asset wlll be in CNY and passed through to the Worker as such. This to me will eliminate some market variable waste, and also help the project managers/developers with their own tax reporting/accounting.
I like this method better.. it will keep our funding method for new features in the same place under Worker.
This is not only and maybe not even preferable way for funding. I predict that there will be lots of complaining in this kind of contracts. Crowdfunders want a feature and somebody says "yeah, I'll do it for 20k" and after a while they announce that "20k isn't enough, I want more".
I think easier way would be that a company or a group of developers make the feature half way ready and then announce that "we have a new feature and if you want it implemented in Bitshares, we want in exchange an FBA with these parameters". BTS shareholders don't need to know how much the feature cost to develop – all that we have to care is that will it be a good deal for Bitshares. Do we want that feature on the blockchain, how many users it could get, etc.
i would like to do it KISS - keep it simple and stupid!
in bitshares to many features are to complicated, so let us think how we can do a FBA without much overhead.
1. some people create a multikey account. could be the committee or something totally different
- they control the creation and maybe the payment if wanted
2. buyback can also be handled with this multi account or better something is coded for automation buyback
I agree.. that's where I started from and as my post continued I pushed the idea more towards it happening within the Worker space. However when it comes to managing the FBA ongoing, it really should be in the hands of the committee members just like MPAs. Otherwise we invite liabilities and other issues into this.
I agree.. that's where I started from and as my post continued I pushed the idea more towards it happening within the Worker space. However when it comes to managing the FBA ongoing, it really should be in the hands of the committee members just like MPAs. Otherwise we invite liabilities and other issues into this.
What kind of liabilities you mean? I'd like to see concrete examples so we can understand better what we are dealing here with.
On the other points, we are not necessarily on the same page here.
My central point is that FBA is a deal between Bitshares and developers/investors of a feature. Bitshares recieves the feature and developers/investors recieve the FBA.
There is no need for any kind of FBA-sale. There might be a sale of FBAs because it is funded by crowdfunding, but that should be managed by the crowdfunders. It doesn't even need to happen in these forums, it can be other forum, Kickstarter or something else. There might be a genius idea for some cryptocurrency, and the developers choose to implement it in Bitshares rather than making their own blockchain. They can design and crowdfund it in their own forum and come to us when they have a deal to propose.
This is what I meant with when I said that funding via reserve pool is too limiting. Funding doesn't need to be on the blockchain. Blockchain can be used for that, but I don't see any reason why it should be done only with Bitshares blockchain.
Privatized funding doesn't need to look anything like the worker system we now have. I think it will be a lot more efficient when there is a small group of developers/investors who handle the whole thing and don't ask much from the community. They don't have to waste time on the forums where lots of people are complaining how expensive it is, or how they want it changed, or how they are never going to use it. Instead developers/investors can design a killer feature on their own. They will of course keep all the profits, so they have great incentives to really focus on getting the feature right. They don't need to ask other people to market the feature, because they have an incentive to do it themselves.
What you are calling for is a model that disenfranchises the community at large or others to participate. The ultimate result of this, as we have seen demonstrated, is that the community will not support something that is integral as part of how bitshares works unless they can have at least the opportunity to participate.
Is this change actually happening or is it a proposal?This "is" going to happen for the Stealth feature ("is" happending depends on whether shareholders approve the worker and the implicit hard fork)