[Witness Proposal] gdex-witnness

[Thul3]

Let's be realistic ZB is voting what Bitcrab is telling them to vote.

He posted himself earlier that he is going to tell them what to vote for.

Also, BitShares-core comes with a lower limit of 11 witnesses - can't go below that.

So they are voting now to have a max of 11 witnesses.

Would love to know if the community agrees with this low amount of witnesses.

Also it was raised that ZB using their members BTS is very unethical and bitcrabs argumentation was they won't harm bitshares ecosystem.
I see voting only for 2 witnesses with such a big stake as harm expecially as it was dicussed before that voting only for themself won't be recognised by the system as a low number voting.

[xeroc]

Tough question actually. Why would they vote for anyone they don't know?
Also, BitShares-core comes with a lower limit of 11 witnesses - can't go below that.

Would you vote for a witness and committee member who uses BTS from an exchange wallet to vote only for 2 witnesses for the entire bitshares ecosystem ?


Bitcrab is currently voting with the BTS in ZB's wallet that the whole bitshares ecosystem should only have 2 witnesses in total.


Is he doing a good job with that voting ?

[Thul3]

Would you vote for a witness and committee member who uses BTS from an exchange wallet to vote only for 2 witnesses for the entire bitshares ecosystem ?


Bitcrab is currently voting with the BTS in ZB's wallet that the whole bitshares ecosystem should only have 2 witnesses in total.


Is he doing a good job with that voting ?

[bitcrab]

this is a poll with 2 worker proposals, not a budget based worker proposal.

here the essential point is which WP get more voting power, not whether the WP become active.

[finn-bts]

as in the Poll of bsip41 - worker proposals  1.14.144 and 1.14.155, far more voting power support to implement bsip41, gdex-witness plan to feed 1.05 as MSSR for bitCNY in 2 days.

bsip41: https://github.com/bitshares/bsips/blob/master/bsip-0041.md

Sorry, I will vote for no until these wrong feed price been voted out.
I don't think witness should execute it until it become an active worker.

Cancellation of BSIP42 and execution of BSIP41 can be carried out at the same time. If cancellation of BSIP42 is not well executed after you support BSIP41, you can cancel the ticket of BSIP41 without much impact

[alt]

as in the Poll of bsip41 - worker proposals  1.14.144 and 1.14.155, far more voting power support to implement bsip41, gdex-witness plan to feed 1.05 as MSSR for bitCNY in 2 days.

bsip41: https://github.com/bitshares/bsips/blob/master/bsip-0041.md

Sorry, I will vote for no until these wrong feed price been voted out.
I don't think witness should execute it until it become an active worker.

[Thul3]

There is a high possibility that this is a bull trap.Actually the possibility is bigger being a bulld trap than a bull.
Reducing MSSR back to 105% makes that should the price go down again no margin will be eaten again.
The same mistake as before.
If you want MSSR 105% (which i support on acurat price feed as it make sense) make first sure to provide real feed price to ensure margin orders being eaten in a down trend.
At current price feed situation its just a protection for margins to not get eaten.

EDIT : Just saw it seems BTS on bitcny have now real price.

[bitcrab]

The POLL is NO CONSENSUS.

You are BREAKING ALL RULES AS WITNESS !!!!!!

You have no right to change MSSR without creating a worker which will get voted in.

I will make sure that all witnesses which will change MSSR without a REAL community consensus will lose their voters.

he is talking about the on-chain poll

I know the NO BSIP42 is a clear signal to stop manipulation and that people want the margin to get eaten.What he is doing now is not changing price feed and lowering the MSSR back to 105% so margins won't be eaten anymore.
Also he is the only bigger proxy voting for BSIP41 so i doubt this is real consensus.

margin call orders are there at the top for long time, if bitCNY holders want to eat, they had done, if they won't, no need always let the margin call orders press the price and create high bitCNY premium.

bitcrab has only about 30M voting power, everyone can know whether I am the only big proxy to support bsip41.

[Thul3]

The POLL is NO CONSENSUS.

You are BREAKING ALL RULES AS WITNESS !!!!!!

You have no right to change MSSR without creating a worker which will get voted in.

I will make sure that all witnesses which will change MSSR without a REAL community consensus will lose their voters.

he is talking about the on-chain poll

I know the NO BSIP42 is a clear signal to stop manipulation and that people want the margin to get eaten.What he is doing now is not changing price feed and lowering the MSSR back to 105% so margins won't be eaten anymore.
Also he is the only bigger proxy voting for BSIP41 so i doubt this is real consensus.

[clockwork]

The POLL is NO CONSENSUS.

You are BREAKING ALL RULES AS WITNESS !!!!!!

You have no right to change MSSR without creating a worker which will get voted in.

I will make sure that all witnesses which will change MSSR without a REAL community consensus will lose their voters.

he is talking about the on-chain poll

[Thul3]

....

[bitcrab]

as in the Poll of bsip41 - worker proposals  1.14.144 and 1.14.155, far more voting power support to implement bsip41, gdex-witness plan to feed 1.05 as MSSR for bitCNY in 2 days.

bsip41: https://github.com/bitshares/bsips/blob/master/bsip-0041.md

[bitcrab]

plan for next update on bitCNY:

Pdex：BTS price in DEX in smartcoin
Pf: current feed price
premium: current premium
GS_price: global settlement price

scale= 0.5;
get Pdex, Pf, premium, GS_price;

black_swan_protection_price = GS_price*MSSR*1.01

while True:
   
   get Pdex, Pf, premium;
   if 0.5%>premium>-1%: ##just adopt the current median if the absolute premium is low enough.
       feed price = Pf;
   else:
       feed price = Pf*(1+premium*scale);
   feed price = min(feed price, Pdex*MSSR)
   feed price = max(feed price, Pdex, black_swan_protection_price)
 
   time.sleep(120); ##update every 2 minutes.

[bitcrab]

What are your thoughts on enforcing not a 1:1 peg, but one with a constant premium? There have been discussions on it in telegram and I tend to agree that a small constant positive premium will behave more stable than 1:1.

In your algorithm that would correlate to something like

Code: [Select]

   ...
   target_premium = 0.5%; // arbitrary number, chosen here to reflect the lower bound of allowed premium to be 0

   get Pdex, Pf, premium;
   premium = premium - target_premium;
   ...

in current bitCNY situation, your algorithm will make feed price even lower. maybe that will lead to better pegging, but will make more margin call happen which seems not so necessary. this may be not good as now feed price is already more than 2% lower than DEX price in bitCNY market.

I prefer to accept a premium between -0.5% and 0.3% with adopt the current median.

[sschiessl]

What are your thoughts on enforcing not a 1:1 peg, but one with a constant premium? There have been discussions on it in telegram and I tend to agree that a small constant positive premium will behave more stable than 1:1.

In your algorithm that would correlate to something like

Code: [Select]

   ...
   target_premium = 0.5%; // arbitrary number, chosen here to reflect the lower bound of allowed premium to be 0

   get Pdex, Pf, premium;
   premium = premium - target_premium;
   ...

[bitcrab]

plan to adopt below feed price algorithm to replace the current one:

Pdex：BTS price in DEX in smartcoin
Pf: current feed price
premium: current premium

scale=1;
get Pdex, Pf, premium;

while True:
   
   get Pdex, Pf, premium;
   if 0.3%>premium>-0.5%: ##just adopt the current median if the absolute premium is low enough.
       feed price = Pf;
   else:
       feed price = Pf*(1+premium*scale);
   time.sleep(120); ##update every 2 minutes.

[Thom]

This topic is for "[Witness Proposal] gdex-witnness", the correct place to discuss is at "Witness Report for Verbaltech2":
https://bitsharestalk.org/index.php/topic,23902.0.html

Anyway, I suggest both of you settle the issue privately. What both of you share here may misused by someone else to call a public unvote, we can't lose both of you.

Point noted, however abit made it a point to attack my abilities here, so here is where I refute them. He has chosen not to respond to my DMs, and seems to be less in favor of talking to me to and "working this out".

[Bangzi]

This topic is for "[Witness Proposal] gdex-witnness", the correct place to discuss is at "Witness Report for Verbaltech2":
https://bitsharestalk.org/index.php/topic,23902.0.html

Anyway, I suggest both of you settle the issue privately. What both of you share here may misused by someone else to call a public unvote, we can't lose both of you.

[Thom]

@abit: How typical of those with claims and shallow evidence to avoid dealing with the substance of a matter and use excuses like "I don't have time". Yet you have time to write me a DM and lengthy posts here to attack my abilities. Sounds rather hypocritical of you.

Your assessment of my attitude concerning the importance of price feeds and timeliness of security patches is wrong, totally. It is merely your emotional response to someone that doesn't bow down to you or disagrees with you. You couldn't have demonstrated that any better than you did when you took it upon yourself to ban me from the witness channel.

And I guess I'm wasting my time with you as well, if you insist on focusing on one and only one aspect of witness duties and trying to make a claim an occasional mistake is adequate evidence I am not a capable witness. You have to do much better to discredit 3+ years as a witness that has run at least 4 nodes since graphene was launched. If you are so concerned about the quality of witnesses why don't you help set standards so their skills can be assessed objectively? You don't b/c that isn't what you're really concerned about, despite all your claims towards others. No, it's very clear you only care about feeds of CNY, not about metrics to objectively measure things, not about decentralization of nodes, not about documentation to improve adoption, not about feed frequency, not about tools like RoelandP's Witness Log that displays objective feed data for all witnesses. You have a very narrow focus which would be just fine if you didn't try to force others to conform to it to the exclusion of other important things.

I do understand very well the importance of price feeds, but apparently you, the author of bsip42 do not and are thus willing to foist it upon this ecosystem without any guidelines or clear, measurable objectives or timeframes to achieve them. None of the questions Thul3 or I asked about reports, timeframe to completion etc have been addressed. Why not? Some of them should have been in the bsip.

All that you've shown everyone with your posts here is how quickly you jump to conclusions, how dictatorial and demanding you are and how you fail to be as concerned about the well being of the BitShares ecosystem as you should be as a core dev. I sure hope the other devs are in the habit of doing code reviews to keep you in check, as your attitude is really scary, and not conducive to an open project where all ideas should be encouraged not censored as you did.

I gather from reading Telegram that the devs at the Bitfest conference have discussed Bsip42 and have come up with another approach that preserves the former market feed price but adds a new adjustment or "premium" value (bsip42's PID feedback) which can easily be applied to the market feed to obtain the bsip42 target price. Sounds like a much safer approach that minimizes potential disruption to BitShares. Not surprisingly you don't think it's worth it, despite the flexibility and safety it affords. More evidence you are apparently not concerned with keeping the ecosystem a free market for all but are all to willing to change it to support your own agenda.

I am able to see the important things when clearly posted in the proper places and with the proper info. Your terse "pinned" messages don't always identify the purpose, or even provide a vague hint about why a patch or release is necessary - emergency - security - other. You are just not consistent with the info you do provide and then you want to blame others if they don't jump to your command. That's hogwash.

[abit]

@Thom: looks like you're still unable to see why emergency fixes are urgent, why correctness of price feed is important. That's why I think you're not qualified. As I've DMed you (also pasted above), I don't have time to convince you. Whether I was subjective, all in the data and chatting log pasted above.

[armin]

Interesting conversation

[Thom]

I could highlight many more points from these convos which is concerning me like you have no clear rules ,standards for running BSIP42 .
The description of BSIP 42 is also very fluffy.

About Thomas when reading your convo it seems you had no problem with him as witness for 3 full years till he was not updating BSIP42 quickly as there was no timeline and just has an experimental status  and demanding some standards ?
This quickly leaded that you and bitcrab unvoted him even BSIP 42 says nothing how quickly he has to implement it.
Some sort of power play you execute what we demand quickly or else you will be voted and kicked out ?
...
Where does the experiment of bitCNY ended ?
Where is the Data collected ?
Was is really a success if we didn't see now a bigger down movement ?
No info no standards no nothing just a bunch of people pushing and pushing with poor claims but without any proof at all

Thank you for those thoughts Thul3. Yes, there does seem to be a strong push for these major changes.

Abit is blowing things way out of proportion. He makes a bold claim I'm not "qualified to be a witness" and only provides subjective evidence. His "urgent" concern was my "jumping" CNY feed (and BTW he only mentioned one asset out of the 22 feeds I publish several times an hour), and completely ignores the median protection built into the core and says absolutely nothing except conjecture and speculation about the way my feed data has affected the final CNY price.

I agree with Thul3 about how this proposal has been ram rodded thru without adequate planning, and you can see how abit appointed himself dictator in control of who can take part in witness channel discussions. And no, he made no apology for his actions. He clearly has an authoritarian attitude and a bias against me, probably b/c I am not a conformist that withholds my thoughts and I oppose power hungry people who make unilateral decisions, and fail to consider the impact on the community changes like bsip42 can have. If abit put the concern for the ecosystem as a whole first (and not just the portion that trades the CNY asset), he would have thought about and provided some guidelines for how bsip42 could be conducted, and what metrics could be used to measure algorithm performance. Instead he puts himself "in charge" of experimentation and complains when someone's CNY feed doesn't look good to him.

He complains against me for being too verbose, makes a major issue out of going off topic at times (that makes me different from others how?) and then complains about my not upgrading according to his timetable. He uses no standards (inconsistently uses letters and numbers when referring to patches, uses a confusing statement about which version the patch is to be applied to - a previous patch or a release?)

Although I missed doing a witness report for August, that is very rare for me. Most witnesses don't even write witness reports at all. Every attempt I've made over the last 4 years to suggest better standards for witnesses has been met with deaf ears and apathy. A few listen and contribute, for example roelandp who created a marvelous tool to monitor price feeds. That is A standard suitable for all witnesses, but abit wasn't even aware of it.

Abit's claim that I'm not "qualified" to be a witness is a baseless accusation for which he has provided practically no justification. Besides, the claim is ridiculous on its face given the issue took place during a period of experimentation that had no firm guidelines and no standard metrics to measure compliance against or no timeframe to complete the implementation.

Another reason the claim is hollow is because there are no minimum requirements (i.e. qualifications) for witness duties. Feeds - accuracy, for which assets, update frequency, etc. and feeds are merely 1 aspect of a witness' duties. Don't let Abit or anyone else lead you away from expressing yourself, and don't let them repress your curiosity and questions.

Abit is on a witch hunt and has a personal agenda to get me voted out without sufficient cause and without making a solid case. It's plain to see from what Abit himself posted here how his anger flares up when people like me are bold enough to ask questions rather than simply conform to his terse edicts.

[Thul3]

Just confirms what i thought about the lack of governance what you guys do.

There are clearly no standards as majority of witnesses doesn't even feel the necassary anymore to inform the community about changes but just decide in your small group and keep forward.
I could highlight many more points from these convos which is concerning me like you have no clear rules ,standards for running BSIP42 .
The description of BSIP 42 is also very fluffy.

Seeing the same witnesses supporting that crap without raising any concerns or asking for standards just confirms what i experienced myself in other chats when talking about BSIP42 and reading their crap defending BSIP42 with their nonsense without a single word about giving free manipulation access to everything with no clear rules/standards or any other information.
Seems like a small group feels like they can do whatever they want without the inclusion of the community.

About Thomas when reading your convo it seems you had no problem with him as witness for 3 full years till he was not updating BSIP42 quickly as there was no timeline and just has an experimental status  and demanding some standards ?
This quickly leaded that you and bitcrab unvoted him even BSIP 42 says nothing how quickly he has to implement it.
Some sort of power play you execute what we demand quickly or else you will be voted and kicked out ?

I feel concerned that other witnesses are posting under new nicknames.
Seems for me like some sort of defense against retaliation

Now after so short time you guys already demand to change bitusd and mcr and global settlement.

Where does the experiment of bitCNY ended ?
Where is the Data collected ?
Was is really a success if we didn't see now a bigger down movement ?
No info no standards no nothing just a bunch of people pushing and pushing with poor claims but without any proof at all

[abit]

--- earlier messages in witness channel (security fix 1) begin ---
Abit More 2018-06-30, 2018 11:30:18 CET
Mainnet block producing nodes please upgrade to patch instead of 2.0.180612 to avoid a potential unintended forking.
Don't need to force a replay

[message pinned]

[most witnesses upgraded]


(2018-07-19, a while before 2.0.180612 hardfork)

Alex M - clockwork
So is everyone prepped for HF today?

we should do a complete roll call

Abit More
Ping everyone. Make a checklist

Alex M - clockwork
was about to

Alex M - clockwork
in.abit Confirmed up-to-date
bhuz Confirmed up-to-date
verbaltech2 @ThomasFreedman
abc123 Confirmed up-to-date
roelandp Confirmed up-to-date
witness.still Confirmed up-to-date
xman Confirmed up-to-date
delegate-1.lafona Confirmed up-to-date
elmato Confirmed up-to-date
xeldal Confirmed up-to-date
rnglab Confirmed up-to-date
sahkan-bitshares  Confirmed up-to-date
xn-delegate Confirmed up-to-date
fox  Confirmed up-to-date
witness.yao Confirmed up-to-date
blckchnd Confirmed up-to-date
delegate.freedom Confirmed up-to-date
crazybit Confirmed up-to-date 
bangzi  Confirmed up-to-date
magicwallet.witness Confirmed up-to-date
openledger-dc Confirmed up-to-date
witness.hiblockchain Confirmed up-to-date
gdex-witness Confirmed up-to-date
winex.witness Confirmed up-to-date
delegate-zhaomu   Confirmed up-to-date
clockwork Confirmed up-to-date
delegate.ihashfury Confirmed up-to-date

26/27 confirmed

Thom verbaltech2
Ok guys whats all the hullabaloo about this "patch" anyway? I;ve seen it mentioned but shit we just rolled out 612 and it hasn't even activated yet and now you need a patch for it?

If this patch is so critical it be deployed before 612 hf activates THAT should have been anounced before now in ALERTS channel.

I see abitmore saying it isn't that urgent in this convo above, so what gives with all the urgency for it??
And why call it patch and not provide a release#?
I have NOT updated to patch, whatever that is for???
Today just happens to be the hf day on another chain I work on, also a hf. Timing is bad on this for me.

Abit More
forget it then

Thom verbaltech2
I am ready (so I thought) for hf today, so somebody please explain why I need to jump on this patch in the next few hours.
So why the ugency if you say that? crying wolf for no reason?

Abit More
click the pinned message
and read the following messages
it's a softfork fix for a potential forking issue

Thom verbaltech2
Why not put this out in ALERTS channel?

Abit More
it's good enough when > 2/3 of witnesses have upgraded

Thom verbaltech2
Ok, then I'll relax.

Abit More
it's not an urgent fix, why alert channel?

Thom verbaltech2
Just not cool to wake up to the ugency I see here this morning.

Abit More
when I pinned that message, there should be a notification

Thom verbaltech2
Why then this roll call, and long discussion?

Abit More
this? which?
just last time check IMHO

Thom verbaltech2
Not here Abit. Please use alert channel for important announcements. Others may differ on that, may consider alerts true EMERGENCY items.

Alex M - clockwork
theres been no urgency
last a last check roll call
just*

Thom verbaltech2
Alerts is rarely used. Perhaps it should be used for urgent AND emergency messages. One thing this ecosystem lacks is standards for expectations. I see people saying we should look to core devs as managers - well, not so great at that imo, if they can't set standards.

You devs do a very good job of coding and testing, and your getting better, but we need more structure that comes by way of setting expectations which IMO is best done in a DAC by publishing standards. The BSIP concept is a good example, standards for workers.

Alex M - clockwork
the patch thing was posted days ago
call wasnt about patch specifically but about updating to HF version

Thom verbaltech2
I know, I've seen it Alex, but not really much talk about why or way to evaluate it's relative importance. And why not give it a better, more official name?

Alex M - clockwork
i think to avoid drawing attention to it as witnesses had already upgraded to HF version
and a specific transaction would have caused them to fork

Thom verbaltech2
Let me ask the devs & witnesses here - do you regularly monitor git at the same frequency as feeds? If an issue is important enough that witnesses should see it it should be more visible than git IMO.\

Alex M - clockwork
which could have been used as an attack vector
>Thom verbaltech2
>Let me ask the devs & witnesses here - do you regularly monitor git at the same frequency as feeds? If an issue is important
thats why it was mentioned here 2 weeks ago
I'm getting confused as to what the problem is

Thom verbaltech2
Sorry for tone guys, but how often do I see a roll call of who has deployed some piece of code? RARELY. Also length of posts on this is long. Also just awoke after a restless night so a bit grumpy atm.
2 weeks? Really that long?

Alex M - clockwork
>Thom verbaltech2
>Sorry for tone guys, but how often do I see a roll call of who has deployed some piece of code? RARELY. Also length of posts on
Ok...my bad
Thought it was expected to go through a final check of everyone being updated for the HF today

Thom verbaltech2
So the readiness for HF with 612 is being conflated ... no wonder it seems urgent. These are two very different matters of concern,

Thom verbaltech2
And somebody injected question about patch

Thom verbaltech2
Pinned msg is about patch, not HF. I do agree with you Alex, roll call for HF is a good idea, but probly should have been done a day or 2 earlier and very separate from patch

Alex M - clockwork
>Thom verbaltech2
>Pinned msg is about patch, not HF. I do agree with you Alex, roll call for HF is a good idea, but probly should have been done
well..only got round to it today

Thom verbaltech2
Back to standards

Thom verbaltech2
And to be honest, our API should have a way to obtain a nodes current version. If it had that we could automate alot of this stuff and manage it better.

Ryan R. Fox (BitShares Core)
>Thom verbaltech2
>And to be honest, our API should have a way to obtain a nodes current version. If it had that we could automate alot of this
Been discussed previously. Result was no: presents security concerns. Perhaps better is block producers telling other producers what version they are producing with. Now information is confined to those that need to know.

Thom verbaltech2
Security concens huh. I can see that argument. So consensus is that outweights the benefit. Interesting.

Alex M - clockwork
>Thom verbaltech2
>Security concens huh. I can see that argument. So consensus is that outweights the benefit. Interesting.
not for me
witness nodes are (should be) heavily protected network wise

Alex M - clockwork
so abusing them by knowing what version theyre running
is only possible via crafted transactions
transactiosn are cheap
if you find an exploit

...

Fabian <xeroc> Schuh
May I remind everyone that the BBF has mailing lists for witnesses too?

Thom verbaltech2
Yeah, not realy a fan of mailing ists

...

Thom verbaltech2
I gotta get on guys. Too much to do. I will try to get patch deployed after I get a few things done in a day or 2, unless it truly becomes urgent.

Abit More
>Thom verbaltech2
>I gotta get on guys. Too much to do. I will try to get patch deployed after I get a few things done in a day or 2, unless it tr
no need to update to patch
it's only 40 minutes until hf
after hf that patch is useless

Alfredo Garcia
i recommend you to stay aware for 1 or 2 hours more

--- earlier messages in witness channel (security fix 1) end ---

--- earlier messages in witness channel (security fix 2) begin ---

(testnet crashed, we made a patch for mainnet)

Abit More 2018-08-07 20:04:22 CET
ALL witnesses please upgrade mainnet node  ASAP
[message pinned]

[announced in alert channel]

[most witnesses upgraded]

Abit More 2018-08-07 20:12:11 CET
@ThomasFreedman this time I posted to alert channel. are you around?

Alex M - clockwork 2018-08-08 21:55:59 CET
@ThomasFreedman ping?

(2 days later)

Thom verbaltech2 2018-08-09 22:51:06 CET
is there any way to determine the core version from cli_wallet?

--- earlier messages in witness channel (security fix 2) end ---

--- earlier messages in witness channel (security fix 3) begin ---

Peter Conrad 2018-08-13 15:32:11 CET
And now to something completely different:
we have another security patch. Please upgrade block producing nodes

[message pinned]

[most witnesses upgraded]

Abit More 2018-08-14 0:02:22 CET
All witnesses please revert the patch

[message pinned]

[witnesses were downgrading]

...

Thom verbaltech2 2018-08-14 01:06:10
Have any of you noticed patch doing a lot of creating database api / freeing database api calls? Didn't see that (earlier).

Peter Conrad
That's what you see when a client connects/disconnects.

Thom verbaltech2
>Peter Conrad
>That's what you see when a client connects/disconnects.
The node I just updated is being hammered then. I haven't seen that before to the magnitude I am now.

Wanted to alert everyone if it was considered abnormal.
2 of 4 nodes updated

Peter Conrad
You're a bit late, you need to get back to producing on the previous version.
Sorry about the confusion.

Thom verbaltech2
>Peter Conrad
>You're a bit late, you need to get back to ...
So what is going on exactly? I presume based on reverting a problem was discovered with patch, but I don't know why patch was created after only 4 days on the previous patch

Thom verbaltech2
>Peter Conrad
>You're a bit late, you need to get back to ...
Confused? Who wouldn't be. No reasons were given for either patch, nor why the need to revert.

Abit More
if you want to discuss how to solve the problem, welcome
code IS there

Alfredo Garcia
the patch haves an issue thats why it needs to be reverted by now

Thom verbaltech2
What problem? git Issue # pleae?

Abit More
>Thom verbaltech2
>What problem? git Issue # pleae?
security issue. No public disclosure before covered
are you serious?
witnesses are meant to help. not accuse

Thom verbaltech2
I figured, but it would be useful to understand the level of urgency required.

I need to update a docker image and then deploy to each node. Last update was very fast to deploy + sync.
>Abit More
>witnesses are meant to help. not accuse
Please don't be so defensive. I'm not making any acusations abit

Abit More
ok. sorry

Thom verbaltech2
Apology accepted. NP

--- earlier messages in witness channel (security fix 3) end ---

--- earlier messages in witness channel (security fix 4) begin ---
Abit More 2018-08-16 15:39:34 CET
Witnesses please upgrade to fix4...

Abit More pinned «Witnesses please upgrade to fix4...»

[witnesses were upgrading]

(This time Thom is quick)

Thom verbaltech2 18:52:55
Witness verbaltech2 - all nodes updated

--- earlier messages in witness channel (security fix 4) end ---

--- earlier messages in witness channel (security fix 4n and bsip42) begin ---

Abit More 2018-09-05 9:41:03 CET
TESTNET test-2.0.180817, MAINNET fix4n...

Abit More pinned «TESTNET test-2.0.180817, MAINNET ...»

...

Thom verbaltech2 2018-09-06 22:20:11 CET
I'm a bit confused. Last update called for was for fix4, that's what I'm runnning now. So what's this about 180823? Will fix4n (why change fron letter scheme to numbers? Can we be consistent, or is there significance between letters and numbers for patches?

Alex M - clockwork
i do agree we could do better with the naming

Thom verbaltech2
That would be nice - consistency, conventions. It's up to the core devs to establish them. It helps newbies learn the code faster too.

Mr. Fox, care to chime in on this?

Abit More
patches are meant to be low volume. they're for witnesses only. that's why we use branches but not tags
for wider public we do releases
info posted in witness channel should be kept in witness channel.

Ryan R. Fox (BitShares Core)
>Thom verbaltech2
>That would be nice - consistency, conventions. It's up to the core devs to establish them. It helps newbies learn the code faste
I appreciate your sentiment Thom. We all value consistency. As Abit mentioned above, these patches are kept somewhat on the down low, as they may contain fixes for potential exploits that we must push to active block producers primarily. Obviously everything is public on GitHub, but we want to maintain the numbered releases for general community consumption. There is an Issue to discuss changes to our release number/naming and would appreciate everyone's feedback: https://github.com/bitshares/bitshares-core/issues/1173

Thom verbaltech2
Thx Ryan. I'll post my comments about conventions etc there then.

I'm well aware of the need to limit what is published / discussed for security related changes. However I see no reason to invent a new scheme for every patch.

Please keep in mind if someone such as myself who has been with this project  almost since the beginning is confused, chances are high others will be too, especially those new to the project.

Establishing a few conventions can only help, and I know you're working towards that Ryan.

I agree disclosure of patch details certainly should not be done prior to release, but it should be done. Failure to disclose the purpose and success of a patch could also introduce vulnerabilities (by fewer core devs being aware of the rationale for patches). That can happen if very few people are aware of those details and don't understand their necessity.

Code can be subtle and it's not always easy to see what the programmer intended, so by never disclosing what a patch is for and how it  accomplishes it is a documentation failure IMO. It means with each new [undocumented] patch the code may become more "mysterious".

Mainly I'm commenting due to the way this patch was announced (confusing applicability - to fix4 or non-patch 2.0.180823; also noticed name difference and was simply asking if there was a reason for it, which aparently numbers vs. letters was arbitrary)

Abit did clarify (based on where he makes announcements) applicability, in terms of BP nodes or non-BP nodes.

Ryan R. Fox (BitShares Core)
Appreciate your well intended thoughts. I will discuss amending our release process documentation to address the points you raised. Continual improvement.

Jerry Liu
BSIP42 is passed, so I think every witness can begin to work on update the price feeding for bitCNY

Abit More
>Thom verbaltech2
>Thx Ryan. I'll post my comments about conventions etc there then. I'm well aware of the need to limit what is published / discu
Please be aware that using arbitrary branch names IS to reduce volume. Please not be surprised. In the future we may even release patches in other repositories. In case any, unannounced patches should NOT be discussed / disclosed in public, even the process to release patches that would lead to unexpected disclosure. Yes we can discuss publicly about common process, but please DO NOT specify any branch name in public comments.

[witnesses were discussing BSIP42]

Thom verbaltech2
>Abit More
>Please be aware that using arbitrary branch names IS to reduce volume. Please not be surprised. In the future we may even releas
Lest I repeat myself I am aware of need to keep patch details quiet. It's up to the core dev team to establish naming conventions and a team process to handle sensitive changes.

But that should not be construed to permit wild wild west, "anything goes" as a means of obfuscation to provide security. If everyone on the core dev team aren't in agreement on the process and internal conventions to handle sensitive issues, it will lead to an "elite" group that does, and they will use the excuse of "security" to hide from scrutiny.

Please understand, the conventions I'm referring to are for how to document these patches and other sensitive changes AFTER they have been tested and deployed, AFTER the devs are confident in them and disclosure no longer provides a vulnerability.

If you argue disclosure always introduces vulnerabilites I tend to agree, HOWEVER you can't take that position to far with an open source project whose code is publicly available on github.


Abit More
>"Please understand, the conventions I'm referring to are for how to document these patches and other sensitive changes AFTER they have been tested and deployed, AFTER the devs are confident in them and disclosure no longer provides a vulnerability."
Please be aware that our resources are limited. I don't think we need a document for everything that we've done 2-3 months before. doing document only for document is waste of resources.
@ThomasFreedman ^
you and everyone can ask for @ryanRfox or other core dev's confirmation every time when I or another core dev announces a patch here.

Thom verbaltech2
Also, noticing prices far more volitile now than I've seen them on months. How are we to know when a new algo is more accurate?

We have no standard to guage accuracy against. Look at price volatility this year alone (with no changes to feed algos) and who can say what we come up with now produces more or less accuate feeds than before?

Perhaps this is simply a matter of everyone vying for power / advantage to set prices favorable to their pet markets. If so these "experiments" will always be contensous and claims of inaccuracy (to a non-existent standard) will continue to be made and witness vilanized for using "poor" feed metrics.

>Abit More
>you and everyone can ask for @ryanRfox or other core dev's confirmation every time when I or another core dev announces a patch
"ask for confirmation"? What would we ask? If code and algos keep getting added under a banner of secrecy to protect against "security vulnerabilities", might as well jut move to a non-public repo for all the code.

I'm very sorry to hear you have such a low opinion of dicumentation Abit. The codebase is already large enough that the reasons why some things were coded a certain way is already lost, that's inevitable. Documentation reduces those losses.
The more reasons and rationale are lost (due to several causes, devs move off project as 1 example, no docs or explanation is created as another) the more likely it will be to repeat past mistakes and the harder it will be for newcomers to understand the code and why it is written the way it is.

Alex M - clockwork
I'm lost... Most of the codebase is documented
Security patches are named obscurely and with no discernible pattern because they can be exploited otherwise
I seriously don't get what the request is

Thom verbaltech2
We can use the "Feature Backed Asset" code as a perfect example of what I'm talking about.

Bytemaster changed the implementation of FBA to differ from what was proposed. It was discussed as a dividend type of asset that benefited the specific devs that code the FBA. He changed it to be a "token buyback" scheme and didn't document that change or disclose it to even OnceUponaTime, the primary investror for that work.

It was shocking to me, Once and kencode when this was discovered when kencode began to look at the code in detail.

That should never happen. Bytemaster probably looked at the Howie test and made a judgment what was discussed would fail that test and then tool it upon himself to change how he coded the FBA infrastructure. That should have been above board, not a unilateral decision by  programmer apart from community or investor.

Peter Conrad
I agree with @abitmore in that we're not going to document every single code change. The problem with detailed documentation is that it gets out of date quickly, at which point it hurts more than it helps.
Git commit messages contain some information, and github issues usually contain descriptions and discussion why a change was made. That should be sufficient.
The witness-only patches are not much different from their respective release versions. Witnesses are welcome to review them, and can refuse to implement them if they see a problem.

Abit More
>Thom verbaltech2
>Also, noticing prices far more volitile now than I've seen them on months. How are we to know when a new algo is more accurate?
Please read the BSIP https://github.com/bitshares/bsips/blob/master/bsip-0042.md. "accuracy" is not a concern now.

Alex M - clockwork
>Thom verbaltech2
>We can use the "Feature Backed Asset" code as a perfect example of what I'm talking about. Bytemaster changed the implementatio
now i'm totally lost...this is unrelated to the discussion about the security patches....as far as normal documentation is concerned, the core team is doing a hell of a job to document everything through Tamami

Thom verbaltech2
>"Git commit messages contain some information, and github issues usually contain descriptions and discussion why a change was made. That should be sufficient."

I fully agree with your perspective about how docs can be a liability rather than an aid in some cases. Not for the FBA example I described tho. And when it comes to plugging security vulnerabilities it seems to me those are very important to document (after the fact). As long as the ratonale and approach is explained somewhere thats what I feel will be lost.

Abit More
As I said we don't have time to write document for work that have been done months before.
some patches are temporary, they will be outdated after a special date

Alex M - clockwork
also...I'm quite sure that the FBA design was discussed in the forums

Abit More
for example fix1
it's a 2-week patch.

Thom verbaltech2
>Abit More
>As I said we don't have time to write document for work that have been done months before.
Then you or some other dev may redo work you forgot about months before.

Abit More
it only has effect before July 19.
other patches, if needed, we merge to develop branch right away

Thom verbaltech2
>Alex M - clockwork
>also...I'm quite sure that the FBA design was discussed in the forums
It was, but not the changes. I was there, I confirmed my take of the evolution with OnceUponAtime, kencode and bytemaster.

Abit More
with low volume of course.
I feel my time is wasted discussing these.
@ThomasFreedman please fix your feed, better sooner than later

Thom verbaltech2
Then go, resume coding.

Alex M - clockwork
>Thom verbaltech2
>It was, but not the changes. I was there, I confirmed my take of the evolution with OnceUponAtime, kencode and bytemaster.
yeah i know...just saying that I'm quite sure it was mentioned by BM that dividends woudl be paid via buyback BEFORE he even started implementing it

Abit More
IMHO, that's the most important thing you need to do right now. after you've done, we can discuss other things.

Alex M - clockwork
i'll have to look through the forums  now to ease my curiosity

Thom verbaltech2
Yeah, feeds. I HAVE read the BSIP, and to say "accuracy is no longer a concern" is rediculous. Why have inaccuate feeds, why try to normalize any of our feeds, why claim my feeds need "fixing"? Fixed to what starndard?
>Alex M - clockwork
>yeah i know...just saying that I'm quite sure it was mentioned by BM that dividends woudl be paid via buyback BEFORE he even sta
Then you would be wrong on assuming that.

Abit More
>Alex M - clockwork
>i'll have to look through the forums now to ease my curiosity
I'd recommend to that AFTER fixed feed

Alex M - clockwork
Both tonight .not homeyet

Thom verbaltech2
The BSIP was only approved a short time ago. Why not complain to other witnesses that are less attentive to their witness duties?

Besides, this whole feeds / BSIP 42 puzzles me, and I want to see how feeds evolve based on it. My approach is to see how those close to CNY market achieve "better" results before I could come up with something better than I already use.

Demands to "get a new feed algo coded fast" make no sense. Let the experimentation begin, and lets see the data so we can judge the merrits of the results. Otherwise we'll have 29 witnesses claiming "their" feed is best.

Abit More
>Thom verbaltech2
>The BSIP was only approved a short time ago. Why not complain to other witnesses that are less attentive to their witness duties
As a stake holder, if you have an different opinion about the BSIP, you vote and/or discuss in the linked posts.
As witnesses, we execute approved BSIPs. If nobody executes, the experiment won't begin.
I did tag all witnesses that didn't start adjusting feeds.


(some days later)

Thom verbaltech2 2018-09-13 1:27:35 CET
Not sure I heard anything about a fix4n.

...

Alex M - clockwork
>Thom verbaltech2
>Not sure I heard anything about a fix4n.
seriously? it's right there in the pinned msg and we had a big discussion about it the other day...

Thom verbaltech2
Yeah ,missed it. Was discussion public?If so what was the controversey?

Alex M - clockwork
>Thom verbaltech2
>Yeah ,missed it. Was discussion public?If so what was the controversey?
"we" as in : including you

Abit More
>Thom verbaltech2
>Not sure I heard anything about a fix4n
Pinned message. Also iirc you've complained when the message is pinned
I'd suggest that you need to pay more attention to this channel
Sorry, replied before reading later conversation

Thom verbaltech2
>Abit More
>Sorry, replied before reading later conversation
Apology accepted.

--- earlier messages in witness channel (security fix 4n and bsip42) end ---

[abit]

Frankly speaking, I don't think @ThomasFreedman is a qualified witness, so I unvoted. I didn't ask anyone to unvote him so far. If someone else happened to have unvoted him as well, IMHO it's a coincidence.

When I was saying "Stake holders are free to unvote the witnesses that didn't respond in time" in this post, the sentence was after "It's up to the witnesses to publish what they're using". I wanted to say stake holders have the right to ask witnesses to report what algorithm they're using, if the witnesses didn't report in time, stake holders have the right to unvote. I think @j.galt misunderstood it, he thought I was asking people to unvote @ThomasFreedman for not fixing price feeds.

I admit that I was a bit emotional when banning @ThomasFreedman from witness channel. Consequently my admin privilege of banning people has been revoked.

Related conversations are pasted below.

After I replied him with detailed data several times, @ThomasFreedman still fails to find what's wrong in his feed. Instead, he turned to question me but not the data.

While we're discussing important things in the channel, he posts long paragraphs which IMHO were off-topic. It's not the first time. He had failed to apply security patches in time then blamed that we didn't notify in alert channel. The next time when we DID notify in alert channel, he still failed to upgrade in time (IMHO). And etc.

--- witness channel conversation (the most recent feed issue) start ---

Thom verbaltech2 2018-09-14 17:32:49 CET
I just updated my stresstest steemit page. Nothing much added, not much to show. As long as the tests don't crash my node, bts_tools will capture the network activity as it reports it for a full 24 hr window.

Abit More
@ThomasFreedman your feed seems unstable
jumping from 0.72 to 0.8x

Thom verbaltech2
>Abit More
>@ThomasFreedman your feed seems unstable
Not great in terms of graph resolution, but does show overall activity.

>Abit More
>@ThomasFreedman your feed seems unstable
I will check it.

Thom verbaltech2
>Abit More
>jumping from 0.72 to 0.8x
What do you mean by "jumping" abit? You really should be more descriptive. Samples by Roeland's log show feeds are generally within 5%, except btc which most everyone is reporting on on the high side.

Abit More
seems @xeldal and @muagkov and @blockchained need to check feed

Roelandp
verbaltech OL blockchained are also quite higher tbh right?

Abit More
>Thom verbaltech2
>What do you mean by "jumping" abit? You really should be more descriptive. Samples by Roeland's log show feeds are generally ...
does the tool provide historical data?

Roelandp
no but i have historical data in my backend
in my db
so i can start pushing graphs

Abit More
>Thom verbaltech2
>What do you mean by "jumping" abit? You really should be more descriptive. Samples by Roeland's log show feeds are generally ...
verbaltech2 report feed: 1.21137 BTS/CNY 2018/09/14 17:19:42 30498191
verbaltech2 report feed: 1.38341 BTS/CNY 2018/09/14 17:31:30 30498427
verbaltech2 report feed: 1.20063 BTS/CNY 2018/09/14 17:40:21 30498603
CET time.

Thom verbaltech2
When you make a statements about a witnesss's feeds it casts a bad light when yor statement doesn't always qualify the specifics.

I rely a lot on Roeland's witness_log. What are you using to make your judgements abit? Are you expecting perfection? Why not mention the other witnesses that have very slow update times or don't report certain assets like BTC price?

I sense you focus on only certain people and are biased. Also, what standards are you using? At least with Roeland's witness_log we have a common standard.

Anybody can chime in as you do with a "report" about feeds and it is just one peron's perspective, an opinion without data.

You are free of course to continue, but I think it would be better for the ecosystem if you would be more specific.


Abit More
magicwallet is not the only source for bitcny/fiat IMHO
>Thom verbaltech2
>When you make a statements about a witnesss's feeds it casts a bad light when yor statement doesn't always qualify the ...
verbaltech2 report feed: 1.21137 BTS/CNY 2018/09/14 17:19:42 30498191
verbaltech2 report feed: 1.38341 BTS/CNY 2018/09/14 17:31:30 30498427
verbaltech2 report feed: 1.20063 BTS/CNY 2018/09/14 17:40:21 30498603
just check the numbers.
no feed is better than wrong feed, IMHO.
I'm also pinging others publicly. when I found something wrong
not specifically to you.
the data is from wallet.

Thom verbaltech2
Wrong? Wrong WHEN? How can yo make the judgement it's WRONG?

That is a mighty bold claim to make sir.

One could aledge "wrong" != median, so again I say you're just using your own personal, biased, "standard".

The point of feeds from several witnesses is to allow a range of values and the core will produce a median that is reasonably correct.

I say your claim of "wrong" is wrong and biased.

[banned]

--- witness channel conversation (the most recent feed issue) end ---

--- direct message conversation (the most recent feed issue) start ---
Thom
Please consider reporting your feedback about my feeds to me privately rather than in the public forum, UNLESS you don't get a response in a few hours OR it's an urgent issue.

As bsip42 has got many of the witnesses scrambling due to a false sense of urgency to "fix" their feeds, you should expect some instability.

I feel your insinuation my feeds are "wrong" is out of line.

I don't know who removed me from the active witness telegram group, but it was uncalled for and out of line as well.

Abit
it is urgent
the jumping price may lead to unexpected serious consequence

Thom
If that is so the median calculation is not working, so I say it's not urgent. You are taking individual samples and applying your subjective assessment to it. As I said, you need to accept with this bsip42 experimentation going on there will be outliers from time to time. It can't be urgent if Roeland's log shows MY feeds are less than 5% off from accepted median.

Please use more than just a few random samples from your cli_wallet before you accuse a witness in public.

And why do you single me out over other witnesses that don't produce feeds very often, like only every few hours? There is more to a witness' duties than price feeds

Those who complain only about a single aspect are showing their bias and lack of concern for the witness role in general.
You can't really claim outliers are "wrong" when bsip42 allows for experimentation, and without limitations as to window of accuracy, to what standard is accuracy measured etc. It's the wild wild west for feeds until consensus is achieved about this bsip42 experimentation and whether improves feeds.
History demonstrates the median calculation will protect the asset price from outliers. Your claim of urgency and justification to "call me out" in public given an experimental context is uncalled for.

Abit
check your own data
verbaltech2 report feed: 1.21137 BTS/CNY 2018/09/14 17:19:42 30498191
verbaltech2 report feed: 1.38341 BTS/CNY 2018/09/14 17:31:30 30498427
verbaltech2 report feed: 1.20063 BTS/CNY 2018/09/14 17:40:21 30498603
verbaltech2 published feed price of 0.7289 bitCNY/BTS 2018-09-14 18:01:42
verbaltech2 published feed price of 0.8371 bitCNY/BTS 2018-09-14 18:00:30
check in wallet, or a block explorer
in one minute 2 feeds
more than 10% difference

Thom
I do. We just use different means to judge it. You use cli_wallet, I use witness_log, a beter way to gauge and far more objective.
What is the market doing between the samples you see?  How do you know it doesn't swing 10% in 10 minutes from the sources I'm using? You don't. But Roeland's witness log paints an entirely different picture of my feed accuracy.
Until you can show how MY feeds affect the published median price I don't see that your method of assessment has merit.

Keep in mind you don't know how my algorithm is coded and if it contains errors in some of it's results so what, bsip42 has given everyone permission to experiment, so that's what I'm doing.

First you complain b/c I didn't "jump on the experiment" right away, not you say now that I have I don't have perfect results.

Give me a break and please get off my case. There are other witnesses that do far less than I and I see nobody complaining about them.
Just caught a big deviation! First 1 I've seen since I started playing around.

Abit
If you can't see the problem. I have nothing to talk to you.
bye.

Thom
OK.

So to go along with your statement that no feed is better than an "inaccurate" one I will stop feeding CNY until this experimentation reaches some type of consensus.
And that was the approach I started with, to continue with old feed method until this was over. Now will stop entirely for that asset.

Thom
Bummer, disabling only CNY asset is proving to be difficult.

Thom
Last msg (so as not to keep bugging you)

CNY not disabled, but made further adjustments and reduced publish interval (several witnesses only publish hourly or even longer intervals).
--- direct message conversation (the most recent feed issue) end ---

[Thul3]

@abit

By the way, out of curious but with respect, may I ask who are you? Looks like you know some conversation occurred in the witness channel which is invite only, you also know the alerts channel which is also invite only and rarely used recently. We do need more people to discuss, to get better solutions.

Funny you are asking who he is as you need more people to discuss........

Out of curious but with respect is it true that you banned a top bitshares witness from the Bitshares_Witnessses telegram channel just because he disagreed with you about BSIP 42 ?

Did you had the right to do so ,which followed with an instant down voting as witness by bitcrab ?

If thats true it looks for me for a clear abuse of power as admin ,comitee member and BSIP42 initiator .

 

[Thul3]

We are moving directly into a global settlement.BTS price is arround 0.76 CNY and we got already a 21 million sell wall with a CTR of 1.65.
No Margin Calls are being bought in a downtrend and we just need to reach a price of currently 0.47 CNY per BTS to cause a global settlement.

And we are still in a bear market.
This experiment is so dangerous and am really asking myself why some people do these kind of experiments which clearly is killing the margin call function by putting everyones collateral in danger.

[j.galt]

Stake holders are free to unvote the witnesses that didn't respond in time.

Shareholders are always free to vote witnesses out based on whatever criteria they choose, but aren't you getting "a bit" ahead of yourself to even suggest this now?

What do you mean by that statement anyway? Respond "in time" for what? The bsip was vague in terms of limits and there were no time limits in it. It didn't even mandate witnesses participate in the experimentation. You wrote the bsip you know that. Bsip 42 is an experiment, primarily for only 1 asset initially. Suggesting shareholders vote out witnesses based on price feeds during a period of experimentation sounds dramatic and rather aggressive to my ears. That doesn't exactly foster unity in the community, and unity is something we can never have enough of.

It would be more conservative and wiser to wait for published results of these experiments before people vote witnesses out based on any criteria during a period of experimentation. That's what I meant when I said this is being "rushed" into production.

Your bsip was actually more comprehensively written than others, but for the impact such changes might cause there was almost no guidance on how experimentation would be conducted. It is lucky the market has been relatively stable or things could have gone badly. It's also too early to tell if a single set of feedback settings will work for all market conditions.

No reason to rush this. Applying a PID algorithm to help peg derivatives is interesting and may provide a "tighter" peg, so I'm all for seeing how it will work. I do like the "Constant voting evaluation" in bsip 42, and for this type of experimentation that provision is very important. But let's not impose any requirements on witnesses or hold them accountable until A) we've seen enough market variations to evaluate the stability of a PID approach, and B) some type of report or description is published that outlines safe limits for PID feedback so as to avoid widening the price away from the peg.

I've seen the damage done to robotic joints due to errors in PID control settings, and far more is at stake in a financial system. No, it's way too early to vote witnesses out or sanction them based on anything related to bsip 42.

[abit]

Has a consensus emerged yet to set parameters for this PID algorithm? What results have been published? Does the author of BSIP42 expect all 27 / 29 witnesses to code their own versions of this or are open source versions available to witnesses they can tweak?

All PID process control algorithms rely on getting the feedback tuned in for the specific characteristics (inherent latency) of the system being controlled. That latency almost certainly is affected by the feed sources used. I suspect it is also affected by network latency, and we know that varies widely between western and far eastern API nodes.

If the point of BSIP42 is a tighter peg and not just a subsidy for traders, from what I observed the "experimentation" which BSIP42 allowed for (based on what I saw on Telegram it was treated like an absolute and urgent requirement on par with security patches!) was rushed into production without much planning and coordination at all. From the time BSIP42 was approved to when some were practically demanding witnesses to produce "conforming" CNY feeds was only a few days.

If a large percentage of witness participation in this CNY PID price feed experimentation was necessary it should have been announced in the BTS Witness Alerts Telegram channel. 

If the goal is a tighter CNY peg it seems to me a common reference implementation we can all tweak based on our preferred price sources used in various places around the globe would be a necessary starting point. Without that (for example if every witness or most of them wrote their own PID script) it will take longer for all witnesses to get on same page as they optimize their script's parameters and feedback to be in harmony with other witnesses and the median feed price.

I found it troubling this experimentation as conducted could trigger a black swan event, and this wasn't discussed much. In general I have zero objections to refine and improve our feed algorithms, but we shouldn't rush into it as it seems we're doing.

Water under the bridge so they say if a consensus for a new CNY feed algorithm has now been determined. Has it? If so, now all the non-coding witnesses need is a report or program they can tweak and they too can join in. Even if it has for the current market conditions, that doesn't mean all hell can't break loose if the market volatility gets to wild.

Abit's concern for feeds too far away from the median that leads to an abrupt (and catastrophic) price changes was always a potential risk with how BSIP42 was conducted. Fortunately that didn't happen, even with several witnesses not using (or not having the PID tuned well) a PID feed algorithm. The median / indirect manor feed prices are published works well. Outliers could be a problem if the market became more volatile though. However the parameters used to control the PID feedback set in a non-volatile market may not be tuned properly for changes in a volatile market, and if feedback is too sensitive could lead to some vary wide price swings.

Thoughtful comments. I believe most non-coder witnesses are using zapata's price feed script (https://github.com/zapata/bitshares-pricefeed) with "my" "lazy" formula, or another script with my formula, before an open-source PID-enabled script is published. Otherwise we may have seen swings or still-high premium.

My formula is not perfect because it's based on current feed. That said, if current feed is jumping, new feed will be jumping as well, as you've mentioned. It's up to the witnesses to publish what they're using. Stake holders are free to unvote the witnesses that didn't respond in time.

By the way, out of curious but with respect, may I ask who are you? Looks like you know some conversation occurred in the witness channel which is invite only, you also know the alerts channel which is also invite only and rarely used recently. We do need more people to discuss, to get better solutions.

[bitcrab]

BSIP42 is accepted means witnesses can work based on the negative feed back core ideas, I don't think we need one unique algorithm for every witness to adopt, but I agree that witnesses should publish their algorithm for community to evaluate.

I don't think the diversity of algorithm is bad, and I don't think we "rush" on this implementation, in China one week is very long time.

witnesses is a distributed team, they can consider, code and watch, I believe they can do work well, actually BSIP42 now work well in bitCNY.

BTW, gdex-witness started implementing BSIP42 in bitUSD, same algorithm with bitCNY as shown above in this thread.

[j.galt]

Has a consensus emerged yet to set parameters for this PID algorithm? What results have been published? Does the author of BSIP42 expect all 27 / 29 witnesses to code their own versions of this or are open source versions available to witnesses they can tweak?

All PID process control algorithms rely on getting the feedback tuned in for the specific characteristics (inherent latency) of the system being controlled. That latency almost certainly is affected by the feed sources used. I suspect it is also affected by network latency, and we know that varies widely between western and far eastern API nodes.

If the point of BSIP42 is a tighter peg and not just a subsidy for traders, from what I observed the "experimentation" which BSIP42 allowed for (based on what I saw on Telegram it was treated like an absolute and urgent requirement on par with security patches!) was rushed into production without much planning and coordination at all. From the time BSIP42 was approved to when some were practically demanding witnesses to produce "conforming" CNY feeds was only a few days.

If a large percentage of witness participation in this CNY PID price feed experimentation was necessary it should have been announced in the BTS Witness Alerts Telegram channel. 

If the goal is a tighter CNY peg it seems to me a common reference implementation we can all tweak based on our preferred price sources used in various places around the globe would be a necessary starting point. Without that (for example if every witness or most of them wrote their own PID script) it will take longer for all witnesses to get on same page as they optimize their script's parameters and feedback to be in harmony with other witnesses and the median feed price.

I found it troubling this experimentation as conducted could trigger a black swan event, and this wasn't discussed much. In general I have zero objections to refine and improve our feed algorithms, but we shouldn't rush into it as it seems we're doing.

Water under the bridge so they say if a consensus for a new CNY feed algorithm has now been determined. Has it? If so, now all the non-coding witnesses need is a report or program they can tweak and they too can join in. Even if it has for the current market conditions, that doesn't mean all hell can't break loose if the market volatility gets to wild.

Abit's concern for feeds too far away from the median that leads to an abrupt (and catastrophic) price changes was always a potential risk with how BSIP42 was conducted. Fortunately that didn't happen, even with several witnesses not using (or not having the PID tuned well) a PID feed algorithm. The median / indirect manor feed prices are published works well. Outliers could be a problem if the market became more volatile though. However the parameters used to control the PID feedback set in a non-volatile market may not be tuned properly for changes in a volatile market, and if feedback is too sensitive could lead to some vary wide price swings.







 

[bench]

Why didn't you agree on a collectiv refferal program which would bring massivly new members to DEX ?
This would be a good solution

Where can I find information about the collective referral program? 

[Thul3]

What will be the next proposal to cancel black swan events ?

you are right, I am considering to cancel black swan events.

Why didn't you agree on a collectiv refferal program which would bring massivly new members to DEX ?
This would be a good solution

Maybe you should focus on adoption instead of manipulation ?

I'm just helping Bitshares to evolve. I cannot persuade more people to adopt bitCNY if it is always in serious shortage and high premium.

Why didn't you agree on a collectiv refferal program which would bring massivly new members to DEX ?
This would be a good solution?

I'm really not here to attack you personly but i'm trading a lot and for me there is a high possibility we will see a BTS price of0.25-0.3 BitCNY and lowering the margin call security makes it in my eyes way more probable to cause a global settlement if margin calls won't be filled anymore.

[bitcrab]

What will be the next proposal to cancel black swan events ?

you are right, I am considering to cancel black swan events.

Maybe you should focus on adoption instead of manipulation ?

I'm just helping Bitshares to evolve. I cannot persuade more people to adopt bitCNY if it is always in serious shortage and high premium.

[Thul3]

What will be the next proposal to cancel black swan events ?

you are right, I am considering to cancel black swan events.

Maybe you should focus on adoption instead of manipulation ?

[bitcrab]

What will be the next proposal to cancel black swan events ?

you are right, I am considering to cancel black swan events.

[Thul3]

BTS price on bitCNY is nearly 10% under margin call price which has already a premium of 10% under feed price.
When checking the reason i realised you just destroyed the function to arbitrage these margin calls even the current price on DEX is 10% lower than the margin call price.


People stopped buying margin called assets and BTS price is now 10% under margin call which means once the downtrend starts these margin walls will get bigger and bigger.

You just increased massivly the risk for a black swan event


What will be the next proposal to cancel black swan events ?

[abit]

1. due to the median mechanism, not like traditional PID system, in BitShares individual witness's feed affects the result only indirectly. We need more witnesses to adopt a feedback algorithm like this one. Before majority of witnesses started using a feedback algorithm, it's doesn't make sense to adjust one's feed far away from median. It's even dangerous since it may lead to potential unnecessary big swings when the trend changes.

2. IMHO it's not good to arbitrarily set a limit/cap on "i" since it may prevent the factor from effectively developing, especially when Ti is playing a key role.

[bitcrab]

updated version:

Pdex：BTS price in DEX in bitCNY
Pf: current feed price
premium: current premium
Premium0: premium in the last period

Tp=4;Ti=10; Td=1; ##parameters for PID control, here the Ti plays a key role, it should fit the update period

get Pdex, Pf, premium;
premium0=premium;
p=Tp*premium;
i= Pf/Pdex-p-1; ##set initial value for p,i,d to make the initial calculated feed price equal to the current feed price in system.
d=0;

while True:
   
   get Pdex, Pf, premium;

   i+=premium/Ti;
   if i>0.4: ##set limit to i, to speed up the backward adjustment if premium change to cross 0
       i=0.4;
    if i<-0.3:
       i=-0.3;
    d=Td*(premium-premium0);
    premium0=premium;
           
   p=Tp*premium;
   
   if p+i+d>0:
     feed price = Pdex*min(1+p+i+d, 1.5, 1.03*Pf/Pdex) ##limit the feed price comparing to Pdex and current feed price while the adjustment is upward.
   else:
     feed price = Pdex*max(1+p+i+d, 0.98*Pf/Pdex)##limit the feed price comparing to current feed price while the adjustment is downward.
   time.sleep(120) ##update every 2 minutes.

[bitcrab]

gdex-witness plan to adopt below algorithm for bitCNY price feeding, the core idea comes from PID control theory.

Pdex：BTS price in DEX in bitCNY
Pf: current feed price
premium: current premium
Premium0: premium in the last period

Tp=4;Ti=6; Td=1; ##parameters for PID control, here the Ti plays a key role, setting it to 6 will make i reach maximum in 20 hours if the premium keeps 2% or higher.

get Pdex, Pf, premium;
premium0=premium;
p=Tp*premium;
i= Pf/Pdex-p-1; ##set initial value for p,i,d to make the initial calculated feed price equal to the current feed price in system.
d=0;

while True:
   
   get Pdex, Pf, premium;

   while (10 minutes passed after the last execution)：
         i+=premium/Ti;
         if i>0.4: ##set limit to i, to speed up the backward adjustment if premium change to cross 0
            i=0.4;
         if i<-0.3:
            i=-0.3;
         d=Td*(premium-premium0);
         premium0=premium;
           
   p=Tp*premium;
   
   if p+i+d>0:
     feed price = Pdex*min(1+p+i+d, 1.5, 1.2*Pf/Pdex) ##limit the feed price not higher than 1.5 times Pdex or 1.2 times current feed price while the adjustment is upward.
   else:
     feed price = Pdex*max(1+p+i+d, 0.91*Pf/Pdex)##limit the feed price no less than 0.91 times current feed price while the adjustment is downward.

[bitcrab]

updated gdex-witness bitCNY feed price algorithm:

Pdex：BTS price in bitCNY in DEX
premium: calculated from magicwallet bitCNY deposit/withdraw fee and BTS price difference in bitCNY & fiat CNY.

if 0<premium<1%:
feed price = Pdex*(1+9.6*premium)

if 1%<premium<2.4%:
feed price = Pdex*(1+9.6%)

if 2.4%<premium:
feed price = Pdex*(1+4*premium)

[gghi]

gdex-witness now adopt a new algorithm to feed bitCNY price, the new algorithm is based on BSIP42.

1.get a market price in fiat CNY which is the max from referenced exchange.
market price = max(Pdex, Pcex1,Pcex2...)
2.calculate the bitCNY premium in percent from BTS price difference between DEX and CEX, and the deposit fee in magicwallet.
3.set a limit to restrict the max percent for adjusting the feed price, initially let limit=10%
feed price = market price*[1+min(premium, limit)]

feed price = market price*1.05*[1+min(premium, limit)]      feed price = market price*1.03*[1+min(premium, limit)] 

feed price = market price*1.02*[1+min(premium, limit)] 
   

 

we understand that although BSIP42 worker proposal is active, we need more time for community to review and decide. we now begin to adopt the new algorithm is to do some experiment, to do some controllable change to show the result to the public and help the voters to decide whether to support this kind of change. if finally the BSIP42 is rejected, we'll return to the old feed algorithm immediately.

any comments on the new algorithm are welcome.

[sschiessl]

https://github.com/bitshares/bsips/pull/105

Please consider this, and please to also honor it if accepted.

[sschiessl]

we understand that although BSIP42 worker proposal is active

https://bitsharestalk.org/index.php?topic=26966.msg321621#msg321621

[bitcrab]

gdex-witness now adopt a new algorithm to feed bitCNY price, the new algorithm is based on BSIP42.

1.get a market price in fiat CNY which is the max from referenced exchange.
market price = max(Pdex, Pcex1,Pcex2...)
2.calculate the bitCNY premium in percent from BTS price difference between DEX and CEX, and the deposit fee in magicwallet.
3.set a limit to restrict the max percent for adjusting the feed price, initially let limit=10%
feed price = market price*[1+min(premium, limit)]

we understand that although BSIP42 worker proposal is active, we need more time for community to review and decide. we now begin to adopt the new algorithm is to do some experiment, to do some controllable change to show the result to the public and help the voters to decide whether to support this kind of change. if finally the BSIP42 is rejected, we'll return to the old feed algorithm immediately.

any comments on the new algorithm are welcome.

[ripplexiaoshan]

5% 5% 5%. Hope more developers can join BitShares as witness.

[R]

What are your plans regarding publishing price feeds? What price feed script library will you use? Would you consider publishing feeds for Hertz?

Thanks, good luck becoming an active witness

[bitcrab]

Hello everyone, We, GDEX team, now announce to apply for a witness - gdex-witness

In the past several months, GDEX has provided gateway service for coins like BTC, ETH, EOS, NEO, QTUM, GXS, BTM, BTO, HPB, ATN, etc. we tried to create more user friendly service for all BTSers, hope you can enjoy our service.

I, bitrab, committee member of Bitshares and Lead of GDEX team, have ran a witness by myself 1 year ago, finally I gave up as I am not professional enough on many technology things. now we have development team that include members focus on development/deployment/QA test/maintenance, I believe they can ensure the witness node to run well.

As a big shorter I understand deeply the importance of exact price feeding, in our view, fed price should reflect the market fact about with what a price people can convert BTS with one kind of fiat. we build our price feeding scripts based on this view.

config detail of relevant nodes:

Witness  main  server:

-  Type:  Dedicated
-  System:  Ubuntu  Server  16.04  LTS
-  Processor:  Intel(R)  Xeon(R)  CPU  E5-2686  v4
-  Cores:  4
-  Ram:  32GB  DDR3
-  Disk:  1TB  SSD
-  Bandwidth:  1  Gbit/s
-  Location:  Japan

Witness  backup  server:

-  Type:  Dedicated
-  System:  Ubuntu  Server  16.04  LTS
-  Processor:  Intel(R)  Xeon(R)  CPU  E5-2686  v4
-  Cores:  4
-  Ram:  16GB  DDR3
-  Disk:  500GB  SSD
-  Bandwidth:  1  Gbit/s
-  Location:  Japan

Witness  price  feed  server  *2:

-  Type:  Dedicated
-  System:  Ubuntu  Server  16.04  LTS
-  Processor:  Intel(R)  Xeon(R)  CPU  E5-2686  v4
-  Cores:  4
-  Ram:  16GB  DDR3
-  Disk:  500GB  SSD
-  Bandwidth:  1  Gbit/s
-  Location:  Japan

GDEX  API  server  *2(wss://ws.gdex.io):

-  Type:  Dedicated
-  System:  Ubuntu  Server  16.04  LTS
-  Processor:  Intel(R)  Xeon(R)  CPU  E5-2686  v4
-  Cores:  4
-  Ram:  32GB  DDR3
-  Disk:  1TB  SSD
-  Bandwidth:  1  Gbit/s
-  Location:  Japan

GDEX  API  server  *2(wss://ws.gdex.top):

-  Type:  Dedicated
-  System:  Ubuntu  Server  16.04  LTS
-  Processor:  Intel(R)  Xeon(R)  CPU  E5-2682  v4
-  Cores:  4
-  Ram:  32GB  DDR3
-  Disk:  1TB  SSD
-  Bandwidth:  200  Mbit/s
-  Location:  China

Contacts:
Website:  https://gdex.io
QQ  group:602573197
Telegram:https://t.me/GDEXer

we also welcome every friends to attend the 2018 Global Graphene Developer Conference: http://blockgeek.io/graphene/index.html

Thanks for support!