Author Topic: Change the base parameter of bts by all bts stockholder to avoid hard fork  (Read 4285 times)

0 Members and 1 Guest are viewing this topic.

Offline vikram

We are swamped with other issues right now, and it looks like at this point we might collect the remaining market fixes and uia upgrades into a single next devshares release (which might be DVS 0.9) since we need to hardfork again to fix the current bts market.

Ping me to this thread again after the next DevShares release and I'll see what we can do.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
If we can get the devs to agree on somthing like the following, @cass can
quickly build something awesome up. I already talked with him about this and he
has something nice in mind already.

So, @vikram @toast @theoretical @modprobe @dannotestein, how about this:
Which of the features in the last block can we move somewhere earlier, like a
1.0? Hope certain are you guys that 1.0.0 will be after 0.10.0?

Give us some input and @cass can do the reset (hehe)

0.8.0
 * Multisig Addresses for Issers
 * Enhanced Permissions for UIA owner(s)
 * Regulation compliant UIA
 * Enhanced Contact Features

0.9.0
 * Dividends on UIA
 * Mutlisig for All Assets
 * Functional Escrow
 * Automated Black Swan Resultion
 * Localization Support for Account Names

0.10.0
 * RPC Enhancements
 * Signed Releases
 * Singing of Raw Unsigned Transactions

Upcoming Features (unsorted):
 * Smart Contracts / Turing Complete Scripting
 * Domain Name System
 * Voting
 * Prediction Markets
 * Bond Markets
 * Support for Child DACs
 * Non-Binding Proposals
 * Dynamic Parameters (and potentially even binding proposals which are proposed by delegates and ratified by shareholders)
 * Incorporation of the BTC blockchain (SPV)
 * BitShares Standard Gateway for ECDSA Altcoins
 * 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)
 * Schnorr Signatures alternative to ECDSA
 * Improvements to Lightweight Client Security
 * Faster Validation using Threshold Signatures
 * Blockchain Pruning

Offline betax

  • Hero Member
  • *****
  • Posts: 808
    • 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

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: 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 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: 1214
    • View Profile
    • My posts on Steem
  • BitShares: 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

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: 1214
    • View Profile
    • My posts on Steem
  • BitShares: 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 abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
BitShares committee member: abit
BitShares witness: in.abit

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: 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!

Offline Rafikichi

  • Jr. Member
  • **
  • Posts: 24
    • View Profile

Offline doyoubit

  • Jr. Member
  • **
  • Posts: 47
    • 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 btswildpig

  • Hero Member
  • *****
  • Posts: 1424
    • 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 arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: 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 vikram

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