Author Topic: How do changes to Bitshares design get accepted in the network?  (Read 1765 times)

0 Members and 1 Guest are viewing this topic.

Offline yiminh

  • Full Member
  • ***
  • Posts: 66
    • View Profile
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.

have the note team swear never ever hardfork, we then got a winner!

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
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.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline starspirit

  • Hero Member
  • *****
  • Posts: 948
  • Financial markets pro over 20 years
    • View Profile
  • BitShares: starspirit
thanks xeroc, monsterer, pc.

From what I understand then, in practice developers decide the version, after community consultation, and promote that version for switching by delegates and users. If there ever were disagreement, delegates (or more specifically, block-producers) could support whichever version they preferred, owners could vote for whichever block-producers will support their network, and users could choose to use whichever network they wish.

Users pay the fees that incentivise everyone. Owners control who is allowed to earn those fees. Block-producers support the network infrastructure. So competitive development teams ultimately need to convince all three of these stakeholder groups that their version is best to ensure a successful transition?

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
- Where does the BitShares code reside (for example, the trading engine)? Is it all in the client? Is there separate code used by the block-producing nodes, and how is it different? Does common code also sit elsewhere?

All in the client, including the block producing code.
woulnd't be so sure .. maybe we see a separation of CORE and GUI

Quote
- If there is a major code change, who directs the propagation of this change through the network and how? Is it users, delegates, or both? Does this acceptance happen by simply downloading a new client version?

Code changes are directed by the core developers, usually through a hard fork, which is accepted by downloading and running a new version.
I can recall plans to have ALL future hardforks to require shareholder approval
(onchain)

Quote
- In practice, how do all the developers agree on the code change? Is somebody responsible for vetting and testing all the changes made before a new version is released?

They have an internal process, which feeds back into the forum for changes, but it ultimately comes down to the core team.
Shareholder approval is what counts in the end. At least that is the bigger
picture AFAIK

Quote
- If there were competing developers or development teams, that might produce
  competing client versions, how is a consensus formed within the community on
  which one will be supported? In practice, is it possible to even have
  developers compete on version design, or does this need to be a coordinated
  effort?

Multiple clients can happily compete as long as they all follow the protocol (therefore stay on the same fork). If you have different clients following different protocols, then you have a problem.
[/quote]
In the end, the delegates have to decide in favor for a 'fork' in this case.
Though I don't think this scenario will ever arise, the shareholders of BTS have
the option to vote for their fork with their stake pro/con a delegate.

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
- Where does the BitShares code reside (for example, the trading engine)? Is it all in the client? Is there separate code used by the block-producing nodes, and how is it different? Does common code also sit elsewhere?

The core client is maintained at github: https://github.com/BitShares/bitshares
It contains all the code required for producing blocks as well as what 'normal' nodes need (including the trading engine). Actually 'normal' nodes perform the same operations on the blockchain (including the matching of market orders). The only difference between block-producing nodes and 'normal' nodes is that the block producers decide which transactions are included in the next block.


- If there is a major code change, who directs the propagation of this change through the network and how? Is it users, delegates, or both? Does this acceptance happen by simply downloading a new client version?

A "major" (in the sense of "incompatible") code change is called a hard fork. A hard fork forks the blockchain into two prongs. One prong belongs to users of the old code, the other belongs to users of the new code. Because transactions between the prongs are impossible, this is an undesirable situation which users as well as delegates try to avoid. So in a way they both decide.

For BitShares there is a specialty: if all of the delegates decide to stay on one prong (or all decide to switch to the other), then the prong without delegates comes to a standstill and is effectively dead. So the delegates can make the decision among themselves as long as it's unanimous.


- In practice, how do all the developers agree on the code change? Is somebody responsible for vetting and testing all the changes made before a new version is released?

There is a core team of developers around Bytemaster and Vikram sitting (literally) in Blacksburg.


- If there were competing developers or development teams, that might produce competing client versions, how is a consensus formed within the community on which one will be supported? In practice, is it possible to even have developers compete on version design, or does this need to be a coordinated effort?

Since the code is open source, anyone could step up and take over development. If they develop something that's not compatible with the existing code, they will create a hard fork and it's up to the users to decide, see above.

It is absolutely possible to create and maintain an independent client, as long as the core functionality remains compatible with the existing core client.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline monsterer

- Where does the BitShares code reside (for example, the trading engine)? Is it all in the client? Is there separate code used by the block-producing nodes, and how is it different? Does common code also sit elsewhere?

All in the client, including the block producing code.

Quote
- If there is a major code change, who directs the propagation of this change through the network and how? Is it users, delegates, or both? Does this acceptance happen by simply downloading a new client version?

Code changes are directed by the core developers, usually through a hard fork, which is accepted by downloading and running a new version.

Quote
- In practice, how do all the developers agree on the code change? Is somebody responsible for vetting and testing all the changes made before a new version is released?

They have an internal process, which feeds back into the forum for changes, but it ultimately comes down to the core team.

Quote
- If there were competing developers or development teams, that might produce competing client versions, how is a consensus formed within the community on which one will be supported? In practice, is it possible to even have developers compete on version design, or does this need to be a coordinated effort?

Multiple clients can happily compete as long as they all follow the protocol (therefore stay on the same fork). If you have different clients following different protocols, then you have a problem.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
From my understanding I suppose that will be plenty of documentation and a huge announcement that will address these concerns.
It seems they went dark for some reason and I bet it is a good one :) (not an investment advice :) )

Offline starspirit

  • Hero Member
  • *****
  • Posts: 948
  • Financial markets pro over 20 years
    • View Profile
  • BitShares: starspirit
I would like to better understand the process by which new designs (e.g. bitAssets) or other code gets introduced into BitShares. My background is financial not coding, so I'm admittedly a layman on this topic.

- Where does the BitShares code reside (for example, the trading engine)? Is it all in the client? Is there separate code used by the block-producing nodes, and how is it different? Does common code also sit elsewhere?

- If there is a major code change, who directs the propagation of this change through the network and how? Is it users, delegates, or both? Does this acceptance happen by simply downloading a new client version?

- In practice, how do all the developers agree on the code change? Is somebody responsible for vetting and testing all the changes made before a new version is released?

- If there were competing developers or development teams, that might produce competing client versions, how is a consensus formed within the community on which one will be supported? In practice, is it possible to even have developers compete on version design, or does this need to be a coordinated effort?

Sorry if these questions don't make complete sense.