Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - luckybit

Pages: 1 ... 179 180 181 182 183 184 185 [186] 187 188 189 190 191 192 193 ... 195
2776
Keyhotee / Re: How will Keyhotee guard the usage of private key for ID?
« on: December 29, 2013, 11:12:14 am »
Keyhotee asks you for your password when you start the program and will keep your private key in memory only.  On disk it is always encrypted.

In order to process incoming messages your private key needs to be 'live' at all times.  There is no way around that. 

With the wallet system you only need your private key for sending money.

Bottom line, you are relying on the physical security of your computer and OS while Keyhotee is open.    Any bright ideas on how to improve that?

Might be a good idea to make use of the trusted platform module.

2777
It seems that the title is already determined:
Social Consensus Software License (SCSL)

And it has to apply to all future DACs which use this license and not just Bitshares. Anyone who uses code written under the SCSL should abide by the SCSL. A good model for this would be the GPL and copyleft licenses such as the Creative Commons.

Invictus Innovations should not be in control of this because it's bigger than Invictus Innovations. This license is supposed to last even if Invictus Innovations goes out of business.

2778
General Discussion / Re: Whats your strategy on PR?
« on: December 29, 2013, 09:19:13 am »
Contact whoever made this video and please give this guy a bounty to make a video explaining DACs. This is the best Bitcoin explanation video I have seen
https://www.youtube.com/watch?v=QyVeHC4X2eA

2779
The distributed economic allegiance system:
A participant may pledge allegiance to a participant of equal or higher level whether economic or other criteria. This pledge is sworn or sown into the blockchain.

Definitions:
Mentors are like leaders/mentors in a social network.
Apprentices are like followers/apprentices in a social network.
Pledges are a promise of loyalty sown into the blockchain.

How it all works:
Participant A (Alice) is now a sworn Apprentice of participant B (Bob) who is the Mentor. The Mentor earns a percentage of the credits that the Apprentice earns. In this way participant A and participant B are linked in an economic allegiance stored within the blockchain itself.

A Mentor who has more Apprentices would gain more credit and rewards. As a Mentor gains more Apprentices their title could reflect that.

By having this economic allegiance system cooperative competition is encouraged.

This is not the only possible economic allegiance system but is just an example of what can be built. There are endless possibilities but the main component which has to exist is to allow one address in a blockchain and public key to swear allegiance to another. This allegiance can be sworn to anything because the public key and address could be a regular corporation, an autonomous agent, a contract, a DAC, some principles, I think you get the point.

So for example if Mentor A swears to a set of principles, then their investments would be set up in such a way so that it automatically invests in what that organization representing those principles requires. That means in order for the investment to take place there are certain qualifications which would have to be met, and the Mentor would decide if these qualifications align with the principles of his or her followers, if the Mentor signs off on it then his followers would automatically invest as the Mentor does. This can be facilitated and amplified by Ciphertext-Policy Attribute-Based Encryption.

Additionally, the Apprentices would be able to set aside a specific amount of investment capital to be used for this purpose in follow the leader manner. The Apprentice is always free to break allegiance. The benefit of allegiance is that the Apprentice would become part of a guild and gain a guild badge giving them inclusion and all the special privileges associated with being a member.

Please peer review.

2780
Bitcoin's been the first, but by far not the best innovation. For example, currently 75% of hash power is controlled by only a few people/organizations (big server farms). I am happy that the development of bitshares brings a lot of ideas for the whole crypto world.

And this is the problem. People say Satoshi was a genius and he was, but he's not the end of and he's not the only. We should be pushing the innovation rather than looking at Bitcoin.

Win or lose, you have to try to improve on whatever already exists.

2781
Marketplace / Re: 200 PTS - Bounty Rules and Procedures Document
« on: December 29, 2013, 03:25:04 am »
I was recently inspired by this: http://letstalkbitcoin.com/emergent-networks-and-falling-hierarchy/#.Ur9syGQW3M4 on emergent networks.

Response to 1) I think there will always be cut-throat competition. On this project for instance, let's say there are two teams working on the problem. Only one team can win. That means it's going to be a complete waste of time for the losing team. Perhaps someone should have the unfortunate job of discouraging teams that are on the wrong track and have a low chance of winning. This would minimize wasted time. If the team was really spirited though, they could pivot and move in a new direction.

(By the by, I'm putting together a team for this. I'm thinking a three person team to set the outline and work out details. The team members must be willing to do a group video or phone conference. Our team would then set smaller bounties for other community members to write specific parts of the manual. This should be a fast way to get the job done.)
Study the work of John Nash https://www.youtube.com/watch?v=brkhuetnJmM (the Stag hunt) https://www.youtube.com/watch?v=stzPcqmyhI4  . There does not always have to be cut throat competition. That only happens when cut throat competition is the easiest winning strategy and that winning strategy is promoted by the market.

So we should not reward cut throat competition and instead reward cooperative competition. We are all on the same team as part of the same community/economic ecosystem and certain cut throat activities damage our ecosystem. Cheating for example is not good for anyone who wants to make a living following the rules. Just like how botnets aren't good for any of us who mined following the rules. If someone were just out to win in the most cut throat fashion then creating botnets is more lucrative than being fair, stealing someone elses ideas is more lucrative than coming up with your own, and sabotaging someone else's work is more lucrative than competing on merit.

If you look at how governments operate, they are cut throat and never compete fairly with each other. If we are trying to build the ideal free market then we should do what we can to try to understand how game theory can be used to produce cooperative capitalism so that competition is used only to make the overall economic ecosystem stronger, more robust, etc.

2782
BitShares PTS / Re: PTS has disappeared from coinmarketcap.com
« on: December 28, 2013, 04:40:54 pm »
Anyone have insight on this? Thanks.

People on the Litecoin forum were threatening to boycott unless they removed certain stuff.

2783
Marketplace / Re: 10 PTS - AngelShares Press Release Bounty [PENDING]
« on: December 28, 2013, 12:46:56 pm »
Can you make this a Google document so we can log in an edit it?

Invictus Innovations proudly announces AngelShares, a groundbreaking crowd funding campaign to develop new decentralized autonomous companies (DACs).  AngelShares comes a little over one month after Invictus saw a wildly successful launch of ProtoShares, a clone of Bitcoin, saw its market capitalization rise to over $25 million dollars in the first month.  ProtoShares is unique bitcoin clones in that its value is derived from a social contract to grant those who hold ProtoShares a minimum of 10% stake in all of our DACs, including our flag-ship Decentralized Bank and Exchange called BitShares.

Invictus realized that there was very strong demand for their ideas and that the money currently spent mining ProtoShares amounted to millions of dollars that could be redirected toward funding the BitShare ecosystem rather than padding the pockets of local utility companies or cloud hosting service providers such as Amazon.  Invictus expectshopes to raise over $4 million dollars worth of ProtoShares and Bitcoin in the first quarter of 2014.

AngelShares works like a mining pool where every day 10,000 shares are minted and distributed among the investors proportional to how much they invested.  Instead of using hash power as a proof-of-work like most Bitcoin clones, AngelShares uses Protoshares or Bitcoin donations as a reusable proof-of-investment.   When people mine with hash-power the value of the work is consumed and no value is retained to back the issuance of the new crypto-currency, but when they ‘mine’ with their money the value can be recovered and applied to develop and promote a decentralized autonomous company.

To get AngleShares individuals make a donation to a public ProtoShares or Bitcoin address from a locally controlled wallet.  The record of their donations are recorded securely in the respective blockchain for everyone audit.  Each day represents a new auction and a new opportunity for vigilant fans to gain a stake in the future of BitShares.   Invictus believes this new approach to crowd funding will combine all of the appeal and excitement of mining with the addictive nature of auctions to produce an engaging opportunity that will capture the daily attention of a growing community.

AngelShares represents a fresh attempt to strike a balance between techniques used by Mastercoin, Ripple and others.  The common complaints Invictus heard about prior attempts at crowd funding were that they favored early adopters or were only available to a small group of insiders or large investors.  AngelShares strives to provide an equal opportunity for everyone regardless of when they learn about the potential of BitShares or how much money they have.   Invictus believes that this model will be copied by other teams that which to crowd fund their own decentralized autonomous companies.

To learn more about the potential of the BitShares Bank and Exchange and how to participate in its development you can visit http://invictus-innovations.com.

2784
Marketplace / Re: Bounty Specification Discussion
« on: December 28, 2013, 06:03:02 am »
I agree cooperation is better, so we want people to claim dibs on a particular bounty so no one can take it from them.  If two developers both want to go after a bounty then they would have to bid lower.  Obviously two people could bid on a task and accepting the lowest bid is not going to produce the best quality code as people will bid low and then deliver late (or not at all).  These false starts can delay the whole process.  In order to evaluate bids requires us to interview developers and from experience I can tell you that interviews are very poor predictors of performance.
This was my thinking on having a bounty token. The holder of the token owns the contract/bounty in the exact proportion of the amount of the token they own with 1 being a whole token and then divisibility down from that which they can distribute to others. Then whomever redeems the token gets their proportional share of the profit all in automated fashion.

I admit this would probably take a bit of work in itself to build but it's just smooth to me.  Interviews could probably be automated away unless you're hiring someone for a long term project and you want to see how they can work with others already on the team. For that interviews can perhaps tell you how they get along. Reputation could tell you who is known to be reliable and reliability does not mean that they always finish the task but that they distribute the task to someone else far in advance of the expiration date if they aren't up to the task. It's entirely possible that someone can take a bounty, start working on it, get 25% complete and find out they cannot do the other 75%. This person should be able to redeem their bounty profit from the 25% they did complete and whomever completes the other 75% should redeem their bounty profit.

I think that if you define tasks to be small enough that a competition involves first to complete at a certain quality level then it could work.  The goal would be to keep things small, well defined, and to separate DESIGN from implementation. 
I agree with this. Design has to be separated from implementation. A design contest for example could be great for theoretical researchers, but sometimes the best programmers who can create bug free code aren't up to date with the theoretical research side.
Given that github makes tracking code / commits easy that we can make open development a requirement as well.  Blatant copies of someone else's implementation would be easy to track and the copy-cat would always be a commit behind the leader.
Good point.
The result is that design ideas could be shared, but coding/implementation could not be shared UNLESS one contestant wanted to cooperate and share the bounty by working together.  Obviously two people working together and then splitting the bounty will have a better chance of winning than solo-players. 
One thing the bounties seemed to work well for are short simple tasks which a programmer can do by himself in a few hours. Automating things with scripts for example would work great using a bounty provided that a scripting language is built in to allow this.
In other words I think we could allow contestants to 'license' their contributions to each other and claim the prize.  A contribution that contains copied code without permission of the author would be rejected.  This will force a Nash Equilibrium where two parties must agree on how to divide the bounty rather than forcing us to be the judge.
Interesting. This could work.  Lets see how it goes using this method.

2785
Marketplace / Re: Bounty Specification Discussion
« on: December 28, 2013, 03:40:43 am »
That said, these systems are chicken & egg.  Without a lot of jobs few developers will participate because they need a steady, predictable, source of new work before they consider freelance work full time.   The other problem is committing to a single developer who fails to deliver in a timely manner results in delays.  Eventually I would like to move to this model as it would be most efficient/profitable for both developers and employers.  But before we can do that we must bootstrap the development community.

I was thinking more along the lines of a combination marketing/development effort.  Everyone wants us to distribute PTS / AGS / BTS far and wide with 'give aways' that generate buzz and excitement.   In this market SPEED and QUALITY are the most important factors and with the amount of money to be made cost is almost no consideration.   So the way you get speed is to make it a race.  The way you get quality is to make it a requirement to win the race.   The way you get developers to compete is to make the prize outsized to justify the risk of losing.   The way you get a large number of developers is to pay bounties for referring the winner to the bounty. 

The problem I saw with the competition model in the documentation contest bounty in Mastercoin was that people did not and could not work together which sacrificed quality for competitiveness. I think cooperation can produce a better product than competitiveness in most situations. Competitiveness can get something completed faster but it also introduces risks which would not exist if work could be shared without any punishment. For this reason a bounty exchange model could work better because work could be divided up or exchange. You're right that there has to be a lot of jobs for the exchange model to work but if crowd funding takes off like we think it will there will be plenty of jobs for everyone.

How much marketing buzz and talent do you think we could recruit if we launched a well organized bounty campaign worth $1 million USD total divided among hundreds of bounties?  If these bounties were all competitions where the amount you earn from winning the race is 2-3x what you could earn with a straight up contract? 
I think competition for writing code does not necessarily produce better quality code. You could end up with code which is more buggy or less safe than usual. You could end up with programmers who would ordinarily share knowledge instead keeping it to themselves as trade secrets. You could end up with some trying to game the system to win the competition to get more money by stealing other peoples work.

For this reason I don't think it should be rushed but I do agree for certain specific tasks you can go with this model. For critical functionality or components I don't think competition beats cooperation and team work.
The goal would be to manage the campaign bounties in a way that is transparent, easy to understand, and predictable.  I would like to discuss how we could operate such a campaign.

I think it all depends on the budget. If the budget is big enough you could have the bounty exchange and the competitive campaigns running at the same time for different kinds of work. You could have teams working and cooperating and have competitions to solve really difficult design oriented problems.

A lot of problems with code are just about designing an algorithm or coming up with some pseudo-code. For stuff like this I think competition is best because the code does not have to work well or work at all, it just has to be some algorithm to solve some specific problem. For contests we need to find specific problems which remain unsolved and set high bounties which DECREASE over time. This would encourage people who have the solution to this problems sitting in their notes to open their notes and describe the solution. It could be in the form of a white paper, or a forum post with pseudo-code.

But I think if we are talking about writing code to secure our money we should do that cooperatively. Not a contest or competition to solve some tough theoretical problem but the focus is instead on writing secure, bug free code which can pass peer review and auditing. This in my opinion is very important.

2786
General Discussion / Re: Bounty exchange platform
« on: December 28, 2013, 02:41:16 am »
Nice idea. It would surely work. Bear in mind though, that price for services isn't the bottom line for everyone. The cheapest of anything, may not offer the best service, so it might be an idea to incorporate aspects of value distinct from price offered by having a detailed public feedback system (risks of manipulation), and by allowing requesting services to submit a detailed specification (a universal template) or minimum standard expected for service.

Badges and reputation can be used to measure competence and honor so that a competent and honorable worker has different options. This system would be set up for when there is a lot of work to be done and not a lot of time to try and sort it or dish out the work. It basically it an automated job auction system which would allow for people to log into it at any time and find some work to do for credits.

Keyhotee IDs do not eliminate Sybil attacks, they just make them more expensive.

I really believe that the concept of voting is flawed because it means giving control over your contribution to a mob who may vote to use it in a way that you think is wasteful.   Taken to an extreme, lets imagine that everyone felt a police force was necessary so they all volunteered to put money into a POT and then vote proportional to their contribution. 

Some people vote to enforce drug laws and those against the drug laws end up funding the police oppression.  While better than taxes, this is still a terrible way to allocate funds voluntarily contributed.

Voting is 0 risk and therefore there is no counterforce to discourage voting untruthfully.   In other words, I do not think that voting can reveal truth.  Markets on the other hand can reveal truth.  Someone who attempts to lie to the market by bidding up the value of something will end up swamped with sell offers.  Then they try to sell absent their demand they will lose money.   Market manipulation is only possible when the market participants lack information upon which to make a real value judgement and instead rely upon short-term market fluctuations to make decisions.   In a prediction market on something like, "what color is the sky on a clear day?" you would NEVER be able to manipulate that market to say the sky is green for any length of time without a flood of people rushing in to take the free money you are offering them.  Once you are bankrupt the market will revert to indicating the sky is blue.

On the other hand, if you put money in a pot to get the answer to the question, "what color is the sky?" and then ask participants to vote on the best answer to award the Pot then there is no cost to voting wrong and it would be easily manipulated any time there was profit to be made from it.

I support a hybrid of democratic and market processes. For example you do need people to vote on the quality of someone's contribution and on whether or not the job is complete. That process is a necessary function which can only be accomplished by a vote of some kind. A multi-signature transaction can be used along with escrow which releases or not depending on the up or down vote signal.

Here is the important point:

A badge system allows you to use the mechanism of inclusion to imbue an inner circle with special voting privileges. To earn a badge the candidate would have to be proven by passing the test and voted in by their peers, or the badge could be earned by being honorable allowing them to get special Honorshares, or anything the DAC creator wants. This allows the DAC creator to program the DAC to reward through inclusion the values that the DAC creator wants to bake into the DAC.

So if you do not support the drug war policies then you can simply set your DAC up to give Honorshares to anyone who has a proven track record of making contributions to DACs which do not support the drug war policies. There are probably more ways to do this but the badge system is powerful and should not be discounted.


2787
General Discussion / Re: An open proposal to the community and Brian/Dan
« on: December 28, 2013, 02:15:44 am »
I too agree on the fact that DAC's need to solve actual problems - approaching and acquiring an A-Team is just part of that mission. DAC's are just like start-ups. Therefor the team behind the DAC needs to be able to initially acquire "earlyvangelists" (convince them that the Minimum Viable Product is able to solve their problems) - and as they cross the "chasm" they need to produce an entirely different product and marketing strategy. Why? Because the desires of your earlyvangelist customers and your mainstream customer are fundamentally different. Therefor you need to focus your resources on making a product shaped to the needs of your mainstream customer, and create an acquisition strategy that is able to attract these quantitatively higher customer base.
Who is the mainstream customer? We have to find that out.

Sometimes this transition takes place in a natural and automatic way. Sometimes the entire workforce needs to be replaced in order to cross the chasm. And in other cases the start-up runs out of cash and is not able to sustain operations.

During this transition the startup goes from Team-centric, to Mission-centric and in their last step, to Process-centric. Process-centric is basically what a modern enterprise is all about: creating and reusing an efficient sales/marketing/development process that allows fast and agile production. This transition also means that the enterprise does not need to focus on acquiring expensive but talented people anymore. At this stage they already have a proved model that is working fairly well. All they need is your normal bureaucratic worker that is able to follow simple steps and guidelines.
The difference with DACs is there there is no boss. The shareholders all win together and if every worker can be a shareholder then even workers who run out of jobs to do for the DAC can be permanently connected at a stakeholder level to the DAC with voting rights in the DAC. This is something which would allow workers to not feel bad about their task being automated because it would make their shares more profitable.

What I don't want is for us to mirror the mistakes of the physical world when we have the opportunity to do things right. So while we can learn from the success of real world companies we should not adopt their management strategies because we don't need them here. We don't have to micromanage, we don't have bosses, we can give every employee in a DAC a stake, so we should do so by default so that there are no losers. You don't have to lose in this new world of DACs because by working for the machine you earn a stake in the success of the machine. This is totally different from the way things work in the corporate world because in the corporate world this level of efficiency is impossible with CEOs taking damn near all the shares and compensation to themselves.

Obviously we are not an enterprise; we still need to build an agile and fast-thinking/response A-Team, we still need to follow our mission, and we still need to create success for the DAC.

The fundamental difference between iOS and Android is integrity and opensource, simplicity and functionality. While iOS focused on keeping everything simple but integrated (meaning no freedom), Google focused on functionality and opensource. They gave their users much more freedom with the usage of the OS, and in addition to that, they also had much more freedom in picking a phone for their individual style.

This is precisely the point I was trying to make. The demographic we have who will want to be involved with DACs are freedom loving functionality and open source types. I think a lot of the mistakes made by Apple for sake of increasing profitability and control should not be mirrored in this community. The successes should be mirrored of course. To put it simple I believe Apple punishes the customer far too much for their own good and the fact that customers are loyal to Apple products defies reasoning. That loyalty is what makes Apple special, not their business processes.
And besides that, Google had an easy play entering the, then, new smartphone market. They were an addition to iOS and well, Symbian (can not really be treated as Smartphone software back then). So all Google basically had to do was say "Hey, here we are. Have fun. Be Free. Use Android!" Not much marketing effort needed there. But obviously all the marketing was required by the actual phone makers. They were the ones that had to differentiate the phone - and Android was just one argument.
I agree. I could see some DACs taking the Google approach and some DACs taking the Apple approach depending on the target audience of the DAC. If the DAC is going to try to capture the Apple target audience then it should follow a similar approach. I don't think Bitshares in specific would fit for that audience, or Keyhotee, but there will be DACs which do.

Keyhotee for example seems specifically designed for the libertarian mindset. It does not trust authority by design. It's designed to promote freedom and flexibility for the user.  It's open source. It to me is following more the Google model (or Thunderbird model) because it's focusing on being technologically superior. This does not mean it couldn't be rebranded later on and marketed to a completely different audience because it is open source and under the hood it would be exactly the same. Apple built OSX on top of Free BSD.
Personally, I do not know of a product that has not at least put a minimum effort into "spreading the message" (positioning and branding). But if you know some good examples, please tell me!
Netscape. Because it was one of the first web browsers it did not need commercials. Later on AOL owned Netscape and packaged it in with their CDs. This kind of software sells itself if you can just get people to try it so for marketing something technologically special all you have to do is give out free copies and convince people to use it. Bitcoin is just like that. Keyhotee on the other hand will have to be marketed because people don't understand the importance of their privacy or financial freedom. They believe that companies like Google and Facebook will care if their privacy or financial freedom is violated and that is an error in thinking which can be highlighted. Additionally the DACs could be set up in such a way that it creates an ecosystem where the values are the opposite, to allow people to experience what it is like to have their freedom because a lot of younger generations never had it to value it.
I do not quite agree with your statement that by simply stating that you can make money with Bitshares will lead to the success of the entire system.
I treat Bitshares as a new ecosystem at the same time as treating it as a product. Bitshares, essentially, is a product that is resegmenting an existing market. Therefor a great amount of money and time need to put into educating the current userbase in that market and convince them about the superiority and usefulness of your product.
One of the best features or possible features of Bitshares is that of inclusion. That is why I pushed for the principle of inclusion to be part of any DAC. A lot of people do not have bank accounts, don't have the opportunity to get in on IPOs or take part in the stock market. Think of all the college students who are living with their parents in debt and that would be the initial target demographic for Bitshares. There really isn't a Wall Street competitor. Mastercoin and Colored Coin are the only real competitors. In the long term Bitshares may take on NASDAQ or Forex but only after a critical mass of young college students are already on board.

One thing Apple did right was give out free Ipods to colleges. Bitshares should be given away to college students in specific programs of study such as marketing, finance, philosophy, political science, computer science, economics, etc. It must be determined which students would be most receptive to the technology and target them specifically.
That is exactly why the use of some of my proposed psychological techniques should be used for Bitshares. It only leads to the success of the entire system and the fulfillment of our intentions, it also educates millions of people so they grasp the usefulness of Bitshares and why the system is crucial for the development of our society.
Lets try it and measure it for success.
Punishment should be used for dishonesty, failure to fulfill obligations (would have to be discussed in detail about what is seen as a failure and what not), scamming, faking, etc. etc.

The way someone could be punished is by giving him a "Bad Player" badge or taking some of his points (or in a DACP, his Vx. Meaning, his voting power is heavily decreased due to bad behavior).  The purpose of these punishments would be to fight wrongful behavior within a DAC and not allow any scams or other forms of illicit actions to be taken place. People who try to game the system will be punished, and their public image will be damaged (perhaps through badges).

I do think that the algorithm should be able to punish wrongful behavior. Maybe a plenum (like a court) should decide on the severity of the crime and then come up with an adequate punishment.
I think for political reasons we should stay away from algorithmic law enforcement and courts. I do think we should have peer review, audits, and use the tactic of exclusion but I don't see why we should create algorithms for punishment because then we could end up with a system of governance worse than what we already have. I think if you want to punish someone you just don't let them in on the latest projects (exclude them).

You can set it up so that DACs only distribute certain shares to people with a certain reputation. Such as Honorshares for people known to be honorable and trustworthy as a form of inclusion reward. People who scam, lie, cheat, steal, would be punished because they wouldn't achieve the same status, wouldn't make as much money, etc. But I do not want any kind of blacklist or whitelist, and no punishment. Let the law enforcement focus on punishing thieves and abusers but it should not be our job.
And obviously ones hurt image can be "worked away".
This form of punishment is acceptable. If someone is associated with a scam then everyone should know it. Their Keyhotee ID should have reputation credits in the negative. What I mean is we should not have a specific community enforced punishment. If you want to work with someone with a negative rating you do so at our own risk just like with EBay or Amazon.
This is all still uncertain and should be discussed in detail with others. But I am an advocate for including punishments.

Btw: I'll try and include pictures in the next post. Else this thread is looking so dry for the readers..

I understand your motivation for wanting punishment. It's just not something you can implement easily in code. Exclusion in my opinion is the best punishment. It's basically pushing the scammers to the far edges of the circle. The people in the inner circle would gain the most opportunity because they are included.

This is why I advocate inclusion by default. Everyone should feel like they are a part of something, such as a part of the DAC or a part of the community. As they build up their reputation with badges and the like then you can set up DACs which only accept members with the minimum qualification. You can actually character protect a DAC by only including the people who have those character traits proven over time through the badge/honor system.

So if you want someone trustworthy, someone with honor, someone heroic, someone who claims to have certain values and who has proved it, you could program your DAC to require that people have these badges. You can also have badges for competence. There is no need to have punishment built into the system because you wont get into as many inner circles if you're a scammer because you'll never earn enough merit badges or titles to get that far.

The system I imagine is flat. There is no hierarchy. Everyone starts out as equals on a flat plane. Over time circles will form of core shareholders and core members. These circles will form based on competence, prestige or anything that the creators of the DAC program it to look for. The only people who could become members of these circles would be proven candidates. Anyone else would be part of the outter circle of the DAC away from all the action. You could even set up forums which only allow people to enter with a certain badge, or threads which charge people to enter unless they have a certain badge which lets them in for free.

2788
General Discussion / SCL (Social Consensus License)
« on: December 28, 2013, 01:36:55 am »
I suggest an approach similar to the GPL. We should come up with our own software license which specifically indicates our terms and percentages in the "Social Contract/Consensus". This would make it so that if we write code it cannot be used or cloned in a way which violates the "Social Contract/Consensus" without also violating the law and testing a legal precedent.

The reason to turn the Social Contract into a software license is to create a situation where the programmers themselves agree to only write or contribute to development on projects which accept that particular license. It could allow us to extend the Social Contract/Consensus outside of the bounds of Protoshares and Invictus Innovations and into a much broader space similar to impact of the GPL.

Can Invictus Innovations consult with their legal team to come up with some language which can help us to establish a software license which would restrict the use of our code as only being used in projects which meet the terms of the minimum of the Social Contract/Consensus?

I did not know whether to put this into legal or elsewhere so my apology for the duplication. This is something I think must be done and when I write code for projects I will license it exclusively to the community by using a license which recognizes the Social Consensus or which is the Social Consensus License if Invictus Innovations can come up with the words for us to use.

2789
I suggest an approach similar to the GPL. We should come up with our own software license which specifically indicates our terms and percentages in the "Social Contract/Consensus". This would make it so that if we write code it cannot be used or cloned in a way which violates the "Social Contract/Consensus" without also violating the law and testing a legal precedent.

The reason to turn the Social Contract into a software license is to create a situation where the programmers themselves agree to only write or contribute to development on projects which accept that particular license. It could allow us to extend the Social Contract/Consensus outside of the bounds of Protoshares and Invictus Innovations and into a much broader space similar to impact of the GPL.

Can Invictus Innovations consult with their legal team to come up with some language which can help us to establish a software license which would restrict the use of our code as only being used in projects which meet the terms of the minimum of the Social Contract/Consensus?


2790
General Discussion / Bounty exchange platform
« on: December 27, 2013, 06:00:01 pm »
How about a bounty exchange platform with an Ask/Bid?

This is essentially a bounty auction and exchange platform. It is completely algorithmic in approach and completely automated. It determines the true market price of any kind of labor by reaching the equilibrium point between the supply and demand through the bid/ask.

It would be centralized at first but could be made decentralized, it's also a way to determine who would be selected for the bounty in a completely automated fashion.

It may even allow workers to trade jobs on the exchange provided they do so before the expiration date. This way if a worker bit off more than he could chew he could exchange his bounty with someone else and they'd get paid in his place if they complete it.

Instructions
As the employer first you'd put up your bidding price which is the highest you're willing to pay, then a bunch of potential bid fillers put up their asking price and according to the algorithm it would meet in the middle according to supply and demand at an equilibrium point. This would give the market the true price of the labor.
Input: Employers enter a job description and bidding price to be displayed as the maximum bounty reward.
Input: Employees/Job hunters enter their asking prices, mapped to their Keyhotee IDs.
DAC: An algorithm selects the employee willing to work for the lowest asking price (lowest bounty reward)
DAC: A bot sends an encrypted message to the public key of the Keyhotee ID address and sends a bounty token to their wallet.
DAC: The transaction and exchange exist entirely in a blockchain so that if necessary anyone with that bounty token can exchange their bounty token for anyone else's.
Output1: The job is completed by the expiration date on the bounty token, and the bounty token is redeemed at the true price of labor in the market.
Output2: The job is not completed by the expiration date and the bounty token is never redeemed, therefore it is invalid and expired.
Social Contract: 50% Protoshares, 45% Angelshares, 5% Promotion, Discount and Giveaway shares

What could go wrong? Someone could lose their bounty token and then the bounty would expire wasting valuable time. On the other hand it would save time if someone can trade their received bounty with another person or split their bounty with another person all in automated fashion by using the divisibility of the bounty token. So if I did 90% of the labor and I could not do that final 10% then I could break off 10% of the bounty token and give it to anyone willing to work for it.

Let me know if this idea could work?

Pages: 1 ... 179 180 181 182 183 184 185 [186] 187 188 189 190 191 192 193 ... 195