0 Members and 1 Guest are viewing this topic.
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 ?
Quote from: bitcrab on December 19, 2018, 09:40:16 amas 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.mdSorry, 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.
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
Quote from: clockwork on December 19, 2018, 01:41:44 pmQuote from: Thul3 on December 19, 2018, 01:32:33 pmThe 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 pollI 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.
Quote from: Thul3 on December 19, 2018, 01:32:33 pmThe 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
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.
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; ...
... 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; ...
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.htmlAnyway, 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.
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
--- earlier messages in witness channel (security fix 1) begin ---Abit More 2018-06-30, 2018 11:30:18 CETMainnet 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 - clockworkSo is everyone prepped for HF today?we should do a complete roll callAbit MorePing everyone. Make a checklistAlex M - clockworkwas about toAlex M - clockworkin.abit Confirmed up-to-datebhuz Confirmed up-to-dateverbaltech2 @ThomasFreedmanabc123 Confirmed up-to-dateroelandp Confirmed up-to-datewitness.still Confirmed up-to-datexman Confirmed up-to-datedelegate-1.lafona Confirmed up-to-date elmato Confirmed up-to-datexeldal Confirmed up-to-daternglab Confirmed up-to-datesahkan-bitshares Confirmed up-to-datexn-delegate Confirmed up-to-datefox Confirmed up-to-datewitness.yao Confirmed up-to-dateblckchnd Confirmed up-to-datedelegate.freedom Confirmed up-to-datecrazybit Confirmed up-to-date bangzi Confirmed up-to-datemagicwallet.witness Confirmed up-to-dateopenledger-dc Confirmed up-to-datewitness.hiblockchain Confirmed up-to-dategdex-witness Confirmed up-to-datewinex.witness Confirmed up-to-datedelegate-zhaomu Confirmed up-to-dateclockwork Confirmed up-to-datedelegate.ihashfury Confirmed up-to-date26/27 confirmedThom verbaltech2Ok 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 Moreforget it thenThom verbaltech2I 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 Moreclick the pinned messageand read the following messagesit's a softfork fix for a potential forking issueThom verbaltech2Why not put this out in ALERTS channel?Abit Moreit's good enough when > 2/3 of witnesses have upgradedThom verbaltech2Ok, then I'll relax.Abit Moreit's not an urgent fix, why alert channel?Thom verbaltech2Just not cool to wake up to the ugency I see here this morning.Abit Morewhen I pinned that message, there should be a notificationThom verbaltech2Why then this roll call, and long discussion?Abit Morethis? which?just last time check IMHOThom verbaltech2Not here Abit. Please use alert channel for important announcements. Others may differ on that, may consider alerts true EMERGENCY items.Alex M - clockworktheres been no urgencylast a last check roll calljust*Thom verbaltech2Alerts 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 - clockworkthe patch thing was posted days agocall wasnt about patch specifically but about updating to HF versionThom verbaltech2I 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 - clockworki think to avoid drawing attention to it as witnesses had already upgraded to HF versionand a specific transaction would have caused them to forkThom verbaltech2Let 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 - clockworkwhich 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 agoI'm getting confused as to what the problem isThom verbaltech2Sorry 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 onOk...my badThought it was expected to go through a final check of everyone being updated for the HF todayThom verbaltech2So the readiness for HF with 612 is being conflated ... no wonder it seems urgent. These are two very different matters of concern,Thom verbaltech2And somebody injected question about patchThom verbaltech2Pinned 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 patchAlex 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 donewell..only got round to it todayThom verbaltech2Back to standardsThom verbaltech2And 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 thisBeen 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 verbaltech2Security 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 mewitness nodes are (should be) heavily protected network wiseAlex M - clockworkso abusing them by knowing what version theyre runningis only possible via crafted transactionstransactiosn are cheapif you find an exploit...Fabian <xeroc> SchuhMay I remind everyone that the BBF has mailing lists for witnesses too?Thom verbaltech2Yeah, not realy a fan of mailing ists...Thom verbaltech2I 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 trno need to update to patchit's only 40 minutes until hfafter hf that patch is uselessAlfredo Garciai 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 CETALL 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 CETis 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 CETAnd 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 CETAll witnesses please revert the patch[message pinned][witnesses were downgrading]...Thom verbaltech2 2018-08-14 01:06:10Have any of you noticed patch doing a lot of creating database api / freeing database api calls? Didn't see that (earlier).Peter ConradThat'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 updatedPeter ConradYou'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 patchThom 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 Moreif you want to discuss how to solve the problem, welcomecode IS thereAlfredo Garciathe patch haves an issue thats why it needs to be reverted by nowThom verbaltech2What problem? git Issue # pleae?Abit More>Thom verbaltech2>What problem? git Issue # pleae?security issue. No public disclosure before coveredare you serious?witnesses are meant to help. not accuseThom verbaltech2I 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 accusePlease don't be so defensive. I'm not making any acusations abitAbit Moreok. sorryThom verbaltech2Apology 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 CETWitnesses please upgrade to fix4...Abit More pinned «Witnesses please upgrade to fix4...»[witnesses were upgrading](This time Thom is quick)Thom verbaltech2 18:52:55Witness 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 CETTESTNET test-2.0.180817, MAINNET fix4n...Abit More pinned «TESTNET test-2.0.180817, MAINNET ...»...Thom verbaltech2 2018-09-06 22:20:11 CETI'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 - clockworki do agree we could do better with the naming Thom verbaltech2That 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 Morepatches are meant to be low volume. they're for witnesses only. that's why we use branches but not tagsfor wider public we do releasesinfo 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 fasteI 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/1173Thom verbaltech2Thx 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 LiuBSIP42 is passed, so I think every witness can begin to work on update the price feeding for bitCNYAbit 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 / discuPlease 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 releasLest 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 verbaltech2Also, 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 - clockworkI'm lost... Most of the codebase is documentedSecurity patches are named obscurely and with no discernible pattern because they can be exploited otherwiseI seriously don't get what the request isThom verbaltech2We 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 ConradI 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 implementationow 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 TamamiThom 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 MoreAs 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 dateAlex M - clockworkalso...I'm quite sure that the FBA design was discussed in the forumsAbit Morefor example fix1it'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 Moreit only has effect before July 19.other patches, if needed, we merge to develop branch right awayThom verbaltech2>Alex M - clockwork>also...I'm quite sure that the FBA design was discussed in the forumsIt was, but not the changes. I was there, I confirmed my take of the evolution with OnceUponAtime, kencode and bytemaster.Abit Morewith low volume of course.I feel my time is wasted discussing these.@ThomasFreedman please fix your feed, better sooner than laterThom verbaltech2Then 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 itAbit MoreIMHO, that's the most important thing you need to do right now. after you've done, we can discuss other things.Alex M - clockworki'll have to look through the forums now to ease my curiosity Thom verbaltech2Yeah, 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 staThen 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 feedAlex M - clockworkBoth tonight .not homeyetThom verbaltech2The 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 dutiesAs 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 CETNot 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 verbaltech2Yeah ,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 youAbit More>Thom verbaltech2>Not sure I heard anything about a fix4nPinned message. Also iirc you've complained when the message is pinnedI'd suggest that you need to pay more attention to this channelSorry, replied before reading later conversationThom verbaltech2>Abit More>Sorry, replied before reading later conversationApology accepted.--- earlier messages in witness channel (security fix 4n and bsip42) end ---
--- witness channel conversation (the most recent feed issue) start ---Thom verbaltech2 2018-09-14 17:32:49 CETI 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 unstablejumping from 0.72 to 0.8xThom verbaltech2>Abit More>@ThomasFreedman your feed seems unstableNot great in terms of graph resolution, but does show overall activity.>Abit More>@ThomasFreedman your feed seems unstableI will check it.Thom verbaltech2>Abit More>jumping from 0.72 to 0.8xWhat 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 Moreseems @xeldal and @muagkov and @blockchained need to check feedRoelandpverbaltech 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?Roelandpno but i have historical data in my backendin my dbso i can start pushing graphsAbit 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 30498191verbaltech2 report feed: 1.38341 BTS/CNY 2018/09/14 17:31:30 30498427verbaltech2 report feed: 1.20063 BTS/CNY 2018/09/14 17:40:21 30498603CET time.Thom verbaltech2When 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 Moremagicwallet 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 30498191verbaltech2 report feed: 1.38341 BTS/CNY 2018/09/14 17:31:30 30498427verbaltech2 report feed: 1.20063 BTS/CNY 2018/09/14 17:40:21 30498603just check the numbers.no feed is better than wrong feed, IMHO.I'm also pinging others publicly. when I found something wrongnot specifically to you.the data is from wallet.Thom verbaltech2Wrong? 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 ---ThomPlease 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.Abitit is urgentthe jumping price may lead to unexpected serious consequenceThomIf 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 feedsThose 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.Abitcheck your own dataverbaltech2 report feed: 1.21137 BTS/CNY 2018/09/14 17:19:42 30498191verbaltech2 report feed: 1.38341 BTS/CNY 2018/09/14 17:31:30 30498427verbaltech2 report feed: 1.20063 BTS/CNY 2018/09/14 17:40:21 30498603verbaltech2 published feed price of 0.7289 bitCNY/BTS 2018-09-14 18:01:42verbaltech2 published feed price of 0.8371 bitCNY/BTS 2018-09-14 18:00:30check in wallet, or a block explorerin one minute 2 feedsmore than 10% differenceThomI 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.AbitIf you can't see the problem. I have nothing to talk to you.bye.ThomOK.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.ThomBummer, disabling only CNY asset is proving to be difficult.ThomLast 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 ---
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.
Stake holders are free to unvote the witnesses that didn't respond in time.
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.
Why didn't you agree on a collectiv refferal program which would bring massivly new members to DEX ?This would be a good solution
Quote from: Thul3 on September 13, 2018, 11:14:21 amQuote from: bitcrab on September 13, 2018, 10:32:17 amQuote from: Thul3 on September 13, 2018, 05:40:12 amWhat 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 solutionMaybe 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.
Quote from: bitcrab on September 13, 2018, 10:32:17 amQuote from: Thul3 on September 13, 2018, 05:40:12 amWhat 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 solutionMaybe you should focus on adoption instead of manipulation ?
Quote from: Thul3 on September 13, 2018, 05:40:12 amWhat will be the next proposal to cancel black swan events ?you are right, I am considering to cancel black swan events.
What will be the next proposal to cancel black swan events ?
Quote from: bitcrab on September 13, 2018, 10:32:17 amQuote from: Thul3 on September 13, 2018, 05:40:12 amWhat 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 ?
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.
we understand that although BSIP42 worker proposal is active