Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - abit

Pages: [1] 2 3 4 5 6 7 8 ... 219
1
Stakeholder Proposals / Re: [Witness Proposal] gdex-witnness
« on: September 24, 2018, 01:27:51 pm »
@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.

2
Stakeholder Proposals / Re: [Poll] BSIP42: adjust price feed dynamically
« on: September 24, 2018, 01:18:41 pm »
@abit I'm walking around here on Bitfest and we've been discussing the BSIP42. If we are looking into updating the software with a future hardfork or major release, irregardless of whether to continue the BSIP 42 or it might get voted out we could move and seperate the "pricefeed"-data and the "premium" (modifier) data into a new variable set by witnesses publishing this 'modifier/premium'.

What I would propose is for

- transparency
- useability of the actual market reflecting pricefeeds

to have next to the  quote/base data per asset also a new variable, namely a 'premium' or 'modifier / premium / feedback'-float to be set per asset. This modifier/premium can then be set irregardless of the pricefeed publishing (or together, but ideally also seperate `publish_modifier`) and can be a 'median of medians' .

1. This would mean that witnesses can continue to publish pricefeeds according to the old "market reflecting" data as sampled from all sources.
2. The pricefeed data reflects "true" reflection of the market and can continue to be used as trusted source for input for other projects whatever they may be.
3. Then inside the new software version code the final price to be calculated could be as simple as "pricefeed median * 'modifier median".

- If BSIP42 gets voted out it could be as simple as everyone publishing a "1.0"-value as "modifier".
- If BSIP42 stays active it is way easier to see witnesses' premiums/modifiers and the pricefeeds can stay usefull for other projects beyond and inside the Bitshares realm.

actually I think one other solution may be better: keep feed price as the "real market price" as before, and let witnesses adjust MCR based on the premium/discount get from market. this will give same impact to the the market as BSIP42 and can lead to pegging accuracy.

this need not to add more variables, but need to overcome some technical problem/fix some bugs as @abit has mentioned.

however I think either solution need a long time(several months?) to fix bugs or even do hard fork,  I don't think we should just wait for the solution come, we can just push BSIP42 at current time to make smartcoins better, until the "transparent" solution come.

Yes indeed changing the MCR would be the best solution, but if it would be technically unfeasible or to much demanding for the chain the suggested solution might at least be a good alternative i think, especially since I think that it might be easier to integrate with the current software instead of changing much to the Smart Assets code.
The bug about changing MCR is being fixed. Actually the code is ready, but need testing. https://github.com/bitshares/bitshares-core/pull/1324

However, even when it's able to adjust MCR, the code doesn't allow us to adjust it to less than 100%. That means black swan is unavoidable by adjusting MCR alone when time comes.

By adjusting price, theoretically black swan event is avoidable. More discussion in this post https://bitsharestalk.org/index.php?topic=27170.msg322381#msg322381 .


@roelandp: I don't like the change you proposed because it is not a simple change if want to make it into consensus, to implement it we need to change quite some code, but the gain is little.
* If someone wants to feed something not for the system to use, he can use custom_operation.
* If someone want to track price, he can use latest market trading price.

3
中文(Chinese) / Re: BTS/EUR 卷 泵
« on: September 24, 2018, 01:04:32 pm »
砸盘拉盘?

4
Stakeholder Proposals / Re: [Witness Proposal] gdex-witnness
« on: September 22, 2018, 10:36:00 pm »
Quote
--- 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 ---


Quote
--- 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 ---

Quote
--- 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 ---

Quote
--- 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 ---

Quote
--- 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 :D

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 :D
I'd recommend to that AFTER fixed feed

Alex M - clockwork
Both tonight :P .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 ---

5
Stakeholder Proposals / Re: [Witness Proposal] gdex-witnness
« on: September 22, 2018, 10:34:57 pm »
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.

Quote
--- 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 ---

Quote
--- 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 ---

6
中文(Chinese) / Re: 【讨论】取消黑天鹅和强清功能的可能性
« on: September 20, 2018, 01:46:45 pm »

Quote
再说强清。

既然不是IOU,出入金当然是要看市场容量的。自由交易嘛。

就目前的bitCNY总量(1亿多),提个300万应该没什么难度,一两天时间肯定能提出来了。
等bitCNY总量做更大了,锚定更稳了,认可的人更多,做承兑的人更多,那300万就更没问题了。
哦,除非bitCNY发行量过大导致贬值,承兑商队伍体量不足,现金(法币)紧缺了。

即使如此,为什么必须用强清呢?完全可以吃爆仓单啊。
bitCNY贬值时,BTS喂价低于市价,爆仓单成交价还可以再低10%,吃的还不够爽?比起强清,那是便宜20%啊。
实时结算?如果有便宜20%的爆仓单吃,谁会去强清?
哦,爆仓量不足以覆盖内盘深度?
这时bitCNY还贬值、承兑商还提不出钱来吗?那喂价就会继续下调,会有更多爆仓啊。

你可以看看鼓鼓提现额度情况,弱不经风。


看了,没看出问题。
你提了多少,还剩多少提不出来,能不能发出来看看?
实在不行,我可以找人借高利贷帮你提。

Quote
这时bitCNY还贬值、承兑商还提不出钱来吗?那喂价就会继续下调,会有更多爆仓啊。
------------------------------------------------------------------------------------
这一点有问题,你再深入推敲下。

万一喂价下调到比市场价低50%,才能覆盖深度呢?是不是很多新的问题出来?
喂价下调到低50%都没人吃爆仓单?那市场是得有多熊呀。
不对,熊市 bitCNY 不是溢价吗,喂价怎么会下调?

好,就算会出现这种情况,强清是会有好处还是坏处?你分析下?
理解反了,不是爆仓单没人吃,是有bitcny却没有足够的bts可以买。
没理解反。
bitCNY 是抵押 BTS 产生的,如果盘面没有足够的 BTS 可以买,导致 bitCNY 折价,喂价会下调,制造出爆仓单,就可以买。

7
中文(Chinese) / Re: 这个喂价算法,真的是让人很无奈啊。
« on: September 20, 2018, 01:44:13 pm »
现在还处于算法摸索阶段,喂价出现偏离是可以接受的。个别见证人没喂好不要紧,密切观察调整就好。

遵循同样的调整原则,见证人各自实现自己的算法,可以避免单点问题,避免同一个BUG造成大范围喂价出错,比如2.0上线不久出现的 SEK 黑天鹅事件,就是因为大部分见证人用的同一个喂价脚本出了BUG。

现在算法还没稳定,有些见证人的脚本只会上调喂价不会下调,导致现在有些矫枉过正, bitCNY 出现折价。

等算法稳定了,双向调节效果会真正体现出来。


8
哦,你编辑过了,那我再回一下。

我并不是说你的方案不好,或者说强清方案没有任何效果。

爆仓时强清负补偿,最低负2.5%,也就是相当于MSSR设成2.5%的效果。
强清加目标抵押率,也就和爆仓的目标抵押率效果一样。

不同的只是人为的把强清市场和买卖单市场拆开,让机器人去搬砖拉平。
加上延迟,总量限制,也就是用时间换空间,让暴跌不至于传导那么快。


但是,还是有价格传导,所以还是会有价格压制,解决不了bitCNY溢价问题。
就算 MSSR = 0 ,按原价喂,bitCNY还是会溢价。你信不信?
况且你还有2.5%的惩罚。

机制改这么大,代码要改那么多,效果可能还不如把 MSSR 调成 1% 甚至 0.1% 。

这个方案只是不够好。

9

Quote
我举个例子吧。
abc.btsbots 账上有4000万BTS,抵押一半,用2000万BTS,可以制造至少500万bitCNY。
这500万bitCNY用来强清,剩下2000万BTS用来砸盘。

即时强清,也就是说,强清发起时机器人就能算出多少bitCNY能换多少BTS;同时对比实时买单,可以确认这些BTS能换回多少bitCNY。那么,损益平衡点在哪里是可以马上算出来的。同时发起两笔交易,一笔强清,一笔砸盘。然后每5分钟,再算一遍。无损抽血。抽平为止。

内盘砸盘,价格会传导到外盘,一边砸盘喂价一边下降,爆仓(或者按你的规则是可低价强清的单)更多。

再说补偿与抵押率挂钩的问题。
1. 抵押率已经过低进了即时强清池了,强清还需要补偿?补偿多少?
2. 这个公式,存在一个临界值,抵押率低于这个值强清合算,高于这个值强清不合算。
   假设MCR时,强清补偿5%也就是强清者付5%,在抵押率CR1时,补偿为0,抵押率CR2时,补偿-5%。
   也就是说,抵押率低于CR1,才开始有惩罚,等于变相把MCR降低到CR1。
   另外,抵押率越低补偿越低,等于是动态的MSSR。
   那么很明显,开始爆仓是没人吃的,因为还要加钱;爆仓积累后才会有人吃,价压得越低吃的越便宜。
   这不是鼓励做空吗?并且做空做的越狠就赚的越多。

反弹先不分析了。

恩,这个量化机器人太高端,买盘量如果这么好统计与精确的话,很多的量化机器人就不会亏了,而且机器人如何判读出能够强清到足够的BTS?即使强清量足够,难道就这一个机器人活跃?这个机器人如何保证在喂价变动与其它机器人干扰及抵押率还款变动的情况下得到足够量的BTS?或者即使得到足够量的BTS,将价格砸到强清补偿负值的极限2.5%,也就是抵押率到120%,这个价差很重要吗?

如果即时强清存在这个漏洞,我们可以把这个洞补上,换个思路,发起强清后,延时5分钟才进行强清,去掉延时发送。

另外你举的这个例子,有2000万BTS来砸盘,可以将内盘砸出窟窿,都不用强清的单子,市场自己就会崩盘,崩下来怎么吸不行,吸强清单与抛单又有何区别?

再者如果按照你的分析思路:有如此高端量化机器人,与手持如此大的量的情况,在以前的喂价情况下,完全可以将内盘刷归零,然而事实真是如此?
按我的理解,这个机器人还不算量化机器人,只是简单的搬砖。

可以清多少,砸多少,当然可以算出来。数据都在链上,是公开的,爆仓、强清公式也是公开的。

机器人之间当然会有竞争。
为什么拿 btsbots 举例,因为其他机器人要么速度比不上他,要么资金量比不上,竞争不过。

搬砖机器人求的是稳定收益,即时获利,而不是砸一下,预期价格跌到多少可以再吸货。
4000万虽然对行情能有一定影响,但是不算多。内盘前段时间有过一两亿的日成交量。
也就是说,砸下去不一定能砸趴。就算砸趴了,现在目标抵押率普及了,他也不一定能低价吸回来。

顺便说下,这4000万里3000万是前段时间吃爆仓单建仓的,在有目标抵押率之前,只吃了两三笔就建好了。
更早的仓我没有去查。

延时5分钟强清,也就是现在的强清规则改了时间参数。
机器人风险会稍微大一点,还是可以搬。因为有延时,所以依然是资金量大的机器人有优势。
方法是:先强清,等5分钟后强清执行后,马上砸盘。这种搬法都不需要准备一笔BTS,可以用清出来的BTS砸。
5分钟喂价变化不会太大。相应的,债仓可以清的数量也不会变化太大,盘面买单也不会变化太大。
为降低风险,可以用小额多笔的方式,平滑砸盘曲线。
这样会搬的慢一点,但一直搬还是会搬平的,也就是说强清池实际上还是会压制买盘价格。


Quote

Quote

调喂价从根本上避免了下跌时的爆仓单压盘,具体看现在的实盘数据。

干扰因素确实很多,最主要的是见证人群体的能力不够或者积极性不够,不能及时发现问题进行调整。
这个需要靠投票人去推。


到底如何,让市场检验吧。

见证人的能力够不够,发现问题能不能进行调整,以及社区投票掉见证人,这属于社区中心化的范畴,不讨论。


Quote

姑且不说分析的对不对,好像说的都是 BTS 的事。对bitCNY 溢价、流通量的影响也分析下?

锚定资产正负溢价是常态,就跟汇率一样,谁还能强控汇率? 即使现在的高喂价情况下,一旦市场连续性下跌,入金手续费会无视内外盘价差,至少也会调整至1%多。

承兑商手中的BITCNY量基本是固定的,即使有其它的承兑商加入,影响也不大,至于流通量,现在高喂价情况下,出金手续费为正,接近于1%,很多人是不会通过承兑商流出的,只会提到外盘砸盘流出,入金多,而出金少,自然承兑商是亏的,入金手续费自然也会慢慢回到正值。
你一直说承兑商手里的bitCNY量是固定的,其实不是的。

不炒币的承兑商,手里的资金量是固定的,但是bitCNY量不固定。
熊市时承兑商手里现金(法币)偏多,牛市时bitCNY偏多。
原因很简单,熊市时充值进去平仓了,要么自己平仓,要么吃爆仓单帮别人平仓,bitCNY消失了。
牛市没有爆仓,没有平仓需求,bitCNY供应足。
如果承兑商手里一直源源不断有bitCNY可以兑,就不会有溢价和贬值的问题了。


“出金手续费为正,接近于1%,很多人是不会通过承兑商流出的,只会提到外盘砸盘流出”
流出什么?是说砸BTS换法币?很明显,内盘深度好,即使算上承兑商的1%,砸盘换法币还是内盘砸最合算最方便的。
如果是说bitCNY换CNC或者QC提现,实际上,做承兑的还是那些人,市场价格也是平的。QC/CNC提现甚至收费更高。


“入金多,而出金少,自然承兑商是亏的”
如果bitCNY波动范围大,承兑商可以牛市屯,熊市出;在波动范围不大的情况下,承兑商赚的只是进出差价。
一般的承兑商,做一笔充值就反手做一笔提现,保证不会亏。价格不好,大不了不做,等着。
承兑商会自己找平衡的。
在提现收费的时候,一般是bitCNY供应量偏多的时候,也就是承兑商手里bitCNY也会偏多。
比如现在充值送0.1%,提现收0.6%,扣除鼓鼓收的0.3%,承兑商赚0.2%。
做一笔提现的利润,可以做两笔充值。这样手里法币就多了,bitCNY变少了,维持平衡,但是不会亏本。
行情反过来的时候,手里bitCNY紧缺的时候,就会多做提现,少做充值。

所以,出入金手续费升和降,和承兑商手里bitCNY数量的升和降,是直接相关的。
因为调节喂价会直接影响供应量,所以可以直接影响手续费,达到稳定效果。

10
当然会存在即时砸盘的行为,本身获利行为才会引起强清的动力。

所以需要即时强清+延时发送(设置5分钟或者其它时间)两者结合,

假如设置强清补偿率与抵押率挂钩,120%的抵押率最大的强清补偿率才到负5%(或者为负2.5%)的话,价格即使下滑10%,20%,30%的强清获利行为来搬平也是一点点的搬平,市场本身存在无数的反弹,差价很快就会平掉,没有强制性爆仓来的那么明显,量能那么大,而且机器人也要衡量实时价格,如果实时价格小于强清来的价格,机器人只会越搬越亏,机器人策略也会考虑到这一点吧,而且在反弹期,搬砖价格压制没有爆仓单那么严重,因为爆仓单是一直挂着压制市场,要么吃完,要么等喂价上升。

我举个例子吧。
abc.btsbots 账上有4000万BTS,抵押一半,用2000万BTS,可以制造至少500万bitCNY。
这500万bitCNY用来强清,剩下2000万BTS用来砸盘。

即时强清,也就是说,强清发起时机器人就能算出多少bitCNY能换多少BTS;同时对比实时买单,可以确认这些BTS能换回多少bitCNY。那么,损益平衡点在哪里是可以马上算出来的。同时发起两笔交易,一笔强清,一笔砸盘。然后每5分钟,再算一遍。无损抽血。抽平为止。

内盘砸盘,价格会传导到外盘,一边砸盘喂价一边下降,爆仓(或者按你的规则是可低价强清的单)更多。

再说补偿与抵押率挂钩的问题。
1. 抵押率已经过低进了即时强清池了,强清还需要补偿?补偿多少?
2. 这个公式,存在一个临界值,抵押率低于这个值强清合算,高于这个值强清不合算。
   假设MCR时,强清补偿5%也就是强清者付5%,在抵押率CR1时,补偿为0,抵押率CR2时,补偿-5%。
   也就是说,抵押率低于CR1,才开始有惩罚,等于变相把MCR降低到CR1。
   另外,抵押率越低补偿越低,等于是动态的MSSR。
   那么很明显,开始爆仓是没人吃的,因为还要加钱;爆仓积累后才会有人吃,价压得越低吃的越便宜。
   这不是鼓励做空吗?并且做空做的越狠就赚的越多。

反弹先不分析了。

Quote

当然存在意外因素就是中值喂价偏离实际法币价格太多,喂价刷新的不及时性。

喂价只是表因,不能从根本上改变什么,而掺杂有太多的干预因素。

所以尽量削弱或者消除系统对市场的干预才是合理性规则,也最有利于抵押锚定的发展。


稳定性不够主因不在于喂价。

见证人本身就不应当干预喂价,BTS本来提供的是符合去中心化理念的锚定资产, 当然你们理解的去中心化可能不一样,到底是不是事实上的去中心化,又或者是社区中心化,似乎现在看来也已经不是那么重要。


调喂价从根本上避免了下跌时的爆仓单压盘,具体看现在的实盘数据。

干扰因素确实很多,最主要的是见证人群体的能力不够或者积极性不够,不能及时发现问题进行调整。
这个需要靠投票人去推。

Quote

建模如何,到时候市场来看吧。


我的模型很简单,前提是强清补偿与抵押率挂钩,并能够实现目标抵押率,喂价可以及时刷新,并能够准确反映实际法币价格。

1. 市场上升期:内盘价格会超出喂价,强清此时会进行压制内盘价格,将175-180左右的抵押单进行压制,遏制贴线抵押;

2. 市场平稳期:内盘价格与外盘价格持平,抵押率可能会被压制在195%左右,也可能维系在185%左右。

3. 市场下滑期(比如断头刀式下跌):因为前期抵押率在185%左右,价格迅速下跌到175%的幅度为5%,因为是价格下跌期,如果喂价与外盘价格一致的话,除非强清到150%的单子才有足够的获利性(强清补偿为暂设为负1.5%),也就是需要喂价下降到150%,也就是价格下降幅度近15%,这个时候已经有足量的即时强清单与获利性,此时机器人进行搬砖套利,假定喂价,内盘价格,外盘价格一致,强清来的筹码价格便宜1.5%,本着就近原则,先砸内盘,将内盘价格砸掉1.5%,此时内盘无获利性,然后再强清搬向外盘砸,此时将外盘也砸掉1.5%,喂价随之下降1.5%,然后资金从承兑商或者其它途径回流到内盘,因为本身资金流出需要至少0.3%的费用与流入也需要缴纳近1%的费用(市场大幅下跌的正常费用,非价格差因素),也就说除非对倒型搬砖,不然搬砖基本无获利性,此时还没有加上延时发送与市场价格进一步下滑而喂价没有及时下滑的风险,所以想要搬砖只能在内盘把价格砸下1.5%(完美条件下).

4. 极端市场大腰斩,价格直接瞬间暴跌50%,从2块腰斩到1块,如果没人强清的话,抵押率的变化是,从175%跳到87.5%,资不抵债。

    从175%到110%的价格下降幅度极限为37%.

    需要考虑此种极端条件下,资不抵债的问题,当然最简单的办法就是将MCR调整至300%,这样能够承受的价格下跌力度为63%,但是对抵押产出来说太少而没有意义。

姑且不说分析的对不对,好像说的都是 BTS 的事。对bitCNY 溢价、流通量的影响也分析下?

11
我的观点是: 规则合理的制定应当尽量削弱或者消除系统对市场的干预,尽量让市场进行自我博弈与调节。

1. 强平机制中的强平单直接抛向市场,对市场来说是很大的一个冲击,因为是强制性的覆盖,导致系统对市场有极强的干预性,所以强平这个机制也有问题;

2. 强清补偿参数的固定化问题,如果高了,会导致强清功能失效,如果低了,会导致强清泛滥,导致系统不能有限保护抵押而导致市场空头盛行,不过对价格的压制效果倒是不明显,主要是对抵押规模有极大的压制;所以强清补偿参数也有问题;

3. 喂价公式: 其存在规则引导系统过度干预市场,也隐含有见证人直接通过喂价干预市场的因素,而且也没有解决强平单直接抛向市场导致系统强制干预市场这个行为,所以喂价公式并不是最终方案,只能做个临时应对之策;

对于为什么提出即时强清这个想法,因为现在的爆仓单压制盘面与强清基本一致,但是如果是即时强清则有更多的人为因素在里面(哪怕是机器人搬砖),有人参与必然要考虑获利性,强清到了单子之后是直接砸向市场还是挂单在一定位置等着来吃,这有更大博弈,而与爆仓单压制盘面的不同在于,爆仓单很长时间内是不会被吃完的(因为高喂价带来的抵押单巨大,而且喂价的更新有相当的延迟性),只能静等喂价上升,而且喂价上升后,这些爆仓单也不会被吃掉,而强清不存在此问题。


我们寻求的一套规则应当极大的程度上削弱规则引导系统干预市场的能力,即不偏袒与多方,也不偏袒与空方。


BITCNY的不稳定最主要的因素在于强平单强制性的甩向市场,导致大幅度的价差产生,喂价只不过是诱因,改喂价只是治表而不是治本。

                        另一个因素在于抵押的规模与承兑商的规模(承兑商的流通量)。


建模型分析很简单, 单独的把某一条件撤掉,推论一下内盘市场的反应就行。

1. 有喂价,没有强平,内盘市场价格是否会与外盘一致?

2. 没有喂价,有强平,内盘价格是否会与外盘一致?


喂价一致的情况下,也就原喂价,这里的强清补偿采用与抵押率挂钩。

1. 无强平,有强清,内盘价格是否会与外盘一致?

2. 有强平,无强清,内盘价格是否会与外盘一致?

我仍然认为下跌时的即时强清和爆仓没什么区别,还是会压制价格。
只要有差价在,机器人搬砖效率很高的,很快扳平。
机器人多是即时获利,很少有屯货的,因为屯货意味着流动性降低,意味着风险。

反而,调整喂价可以直接避免价格压制。

自由市场下,价格是所有因素的最直观的综合反映;因而,调整价格,会反向影响整个市场,是最直接有效的调节手段。


为什么要干预,要调整,因为我们需要一个价格稳定的bitCNY产品。
自由的博弈,目前为止,带来的稳定性明显不够。

我的建模分析我推演过了,你想不同建模,也可以自己推演下。

12
中文(Chinese) / Re: 【讨论】取消黑天鹅和强清功能的可能性
« on: September 19, 2018, 10:53:14 am »

Quote
再说强清。

既然不是IOU,出入金当然是要看市场容量的。自由交易嘛。

就目前的bitCNY总量(1亿多),提个300万应该没什么难度,一两天时间肯定能提出来了。
等bitCNY总量做更大了,锚定更稳了,认可的人更多,做承兑的人更多,那300万就更没问题了。
哦,除非bitCNY发行量过大导致贬值,承兑商队伍体量不足,现金(法币)紧缺了。

即使如此,为什么必须用强清呢?完全可以吃爆仓单啊。
bitCNY贬值时,BTS喂价低于市价,爆仓单成交价还可以再低10%,吃的还不够爽?比起强清,那是便宜20%啊。
实时结算?如果有便宜20%的爆仓单吃,谁会去强清?
哦,爆仓量不足以覆盖内盘深度?
这时bitCNY还贬值、承兑商还提不出钱来吗?那喂价就会继续下调,会有更多爆仓啊。

你可以看看鼓鼓提现额度情况,弱不经风。


看了,没看出问题。
你提了多少,还剩多少提不出来,能不能发出来看看?
实在不行,我可以找人借高利贷帮你提。

Quote
这时bitCNY还贬值、承兑商还提不出钱来吗?那喂价就会继续下调,会有更多爆仓啊。
------------------------------------------------------------------------------------
这一点有问题,你再深入推敲下。

万一喂价下调到比市场价低50%,才能覆盖深度呢?是不是很多新的问题出来?
喂价下调到低50%都没人吃爆仓单?那市场是得有多熊呀。
不对,熊市 bitCNY 不是溢价吗,喂价怎么会下调?

好,就算会出现这种情况,强清是会有好处还是坏处?你分析下?

13
如果把 BTS 当成一个公司看, bitCNY 等智能货币,是公司的“产品”。
对这个产品的期望是:它的市场交易价格在对应的标的(比如法币 CNY )附近波动。
产品的质量,当然是很重要的。就是要波动尽量小。

-------- 分割线 -----------

从产品开发角度来说,产品是否成功,应该是结果导向。方向走对了,就继续;错了,就认错、纠正。

BM最开始设计的 bitCNY ,是没有任何数据反馈的,结果是锚定偏差很大。具体多大我不知道,那时我还没有接触到这么深。但是很早的社区成员是知道的。

后来,作为尝试,引入了喂价作为反馈输入,把偏差稳定在了 20% 以内,可以说是很大的进步。所以这个引入反馈输入的方向是对的。其实,一直也有很多人反对引入喂价,认为是价格操纵,是中心化等等。

中间还有其他机制优化,比如从最初的撮合方式借款、固定3倍抵押、30天强制还款,改成现在的自由抵押借款,产品是一直在进步的。

现在,我们改革,就是继续沿着这个反馈的方向,继续以结果为导向,优化实现细节。因为我们对于 20% 的波动范围不满意,希望锚定更稳,波动更小。

-------- 分割线 ---------

从 BTS 2.0上线开始(不止是BSIP42开始),对见证人职责的一个比较确切的描述就是:

见证人根据市场行情,动态调整生产智能货币( bitCNY 等)需要的最低抵押要求、强制清算兑换比例,以保证智能货币( bitCNY 等)的市场价格在对应的标的(法币 CNY 等)附近波动。

市场行情包括:
* BTS 在各个市场的成交行情,包括内盘和外盘
* bitCNY 在各个市场的成交行情,包括内盘和外盘

最低抵押要求包括:
* 抵押物/债务 的一个最低比例(单位是 BTS / bitCNY ),低于这个比例时,会触发爆仓;
* 触发爆仓时,系统强制卖出抵押物的最低价格

强制清算兑换比例:也就是多少 bitCNY 可以强制换多少 BTS 。


-------- 分割线 -----------

按照上面的描述(也可以说是定义、或者需求),

* 市场参与者对于产品(bitCNY)的期望就很清晰:主要关注 bitCNY 的市场交易价格。

* 见证人对于自己的职责也会很清晰:关注 bitCNY 的市场交易价格。

* 投票人(BTS 持有者)对见证人是否履行职责的判断也会清晰: bitCNY 的市场交易价格是否在法币 CNY 附近。

在这个需求下,强制清算是作为辅助功能存在的。
(当然我们不排除把强制清算改成主要功能的可能性,如果市场失效的话)


---------- 分割线 ------------

结果导向,那么就需要让大家更关注结果,也就是对注意力的引导,这在用户体验(UX)设计上是很重要的一点。

而目前的界面设计、宣传,向用户过多的暴露实现细节,导致相当部分用户注意力转移,反而没有去关注结果。

注意,我说的是用户。

一般用户看的基础界面上,应该把强制清算价格等数据隐藏起来,更突出当前成交价、挂单深度。

高级用户界面,包含借款、强制清算功能的,需要显示抵押比例要求、爆仓时的最低卖价、强制清算价格等信息。
但这些信息,都是为当前成交价服务的。

现在很多用户盯着强制清算价不放,而忽略当前成交价,是界面没有做好引导的结果。


---------- 分割线 ------------

当然,作为投票人、规则制定者、开发者,有必要关注实现细节。这也是这贴的主要讨论目的之一。

公司生产产品,产量受各种条件影响,进而影响价格,是正常的。
一般的小的影响,机制、规则可以应对;大的影响,比如恶意操纵,就不太好说。

使用产品的用户,也就是 bitCNY 持有者,利益当然是需要保证的,并且,“质保”必须有合理范围。
但很难界定说怎么样是合理。

我们现在讨论的主要争议,是极端情况下,现在的机制如何应对。

---------- 分割线 ------------

举个例子。

假设现在有个公司,使用 bitCNY ,客观上需要买两个亿。
这个公司没有公开宣传,而是在市场上慢慢买入,屯着,不花掉,也就是不买 BTS 。
为了不至于太明显,公司分很多账户买,甚至在市场上互相倒手。

那么,市场上流通的 bitCNY 会慢慢减少,bitCNY的充值费率也会走高。
同时,承兑商手里的 bitCNY 少了,现金(法币)多了。
* 不做抵押的承兑商,会严重缺货。
* 做抵押的承兑商,货也会变少。
* 贴线抵押的投资者,手里没有 bitCNY ,抵押出来的 bitCNY 都交给空军了。
* 而空军,可能把 bitCNY 屯着,可能自己做承兑、或者通过承兑商提现,最终流到公司手里。空军手里也会有法币CNY。

为了稳定费率,见证人会慢慢提高喂价,鼓励抵押者会制造更多 bitCNY 出来,继续投放到市场。
* 不做抵押的承兑商继续缺货。
* 做抵押的承兑商,会有些货可以兑,同时手里法币继续增多。
* 贴线抵押的投资者,制造出来的 bitCNY 又换成了 BTS ,导致市面流通 BTS 减少,一定程度会拉升 BTS 价格
* 空军手里BTS继续减少,bitCNY 或者法币继续增多

按这个模型,是不是对 bitCNY 的真实需求会引导导致 BTS 价格上升,同时bitCNY价格稳定、供应充足?

如果不调喂价呢?
* 承兑商手里没货。
* 贴线抵押的抵押不出多的bitCNY
* 公司买不到货
* bitCNY溢价严重

---------- 分割线 ------------

上面那个模型只有一个输入量,就是公司对 bitCNY 的需求。

如果公司需求不是买入,而是因为业务方向调整等原因,需要把 bitCNY 换成法币,反过来推导就行了。

bitCNY需求减少,导致折价,进而喂价下调,贴线抵押的投资者、做抵押的承兑商如果没有及时平仓,就会爆仓,释放 BTS ,导致 BTS 下跌。

什么?喂价太高,爆仓会不成交?不会的,当bitCNY折价,喂价就会一直下调,早晚会调到爆仓单能成交的范围。

也就是对bitCNY的真实需求下降会导致 BTS 价格下跌,但 bitCNY 价格仍然稳定。


---------- 分割线 ------------

那么好了,既然可以这样推导,那么庄家或者大户是不是就可以按这个方式操作,割韭菜?
我的结论是:如果有大户或者庄家有足够实力,是可以这样割的。
但是当市场足够大,参与者足够多,市场博弈就会更复杂,在有人在收割的时候,另外的人在建仓。

贴现抵押的投资者,在这个过程中,起到的是价格传导的作用,伴随着高收益预期、以及高风险。

其他的投资者,也会起到价格传导作用,但因为是博弈,有人卖有人买,模型里可以忽略。

---------- 分割线 ------------

极端情况,如果公司需求变得很快怎么办?比如,今天要买2亿 bitCNY ,明天要出2亿 bitCNY?

如果bitCNY供应量只有2亿,承兑价格可能会剧烈波动,那么BTS价格也跟着剧烈波动。

1. 剧烈波动,会不会出现资不抵债,导致黑天鹅事件?

这还真不好说。

我认为,当初承兑商收了公司的法币换出 bitCNY ,现在公司要换回法币,多半是换的出的。
系统里少掉的那部分法币,是空军拿走了。价格下跌到一定程度,可能空军会变多军?

同时,承兑商的规模也很重要。

2. bitCNY价格是否能保证稳定?

这种情况下,要稳定bitCNY价格,一是提高总供应量,二是增加喂价反馈灵敏度和准确度。

其实公司也不傻,快买快卖必然导致亏损。

哦,可以用强清?谁来帮忙分析下,强清在这个模型里会对结果有什么影响?

我认为,公司不是庄,所以没有把bitCNY强清转成BTS再去交易所砸掉换法币的动力,因为价格波动风险太大。

---------- 分割线 ------------

分析完需求模型,再分析下市场模型。也就是,BTC 涨跌、以及币市大盘的涨跌,对 bitCNY 的价值、供应量的影响。

1. 在外界还没有足够认可 bitCNY 的情况下,币市涨跌不会对 bitCNY 需求产生直接影响,
也就是说,交易者卖出 BTC 或其他币,也不会换成 bitCNY。
大概率他们也不换成 BTS ,而是换成法币,甚至会卖掉 BTS 换成法币。

这种情况下,即使因为搬砖党,内盘 BTS 卖单也会增多,导致 BTS 交易价格下跌。
因为 BTS 很大部分交易量在 bitCNY ,会变相导致 bitCNY 升值。

喂价就会上调,按照需求模型,会平衡掉一部分BTS价格下跌。
同时,抵押率会下降,有交易者认为 bitCNY 抵押率太低,有贬值预期,会反向操作。

这样就形成博弈,达到一个稳定局面。最终 BTS 价格可能会下跌,但是 bitCNY 趋于稳定。


2. 在外界认可 bitCNY 的情况下,大量 BTC 换成 bitCNY , BTC 价格会和 bitCNY 需求负相关,
进而,可能传导到与 BTS 价格负相关,也可能因为大盘或者其他原因导致负相关不明显。
这是后话了。

---------- 分割线 ------------

大家怎么看?

14
中文(Chinese) / Re: 严重BUG,可以任意操作别人帐号
« on: September 18, 2018, 10:27:12 pm »
为什么脑密钥是空的、我的会是多少?怎么查看脑密钥?
你账上还有钱,估计就说明没中招。。呵呵,开个玩笑。

如果发现自己账号公钥在下面这四个里,就赶紧改吧。

    "pub_key": "BTS7X84JxsPQBv9HKiBA2W6RSqcgPaRoWLTtfYCQ4yMy4DMrsASAk"
    "pub_key": "BTS7gfghfHDTCi5HVYTZ7fnzfA8v9ccqRJTSwvZbRjfhVtGoqRBRN"
    "pub_key": "BTS6ttNrvy4CXKmW36GxdXnyU2z1mprcKteUrqDTz1u9a7QSNaoR8"
    "pub_key": "BTS5iavugBUH517iRkzL54B53GtcieXzZ6zspiiwE3umrTFGXYwN6"


15
中文(Chinese) / Re: 【讨论】取消黑天鹅和强清功能的可能性
« on: September 18, 2018, 12:42:34 pm »
恩,今天的BTC反弹带来了内盘一个很有趣的现象。

值得研究一下,或者命名一下。
具体说说?我猜开始吃爆仓单了吧。

Pages: [1] 2 3 4 5 6 7 8 ... 219