Just catching up on the announcement of BitShares 2.0.

I am baffled that people are being caught in the thick of thin things about secondary matters like the ownership of Cryptonomex, and fail to see the elephant in the room: BitShares without its free-software community funded core is not BitShares anymore! It cannot be as per the very nature of BitShares. The whole point and philosophy of BitShares is to be an open toolkit allowing anyone to leverage on the technology to create all sorts of innovative DACs, and in return sharedrop some of the new DAC's tokens to BitShares holders under what we call the "social consensus".

What you are being pitched as BitShares 2.0 is an attempt to strip from the real BitShare immensely valuable assets such as its community, its brand name, its place in the crypto space and slap them on top of a proprietary non-free-software technology to increase it's appeal. Bitshares 2.0 is not an upgrade, it's a corporate dismantelment.

Under the BitShares 2.0 "proposall "announcement", BitShares becomes a trade show exhibit for the exclusive benefit of Cryptonomex Inc. Bitshares 2.0 and the BitShares community will be used as:
- A lab rat to test Graphene before it's used for real clients, and to test future new features before they are added to the professional toolkit.
- A display to show to Cryptonomex's clients that Graphene works as intended
- A live testnet for Graphene prospects and users to test their applications
- An exhibit model for sales and fund raising pitches as well as presentations
- A social sandbox in which Cryptonomexand its clients can test new marketing and product ideas before trying them in the wild
- A free source of consulting, features proposals, feedback, bug reports, bug fixes and contributions
- An army of volunteers to help promoting Graphene
- A complementary source of funds

BitShares loses everything. Under the new model:
- It cannot anymore be forked and loses the benefit of sharedrops by third party DAC developers.
- Its allowed scope of evolution becomes restricted by the use cases allowed by the Graphene licence.
- It loses the control of the BitShares brand
- It loses its reputation on the crypto scene: even Ripple is free software with no strings attached!
- It loses its soul and fundamental raison d'etre

Meanwhile since BitShares is still around and may even do well for a while after the upgrade when it's not yet too apparent that it has lost its purpose and independance, BitShares core developers can continue to sell their BTS.

It's time to wake up: we do not have to accept the upgrade to BitShares 2.0 and the subsequent disparition of the free software BitShares we have funded. Nothing justifies such an extreme solution. From an organizational perspective, if the core developers are going to walk away, it would be very poor decision making to accept an upgrade to new code that only they understand and control. No organization in their right mind would migrate to a system developed by an employee who is leaving, BitShares is no exception. From a technical perspective nothing justifies a migration either: the Graphene based chain will be launched in parallel as a BitShares fork, why not just let it be a BitShares fork? The rules so far have been that anyone forking BitShares was going to do it under her own brand and was expected to respect the social consensus. I don't see any reason to change the rules.

Don't let yourself impressed by people telling you that BitShares is in a dead end, that developments have stalled, and that selling our soul by accepting a faustian pledge is the only solution. BitShares price may be low, but this has happened quite a few times to Bitcoin, Ripple and NXT to name only a few, and they are still doing fine. The whole crypto industry is in a bear market so things are looking gloomy, but like any bear market, this is only temporary. Better days will come when the market reverses, and these days may not be that far away given the fact Bitcoin's price has  stabilized. Developments may have stalled as a consequence of the price drop, but will resume when the price rises again, and BitShares isn't going to die because developments have slowed down: if that was the case Bitcoin wouldn't be around anymore.

There is no reason to rush and accept a bad deal. Cryptonomex may have timelines but we don't. Let's take the time to discuss and campain and see what the community really thinks about the upgrade.

edit: replaced "closed source" by "non free software" and "open source" by "free software"

which should go a long way toward paying their present and future fines:

http://venturebeat.com/2015/05/05/u-s-treasury-slaps-virtual-currency-startup-ripple-with-700k-fine/

Quote from: starspirit on May 14, 2015, 03:42:19 am

So competitive development teams ultimately need to convince all three of these stakeholder groups that their version is best to ensure a successful transition?

I think in practice a competitive development team would - in everyone's interest - create their own chain, possibly sharedropping on BTS. IMO it would be close to impossible to convince a significant majority to switch, while convincing a significant minority would cause severe damage to the network.

Quote from: Thom on May 11, 2015, 10:20:01 pm

Quote from: bytemaster on May 11, 2015, 07:58:00 pm

Well, Stan introduced a new role that wasn't part of this discussion but it boils down to:

1) Who runs nodes and includes transactions (block producers) which should be elected and have no other roles and how much do they get paid for this one role (just enough to cover costs)

2) Who (if anyone) gets paid, how much, for how long, and how much vesting, and with what priority given a defined maximum budget of 5 BTS / sec for all spending

3) Who gets to set block chain parameters (fees, block sizes, block producer pay, maintenance collateral requirements, vesting terms, referral program parameters, etc)

Answer is these roles are all separate and individually voted on.

Thanks for that Dan, it helps. Would you please label the roles and associate them with the functions they perform? I've seen the term worker used, but that is vague and could apply to all roles. I used manager, assuming a team lead position which you have now dispelled by saying all of the roles are voted into place. Presumably all of these roles are called delegates?

Does a vesting period apply to all of the roles? It doesn't seem to make sense for the block signers if they are only being reimbursed for server costs, nor does that seem reasonable to me. I know you've said the nodes "pretty much run themselves once setup", but that doesn't reduce the time to maintain a delegate node to zero. Besides, in my experience over the last 3 months it's consumed a significant amount of time, far from the claim it runs itself with minimal investments of time.

Stan used "workers, signers & knob turners", just to confuse things even more.

You also said you didn't think these new roles would have much of an impact on existing delegates. The discussion hasn't even addressed cases like Riverhead who acts as the technical arm of several delegates. Will he be paid and voted into place independently for each (worker?) he supports? What about structure / rules to insure a good measure of reliability and decentralization?  What about qualifications to roles?

I think any serious proposal should spell out in detail the before and after effects it will have on our existing way of doing things, nominations, delegate fees (the same for all roles?), voting, pay, whether delegate teams will be allowed etc etc. It's not a trivial undertaking to accomplish and get done before the 1.0 release along with everything else. I feel this is a major discussion that cuts to the heart of DPoS, and it needs to be refined and solidified prior to 1.0. The good news is that as far as anyone knows, the date for when 1.0 goes into the wild is not yet public. With topics like this still under heavy discussion, that's a good thing indeed, as it allows time to hammer out these fundamental changes we're discussing.

I am curious why you think it's necessary for all of these roles to be voted into place separately and would like to hear your perspective on that. I also think the point Ander raised about the complexity of our ecosystem and effect on voter apathy should not be discounted.

I do agree the delegate structure needs improvement and that should be done prior to releasing 1.0. So this discussion is on target IMO.

Lucky for you I have been working on just such a paper... here is a preview of the motivation for this:

Quote

Under DPOS 1.0 the stakeholders would select 101 delegates by approval voting.  These delegates would take turns producing blocks every 10 seconds. Each delegate would get to set their own pay rate as a percent of the maximum.  Decisions about which fees to charge and hard-forks to adopt rested in the hands of delegates which acted individually.

This system worked reasonably well but over time some serious issues became apparent. Some of these issues include:

Requiring stakeholders to select 101 delegates may be too much leading to most stakeholders voting for less than 101 or not carefully vetting the delegates they chose.
Forcing all “employees” to run servers to get paid significantly complicated the hiring of people without those skills.
There was no way to come to a consensus on what the fee structure should be.
With a total budget of $50,000 per month of new issuance, each individual delegate had a maximum budget of $500 per month which is not enough to get someone’s full time attention.   It was politically unpopular to give one individual multiple delegate positions for fear of centralization.
Delegates have too much control in a single position that opens them up to unnecessary legal liability.

DPOS 2.0 Overview

Under DPOS 2.0 the roles of delegates have been divided into 3 categories:

Witness - produces blocks and is paid a percentage of transaction fees.
Worker - is paid a fixed number of tokens per day to perform a task
Delegate - co-signer on a dynamic multi-sig account with permissions to change blockchain parameters.

Each of these roles is filled by approval voting.  The number of Witnesses and Delegates is directly voted upon by the stakeholders.    Each stakeholder must vote for at least as many Witnesses and Delegates as they believe the system should have.   The number of witnesses/delegates is defined such that at least 50% of voting shareholders believe there is sufficient decentralization.  The number of workers is determined by how many workers the available daily budget will cover when paid out to workers from most approved to least approved.



Delegates

The delegates have multi-sig control over a special account dubbed the “genesis account”.  This multi-sig account can do anything any other account can do with a 2 week delay.  If enough delegates are voted out within two weeks of jointly approving a transaction then the transaction will fail to go through.   

The “genesis account” has the unique privilege of changing critical parameters such as: Block Interval, Block Size, Witness Pay Rate, Burn Rate, and even the review period for their own transactions.   

Delegates are not paid positions and are therefore honorary and held by individuals who have a vested interest negotiating changes to the network parameters. 

Legally the delegates have no direct power other than to propose changes for the stakeholders to reject.   This means delegate positions are safe from regulation and power truly rests in the hands of the stakeholders.   

Unlike DPOS 1.0 where each delegate operates independently, under DPOS 2.0 delegates are forced to reach consensus directly before any change can be proposed. 

Quote from: yiminh

Quote

16 month and not a stable wallet, the core dev team needs to be fired,the market is doing just that, let the free market work its magic.

Rome wasn't built in 16 months.

Can't wait to be able to vote on those projects because at the end of the day...money talks. (Now is the time to buy if you want to have voting power in the future)

BTS dilution every 2 month, II'll take Fedral Reserve anyday!

Toast has been a great member of our team but has always been a free agent and not an employee.   He came to BTS to produce the DNS chain but that has been absorbed by BTS.

He is currently serving as a liaison to BTS Music team which was progressing largely without technical support from the core team until Toast went over to help.   I recently talked with Toast about the future for BTS Music and am gathering the requirements that they would need to launch on the BTS chain rather than their own chain.   

To my knowledge Toast is actually bringing new money into the BTS ecosystem and is still a believer in our future.   I applaud Toast for finding a way to pay his bills while still contributing to our ecosystem full time without having to sell all of his BTS.   

Toast is sending any BTS his delegates earn to the angel account and we are using those funds to keep the other developers fed. 

To Clarify:  Music is still planning their own chain and that hasn't changed.  I am merely attempting to find out what it would take to CHANGE that while still providing a win for NOTE holders.   It is possible that nothing could change that.  COB and Eddie have done said nothing and my position has long been a desire to bring them into BTS.