BitShares Forum

Main => Stakeholder Proposals => Topic started by: oxarbitrage on August 13, 2017, 06:16:07 pm

Title: Hardfork schedule proposal
Post by: oxarbitrage on August 13, 2017, 06:16:07 pm
I identified 4 big groups of issues that require hardfork and added them in the form of milestones:

https://github.com/bitshares/bitshares-core/milestones

We have 27 issues that require hardfork, no dates had been added but the plan is to discuss and add dates to them. i think we should do BSIP018 first but i leave this for shareholders/community consideration. We should maybe try to add more issues to the BSIP018 fork.

Please feel free to change/suggest changes, this is just one form of identify and separate the hardfork issues but may not be the best.
Title: Re: Hardfork schedule proposal
Post by: xeroc on August 13, 2017, 07:17:37 pm
I agree with adding some of the minor fixes to the bsip18 HF aswell bit ofc only after thorough testing on the testnet .. each of those issues separately ..

Imho
Title: Re: Hardfork schedule proposal
Post by: pc on August 14, 2017, 03:49:52 pm
Thanks Alfredo!

IMO every hardfork requires shareholder approval. Most of the hardfork issues are yet to be implemented. IMO we should include some of the low-hanging fruit into the BSIP-0018 hardfork and focus on finishing up a release.
Title: Re: Hardfork schedule proposal
Post by: oxarbitrage on August 14, 2017, 03:51:57 pm
i agree with that @pc and so also @xeroc . we neeed to decide what can we move to bsip 18 and leave the rest for a future release.
Title: Re: Hardfork schedule proposal
Post by: pc on August 14, 2017, 09:19:25 pm
Here's a more comprehensive list of hardfork items, together with their current state, estimated work size, and approval status. I'm open to suggestions regarding the size, it's just a rough guesstimate.

IssuePRNameBSIPStateSizeApprovedRemarks
216 (https://github.com/bitshares/bitshares-core/issues/216)340 (https://github.com/bitshares/bitshares-core/pull/340)Process to Reset a SmartCoin after a Blackswan Event0018 (https://github.com/bitshares/bsips/blob/master/bsip-0018)ReviewL1.14.56
154 (https://github.com/bitshares/bitshares-core/issues/154)Letting settlement_price expire would allow to reuse symbols for prediction markets0017 (https://github.com/bitshares/bsips/blob/master/bsip-0017)PlannedLN
23 (https://github.com/bitshares/bitshares-core/pull/23)386 (https://github.com/bitshares/bitshares-core/pull/386)Issue: Early withdrawal claimsReviewSN
143 (https://github.com/bitshares/bitshares-core/issues/143)348 (https://github.com/bitshares/bitshares-core/pull/348)Require voted entities to existReviewSN
338 (https://github.com/bitshares/bitshares-core/issues/338)Margin call order fills at price of matching limit_order but not at a price related to itself or settlement_priceRequestedMN
342 (https://github.com/bitshares/bitshares-core/issues/342)Rounding issue when matching orders RequestedMN
343 (https://github.com/bitshares/bitshares-core/issues/343)Inconsistent sorting of call orders between matching against a limit order and a force settle orderRequestedMN
353 (https://github.com/bitshares/bitshares-core/issues/353)369 (https://github.com/bitshares/bitshares-core/pull/369)Computation of number of committee members is wrongReviewSN
22 (https://github.com/bitshares/bitshares-core/issues/22)[Feature Suggestion] No Fee on User Side with Whitelisted UIARequestedS/MN
59 (https://github.com/bitshares/bitshares-core/issues/59)Audit charging of per-kilobyte feesRequestedLN
169 (https://github.com/bitshares/bitshares-core/issues/169)Asset can be registered with null core exchange rate, but not updatedRequestedSN
138 (https://github.com/bitshares/bitshares-core/issues/138)[Proposal Improvements] Add fee paying account to `available_active_approvals`Requested?N
173 (https://github.com/bitshares/bitshares-core/issues/173)Code review of [BSIP10] percentage based transfer fee0010 (https://github.com/bitshares/bsips/blob/master/bsip-0010)ReviewL1.14.29
186 (https://github.com/bitshares/bitshares-core/issues/186)612 (https://github.com/cryptonomex/graphene/issues/612) *Implement simple rate limited free transaction featureReviewLN?https://bitsharestalk.org/index.php/topic,21462.30.html
267 (https://github.com/bitshares/bitshares-core/issues/267)implement rotating standby witnessesRequestedM?N
170 (https://github.com/bitshares/bitshares-core/issues/170)new_options should be optional in asset_update_operationRequestedM?N
199 (https://github.com/bitshares/bitshares-core/issues/199)[Request] Require owner key for change of asset-issuerRequestedMN
197 (https://github.com/bitshares/bitshares-core/issues/197)Account_update_operation requires both owner authorities and active authorities when owner presentsRequestedSN
269 (https://github.com/bitshares/bitshares-core/issues/269)Fix recursive account permissionsRequestedSN
202 (https://github.com/bitshares/bitshares-core/issues/202)Hard fork request: correct wrong voting proxy settingsRequestedSN
125 (https://github.com/bitshares/bitshares-core/issues/125)When signing a block that updates the signing witness's signing key, use correct signing keyRequestedSN
210 (https://github.com/bitshares/bitshares-core/issues/210)Authorities on custom_operation are not checked correctlyReview?NSee https://github.com/FollowMyVote/graphene/commit/373700e717b2353eb485316f4bc93ab0d2468e05
188 (https://github.com/bitshares/bitshares-core/issues/188)New OP for issuer to reclaim fee pool fundsRequestedMN
146 (https://github.com/bitshares/bitshares-core/issues/146)proposal_delete_operation issuesRequestedSN
214 (https://github.com/bitshares/bitshares-core/issues/214)Unable to propose a proposal with an `approve_proposal` operationRequestedSN
Introducing expiring votes for Witnesses, Committie members & Proxies within the Bitshares network0022 (https://github.com/bitshares/bsips/blob/master/bsip-0022)DiscussionM?N

I was surprised to find that we have quite a few things in the queue that are already implemented. Apparently some things have been more or less forgotten and need to be updated and reviewed in-depth. We should focus on those, IMO, and possibly add a few of the 'S' items as well.

Edit 2017-08-31: PR #23 has been superceded by #386
Title: Re: Hardfork schedule proposal
Post by: abit on August 15, 2017, 09:47:48 am
Thanks for the list.
It's sad that my screen is too narrow, had a hard time to read.
Title: Re: Hardfork schedule proposal
Post by: pc on August 15, 2017, 03:05:31 pm
Shortened the links, should be better now
Title: Re: Hardfork schedule proposal
Post by: questionsquestions on August 15, 2017, 06:26:21 pm
I'd like to bring to your attention BSIP-0022 (https://steemit.com/bitshares/@cm-steem/bsip-0022-draft-introducing-expiring-votes-for-witnesses-committie-members-and-proxies-within-the-bitshares-network-an)

It would be extremely useful to have this functionality in the next hard fork so that active accounts have a better chance of being considered in any votes.
Title: Re: Hardfork schedule proposal
Post by: pc on August 15, 2017, 06:49:53 pm
Removed obsolete https://github.com/bitshares/bitshares-core/issues/189
Added BSIP-0022

Personally, I'm pretty sure that BSIP-0022 will not be part of the next hardfork. AFAIK this is still being discussed and nobody is working on it. I also think that it is questionable if this will receive shareholder approval.
Title: Re: Hardfork schedule proposal
Post by: pc on August 16, 2017, 04:40:48 pm
@bitcrab Are you still interested in issue 203 (Hard fork request: re-enable some permission settings of TCNY) ?

I have tried to ping hipster wrt issue 269 on steem and steemit.chat, but no reply so far.
Title: Re: Hardfork schedule proposal
Post by: bitcrab on August 16, 2017, 05:15:05 pm
Quote from: pc on August 16, 2017, 04:40:48 pm
@bitcrab Are you still interested in issue 203 (Hard fork request: re-enable some permission settings of TCNY) ?

I have tried to ping hipster wrt issue 269 on steem and steemit.chat, but no reply so far.

I have given up TCNY and also TUSD, no need to spend resource on them.
Title: Re: Hardfork schedule proposal
Post by: pc on August 16, 2017, 06:59:46 pm
Thanks for the clarification. Closed issue 203 and removed it from the list.
Title: Re: Hardfork schedule proposal
Post by: alt on August 17, 2017, 12:10:28 am
do we really need this?

Quote
Code review of [BSIP10] percentage based transfer fee   
Title: Re: Hardfork schedule proposal
Post by: pc on August 17, 2017, 04:21:45 pm
Do you mean "do we need the review" or do you mean "do we need percentage-based transfer fees"?
AFAICS the latter has already been decided by the shareholders, and regarding the former I would say that yes, a review is needed before we merge the code.
Title: Re: Hardfork schedule proposal
Post by: xeroc on August 18, 2017, 09:30:35 am
Quote from: pc on August 17, 2017, 04:21:45 pm
Do you mean "do we need the review" or do you mean "do we need percentage-based transfer fees"?
AFAICS the latter has already been decided by the shareholders, and regarding the former I would say that yes, a review is needed before we merge the code.
I thought about fees a little too ...
do you thing we can have something like this:

The asset issue sets an attribute for his asset on "what fee type is used". Then we can offer
* flat fee (BTS only) .. no fee pool
* flat fee with fee pool
* percentage based fee (BTS only)
* percentage based fee with fee pool
* bandwidth-based according to BTS reserved by issuer
* bandwidth-based according to BTS reserved by user (only for committee-owned/approved assets)
* any other type of fee that can/could/may be implemented

How difficult would it be to modify the code such that the "fee" part of it becomes more "plugin"-ish?
Title: Re: Hardfork schedule proposal
Post by: alt on August 18, 2017, 10:52:57 am
it's already 1 year ago.
last time I asked who need this feature?
nobody give the answer.
abit said he need earn money from us,
so he create this worker, and he promise give some money to Bytemaster for review.
then this worker vote up by somebody.

can you give me the answer if you know?
 
Quote from: pc on August 17, 2017, 04:21:45 pm
Do you mean "do we need the review" or do you mean "do we need percentage-based transfer fees"?
AFAICS the latter has already been decided by the shareholders, and regarding the former I would say that yes, a review is needed before we merge the code.
Title: Re: Hardfork schedule proposal
Post by: pc on August 18, 2017, 03:48:46 pm
I don't know the answer, and personally I don't think that this feature is desparately needed. Nevertheless, the worker has been voted in, it has been implemented, and we have paid for it.

Seeing that this discussion seems to be mostly ignored, how do we proceed from here?
Title: Re: Hardfork schedule proposal
Post by: alt on August 19, 2017, 12:30:22 am
my principle for the core:
1. keep logic as simple as possible.
2. every change should have enough good reason, because we don't know if other business depend on this.
    without a good reason, we even don't need to waste time to review.

so althrough we have pay for this worker, I don't agree to merge this feature, and don't want to review it.
Title: Re: Hardfork schedule proposal
Post by: fav on August 19, 2017, 07:25:38 am
Quote from: alt on August 19, 2017, 12:30:22 am
my principle for the core:
1. keep logic as simple as possible.
2. every change should have enough good reason, because we don't know if other business depend on this.
    without a good reason, we even don't need to waste time to review.

so althrough we have pay for this worker, I don't agree to merge this feature, and don't want to review it.

I don't remember this one, however if stakeholders voted for it it's not up for debate. It has to be Integrated
Title: Re: Hardfork schedule proposal
Post by: pc on August 20, 2017, 12:15:58 pm
Guys,

last call!

I'd like to wrap this discussion up and get BSIP-0018 into action. AFAICS we have the following things more or less ready for inclusion:

* PR 340 (BSIP-0018, approved)
* PR 23 (bugfix wrt early withdrawals)
* PR 348 (bugfix wrt voting)
* PR 369 (bugfix wrt committee voting)

Anything else?

Do we need shareholder approval for these bugfixes? It could be argued that we don't because the fixes don't change the *intended* operation of the blockchain. This is a dangerous road though, because in other cases there could be disagreement about whether something is a bug or intended...
Title: Re: Hardfork schedule proposal
Post by: alt on August 21, 2017, 12:52:28 am
sorry, but BSIP link wrong, it should be https://github.com/bitshares/bsips/blob/master/bsip-0018.md
May I ask a question about the new logic?
suppose USD already had a blackswan, the black swan price is at 0.1 USD/BTS, SWAN.current_supply is 1M USD
when we enable this new logic, the feed price is 0.2 USD/BTS.
from the descript I can still make a operation  bid_collateral_operation(debt_covered: 1M USD, additional_collateral: 1BTS).
then I can get the debt about 1M USD, and all the collection about: 1M/0.1 BTS ?

Quote from: pc on August 14, 2017, 09:19:25 pm
Here's a more comprehensive list of hardfork items, together with their current state, estimated work size, and approval status. I'm open to suggestions regarding the size, it's just a rough guesstimate.

IssuePRNameBSIPStateSizeApprovedRemarks
216 (https://github.com/bitshares/bitshares-core/issues/216)340 (https://github.com/bitshares/bitshares-core/pull/340)Process to Reset a SmartCoin after a Blackswan Event0018 (https://github.com/bitshares/bsips/blob/master/bsip-0018)ReviewL1.14.56
154 (https://github.com/bitshares/bitshares-core/issues/154)Letting settlement_price expire would allow to reuse symbols for prediction markets0017 (https://github.com/bitshares/bsips/blob/master/bsip-0017)PlannedLN
23 (https://github.com/bitshares/bitshares-core/pull/23)Issue: Early withdrawal claimsReviewSN
143 (https://github.com/bitshares/bitshares-core/issues/143)348 (https://github.com/bitshares/bitshares-core/pull/348)Require voted entities to existReviewSN
338 (https://github.com/bitshares/bitshares-core/issues/338)Margin call order fills at price of matching limit_order but not at a price related to itself or settlement_priceRequestedMN
342 (https://github.com/bitshares/bitshares-core/issues/342)Rounding issue when matching orders RequestedMN
343 (https://github.com/bitshares/bitshares-core/issues/343)Inconsistent sorting of call orders between matching against a limit order and a force settle orderRequestedMN
353 (https://github.com/bitshares/bitshares-core/issues/353)369 (https://github.com/bitshares/bitshares-core/pull/369)Computation of number of committee members is wrongReviewSN
22 (https://github.com/bitshares/bitshares-core/issues/22)[Feature Suggestion] No Fee on User Side with Whitelisted UIARequestedS/MN
59 (https://github.com/bitshares/bitshares-core/issues/59)Audit charging of per-kilobyte feesRequestedLN
169 (https://github.com/bitshares/bitshares-core/issues/169)Asset can be registered with null core exchange rate, but not updatedRequestedSN
138 (https://github.com/bitshares/bitshares-core/issues/138)[Proposal Improvements] Add fee paying account to `available_active_approvals`Requested?N
173 (https://github.com/bitshares/bitshares-core/issues/173)Code review of [BSIP10] percentage based transfer fee0010 (https://github.com/bitshares/bsips/blob/master/bsip-0010)ReviewL1.14.29
186 (https://github.com/bitshares/bitshares-core/issues/186)612 (https://github.com/cryptonomex/graphene/issues/612) *Implement simple rate limited free transaction featureReviewLN?https://bitsharestalk.org/index.php/topic,21462.30.html
267 (https://github.com/bitshares/bitshares-core/issues/267)implement rotating standby witnessesRequestedM?N
170 (https://github.com/bitshares/bitshares-core/issues/170)new_options should be optional in asset_update_operationRequestedM?N
199 (https://github.com/bitshares/bitshares-core/issues/199)[Request] Require owner key for change of asset-issuerRequestedMN
197 (https://github.com/bitshares/bitshares-core/issues/197)Account_update_operation requires both owner authorities and active authorities when owner presentsRequestedSN
269 (https://github.com/bitshares/bitshares-core/issues/269)Fix recursive account permissionsRequestedSN
202 (https://github.com/bitshares/bitshares-core/issues/202)Hard fork request: correct wrong voting proxy settingsRequestedSN
125 (https://github.com/bitshares/bitshares-core/issues/125)When signing a block that updates the signing witness's signing key, use correct signing keyRequestedSN
210 (https://github.com/bitshares/bitshares-core/issues/210)Authorities on custom_operation are not checked correctlyReview?NSee https://github.com/FollowMyVote/graphene/commit/373700e717b2353eb485316f4bc93ab0d2468e05
188 (https://github.com/bitshares/bitshares-core/issues/188)New OP for issuer to reclaim fee pool fundsRequestedMN
146 (https://github.com/bitshares/bitshares-core/issues/146)proposal_delete_operation issuesRequestedSN
214 (https://github.com/bitshares/bitshares-core/issues/214)Unable to propose a proposal with an `approve_proposal` operationRequestedSN
Introducing expiring votes for Witnesses, Committie members & Proxies within the Bitshares network0022 (https://github.com/bitshares/bsips/blob/master/bsip-0022)DiscussionM?N

I was surprised to find that we have quite a few things in the queue that are already implemented. Apparently some things have been more or less forgotten and need to be updated and reviewed in-depth. We should focus on those, IMO, and possibly add a few of the 'S' items as well.
Title: Re: Hardfork schedule proposal
Post by: pc on August 21, 2017, 10:15:16 am
Quote from: alt on August 21, 2017, 12:52:28 am
May I ask a question about the new logic?
suppose USD already had a blackswan, the black swan price is at 0.1 USD/BTS, SWAN.current_supply is 1M USD
when we enable this new logic, the feed price is 0.2 USD/BTS.
from the descript I can still make a operation  bid_collateral_operation(debt_covered: 1M USD, additional_collateral: 1BTS).
then I can get the debt about 1M USD, and all the collection about: 1M/0.1 BTS ?

No, this is prevented in the section "Auto-revive after increase of settlement fund value". If the BTS price recovers that much, the settlement fund and debt are turned into a normal short position belonging to the asset issuer (in the case of bitUSD that would be the committee).
Title: Re: Hardfork schedule proposal
Post by: abit on August 21, 2017, 11:22:09 am
From Github (https://github.com/bitshares/bitshares-core/pulls?q=is%3Apr+is%3Aopen+label%3Ahardfork) it seems PR #23 still needs some work. Others are all OK now.
Title: Re: Hardfork schedule proposal
Post by: alt on August 21, 2017, 01:35:28 pm
thanks, it's reasonable for me.
Quote from: pc on August 21, 2017, 10:15:16 am
Quote from: alt on August 21, 2017, 12:52:28 am
May I ask a question about the new logic?
suppose USD already had a blackswan, the black swan price is at 0.1 USD/BTS, SWAN.current_supply is 1M USD
when we enable this new logic, the feed price is 0.2 USD/BTS.
from the descript I can still make a operation  bid_collateral_operation(debt_covered: 1M USD, additional_collateral: 1BTS).
then I can get the debt about 1M USD, and all the collection about: 1M/0.1 BTS ?

No, this is prevented in the section "Auto-revive after increase of settlement fund value". If the BTS price recovers that much, the settlement fund and debt are turned into a normal short position belonging to the asset issuer (in the case of bitUSD that would be the committee).