Author Topic: Hardfork schedule proposal  (Read 8727 times)

0 Members and 1 Guest are viewing this topic.

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
thanks, it's reasonable for me.
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).

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
From Github it seems PR #23 still needs some work. Others are all OK now.
BitShares committee member: abit
BitShares witness: in.abit

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
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).
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
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 ?

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

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
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...
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline fav

  • Hero Member
  • *****
  • Posts: 4278
  • No Pain, No Gain
    • View Profile
    • Follow Me!
  • BitShares: fav
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

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
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.

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
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?
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
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?
 
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.

Offline xeroc

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

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
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.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline alt

  • Hero Member
  • *****
  • Posts: 2821
    • View Profile
  • BitShares: baozi
do we really need this?

Quote
Code review of [BSIP10] percentage based transfer fee   

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
Thanks for the clarification. Closed issue 203 and removed it from the list.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de

Offline bitcrab

  • Committee member
  • Hero Member
  • *
  • Posts: 1928
    • View Profile
  • BitShares: bitcrab
  • GitHub: bitcrab
@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.
Email:bitcrab@qq.com

Offline pc

  • Hero Member
  • *****
  • Posts: 1530
    • View Profile
    • Bitcoin - Perspektive oder Risiko?
  • BitShares: cyrano
@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.
Bitcoin - Perspektive oder Risiko? ISBN 978-3-8442-6568-2 http://bitcoin.quisquis.de