Users have to create, share, distribute, and manage partially signed transactions.   This is not viable for almost all users.  Only the most paranoid and patient of users.  The infrastructure required to "get this right" is significant. 

What's wrong with allowing users to store partially signed transactions on the blockchain?  It'd fix "share", "distribute" and to some extent "manage".  "Create" and the rest of "manage" is more a UI thing.

Being generic means it is harder to use.

These use cases are: 
1) escrow 

I agree that having explicit support for escrow would be positive (especially well-integrated with TITAN accounts).  I'm not a multisig expert, but I suspect it'll largely be a UI effort that'll use multisig under the hood at the blockchain level (maybe using the transaction memo to store a hint).

LottoShares (third party)DAC has been terminated after being abandoned by Dev.

Can someone cite some announcement somewhere?

so with your proposal all the new development would be done in Dev Shares and only bug fixes will be done in the main branches?

New feature development would be done on a testnet first.  Then a NewShares hard fork is created when a feature has been operating on testnet with no problems (and the devs say the feature is considered complete and ready to be included in a network whose coins have permanent value).  Once the feature has been in NewShares for a few weeks and there are no problems, it will be scheduled to be included into DevShares at the next scheduled two-month DevShares hard fork.  Once the feature has been in DevShares for somewhere between a few weeks and several months, mature DAC's can issue a hardfork including the new feature (if/when the maintainers of those mature DAC's think the DevShares testing has been adequate, including a mature and stable GUI.)

Maybe the following breakdown will help:

testnet - Very frequent hard forks, features considered still incomplete or under development, finite network lifespan, no permanent value.

NewShares - Very frequent hard forks, latest complete features, only receives feature updates after they have been proven on testnet, finite network lifespan, permanent value (due to being re-issued as inflationary DevShares when network is shutdown).

DevShares - Scheduled hard fork every two months, fairly new features, only receives feature updates after they have been proven in NewShares, unlimited network lifespan, permanent value.

Mature DAC's (BTSX, DNS, Music, etc.) - Infrequent hard forks, only receives feature updates after they have been proven in DevShares, unlimited network lifespan, permanent value.

All networks (except perhaps testnet) will receive bug fixes, security updates, and minor features.  The "trickle down" is mainly for features that require either changes to the economics, or large, complex code changes.

Concrete examples of features which I think would benefit from having the NewShares / DevShares environment for testing include many features I've written forum posts and whitepapers about:

- Changes to price feed / short / margin / yield mechanics
- Atomic cross-chain trading
- Private airdrops
- BitBonds

I think all of my proposals on these topics will create significant shareholder value, but BM has been hesitant to implement them.  I suspect this hesitation is partly because he fears (legitimately) that the BTSX brand may be damaged if BTSX continues to have very frequent hardforks which make big changes to economics.  I'm hoping to overcome this fear by isolating the changes to separate DAC's, and informing investors in advance that those DAC's will contain relatively immature features and have frequent hard forks which implement significant changes to the economics.

- value could be in form of bounties from I3 or the developmentteams
- value could also come from delegates who are pledged to buy dev shares in a regular basis
- value could also come for new DACs to allocate some shares to dev shares and with the allocation they "hired" the Dev Shares team to develope besides them self

DevShares shareholders should be able to vote for "business delegates" who will be able to fund development / marketing from inflation [1], as well as an overall cap on the total inflation allowed [2].  The business delegate may be I3 or somebody else -- or there may be multiple business delegates.  It's up to the business delegate(s) plan(s) whether they spend it on bounties, a dev team funded only by DevShares inflation, or a dev team which receives funding from inflation of a variety of DAC's.  There is no technical way to evaluate whether the business delegates are honestly using their funds according to their published plan.  But shareholders retain control since they can vote to reduce or eliminate future funding of business delegates that are ineffective.  Further discussion of business delegates really belongs in a different thread like [1].

[1] https://bitsharestalk.org/index.php?topic=9452

[2] https://bitsharestalk.org/index.php?topic=9452.msg123106#msg123106

BTSX has shown there are two problems with traditional testnets:

- Usage of testnet is very light, problems often don't surface until features hit mainnet
- Testnet can test mechanics, but can't test economics

Both of these are due to the fact that testnet coins have no value.  I'm thinking of fixing this as follows:

- Create a new DAC called DevShares.  DevShares have permanent value; every two months there is a scheduled hardfork that adds new features.
- Create another new DAC called NewShares.  A NewShares network includes bleeding-edge features and may be frequently hardforked (like BTSX shortly after BitUSD release).

NewShares is a "tempnet":  It has a finite lifetime like a testnet.  But unlike a testnet, NewShares shutdown time is hard coded from launch.  Honest NewShares clients will stop accepting blocks after the hardcoded shutdown time, which will be approximately a week before the next DevShares hardfork.  NewShares is snapshotted at the last block, and (inflationary) DevShares are issued to all NewShares holders.  Thus, another difference between NewShares and a testnet is that NewShares are intended to have a nonzero value (because NewShares represent the right to receive DevShares in the near future, which will have nonzero value provided DevShares themselves have nonzero value).

After a NewShares shutdown, a new genesis block for a new NewShares network may be issued.  (The new genesis block's height field will continue after the previous NewShares net's final block field, which may make certain implementation issues easier.)

So basically features go from testnet -> NewShares -> DevShares -> stable DAC's, where "stable DAC's" are BTSX, DNS, Music, etc.

Even though the NewShares network is temporary like a testnet, the economics of NewShares will hopefully be realistic because NewShares will be converted into DevShares which have permanent value.  DevShares must be a new DAC because its inflationary model is different, and existing DAC's have already made promises to investors about their inflation model.

DevShares will themselves have substantial value because their feature set will be updated much faster than BTSX.  With the DAC "business delegate" model, some of DevShares' value can be siphoned off to support development.  Also we can airdrop genesis block NewShares on each NewShares tempnet to holders of other DAC's that support the business delegate model.  This encourages wide participation in NewShares and DevShares, and (quite indirectly) funds development:  The regular airdrops to DAC's that support the business delegate model may increase the price of those DAC's.

Basically the purpose of NewShares is to allow trying out features and economic experiments without having to commit to supporting them forever, or risking the entire market cap of BTSX on some unproven concept for e.g. different shorting mechanics.  And alleviate the pain of hard forking by scheduling them (in the case of DevShares) and separating out people who are willing to keep up with hardforks into their own network (in the case of NewShares).  Of course critical security issues may still require an unscheduled hard fork.

There's an analogy to the typical organization of software projects:  You can think of NewShares as the "development branch" (very new features, sometimes compat-breaking), DevShares as the "master branch" (pretty new features that the devs regard as final but have not received as much real-world testing from users as the stable branch), and BTSX as the "stable branch" (receives bug fixes and security fixes, and new features when they have been thoroughly tested by more adventurous users).

Also, the NewShares model alleviates the problem of requiring many different versions of the validation logic / market engine:  After NewShares shutdown, the next NewShares net starts from a "clean slate" and doesn't need the obsolete validation logic because it's not required to be backward compatible with the old net which has been shut down.  The details of NewShares mechanics never make it into DevShares code.  DevShares only knows about the shutdown block distribution of NewShares, it doesn't need to know anything about the semantics of the NewShares transactions that caused the transitions from the genesis block to the shutdown state.

Sorry, I'm actually kind of busy at the moment.  Wasn't expecting the super fast reply.  I should be free in an hour or two, but it's fine if you aren't available.  But mission accomplished:  I now have a point of contact that doesn't turn unread messages into Hawking radiation

If you're a mod, feel free to lock / delete this thread.

I'm a long-time forum member with lots of contributions to the forum and Github.  I've made several suggestions that have been implemented, bug reports that have been fixed, and pull requests that have been merged.

I'd like to take my contributions to the next level by joining the BitShares team as a developer.

I've tried asking bytemaster about joining the team privately by PM and email, but I have not received any reply.

Who should I contact, and what is the ETA on some reply?

Thanks.

As long as it is possible to extract from the reserve fund in some way, no matter how difficult, you can bet that the reserve fund will be empty at all times and that regular people will never get any yield.

You're thinking the system has no "memory" of how much yield has been claimed by a given BitUSD balance.  So immediately after a claim the same BitUSD could claim the same amount.  In other words, a user's equity in the fund is proportional to their BitUSD.

This is not the case -- the system does such have such a "memory"!  A user's equity in the fund is proportional to the amount of BitUSD they have, times a yield factor.  The yield factor starts at zero for new BitUSD, then increases over time -- but it resets to zero when yield is claimed or the balance moves. 

You might object "But this means different BitUSD are not totally fungible against each other!  Old balances are now more valuable than young balances!"  And this objection would be correct.  This was my objection to an earlier version of the yield proposal, where the yield factor's trajectory bent much more sharply.  You could in theory have a BitUSD "bank" that holds BitUSD in its vaults and tries very hard to keep moving it.  Then two depositors of the bank would be able to exchange value by writing checks; depositing a check would change the balance of both users' accounts, but the BitUSD in the vaults would not move.  The system could be economically profitable for both the bank and its depositors; they'd split the increased yield.  This is still theoretically possible with the current implementation, but I don't think it would be profitable enough to justify its running costs.

The reason we need to have the yield factor increase non-linearly is because they decided automatic compounding of interest was too hard to implement.  I told them exactly how to do it, but they still don't want to implement any of the algorithms I suggested.  Absent automatic compounding, people would try to do "manual compounding" which leads to spamming the network with tons of send-to-self transactions.  A yield curve that gives better returns than manual compounding prevents this.  I believe Agent86 may have done a more detailed analysis, but I'm not going to go looking for the post right now.

Adam's accounting system in this story is a much-simplified version of my understanding of the yield implementation currently live in BTSX.  It captures the essence of the accounting problems I perceive, without including features of the yield implementation which complicate the analysis.