$ ruby mm_rewards.rb 2019-11-15 1.10.52423

Date: 2019-11-15

Computing snapshots chucksum...
  414296cc145d023e0f000226bf084bb8f655685cb67d3988a1e22f8395b1ce63

Analyzing snapshots data and computing rewards...
  Total Rewards: 39978.11954 BTS

Let's verify the current proposal
  Getting proposal '1.10.52423' from the blockchain...
  Loading computed rewards data and mimic a proposal...
  Comparing proposals...
    No difference found!

I will approve the proposal.

What about giving this blocktrades's idea a chance?

We did try several things in the last months/years, I think we can afford another experiment, moreover if this experiment tries to rely more on our decentralized exchange.

I understand that there are some reservations and concerns, but I think we can try to apply some stratagem to remedy or at least to limit the possibility of negative outcomes.

For instance, we could try this new approach once the market making contest is started.
Thanks to the market making contest, we hope to have:

• Multiple reliable gateways with active deposit and withdrawal
• These gateways should gain more trust since they will provide evidence about their assets being fully-backed
• More liquidity/volume in specific inner markets

We could derive our bitassets prices from these same inner markets (directly or indirectly) that hopefully will see an increase in liquidity: such as BTS/BTC, BTS/ETH, and BTS/USDT
To avoid some bad feedback-loop and/or our inner markets being crashed due to higher pressure from cex's bts markets, we can still apply some trick that we already use.

We could feed:
max(price-from-inner-markets, price-from-cex)
or, in line with the latest proposal from cn-vote group:
max(price-from-inner-markets, moving-average-price-from-cex)
Thoughts?

I will try to step in and share my opinion about the decouple proposal.

Apologies if some of my replies will be slightly off-topic or inconsistent with the OP intention (or his statements), but it is difficult for me to follow the discussion here due to the automatic translation accuracy (not good at all).

Being a member of the committee, I think it is important that you know what is my general view about the proposal to separate the price feeding operation from the block production operation.
My opinion will be reflected in the event that the committee is asked to express itself by voting for applying the changes inside such a proposal. It is therefore important that you are aware as well so to be able to cast your vote accordingly.

I am totally in favor of the separation of price feeding from block production.
In the event that the committee members are asked to cast a vote to support or reject such separation, I will vote to support it.

I think it is important to acknowledge that recent (and eventually future) events about unvoting witnesses to change the bitassets fed price put some danger (as security, safety, and stability) to the whole platform. The willingness of the community and it's stakeholders to express their own opinion and change some rules about a key component as the price feeding is understandable, but we must ensure that this is possible without jeopardizing the security of the entire blockchain.

I also think that bigger changes would probably be needed to best address some other problems that currently affect our bitassets. Some of those changes are included in the BSIP83 draft. At the same time, I understand the reluctance to support such a big proposal that would need a good amount of work, code and time by the core-team.
I, therefore agree on trying to implement these changes with the tools we have available now, without adding new code.

In my opinion, the committee should change major bitassets flag so to not be automatically fed by witnesses anymore, but instead to be fed by a selected list of "feeders".
For start, such feeders list should actually be the currently active witnesses.
This, in my opinion, makes sense because currently active witnesses are already feeding the price for bitassets, are already following the community will, have already implemented some important BSIPs and have already the infrastructure (node) and code (script) needed for such operations. Selecting the currently active witnesses as the initial feeders list would allow us to make the transition as smooth as possible, with the lowest possible risk of price feeding inconveniences and failures.

After the switch is made, the committee would be able to modify the feeders list to remove those witnesses that are not interested in price feeding (or are not considered worthy and fit for the role), and at the same time add those community members who are instead interested to fill and apply for the price feeding role. The committee can look for community feedback and recommendation about how exactly apply these modifications.

About other inputs from the OP:
- I am not sure we really need a bailment from feeders
- We instead can have a no-pay-period during which feeders are checked to ensure their setup is in line with what is required. If not, they will be voted out from the feeders list and will get no pay for their first period. This could also help reduce committee fund management
- We can use worker-poll to determine the initial feeders reward. Suggestion for values in these worker-polls can be made by the committee, considering the costs that the feeders will have to bear.

I hope everything I wrote above is clear enough to not create misunderstandings due to translation errors.

Hello, will cn-vote reconsider their witness voting? In particular for those witnesses that just followed the current rules and social contract for applying bsips?

Keep in mind that one day you may be on the other side, hoping witnesses to follow the agreed rules instead of doing whatever they want, unilaterally.

I made the bsip76 related changes to my pricefeed script on September 29th, day on which the two proposal really became active.

Thx

I am sorry if I did not tell the fact, I really had a bad memory. I am not intended to tell lies.

It's ok, I believe you. I always respected you and I still do.

in our(abit, I and also most of the China community) view, this action is a little urgent, we do not want to see it fall in the trap of low efficiency and bureaucracy.

I really feel we need a new rule on how to handle poll and their threshold, it's reluctant to request a poll to overcome refund400K. and there's no time to develop a new rule at this urgent scenario.

Since active witnesses are applying bsip76 and so there are no other urgent calls to make, I think the whole community should focus on this poll/threshold issue and get to a conclusion before another bsip76-like event occurs.

I probably went a bit off-topic and I am sorry for that.
I hope the whole community can reach an agreement on how to deal with these scenarios so that next time witnesses will know how to react based on community will.

either BSIP76 should be regarded as pass or not, witnesses have already made their decision.

Witnesses were basically forced to since not accepting and applying BSIP76 would lead them to be unvoted, even if the voting process was in contrast with the current rule/social contract.

I am an example of that: you and cn-vote voted me out, and you did that even if I was the only one left not applying BSIP76 (for the good reasons mentioned above) and so even if my price feeding was useless from a consensus standpoint. The only reason to vote me out was for you and cn-vote to show witnesses what would mean not following your decision and your will.

Feeding max(real_price, gs_protection_price)
where gs_protection_price = gs_price * 1.12