Your feeds for CNY were among those that I deemed inaccurate .. chinese community members approached me to tighten up the peg .. all I can do is disapprove workers that are farer away from the actualy price than others ...
If you fix your feeds you can get voted back.

Hello, dear Fabian. From the last time, you've checked our feeds, we made some major updates of feeds scripts, reconsidered reliable sources of prices, so we have much more objective feeds states, than previously. Could you please consider voting again for our witness?
Thanks in advance.

Hello, dear xeroc.
We've noticed, that you have unvoted openledger-dc witness. Came here, to check the reason, as well, as checked witness chat and didn't find any explanations. During the last 1.5y our witness was one of the most stable and its support was quite responsive, so is there some serious reasons for taking voice back? At the same time 3 of bottom active witnesses are missing blocks and still active.
Thanks in advance.

Great work and contribution in BitShares. Keep it that way!
Little tips from OpenLedger team are on the way.

Howdy, everyone.
Today, I’m happy to update information related with our research process. Due to very pressure days, we couldn’t pay full time on RnD direction, so date of result publishing has been moved slighly. Unfortunately, for today, we’ve got results, which showing, that making decentralized gateway (according to vote results) seems inexpedient. You can see (and comment) full explanation below.

The conception.
This one is based on creating multisig wallets (for example, 8 signs required from 19 current witness) on Bitshares and destination blockchain (ETH and BTC, as reviewed ones), where signers are witnesses with their own private keys. After wallets setting up, witness node software will be updated, what will make possible, to monitor outside blockchain also (BTC, as example). In case of noticing income transaction on dedicated address from wallet (every user in BitShares will get own address and will be attached to it – this way OL gateway is working already), the witness independently of others, checks transaction and broadcast own verdict, if this tx is real and confirmed by network. When 8 same verdicts will be accepted, the witness, who has noticed tx first will create transfer of OPEN.BTC to customer, and broadcast tx to the rest of witnesses – they should finalize tx with their signs. In case of withdrawal, each witness should check, if funds have come from user to gateway account and necessary BTC address is pointed, then they initiate BTC transfer in its blockchain, with getting required number of signs by the rest of witnesses.

The problems.
We have discovered possibilities of realization in ETH and BTC blockchain and faced some problems.
There are 2 in BTC:
1) In case of changing set of signers, very expensive tx should be executed (affect every single address with funds for changing access condition) and fees for that tx will be paid from funds of customers. It means, that if anything will threaten to possibility of signing by initial list of involved witnesses (key losts, voting out, leaving bitshares, own disagreement) we will have to pay quite much fees, for initiating new set of signers. We’re still looking for solutions, allowing to set up flexible key management and will be appreciate for any useful info in this area.

2) Every transaction from multisig wallet costs more than from single sign wallet. Tx will require 2-3 times more fees on average. These payments will be also charged to customers. For instance, current gateway is 0.0003 BTC, what is around 3$; with making multisig wallet fees will be around 10$, what makes transactions with amount less than 30-50$ senseless.

The problem in ETH is only one:
1) It’s not possible to generate thousands of address in multisig smart contract. That makes gateway realization impossible. We could, actually, use meta details in every payment for separating payments, but access to optional fields in transfer exists only in full-functional wallets. People from exchanges will be not able to send funds directly.

The alternatives.
For now, the best alternative, for trustless gateway is Atomic Swap technology.
But there are two conceptual problems of solution:
1) AS is slow. It’s quite slow. You should wait confirmation of 2nd blockchain (actually, require confirmation of both blockchains, but mostly, any of BC is slower than BTS). So, it doesn’t present market as it. 
2) Actually AS tx doesn’t affect the BitShares growth/cap/development, cause BTC coins don’t somehow come to BitShares DEX (in contrast with Open.BTC, where income BTC create new market). Simply, BTS holder leaving BitShares, while BTC holder comes to BTS and doesn’t bring anything valuable. It’s swap as it, but not trading. We follow updates on altcoin.io, where guys promise to implement fully working DEX, based on AS, but until now, viability of enterprise solution is doubtful.

Some kind of similar conception was described by Fav and discussed there: https://github.com/bitshares/bitshares-ui/issues/657 and we’re thinking, how to use that in max convenient way.

Due to low potential of clear Atomic Swaps conception (in other words - until it isn’t found yet), our RnD team has decided to look attentively into EVM for BitShares.
We already playing with EVM in EOS testnet and comparing to ETH. We can say already now, that implementing EVM will not affect network speed in cases of current transaction (smart contract instances will be presented as separated transaction and VM will be involved only when it needed, but not with every block). The questions we’re working with now are economical. BitShares concept is quite good in many questions, especially in economical, so it require much attention, to keep everything strong as it now.

Thanks everybody, who has taken part with comments and messages (some people connected in private) – we appreciate very much. Going to continue researching. I’m quite sure, that some useful mechanisms will be presented very soon (but only after full understanding of possibility worker will be presented). Will keep everybody updated about progress and result.

Hello everyone and thanks for your active participation. For now, poll is locked.
As we can see for today, the most preferable options, chosen by community, are Trustless gateway and ACCT transactions (with slight difference in total votes). Both options are very similar to each other and probably, they could be combined in final solution, but our main goal, according to will of the community, is deployment of decentralized gateway in the end.
From tomorrow our team will start researching and solution prototyping, and during next 7-10 days (till 20 Nov max) will prepare and announce detailed worker for community. We’re opened for any kind of collaboration, so, if you have ideas or proposals, feel free to suggest me personally or to our team through this thread.
Regards, OpenLedger Team.

I'm very sceptic about porting a VM to BTS. I believe that in the end it means that we have to sacrifice our speed, because the problem here is that VMs simply don't scale. We're still one of the fastest blockchains out there - sacrificing that for something that in the end would be no better than ETH would be a very bad move IMO.

In our vision to implement VM in parallel and use (call) it only for particular transactions and assets. So, VM integration will expand possibilities on BitShares, but will not limit current functionality.

Not sure if I understand what you mean - are we talking about Atomic Cross--Chain Trading (ACCT)?

In that case I think that this would be a great feature to have. It could provide an actual trustless gateway (as opposed to a delegate-controlled sidechain/gateway) between BTC and bitBTC, and most altcoins out there. The speed of such trades is mostly determined by the speed of the other chain (read: slow), which is why I think that people wouldn't use it for everyday trading but more to move funds into and out of our chain. For everyday trading they would use out built-in high-speed DEX.

It could also be implemented with relatively little effort (read: low cost) I think.

Thanks for remark, added link clarifying sense of ACCT in poll option. For the beginning, we consider ACCT as trusted way to enter into BitShares from outside (other blockchain), bypassing exchanges (involving 3rd parties and regulations). It's actual to whales and allow do not drop price, using exchange. After ACCT implementation, we will look into creating ACCT market, connecting offers from different blockchains, or at least, including BTS ones.

I'd like to see the option to trade all alt coins on Bitshares, then we would become the go to DEX for any trade. Is this possible?

We're working on this already, but it's not related with RnD.  We're also planning to let people choose a list of currencies, which will be connected. So, follow up our newsletters and forum threads.

I feel what we are talking about are:

1. to which direction should Bitshares evolve while the other blockchains evolve rapidly?

2. how to implement the new change and fund the development?

after go through this thread and some relevant posts, I tend to agree the ideas come from https://steemit.com/bitshares/@slavix/beos-bitshares-on-eos-alternative-proposal-for-bitshares-3-0 :  make an EOS clone with BTS as a base token.

maybe smart contracts and VM are the most important factors for the next step evolution of Bitshares, however, EVM is designed specially on Ethereum blockchain, I don't think it can be smoothly integrated into Bitshares blockchain, the obvious difference between the 2 blockchains base will make this process tough, so why not adopt EOS VM, which is also built on Graphene base, instead in this scenario?

thinking continully, if we need to adopt most of the good features introduced by EOS, why not just clone EOS and make BTS the base token? and realize the current Bitshares features as native smart contracts on BEOS (Bitshares on EOS)

to avoid the potential risks and fit the possibility that there is no consensus from community, one selection is to hard fork BTS to 2 parts, one classical BTS and one BEOS, like BTC and BCC, then each one can still prefer what he likes most and the better one will emerge with time elapse.

A worker proposal can be created to fund the development and implementation of this, after a skilled team is organized.

As you got it right, the main goal of current Project is evolving of current BitShares. EOS is amazing project and we constantly watch in this, but it's still raw as product, while launch is planned for the summer of 2018. From our point of view, until alpha/beta testing of completely done platform, taking EOS features in BitShares is too prematurely. But given the fact, that 3 members already supported the idea of EOS implementation, we will think (and we're opened for particular proposals), what is possible to suggest as solution.

About VM proposal, we didn't decide yet exactly which one to implement (will do during research stage), but there two significant reasons, why EVM from our point of view is more preferable for now:
1) Legacy. There are many developers already create SContracts and a lot of sources published, so it will be easy for people, to start/continue making their business on BitShares.
2) Stability. EVM is well-tested already for more than years and it's trusted by business, while EOS is in the beginning of its way.

Your original thread inspired me to write this - https://steemit.com/cryptocurrency/@karnal/privacy-in-the-digital-age

Dear Karnal, we respect your opinion and your undisguised interest to Monero solution (and thanks for link to thread), but we discuss here specific solutions and maybe you could suggest anything, we can add into BitShares to meet your expectations.

Hello and welcome to the updated poll (with possibility to change vote), related with OpenLedger team's proposal directed on making research and further features deployment on the BitShares network.


Detailed text of proposal:
(Previous discussion is available at: https://bitsharestalk.org/index.php/topic,25179.15.html)

Dear Community Members,
Over the past two years, OpenLedger have played an important role in the development and establishment of the BitShares blockchain. Our high-qualified team of developers have been involved in dozens of third-party projects, acting as consultants and direct executors, continuously interacting with the community, developers, and traders to develop their products on the BitShares ecosystem.
Believing in the limitless possibilities of BitShares technology, it is OpenLedger’s vision to build projects for all uses, and truly develop ‘Blockchain as a Service’ (BaaS).

With a varied and rich experience in development using Graphene technology, as well as unmatched experience in working with Bitcoin, Ethereum, NXT, Omni, Waves blockchains, the key goal for the OpenLedger team will be to research ongoing cryptocurrency technological trends, as well as create new features, with subsequent implementation into the BitShares blockchain.
OpenLedger sincerely believe that BitShares is significantly underrated, from both economic and technological points of view in comparison to other crypto-platforms.

The strategic goal of OpenLedger is to create such a platform which will outpace the competition and allow for the creation of a truly decentralized and trusted digital economy. To achieve these goals, we would like to rely not only on our own views and ideas, but also on yours - the community opinion - and we invite you to like to take part and join us in this next stage of Bitshares’ evolution.

For the first stage of our mission, we want the community to vote for one, or more, of the following proposed ideas:

1) Implementing a virtual machine (like Ethereum’s’ Virtual Machine) into Graphene.
Once created, it will allow each user to produce smart contracts that work with assets and Smartcoins. The mechanisms of ICOs, trusted systems for the payments of dividends, and hosting various games/shares/lotteries, are examples of possible, future business cases.
By combining the strengths of the two platforms (the flexibility of ETH Smartcontracts and the speed/throughput of BitShares), they will get the symbiosis of the advantages and eliminate the weaknesses of these two platforms.

2) Implementation of the Atomic Swap mechanism.
Such a mechanism will allow the exchange of funds from one blockchain (Bitshares) to another (bitcoin, as the first), without any participation from third parties. In this case, BTS, MPA (bitUSD), and UIA can be used as bitshares funds.
Given the fact that there is only one real decentralized exchange, the ability to enter it from other blockchains, without any risks (technical and regulatory), and the participation of third parties (gateways), creates huge economic potential for the platform and the cryptocurrency economy.

3) Creation of Fee Backed Asset.
The idea of creating the FBA was proposed back in 2015, but was never implemented. (http://docs.bitshares.org/bitshares/user/fba.html)

In addition to implementing the mechanisms for automatic dividends distribution, it is proposed to discuss additional options for managing fees (the ability to impose payments on the issuer, change the fee rules for creating/closing the order, so that the person who closed the order pays 100% of the fees or 50/50).


We are hungry for constructive dialogue and invite all of you in the community to join us in this quest.
Our menu of ideas may not be complete and if a community member puts forward an idea proposing the implementation of an unlisted, and vital development, we will add this item to the  list (your vote can be changed throughout the voting process).

Phase two will include the tabulation process.
The results will be summed up either on November 9 (in the case of clear and straight voting), or on November 30 (if there will be active discussions or disputes). Whatever the positive outcome, we will prepare a detailed roadmap, which will outline the steps, deadlines, project participants, and financial calculations, which will in turn be presented to the community.

The third stage will be a full deployment on the test network and the environment, with the testing process performed by the team and any interested parties within the community.
Following this, we will start the integration into working nodes. If the changes are significant, we will perform the hard fork, provided that all witnesses agree.

At OpenLedger we believe that true progress and mass adoption of blockchain technology will only come from working together. Collaboration is the new tool for global progress and it should be encouraged at every level, so please join us as we explore the future of the BitShares blockchain.


The OpenLedger Development Teams behind this project are:

Key Management Team:

Ivan – The Initiator and Supervisor of this project, Ivan is deeply involved in strategic planning, research and communications. He has led the OpenLedger development from the first moments of its existence.
Email: ivan@openledger.io
LinkedIn: https://www.linkedin.com/in/ivan-bo-b7421a151/

Mikhail – As the Head of Project, Michael is an experienced Release and Project Manager. Before crypto, he was the head of the management department in Wargaming Inc. (World of Tanks/Warships/Planes creator).
Email: mikhail.makaruk@openledger.io
LinkedIn: https://www.linkedin.com/in/mikhail-makaruk-2022714a/

Key development team:

Alex – The Guardian of Project Servers, Alex is am experienced DevOps and Engineer, controlling more than 20 servers the world over. He has built a unique network of pools with gateways, nodes and wallets, and manages security, resistance and stability of server infrastructures.

Anton – The Team Lead of Project Development, Anthony is a professional Engineer, with 12 years of programming experience (C++, Python, Ruby, JS), dozens of executed projects (four of them during the previous year in the blockchain industry) and limitless enthusiasm. Antony coordinates the work of dev groups in different directions (core, gateway, etc.).

The list of connected developers will be formed closer to the beginning of the approved project.

So, make your choice and feel free to comment!