Why not have a simple way for developers to start an AGS 2.0 fund for any qualified DAC team that wants to develop - let them do more fund raising on our forum


Sent from my iPhone using Tapatalk

Quote from: AdamBLevine on March 03, 2014, 03:00:15 pm

Now sure would be a good time to take some of those angelshares funds and create a big bounty that is paid to the first successful dac to pass xx% profitability for its token holders, honor PTS/AGS with 10% each and survive 6 months.  Then it would be *obvious* that PTS will have value in the future, whereas right now honestly who knows.  In the video it said that Bitshares Music was currently in development but when I spoke to the invictus folks it sounded like they were thinking early 2015 as a reasonable guess. 

This seems like an exceptionally good use of AGS funds as it adds value to the ecosystem and provides a very attractive reason for people to develop for invictus based technologies and honor the 'invisible hand' social contract vs. picking one of the literally seven other protocols that are tackling this same broad problem.   Invictus does not exist in a vacuum, but it's developing like it's in one.   Don't define the tech or specifics as has been done with bounties to the point, just define the outcome you want and let the market participants self organize into the winning combination.'

 

How will you distribute this bounty?

Here is an idea. Award the bounty according to the stake proportion shareholders have in the winning DAC. Since none of us would know which DAC would be the winning DAC you'd end up with a lottery effect where we buy shares in the DACs we think will be the winning DAC.

So if for example you make a DAC, now I'll buy shares in your DAC and will work hard to help your DAC be successfully profitable so that we all can have the award distributed in proportion to the amount of shares we own in your DAC. If I own a lot of shares in your DAC then I'd of course deserve most of the credit for the success if your DAC wins the award.

The same way Angelshares were mapped to PTS, Angelshares could be mapped to the shares of your DAC. The shareholders of the winning DAC would wake up one day to find that their shares have inherited an award of bonus Angelshares mapped to their shares in some proportional ratio. In the future the businesses in the ecosystem could sweeten the pot by adding shares of their own to the award pool.

Simply put, I support the idea of having a bounty for this. I just think the bounty shouldn't go to individuals but should be distributed proportionally to the winning shareholders because that is a way to get people to buy shares in hopes of winning the Angelshare bonus (or whatever future reward bonuses that go beyond this), it also would make people work really hard to make the DACs profitable to win the shareholder bonuses.

Nothing would stop us down the road if multiple DACs are successful from pooling the awards in such a way that the pot gets sweeter for DACs that come along later. Maybe instead of just winning Angelshares maybe the DACs of 2015 could win Awardshares in different DACs according to the innovation or technical problems they solve for the ecosystem.

The Awardshares would be used as an incentive to drive innovation and we could have a top 5 list with the top 5 DACs in some category all winning some awards.

Awardshares would function like bonuses or higher salaries for all participants. This would encourage everyone to participate in making DACs a success because eventually the potential for Awardshares would be so huge that everyone would want to get involved.

The social contract says 10% for Angelshares and 10% for Protoshares. That would mean 80% remains. If 10% were to be for Awardshares then the DAC creators could award these shares at their discretion to other DACs provided that criteria is put in place, voted on democratically by the community, and that the shares are held in some sort of escrow so that once the community votes on the winners the shares are automatically distributed without much human involvement. It should be automatic that the winning DAC gets the Awardshares held in the pool, escrow, or whatever.

Quote from: toast on March 04, 2014, 12:55:50 am

Lots of good ideas being generated in multiple threads right now.. Anyone want to curate?

* move % of angel funds to community multi-sig
* offer bounty for first non-I3 DAC

I think instead of just thinking about "Angelfunds" we should just develop Awardshares as an idea. Let it be a community controlled pool via multi-sig. We vote on the winner to receive the Awardshares. The Awardshares could include any cryptoassets we put into the pool but primarily at this time it should be Angelshares. This way there is flexibility so that in the future should some DACs have shares which a lot of people want or which can be used as an incentive we could put them in the pool.

Awardshares would allow any current or future DAC creator to feed some of their valuable shares into a community controlled pool. Then you would have a list of DACs and a PoS voting system so that the community can vote on the winner. Some criteria should be something which is automatic and which cannot be disputed.

So whether or not a DAC is profitable is not something we should vote on. We should try to find some technical means of measuring the profitability of a DAC and then turn that into a data feed which produces a true or false or a number in the form of a percent. Then the DACs with the highest percent should rise to the top of the list. So the data set could be the top 5 most profitable DACs of 2015, and then let people vote on which DAC is their favorite and speculate by prediction markets which DACs will win the battle of the DACs or the DAC of the year award.

This way you get PoS shareholder feedback, but you also get some data from a data feed which needs no voting. The real question is how to measure profitability? We could make Coinmarketcap and several sites like it a data feed but is that really the right way to go about it?

If consensus can be reached on what is the most profitable, and on what success is, yet there is room for preference to be included, I think it will work great.

Lots of good ideas being generated in multiple threads right now.. Anyone want to curate?

* move % of angel funds to community multi-sig
* offer bounty for first non-I3 DAC

Quote from: AdamBLevine on March 03, 2014, 11:27:52 pm

I don't believe AGS will ever be liquid, but when Bitshares comes out you will have those as liquid assets derived from Angelshares

I agree.  We can't stop someone from releasing a coin that maps to AGS and we can't stop the market from honoring that coin instead of AGS if it chooses.  We couldn't initiate or support that ourselves without altering the value proposition on which people have been relying.

The natural, gradual process of liquefaction is when new families of DACs spin off.   BitShares X effectively liquifies its portion of AGS for holders on February 28th.  If BitShares Bingo winds up serving as the prototype for a family of honorable gaming DACs then more of AGS would become liquid at that time.  So eventually AGS could become mostly liquid through the sum of all children it spawns.

"ex" Goldman Sachs...really bothers me.  Why even take the risk of adding these people to the mix? 

The stakes are very high and though I tend to believe in a good few conspiracies, I am trying to understand why I should not be concerned with "one block chain to rule them all", "ex" Goldman Sachs "advisors", a pyramid structure placed in the logo (though, thank god, no "all-seeing eye"), and the token ironically being called "Ether".  Any one or even two of these would not be so bad...but all of these together make me want to go back and get my tin-foil helmet...and armor. 

I will check back here periodically to read the answers...and hope I can be convinced that Bitcoin technology is not being co-opted by "low level" individuals with historical ties to known Terrorist Banking Cartels.   

For now, back to work!

I'm making a toolkit for the BTS and larger crypto ecosystem. I'm starting a thread because public expectations are a good commitment strategy.

https://github.com/nmushegian/das

C++ sucks balls for anything other than the core networking/blockchain code and the whole dev setup now scares away newcomes who give up after 30 minutes. Most of the stuff new devs would want to work on are not in the core BTS codebase anyway, they want to quickly and easily interact with the BTS ecosystem.

Ideally Dan will establish a byte-by-byte format for transactions so he can offload building the wallet (misnomer: "transaction maker" - the wallet itself is trivial) onto us. If not there are still a lot of "top-down" software that needs to be written.

This week I plan to deliver:
"das" top-level command routing
"das angel" Angelshare utilities, like a merged btc/pts wallet for holding your AGS and code for looking up snapshot allocations
"das keyring"  <- BASIC "wallet" functionality, like just a named list of ECDSA keys and CLI commands for the basic operations on keys

Today I plan to deliver:
* Hopefully most of this week's goal for das keyring.
* Nicely organized super-easy-to-get-started repository


Important stuff in the future:
* BTS X market maker bot
* BTS DNS auction CLI interface


edit: btw "DAS" is distributed autonomous service/system... More friendly and more general that DAC in my opinion.

Quote from: luckybit on November 23, 2013, 08:28:35 am

I realize this could be done without a DAC, I'm just wondering if doing it as a DAC would be better than not. Any advantages?

I think almost no advantages and it would take a rather large amount of time and effort to develop.

Many people have ideas but no idea how to code. I propose a bounty be posted for clean templates of the existing code bases in the community for easy use, along with detailed guides on what can be modified in graduating order from a total noob to semi-competent developers. Thus far NRS,MMC,PTS are great but anyone who wishes to use them will suffer to get things started.

Additional Bounties could be set up for introducing new useable code bases for different applications.

This will help kick start DAC deployment outside of the usual developer circles.

Great, i haven't looked into the BTS code properly yet. However if they take to this idea, maybe they should break it up into individual components. eg A set of BTSX bounties and a set of non BTSX bounties. One could be setting up a new github account with clean template of PTS, with a wiki that describes the process of forking and creating an alternate. This will tie in with the genesis initalization guide i wrote. Fot BTS maybe it could be a repository in the same account doing the same, even keyhotee will have a clean template. Compilation of these clean templates, the tools required and guides would be a huge step for the ecosystem. NRS code as well can be added.

Then as we progress, anyone has access and can request pulls that improve the code as a template. So much possibilities.

another interesting prospect of standardizing the code is a funded drive toward merge mining. I say this because the fall in hash behind PTS saw a rise in NRS, hat is not the most desirable situation as i prefer both chains to bw working, not one at the expense of the other.

If it is a possibility, it would solve the problem of hash power being divided between chains. This also puts the possibility of modular codebase in reach.