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.
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
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.
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.
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.
Issue | PR | Name | BSIP | State | Size | Approved | Remarks |
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 Event | 0018 (https://github.com/bitshares/bsips/blob/master/bsip-0018) | Review | L | 1.14.56 | |
154 (https://github.com/bitshares/bitshares-core/issues/154) | | Letting settlement_price expire would allow to reuse symbols for prediction markets | 0017 (https://github.com/bitshares/bsips/blob/master/bsip-0017) | Planned | L | N | |
| 23 (https://github.com/bitshares/bitshares-core/pull/23)386 (https://github.com/bitshares/bitshares-core/pull/386) | Issue: Early withdrawal claims | | Review | S | N | |
143 (https://github.com/bitshares/bitshares-core/issues/143) | 348 (https://github.com/bitshares/bitshares-core/pull/348) | Require voted entities to exist | | Review | S | N | |
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_price | | Requested | M | N | |
342 (https://github.com/bitshares/bitshares-core/issues/342) | | Rounding issue when matching orders | | Requested | M | N | |
343 (https://github.com/bitshares/bitshares-core/issues/343) | | Inconsistent sorting of call orders between matching against a limit order and a force settle order | | Requested | M | N | |
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 wrong | | Review | S | N | |
22 (https://github.com/bitshares/bitshares-core/issues/22) | | [Feature Suggestion] No Fee on User Side with Whitelisted UIA | | Requested | S/M | N | |
59 (https://github.com/bitshares/bitshares-core/issues/59) | | Audit charging of per-kilobyte fees | | Requested | L | N | |
169 (https://github.com/bitshares/bitshares-core/issues/169) | | Asset can be registered with null core exchange rate, but not updated | | Requested | S | N | |
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 fee | 0010 (https://github.com/bitshares/bsips/blob/master/bsip-0010) | Review | L | 1.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 feature | | Review | L | N? | https://bitsharestalk.org/index.php/topic,21462.30.html |
267 (https://github.com/bitshares/bitshares-core/issues/267) | | implement rotating standby witnesses | | Requested | M? | N | |
170 (https://github.com/bitshares/bitshares-core/issues/170) | | new_options should be optional in asset_update_operation | | Requested | M? | N | |
199 (https://github.com/bitshares/bitshares-core/issues/199) | | [Request] Require owner key for change of asset-issuer | | Requested | M | N | |
197 (https://github.com/bitshares/bitshares-core/issues/197) | | Account_update_operation requires both owner authorities and active authorities when owner presents | | Requested | S | N | |
269 (https://github.com/bitshares/bitshares-core/issues/269) | | Fix recursive account permissions | | Requested | S | N | |
202 (https://github.com/bitshares/bitshares-core/issues/202) | | Hard fork request: correct wrong voting proxy settings | | Requested | S | N | |
125 (https://github.com/bitshares/bitshares-core/issues/125) | | When signing a block that updates the signing witness's signing key, use correct signing key | | Requested | S | N | |
210 (https://github.com/bitshares/bitshares-core/issues/210) | | Authorities on custom_operation are not checked correctly | | Review | ? | N | See https://github.com/FollowMyVote/graphene/commit/373700e717b2353eb485316f4bc93ab0d2468e05 |
188 (https://github.com/bitshares/bitshares-core/issues/188) | | New OP for issuer to reclaim fee pool funds | | Requested | M | N | |
146 (https://github.com/bitshares/bitshares-core/issues/146) | | proposal_delete_operation issues | | Requested | S | N | |
214 (https://github.com/bitshares/bitshares-core/issues/214) | | Unable to propose a proposal with an `approve_proposal` operation | | Requested | S | N | |
| | Introducing expiring votes for Witnesses, Committie members & Proxies within the Bitshares network | 0022 (https://github.com/bitshares/bsips/blob/master/bsip-0022) | Discussion | M? | 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
Thanks for the list.
It's sad that my screen is too narrow, had a hard time to read.
Shortened the links, should be better now
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.
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.
@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.
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.
Thanks for the clarification. Closed issue 203 and removed it from the list.
do we really need this?
Quote
Code review of [BSIP10] percentage based transfer fee
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.
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?
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.
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?
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.
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
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...
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.
Issue | PR | Name | BSIP | State | Size | Approved | Remarks |
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 Event | 0018 (https://github.com/bitshares/bsips/blob/master/bsip-0018) | Review | L | 1.14.56 | |
154 (https://github.com/bitshares/bitshares-core/issues/154) | | Letting settlement_price expire would allow to reuse symbols for prediction markets | 0017 (https://github.com/bitshares/bsips/blob/master/bsip-0017) | Planned | L | N | |
| 23 (https://github.com/bitshares/bitshares-core/pull/23) | Issue: Early withdrawal claims | | Review | S | N | |
143 (https://github.com/bitshares/bitshares-core/issues/143) | 348 (https://github.com/bitshares/bitshares-core/pull/348) | Require voted entities to exist | | Review | S | N | |
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_price | | Requested | M | N | |
342 (https://github.com/bitshares/bitshares-core/issues/342) | | Rounding issue when matching orders | | Requested | M | N | |
343 (https://github.com/bitshares/bitshares-core/issues/343) | | Inconsistent sorting of call orders between matching against a limit order and a force settle order | | Requested | M | N | |
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 wrong | | Review | S | N | |
22 (https://github.com/bitshares/bitshares-core/issues/22) | | [Feature Suggestion] No Fee on User Side with Whitelisted UIA | | Requested | S/M | N | |
59 (https://github.com/bitshares/bitshares-core/issues/59) | | Audit charging of per-kilobyte fees | | Requested | L | N | |
169 (https://github.com/bitshares/bitshares-core/issues/169) | | Asset can be registered with null core exchange rate, but not updated | | Requested | S | N | |
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 fee | 0010 (https://github.com/bitshares/bsips/blob/master/bsip-0010) | Review | L | 1.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 feature | | Review | L | N? | https://bitsharestalk.org/index.php/topic,21462.30.html |
267 (https://github.com/bitshares/bitshares-core/issues/267) | | implement rotating standby witnesses | | Requested | M? | N | |
170 (https://github.com/bitshares/bitshares-core/issues/170) | | new_options should be optional in asset_update_operation | | Requested | M? | N | |
199 (https://github.com/bitshares/bitshares-core/issues/199) | | [Request] Require owner key for change of asset-issuer | | Requested | M | N | |
197 (https://github.com/bitshares/bitshares-core/issues/197) | | Account_update_operation requires both owner authorities and active authorities when owner presents | | Requested | S | N | |
269 (https://github.com/bitshares/bitshares-core/issues/269) | | Fix recursive account permissions | | Requested | S | N | |
202 (https://github.com/bitshares/bitshares-core/issues/202) | | Hard fork request: correct wrong voting proxy settings | | Requested | S | N | |
125 (https://github.com/bitshares/bitshares-core/issues/125) | | When signing a block that updates the signing witness's signing key, use correct signing key | | Requested | S | N | |
210 (https://github.com/bitshares/bitshares-core/issues/210) | | Authorities on custom_operation are not checked correctly | | Review | ? | N | See https://github.com/FollowMyVote/graphene/commit/373700e717b2353eb485316f4bc93ab0d2468e05 |
188 (https://github.com/bitshares/bitshares-core/issues/188) | | New OP for issuer to reclaim fee pool funds | | Requested | M | N | |
146 (https://github.com/bitshares/bitshares-core/issues/146) | | proposal_delete_operation issues | | Requested | S | N | |
214 (https://github.com/bitshares/bitshares-core/issues/214) | | Unable to propose a proposal with an `approve_proposal` operation | | Requested | S | N | |
| | Introducing expiring votes for Witnesses, Committie members & Proxies within the Bitshares network | 0022 (https://github.com/bitshares/bsips/blob/master/bsip-0022) | Discussion | M? | 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.
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).
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.
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).