BitShares Forum

Main => General Discussion => Topic started by: BTSdac on March 16, 2015, 05:28:42 pm

Title: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: BTSdac on March 16, 2015, 05:28:42 pm
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.
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: arhag on March 16, 2015, 06:01:57 pm
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).
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: vikram on March 16, 2015, 06:06:16 pm
This sort of thing is preferable in general and should be done eventually, but not on the roadmap for 1.0.
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: arhag on March 16, 2015, 07:05:04 pm
Quote from: vikram on March 16, 2015, 06:06:16 pm
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:

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).
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: btswildpig on March 16, 2015, 07:11:48 pm
I love  arhag and his long post . always makes me want to copy it and store to my cloud and read it later .
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: doyoubit on March 16, 2015, 11:37:38 pm
Quote from: btswildpig on March 16, 2015, 07:11:48 pm
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%
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: Rafikichi on March 17, 2015, 02:58:01 am
What are your delegate names arhag?
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: xeroc on March 17, 2015, 06:54:01 am
@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!
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: abit on March 17, 2015, 09:03:23 am
Notified.
I think the dividend feature is on milestone 0.8 https://github.com/BitShares/bitshares/issues/1430
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: arhag on March 17, 2015, 06:18:25 pm
Quote from: abit on March 17, 2015, 09:03:23 am
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?

Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: vikram on March 17, 2015, 06:26:08 pm
Quote from: arhag on March 17, 2015, 06:18:25 pm
Quote from: abit on March 17, 2015, 09:03:23 am
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.
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: arhag on March 17, 2015, 06:44:53 pm
Quote from: vikram on March 17, 2015, 06:26:08 pm
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)?
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: vikram on March 17, 2015, 08:27:32 pm
Quote from: arhag on March 17, 2015, 06:44:53 pm
Quote from: vikram on March 17, 2015, 06:26:08 pm
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".
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: arhag on March 17, 2015, 08:53:32 pm
Quote from: vikram on March 17, 2015, 08:27:32 pm
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).
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: betax on March 21, 2015, 07:19:14 am
Quote from: arhag on March 16, 2015, 07:05:04 pm
Quote from: vikram on March 16, 2015, 06:06:16 pm
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 (https://bitsharestalk.org/index.php?topic=14621.msg190263#msg190263) 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 (https://bitsharestalk.org/index.php?topic=14785.msg191711#msg191711)
  • Prediction markets
  • DNS
  • Voting (with cryptographic privacy so that it is suitable for elections)
  • Decentralized BTC/BitAsset exchange (https://bitsharestalk.org/index.php?topic=14318.msg192954#msg192954)
  • BitShares Standard Gateway for ECDSA altcoins (https://bitsharestalk.org/index.php?topic=14808.msg191922#msg191922) (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 (https://bitsharestalk.org/index.php?topic=14004.msg182185#msg182185) (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 (https://bitsharestalk.org/index.php?topic=6584.msg87951#msg87951), or "Economic Clustering" (https://bitsharestalk.org/index.php?topic=14618.msg190100#msg190100) 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 (https://bitsharestalk.org/index.php?topic=13940.0) to lightweight client security (https://bitsharestalk.org/index.php?topic=12909.msg170117#msg170117)
  • Faster validation (by a super majority of delegates) of the blockchain using threshold signatures (https://bitsharestalk.org/index.php?topic=13872.0), which also makes using secure lightweight wallets far more convenient
  • Blockchain pruning (https://bitsharestalk.org/index.php?topic=13965.msg182455#msg182455)
  • Smart contracts / Turing complete scripting
  • Support for child DACs (https://bitsharestalk.org/index.php?topic=11349.0)

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?
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: xeroc on March 21, 2015, 01:11:08 pm
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
Title: Re: Change the base parameter of bts by all bts stockholder to avoid hard fork
Post by: vikram on March 21, 2015, 08:56:38 pm
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.