Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Change the base parameter of bts by all bts stockholder to avoid hard fork  (Read 628 times)

Offline BTSdac


I am not know much of detail of bts, I don`t if change the base parameter like block interval ,MIN tx fee,there must a hard fork,  I don`t know if it is available to change the base parameter of bts by all bts stockholder to avoid hard fork as follow process
1. everyone can create a base parameter vote by spending not little bts, like 5000bts, to avoid there are not many change proposal to increase the load of stockholder.
2.if this proposal can get 51% vote of all stockholder in period ,like 60 days. block change acc.to this result ,change the base parameter automatic.
Actually the different change of pow coin can been consider the base parameter change by imformation of blockchain.
so I think it is less risk by developing this function.
« Last Edit: March 16, 2015, 05:51:04 PM by BTSdac »
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
I don't know about changing potentially consensus breaking parameters like the block interval, but I agree that other parameters (like fees) should be dynamic.

Perhaps before requiring binding proposals it makes sense to use non-binding proposals to figure out stakeholder wishes and let the authenticity of the change come from a super majority of the delegates. So if more than 75% of delegates agree to a particular dynamic parameter change (for example, changing the asset registration fee or transaction fee) then the blockchain will accept the new parameter (no need to download new binaries compiled with a changed constant).

Offline vikram

This sort of thing is preferable in general and should be done eventually, but not on the roadmap for 1.0.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
This sort of thing is preferable in general and should be done eventually, but not on the roadmap for 1.0.

I feel like we should start organizing a list of new features that the core devs agree are desirable for after 1.0 and order them by priority.

A list of things off the top of my head (that the core devs do not necessarily agree should be done) in no particular order:
  • Non-binding proposals (a very basic implementation is described here but I would prefer a nice one)
  • Dynamic parameters (and potentially even binding proposals which are proposed by delegates and ratified by shareholders)
  • UIA dividends
  • Prediction markets
  • DNS
  • Voting (with cryptographic privacy so that it is suitable for elections)
  • Decentralized BTC/BitAsset exchange
  • BitShares Standard Gateway for ECDSA altcoins (Actually I have a better, more secure version of it in mind than the one I linked to that I haven't written up yet.)
  • Better distribution of BitAsset yield
  • Generalized BitAssets (which allow using any other BitAsset as the collateral as well as custom price feed definitions, margin call percentage limits, and authority slates)
  • Bond markets
  • Constraining transactions to particular blockchain forks as added security, or "Economic Clustering" as NXT calls it (We used to have this with TaPoS and was IMO unnecessarily removed from the transition to DPOS, but it is very easy to add back in by slightly changing the transaction signing and validation procedure.)
  • Schnorr signatures as an optional alternative to ECDSA (which I believe should make using threshold signatures easier and faster)
  • Improvements to lightweight client security
  • Faster validation (by a super majority of delegates) of the blockchain using threshold signatures, which also makes using secure lightweight wallets far more convenient
  • Blockchain pruning
  • Smart contracts / Turing complete scripting
  • Support for child DACs

Of these, the only ones I believe there is core dev support for are dynamic parameters, prediction markets, DNS, Voting, smart contracts (however there may not be consensus on architecture and implementation details for smart contracts / Turing complete scripting), bond markets, and perhaps at least some form of generalized BitAssets. Besides that I am sure there is at least partial dev support for non-binding proposals and a decentralized BTC/BitBTC exchange. It would be nice to get those listed somewhere (and any other ones I forgot that the devs agree to) and figure out a prioritization for them.

In my opinion one of the highest priorities should be the Turing complete scripting since if that is done well it can be used to allow other outside devs to easily implement many of the other features in parallel such as DNS, Voting, decentralized BTC/BitAsset exchange, prediction markets, bond markets, and perhaps even generalized BitAssets (although I think I would prefer if the generalized BitAssets were done natively, and perhaps the bond market as well, or at least if "BitBTS" collateralized by BTS with a 100% collateral requirement was added, as a means of separating BTS value from BTS voting rights, then I guess I might be okay with generalized BitAssets implemented with the Turing complete scripting). Another high priority feature, IMO, is actually a set of features that I think work well together which is to implement Schnorr signatures, the threshold signature block signing by a super majority of the delegates, and the changes to the consensus protocol that commit database state to the block headers which allow lightweight clients to operate more securely (and have the side benefit of making blockchain pruning feasible).
« Last Edit: March 16, 2015, 07:09:36 PM by arhag »

Offline btswildpig

  • Hero Member
  • *****
  • Posts: 1404
    • View Profile
I love  arhag and his long post . always makes me want to copy it and store to my cloud and read it later .
这个是私人账号,表达的一切言论均不代表任何团队和任何人。This is my personal account , anything I said with this account will be my opinion alone and has nothing to do with any group.

Offline doyoubit

  • Newbie
  • *
  • Posts: 10
    • View Profile
I love  arhag and his long post . always makes me want to copy it and store to my cloud and read it later .

 long live arhag +5% +5%

Offline Rafikichi

  • Jr. Member
  • **
  • Posts: 24
    • View Profile
What are your delegate names arhag?

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 11963
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
@arhag: that's a nice starting point for a roadmap for post-1.0 releases .. what does it take to find a consensus about the set of features for 1.1, 1.2., ... release among the core devs?
Once we have a plain list, I am sure @cass can put something magical into it!
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

Offline abit

Notified.
I think the dividend feature is on milestone 0.8 https://github.com/BitShares/bitshares/issues/1430
BTS account: abit
BTS committee member: abit
BTS witness: in.abit

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
Notified.
I think the dividend feature is on milestone 0.8 https://github.com/BitShares/bitshares/issues/1430

Well that's a pleasant surprise. Can we get confirmation from Vikram that the dividend feature tentatively scheduled for 0.8.0 is intended to be of a design in which the transaction fee cost to the issuer to issue the dividend is fixed and does not scale with the number of balances holding the UIA?


Offline vikram

Notified.
I think the dividend feature is on milestone 0.8 https://github.com/BitShares/bitshares/issues/1430

Well that's a pleasant surprise. Can we get confirmation from Vikram that the dividend feature tentatively scheduled for 0.8.0 is intended to be of a design in which the transaction fee cost to the issuer to issue the dividend is fixed and does not scale with the number of balances holding the UIA?

No confirmation. It is only in that milestone so that we can consider it after 0.7 and decide if and how to move forward with it. It's ultimate fate could be anything from being closed as wontfix, to actually implementing one of the previous proposals.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
No confirmation. It is only in that milestone so that we can consider it after 0.7 and decide if and how to move forward with it. It's ultimate fate could be anything from being closed as wontfix, to actually implementing one of the previous proposals.

Okay, so then we should consider any issues in milestones that come after the earliest milestone at the time as effectively "not (necessarily) on the roadmap"? Can we assume that issues that are in the earliest milestone are issues that the core devs have concluded should be tackled as part of the roadmap (assuming no unforeseen changes)?

Offline vikram

No confirmation. It is only in that milestone so that we can consider it after 0.7 and decide if and how to move forward with it. It's ultimate fate could be anything from being closed as wontfix, to actually implementing one of the previous proposals.

Okay, so then we should consider any issues in milestones that come after the earliest milestone at the time as effectively "not (necessarily) on the roadmap"? Can we assume that issues that are in the earliest milestone are issues that the core devs have concluded should be tackled as part of the roadmap (assuming no unforeseen changes)?

I would say you shouldn't really assume anything. Even in the closest milestone, an issue might be there just to signify "ok just look at this now and then decide where to move it".

Offline arhag

  • Hero Member
  • *****
  • Posts: 1213
    • View Profile
    • My posts on Steem
  • BTS: arhag
  • GitHub: arhag
I would say you shouldn't really assume anything. Even in the closest milestone, an issue might be there just to signify "ok just look at this now and then decide where to move it".

Well, to reiterate what many other people on this forum have been saying for a while now: we really need a proper roadmap from the core devs. Maybe something like: features/fixes that are definitely planned (with some priority ranking), features/changes that are still being considered, and features/changes that are frequently requested by the community but have been rejected by the core devs for the foreseeable future (with a reason explaining why).

Offline betax

  • Hero Member
  • *****
  • Posts: 803
    • View Profile
This sort of thing is preferable in general and should be done eventually, but not on the roadmap for 1.0.

I feel like we should start organizing a list of new features that the core devs agree are desirable for after 1.0 and order them by priority.

A list of things off the top of my head (that the core devs do not necessarily agree should be done) in no particular order:
  • Non-binding proposals (a very basic implementation is described here but I would prefer a nice one)
  • Dynamic parameters (and potentially even binding proposals which are proposed by delegates and ratified by shareholders)
  • UIA dividends
  • Prediction markets
  • DNS
  • Voting (with cryptographic privacy so that it is suitable for elections)
  • Decentralized BTC/BitAsset exchange
  • BitShares Standard Gateway for ECDSA altcoins (Actually I have a better, more secure version of it in mind than the one I linked to that I haven't written up yet.)
  • Better distribution of BitAsset yield
  • Generalized BitAssets (which allow using any other BitAsset as the collateral as well as custom price feed definitions, margin call percentage limits, and authority slates)
  • Bond markets
  • Constraining transactions to particular blockchain forks as added security, or "Economic Clustering" as NXT calls it (We used to have this with TaPoS and was IMO unnecessarily removed from the transition to DPOS, but it is very easy to add back in by slightly changing the transaction signing and validation procedure.)
  • Schnorr signatures as an optional alternative to ECDSA (which I believe should make using threshold signatures easier and faster)
  • Improvements to lightweight client security
  • Faster validation (by a super majority of delegates) of the blockchain using threshold signatures, which also makes using secure lightweight wallets far more convenient
  • Blockchain pruning
  • Smart contracts / Turing complete scripting
  • Support for child DACs

Of these, the only ones I believe there is core dev support for are dynamic parameters, prediction markets, DNS, Voting, smart contracts (however there may not be consensus on architecture and implementation details for smart contracts / Turing complete scripting), bond markets, and perhaps at least some form of generalized BitAssets. Besides that I am sure there is at least partial dev support for non-binding proposals and a decentralized BTC/BitBTC exchange. It would be nice to get those listed somewhere (and any other ones I forgot that the devs agree to) and figure out a prioritization for them.

In my opinion one of the highest priorities should be the Turing complete scripting since if that is done well it can be used to allow other outside devs to easily implement many of the other features in parallel such as DNS, Voting, decentralized BTC/BitAsset exchange, prediction markets, bond markets, and perhaps even generalized BitAssets (although I think I would prefer if the generalized BitAssets were done natively, and perhaps the bond market as well, or at least if "BitBTS" collateralized by BTS with a 100% collateral requirement was added, as a means of separating BTS value from BTS voting rights, then I guess I might be okay with generalized BitAssets implemented with the Turing complete scripting). Another high priority feature, IMO, is actually a set of features that I think work well together which is to implement Schnorr signatures, the threshold signature block signing by a super majority of the delegates, and the changes to the consensus protocol that commit database state to the block headers which allow lightweight clients to operate more securely (and have the side benefit of making blockchain pruning feasible).

This is great, how can we formalise this and put it as a published roadmap?
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

 

Google+