Quote from: gamey on April 17, 2016, 07:47:03 am

I suspect a lot comes down to how one views the vested balances. I view them as just as legitimate as other BTS, fungible or not. Others seem to take the view that because these BTS are not liquid, then somehow they are in a second class. Obviously I disagree.

Part of the reason they were made vesting was to ensure we retained our devs.

Quote from: bytemaster on October 22, 2014, 12:56:16 pm

The result is that as part of the merger many people (including the large Dev fund) are taking a long-term vested interest in things. 
Do you really want Toast, Adam, and I to have instant access to a large percentage of all new funds or do you want us vesting with a long time horizon? 

We failed to retain Toast, Adam/FMV is crowd-funding separately and BM is focusing on another DAC.

There is also speculation there has been a lot of selling by key parties...  https://bitsharestalk.org/index.php/topic,22098.msg287894.html#msg287894

So in addition to all of the above, by continuing the merger we may also be inadvertently (though I'm sure they will disagree) funding other DACs at our expense.

Quote from: bytemaster on October 21, 2014, 10:28:46 pm

We are the single largest holder of PTS by far.  Giving a large stake to PTS and AGS would be massively in our favor.

I understand your POV and perhaps it is the correct one, but continuing the merger is not a competitive/successful business strategy for BTS at this stage imo so it is worth discussing.

I am highly conflicted by this proposal. My gut reaction is that ending the vesting early is breaking a contract, a breach of trust. On the other hand as is pointed out above the primary reason for vesting the ownership was to retain the people those shares were granted to. The contract was flawed, in that it didn't stipulate the retention of vesting rights were contingent on continued allegiance to the granting party (BTS chain).

Nobody can predict the future with perfect accuracy. I've been around since before the merger so I am well aware of the mistakes made along the way, as dannotestein, empirical and others have outlined here. BM / Stan / CNX have been between a rock and a hard place many times trying to keep the vision alive and sustain the team to carry it out. Major contributors have left the team along the way (Toast, Vikram, Nathan, ...) so their efforts in keeping the team together have their limitations, as does the patience of those who remain to see the BitShares vision of a truly decentralized DEX and platform for growth come to fruition and wider adoption.

Unlike other projects BitShares is highly transparent and the tough decisions are not hidden away from public scrutiny. That characteristic is a double-edged sword. I see the decision to end vesting early as a highly controversial move, and one with good points to consider on both sides. I have no stake in the vesting, just to provide full disclosure, so perhaps that taints my judgment. Can anyone claim total objectivity on this matter? Not very likely anyone reading this can.

It is clear that the source of funds have dried up to continue development and even maintenance to sustain the ongoing cost of the dev team. I see this decision as a matter of survival of the BitShares ecosystem, and as such the early termination of the merger vesting shares represents a significant resource (126Million BTS - 6 months @ 700K / day, or ~$500K @ $0.004 / BTS) that could be applied toward putting the crucial, final touches on the great work BM's team brought into existence, like funding xeroc's efforts to document this work so others can easily build on it.

I find empirical's points highly compelling, and although ending the vesting early will definitely have negative effects, so will allowing it to continue, such as funding work on other chains (tho not directly).

We also need to consider what can realistically be accomplished using this $500K pool if it becomes available. How will we organize to prioritize what work must be done to polish up this ecosystem to attract adoption? Marketing, development or maintenance? Who is qualified to do any development deemed necessary? I don't think it's healthy for the long term success of BitShares to look to an exclusive group of devs as the only ones who can contribute to the code base. We need to promote the opposite perspective, than anyone can contribute, and make it easy for them to do so. We need good conventions, practices of code review and procedures for proposing and adopting the contributions made. Much of that is already in place in the form of worker proposals. The community must step up to the challenge of organizing itself to set priorities, milestones and goals to achieve our objectives. We need solid project planing and a roadmap to rally the community and focus our resources. Can leadership like this emerge from within the community or will it languish and falter? Once again this community is given the opportunity to be responsible for itself and not rely on someone else to make decisions. It took quite awhile before a committee was wiling to take on the role of leadership. Will it be the same now, or will we embrace responsibility?

There are many projects that depend on the continuation of the BitShares ecosystem, each of which provides plenty of reasons to be hopeful for the future of BitShares. I feel the same about many of the people who continue to believe in the vision and promise of a freer future and remain dedicated to seeing that vision made into reality.

  Excellent! Glad to see the 100% reserves mentioned too 

I have to agree with merivercap, this is a well reasoned ... experiment, all based around social consensus AND the collective wisdom of those creating CASH.USD to fund "investments".

If that collective wisdom is accurate and the investments result in added value to the CASH.USD borrower, the transaction will stimulate economic growth. Either way it will stimulate more trading if people are willing to put up the collateral BTS to back their loans.

I think this is a good experiment.  @merivercap for your initiative on this and a well written TLDR (Too Long but DO Read) post.

You are correct on both counts tbone. @Erlich Bachman - allowing short or insecure keys isn't an option for anyone. The last thing BitShares needs is someone loosing their life savings b/c they failed to provide a good brain key.

I got a lot out of BM's discussion on last Friday's mumble. Two important points:

1) There are higher risks for putting wallets on the blockchain, significantly b/c attackers can hammer their target trying to crack the password without any delays between each attempt. They could employ many computers in parallel in the attempt also.You might be surprised at how quickly a password can be guessed via brute force means like that.

2) It's not sufficient to only save private keys. That could work if you're saving a BitShares wallet with only standard accounts, but not if the wallet contains stealth addresses. And, unless a limit is put on how many accounts and stealth accounts a wallet may contain the size of the backup could get prohibitively large to store on the blockchain, even without transaction history.

Regarding the use of blinded transfers as a replacement, I'm not a big fan of that approach. I would want to see more details about the viability of that, focused on the time required to implement it, what the exposure it has on existing code to new bugs, both front end and backend, not to mention who will implement it with this no-dilution cloud hanging overhead.

  ROL !!!!!!!!!!!!!!!

Interesting. There are people in that list that haven't posted here in a very long while, perhaps that should be taken into account as well. In doing so it also should be considered what the quality of such "dormant" accounts were when they were active.

To base your giveaway on this forum alone will be a challenge. Can you programmatically and fairly assess the quality of a forum account? Number of posts, avg. post length, frequency of posts, time active on forum (last active date - join date) are all quantitative metrics you could employ to come up with a weighting factor.

You could also factor in who contributed to the biggest topics, or the most important topics, which may not always be the topics with the largest number of posts (but those would probably have to be manually determined). Perhaps noting which topics BM started or contributed to (there are many he does not participate in, dare I say most?) and assigning a higher weight to people that post in those topics could be a useful metric.

Most of this analysis could be done with SQL queries. It's a matter of how much time you want to put into the assessment. For a time bitsaphire was publishing the mysql database of this forum. Is that still available? Might be kindof fun to play with these ideas on actual data. I am the admin of an SMF forum for a small community so I am quite familiar with the SMF DB structure and quite adept at creating queries to mine data. I did that for several years professionally for a web based financial planning application.

Quote from: liondani on April 07, 2016, 06:45:09 pm

Quote from: onceuponatime on April 07, 2016, 02:07:08 am

I am willing to sell to you, @JonnyBitcoin, all of my shares at 8.34 BTS each in order for you to be able to accomplish what you say you would like to see.

Sell STEALTHS openly on OL  and give the opportunity to our community to participate !

sell them in parallel with 5 different prices and give as 2 weeks....   (like a crowd-sale)

1. 20% at 8.0 BTS / STEALTH
2. 20% at 8.5 BTS / STEALTH
3. 20% at 9.0 BTS / STEALTH
4. 20% at 9.5 BTS / STEALTH
5. 20% at 10 BTS / STEALTH

I am sure it will be successful! 

PS just throwing ideas

Selling to public is different from selling back to the DAC (all stake holders). Arhag posted a solution in last page.

What? Unless arhag changed his username there is no post by him in this thread.

I am surprised nobody has responded to kencode's brilliant idea of using the blockchain as a backup medium. Essentially all you need to do is securely encrypt the account owner keys to provide a solid backup solution. I don't know what the size limitation is on the memo field but surely the storage details for such a small quantity of data isn't beyond our capabilities to easily implement. Require a 10 or 20 word brainkey of the users choosing to encrypt the owner keys of the accounts held in the wallet. People who use stealth are surely going to be more careful, and having a backup of your wallet stored in the immutable blockchain is about as safe as it gets. Give the user options concerning the brain key. They provide or wallet generates it. Validate strength of any the user provides and give them feedback on the quality.

Of course the had part is how to make it easy to use. I like the "Backup Required" prompt in the bottom right corner, perhaps it needs to be more obnoxious, like blinking to catch the users attention and give them an incentive to make a backup and stop that damned blinking! Maybe lightbox the whole app until it's done before the wallet can even be used again after operations involving stealth are performed. However it's done it's GOT TO BE INTUITIVE AND SIMPLE.

I disagree with @roadscape on blinded transactions. I think that is riskier than polishing the stealth feature, especially if it's only a matter of implementing a solid backup approach, and I fully agree with Ken that any server side approach has risks.

Checkout his presentation at devcon1 for a quick, 10 minute synopsis. On his first slide he claims "Continuous auctions are evil, don't use them".