Quote from: pluswave on March 20, 2018, 06:56:51 AM
A reference usage of this data is here: https://github.com/sunchao123456/btsprice .
The idea is , the recharge/withdraw price is compensated to the original BTS price through a user defined factor （0-1). For example, now magicwallet.witness set the factor to 0.4, While you can use 1.1 FaitCNY to get 1 bitCNY, it will compute:

   compensated BTS Price = original BTS Price * (1 + (1.1 - 1)*0.4)

if you can use 0.9 FaitCNY to get 1 bitCNY, it will compute:

   compensated BTS Price = original BTS Price * (1 + (0.9 - 1)*0.4)

The original BTS price is from a fork of alt's btsprice (crazybit's one).

Excellent work!

Witness: rnglab
[email protected]

@alt mate, for better or worst (it's up to us), code is not the law as you already know. Consensus is.

would you accept network funds to collaborate improving the DEX?

what are your thoughts about BSIP38's draft

Fair enough fav.

Although I don't agree to weigh just one single factor when voting; with the Infrastructure Worker proposal being delayed and the Elastic Search plugin under development, I appreciate any active action to fix a high priority bottleneck.

I'm going to work on this early next week, and will try bring Ansible playbooks as soon as possible to make full node deployments easier for everyone.

Your work is sound abit.

In line with these improvements, I think BSIP-38 candidate needs some attention too.

If its complexity requires an extra budget to pay for A bit more time (or for another dev to help), it'd be fair to me.

Quote from: fav on November 15, 2017, 08:06:24 AM
only reasonable solution is asking witnesses to fix their feeds. that's what they get paid for

that was the first step taken as you should know, and the reasons why it was not enough were discussed in depth.

I'll just leave this here: https://en.wikipedia.org/wiki/Law_of_triviality

Quote from: alt on September 18, 2017, 10:45:23 PM

remove my vote for wackou
add roelandp back

Code Select Expand



喂价 – BITCNY/BTS 汇率 – BITCNY/BTS 维持保证金比例 强制平仓比例上限 发布人 发布时间
0.60169556 0.60771252 175% 110% elmato 42秒钟前
0.5995742 0.62955291 175% 110% mr.agsexplorer 57秒钟前
0.57023927 0.59875123 175% 110% openledger-dc 1分钟前
0.520319 0.54770421 175% 110% delegate.btsnow 1分钟前
0.4112 0.514 175% 110% wackou 4分钟前
0.56505956 0.70633182 175% 110% in.abit 4分钟前
0.5774741 0.72196197 175% 110% xman 7分钟前
0.57827193 0.68032435 175% 110% abc123 9分钟前
0.52592766 0.55360963 175% 110% bhuz 11分钟前
0.53325145 0.53858397 175% 110% xeldal 21分钟前
0.53160863 0.66451079 175% 110% delegate-1.lafona 22分钟前
0.6005375 0.720645 175% 110% delegate.baozi 24分钟前
0.52974457 0.66218072 175% 110% delegate.freedom 25分钟前
0.60645839 0.61252296 175% 110% witness.yao 30分钟前
0.60702599 0.61309625 175% 110% delegate.ihashfury 31分钟前
0.488 0.61 175% 110% rnglab 33分钟前
0.60502316 0.61107338 175% 110% witness.still 34分钟前
0.52737709 0.53265086 175% 110% crazybit 37分钟前
0.522844 0.55036211 175% 110% verbaltech2 39分钟前
0.5323 0.56031579 175% 110% sahkan-bitshares 43分钟前
0.5305 0.55842105 175% 110% blckchnd 49分钟前
0.58914041 0.59503183 175% 110% roelandp 51分钟前
0.52055171 0.5479551 175% 110% fox 1小时前
0.5997671 0.60576477 175% 110% xn-delegate 1小时前
0.51790808 0.6473851 175% 110% harvey-xts 10小时前


Removed all BTS/CNY sources but btc38 as a temporary fix. I'll take a deeper look and probably move to btspice script later today.

Quote from: fav on August 11, 2017, 06:05:34 PM

Quote from: rnglab on August 11, 2017, 05:42:01 PM
"Bitshares network prevents 55M Usd Goxing through consensus"

Lets see...

BitShares dex prevents goxing by being a DEX.

Also. Less sensationalist though. " Bitshares DEX gathers consensus to prevent  <a fraudulent exchange> from Goxing 150M ."

Edit: Hopely just a: "Bitshares DEX helps to recover 150M from exchange's lost key"

"Bitshares network prevents 55M Usd Goxing through consensus"

Lets see...

Quote from: alt on August 11, 2017, 08:15:53 AM
I have introduce my architecture which  already used by btsbots.com

just fetch all transactions from witness_node, process all data, generate new data, save it to mongodb.
mongodb is the new backend, it can be expand with a slave node easy.

nodejs get all data from mongodb, it's just a very common nodejs web project, no blockchain tec need for UI developer.
you can hire any reactjs developer to improve/custom your wallet.

you can get the source for btsbots.com: https://github.com/pch957/btsbots-demo-2016
icowallet is a Chinese team who develop a new wallet based the new architecture: https://www.icowallet.net/
they  have their business plan, are funded with a ICO, and will open source their wallet in the future.

I appreciate all your contributions.
This is slowly but steadily going autonomous, more functional and bigger. Proving that building decentralized consensus can result more beneficial than working on controlled, more isolated environments seems to be the greatest challenge now.
I'm ok with forks too. In some cases faster consensus and more direct control may be needed, maybe just having more things in common between peers to make everything easier.
In any case,  having a truly decentralized network as an upstream backup, a global community with synergistic competition and collaboration,  I think most of us agree on its value.

Quote


I will continue contribute to the new architecture, but not as a worker, as a volunteer.

Wouldn't you accept the network to pay what you deserve for solving issues that the network needs to get solved? The network should try to keep you doing things that makes her more valuable.
Even if your business already benefits from your contributions, you are also benefiting the whole network, and that reward should 'buy time' from best and most committed developers to  gain expertise, go deeper and stay longer to satisfy the demands from this highly scalable network.

How without an organized development team? a clean road map and coordination?
This  means to me that at some point proxies should become an active part on development management . Proxies with the ability to identify and to agree on general priorities,  measuring when to delay or trade off partial interests in favor of the whole system, should become something required by most users when they turn to have higher expectations from their shares.
We need to reduce voter apathy and active development is very positive to grow engagement.

I'm not talking about specific proxies. with actual rules this is my ideal expectation from such a powerful role.

This network is one of the most fruitful social peer to peer experiences I have seen, lets find out how to let her grow strong enough to remain free.

Quote from: wmbutler on August 10, 2017, 06:10:55 PM
What if we formally modified the proposal to state that anyone in the community could claim an issue and work it for a bounty.

For example, we could attach a dollar value to each issue and members could submit a PR and be paid the bounty amount for each issue. This would open the process to anyone who had the necessary technical skills to resolve the issue? Would this strategy allow you, @bitcrab, to support the proposal?

EDIT:
In essence, this would turn the worker proposal into a UI development fund.

This attitude is remarkable to me.
What about including someone like @zahomu, to ensure that development is equally beneficial to all, e.g. translating github issues and communicating chinese  <==> english fundamentals when needed.

A complete solution would be to pair this worker proposal with a similar one to improve APIs performance.
@abit, would you accept a well paid worker to lead the development of a node plugin that records the most required data into a more efficient data structure?  please?

This is highly needed.

As far as I know, ChainSquad has no profits form the public testnet management, and it benefits BitShares as a whole. It's a fundamental for development, testing and for projects seeking for a platform to adopt.

On the other hand it's a relief for BitShares to have ChainSquad on charge of it, so I think worker proposals to have the testnet always up to date would be as fair as convenient for everyone.

We have to take some fundamental development decisions to properly feed back this growth, and to keep the platform ready to evolve and scale as needed.
Besides many (not yet prioritized) priorities, we have at least 4 different approaches to evaluate regarding EOS integration.


It's not easy to design a feature and write a BSIP to create a worker proposal, even worst with no clue about its chances to be accepted.
Then if downvoted those efforts are gone, without even knowing if it was rejected because of the asked budget, the feature itself or its priority.
Chances are devs getting discouraged to gather feedback again to improve the proposal or to create new ones.


If we don't set some mid/long term guidlines and a stable development budget, most Graphene devs will probably find better incentives just working with EOS instead of doing colaborative Graphene work for integration and sinergy, not to talk about self BitShares features.

EOS has already raised deep interest in many of our devs. Personally, I think in the short term we will need a core dev team with the hability to evaluate and socialize in a case by case basis the pros and cons between hardcoding a feature into BitShares or interacting with EOS

What I think we actually need as a priority, as a starting point to achieve further consensus regarding development and what not, is a way to improve on-chain polling.

The first feature that I'd suggest towards BitShares v2.1 is to add the hability (for lifetime members maybe?) to create polling workers from the Graphical Interface, and a dirty hack to show them just as polls in a separate tab.
Non ivasive notifications for new/unread polls may also help to rise engagement and vote participation.


On chain polls won't be decisive, but a good way to know what the majority thinks that needs to be done first, and how much would they let the network to invest on it.
Same for devs with new ideas, they would be able to find out if their proposals raise interest and if the budget would be accepted before creating a BSIP.


Hopely, the committee-account will become soon a diverse and active team with incentives ehough to follow development closely, but we really need a way to define immediate priorities before that happens.


I'd like to have a technical discussion about its viability and conveniency.

Prediction markets for decision making could be an option to, but probably harder to implement and to gain adoption in the short term.

hey good job sahkan

Rising the avaibility/performance of web wallets and API nodes on high load moments seems to be high priority.
Web wallets require certain degree of trust. witnesses are already trusted and audited.
Reliably producing blocks and feeds require similar infrastructure management, high availability and hardening skills (plus high load, more complex infraestructure, resources, and daemons to deal with).

It is a good way for a witness to show aptitudes while making a big contribution, and hopely earning something fair as a registrar.
Haven't stopped into the referral system so far. With your own faucet you become the default registrar/referer for account create/upgrade, if there's no LTM account (or enough funds?) present in the wallets that uses your node to interface with the blockchain?

Witnesses aside, If the above is true, couldn't we use committee or worker proposals as a temporal fix by choosing full nodes to be included in upcoming light-wallet and bitshares.org/wallet releases?
Whoud that be incentive enough to run public full nodes and web wallets without running a business nor marketing, just the required infrastructure?
Round robin selection could be an incentive for node performance and distribution in such a case.

Sorry for hijacking your thread! I'll paste this elsewhere if someone wants to talk about it.
You have my vote on your witness.

    bitcrab I appreciate your involvement and your wake-up shakes in here.
Becoming a witness just to understand what it means, to make wiser proxy, committee and business decisions with that knowledge (when there was still practically no reward at all),  demonstrates strong commitment.

I agree on that block reward needs to be reduced in the short term.


    Besides that, it seems to me that there is no common knowledge about what it means to have DPOS block producers (maybe even from some proxies and committee members). That's ok so far, as we are building and running disruptive, real time, resilient, top edge technology, which means a lot to learn and to be aware of, permanently.

The stage of BitShares becoming truly decentralized and autonomous, and thereby fully functional, took more time than what many wanted to wait for. When main dev/s moved to work on Steem or other projects, they left their research and development for the public domain, while reducing the concentration of stake.
Core development was almost paused for more than a year.

A financial blockchain that is safely mutable through consensus (by design), requires strong involvement from block and feed producers. When core development gets active, witnesses can't just automate, monitor, apply fixes, and be always up to date on markets, BitShares channels, and ready to jump from bed. That's not enough when we want new core features and certain fixes to be implemented.

I think this is why:
we can't expect cryptonomex to run live code tests anymore. But guess what? Yes, we can ask witnesses to do that for free.
With core features and fixes to be applied soon, devs and witnesses will need to work closer. 
I won't hardfork before staging on a distributed testnet anymore.

Graphene/BitShares release was vertiginous,  Dan's full control over its code let an enthusiastic group of witnesses to apply patches on their producing nodes on the fly. When new issues were introduced as a consequence, urgent fixes were ready just in minutes, mostly from Dan.

It is hard to replicate every BitShares aspect on a development environment. When new code breaks so meting on main net, specially when it comes to networking/consensus, there's usually no time for testing (or there's no need to if the network forks or goes down).
That can become in a desperate need to have as many witnesses as possible dropping everything else in their lifes to start iterating builds and debugging until the problem gets solved and network consensus is gathered again.

That only happened pretty close after graphene/BitShares release, we had almost no user base then.
And we don't want to rely on a single person (or just a few) to take care of the network now.

I encourage witnesses  and candidates to run nodes and APIs also on testnet.



    Because Dan announced leaving Steemit to work on a new blockchain just in time with the distributed stress test, it's difficult to measure the influence of those results in the price that started to rise again after a long time at the very same moment of the stress test . However we have much more precise information now after the tests, we have publicly proved some aspects that potential users should check when choosing a platform (like being the fastest blockchain).
There's a lot of tests that could be highly beneficial, or even needed on a regular basis.

Isn't it the professional path to follow? For how long would you trust a blockchain without a serious software release protocol?

Will the mayority of witnesses agree on providing infrastructure for public testnet and to coordinate hardforks there, run tests, gather information, analyze logs, build again if fixes are needed and iterating as many times as required before deploying changes on mainnet?
On top of what they already do? Without knowing if there will be any pay next week because of price movements, lack of consensus regarding block reward, or maybe even because of some arbitrary or misinformed whale or proxy down vote?

How would everyone perceive a financial platform that pays the bare minimum to the specialized technicians that they choose to keep it up and safe?




    If fairly paid, the witness job can serve as the main entrance for developers as well. Devs who aspire to work on BitShares have a steep learning curve. They can bring some tool as a way to show their skills, but a lot more is required to get a worker proposal approved. If voted as a witnesses, besides getting specialized very fast, they'll be economically encouraged to continue development (while being a good witness), either to gain reputation for further worker proposals or just to help keeping the witness voted in by bringing needed extra services.

I'd also take into consideration if and how having tempting block rewards boosted the network efect for other chains.



    As a short term way to (be able to) adjust block rewards consistently, I'd suggest defining the minimum required and provable witness infrastructure first, this way we could track expenses and update that budget based on chaging hardware requirements. On top of that we can agree on a fixed salary in USD, and a time lapse in which the change in the average salary in BTS should trigger a (still manual) block reward correction.

Some thoughts on provable witness infrastructure:
- main producer nodes both on main net and testnet. Seed nodes and public API nodes as needed. Those are already public-provable.
- At least one failover node, in a different location: missing to many blocks in a row can be interpreted as a lack of failover nodes or as running them on the same datacenter.
- Independent node/s to produce price feeds (also in a different location): if a witness stops publishing feeds and producing blocks at the same time there's most probably no independent price feeds node or they are in the same datacenter.

It shouldn't be difficult for a monitoring tool to highlight witnesses that stops feeding prices and producing blocks at the same time, nor to check seed and API nodes availability.
This approach would help stake holders and proxies to identify witnesses with inadecuate infraestructure (misuse of budget) sooner or later, while adding complementary metrics to price feeds accuracy and plain missed blocks.

I see no sense at all in proxies asking for hardware specifications and locations (or a fast response in an arbitrary thread) to determine who will be voted for witness. I hope there's no need to explain why at this point.
Best candidates should have a chance to produce blocks and feeds for an evaluating period, only then their aptitudes and commitment can be measured.



    For all this to work we may also need better proxy monitoring tools, so stakeholders can easily check historic participation and decisions taken by proxies, and update their votes when needed without doing a deep research on every proxy for each topic.

We have proxies mainly for two reasons, one is decentralization: holders with low stake and similar ideas can sum their voting weights through a proxy that represents them, and become influential along with bigger stake holders
The other reason is to counteract voter apathy. Regardless of their commitment, most users don't have the time, knowledge or updated information to actively vote on every decision. But paradoxically, at the moment it seems much easier to look into every new proposal and read its specific documentation to decide what to vote, than to periodically dig into the forum for reports from each proxy to have a general idea about who represents you better.
Cryptofresh ballot charts are very important, but centralized historic information about what proxies have voted is the only way for users to easily check their behavior, remain informed and able update proxies dynamically in front of big decisions, as intended.



    Sorry for the wall of text. I'll edit with better formating later. It started as a short comment and ended up with this.
I've  been a witness since graphene release, not for the block reward (just enough to pay the bills) nor speculating on the price ( way easier to buy cheap). I assumed the responsibility for this role because I love the technology and its potential to disrupt many things.

The potential of this role to become a real job, being paid to work on something I advocate, is actually an incentive. But this beast is growing really fast and getting harder to feed. I don't like to do things halfway, it seems it will be demanding a lot more time soon, and I don't have much to spare. In order not to risk my real and stable incomes I should decide whether to maintain this position, based on what the consensus determines regarding the value of this work. Either way I'll stay here as much as I can, you won't get rid of me so easily  :P

rnglab started publishing RUBLE price, thanks for the confidence.
I'll add more feed sources as soon as I can.

Good luck with this project, let me know if I you need something else.