Author Topic: NewShares: "Testnet for economics"  (Read 2318 times)

0 Members and 1 Guest are viewing this topic.

Offline emski

  • Hero Member
  • *****
  • Posts: 1282
    • View Profile
    • http://lnkd.in/nPbhxG
I think this might be extremely useful. Great idea!

Offline theoretical

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
« Last Edit: October 13, 2014, 04:11:09 pm by drltc »
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk

Offline gyhy

  • Hero Member
  • *****
  • Posts: 852
    • View Profile

Offline Shentist

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 1601
    • View Profile
    • metaexchange
  • BitShares: shentist
i like the idea in general.

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?

- so you would need for every blockchain BTSX, DNS etc. a kind of Dev Shares?

is this doable?

- 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

Offline jamesc

Anything that adds stability while giving freedom to try new things has to succeed.  I'm already thinking of features we need to implement.

Would you be willing to address funding up-front?  So, how could workers earn extra shares for features, marketing accomplishments, etc..?  Of course, there is the crowdfunding model where (in your case) air-drop recipients can put some funds into a feature reserve.  After an expiration, share holders can vote to release or refund the funds.  This might make a good feature for your DevShares....


Offline bytemaster

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline theoretical


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.
BTS- theoretical / PTS- PZxpdC8RqWsdU3pVJeobZY7JFKVPfNpy5z / BTC- 1NfGejohzoVGffAD1CnCRgo9vApjCU2viY / the delegate formerly known as drltc / Nothing said on these forums is intended to be legally binding / All opinions are my own unless otherwise noted / Take action due to my posts at your own risk