openledger-dc has revised and updated feeds, according to real prices. Could you consider voting back?

Quote from: xeroc on December 26, 2018, 01:54:14 PM

Quote from: alt on December 26, 2018, 11:32:54 AM
thanks.
I don't want to waste time, so if you can contact xeroc admit to vote out those witness still give wrong feed price tomorrow.
I will support reduce MSSR soon.

Sorry for the late response. We have Christmas season in Europe and plenty of appointments with family and friends.
I will look into this an moment.

edit:
I just removed my vote from witnesses xn-delegate, roelandp, and xman as they are feeding CNY prices that are more than 8% off.
gdex-witness promised to fix their feed script shortly.
I have also removed openledger-dc since they feed a USD price that is almost 20% off.

Quote from: xeroc on January 02, 2018, 02:15:28 PM
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.

openledger-dc

wss://bitshares.openledger.info/ws (Germany)
wss://openledger.hk/ws (Singapore)

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.

Howdy
1) Only from accounts they refer and not more than 80% of fees, they pay. 20% always go to network.
2) BitShares.org and OpenLedger.io are only entry points (front-end or client, actually) to the same system. It doesn't matter, which one you're using in case of OBITS distribution. You hold your funds in account inside of BitShares BLOCKCHAIN, so no matter how do u like to access your account: either using desktop/web (like openledger.io or bitshares.org) client, or using console. You may even hold OBITS in LTM account and you won't lose anything.

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

Absolutely support Fav's initiative for making entry point more decentralized. Our team is always ready to assist and consult anyone, going to deploy public node. Just pm me or connect with our team in any of tm channels.

In any case, everyone always may rely on infrastructure of public nodes built by OpenLedger without any limitations. Feel free to use any of our aliases with or without adding "/ws" (for web sockets):
bitshares.openledger.info
dex.openledger.info
eu.openledger.info
openledger.co
openledger.io
openledger.hk

Current total load is around 20% of whole capacity. Most of nodes are located in EU.

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.

Quote from: JonnyBitcoin on November 09, 2017, 03:43:28 PM
This is how I think a trustless BTC token could work on BitShares:
Multisig bitcoin wallets that include the witnesses and possibly the BTC depositor with a designated time locked withdrawal every 3 months.

This essentially very similar to the sidechain solution proposed by http://www.drivechain.info/

The biggest problem i see, is that list of the witnesses, in theory, cannot be constant, while when we create multisig in bitcoin, every involved witness will get own key from the beginning and wallet cannot be changed later (we're researching this question, maybe anyb knows if it's possible?). I can assume multisig scheme 5-8/16, with potential reserve. But still, if significant number of witnesses will stop their activity by any reason, we will have to create new BTC wallet with a new list of signers.

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.

Dear Digital Lucifer, I'm glad to see your activity and so loud words. The whole system will be happy when you will deliver any quality solution or even product on BitShares network.

The main idea of the poll and topic is preparation before creating RnD workgroup and getting feedback from community, about wishes and needs. Any specific plan or project will appear only in the end of 2nd stage, as well as team of experienced developers will be combined in the team and announced. It's not a wise approach to start development, before goals and aims are clear to all parties. Listed ideas were created not only because "it would be cool to have this on BitShares", but also, because we have 2 teams (business analytics and developers) agreed, that in the end, solutions like these are technically possible and demanded. They will never seem easy and so obvious, as presented, so it's not surprise for me, that your reaction is negative mostly.
I'm also not a forum-speaker and don't see sense in debating right now, before we've spent time on researching and tried prototyping. I believe, that you're experienced enough and can bring a lot of profit in ecosystem, so will look attentively on your development process and github account, for possible useful learning.

Quote from: pc
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.

Quote from: pc
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.

Quote from: wdfh
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.

Quote from: bitcrab
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.

Quote from: karnal
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.

Dear community. Due to my mistake, I've done poll, without possibility to change vote, while announced possibility to add new options for voting during discussion. Sincerely apologize for inconvenience, but seems the only way to get fair final decision is creating new poll with revoting (option with trustless gateway is included). Voting in current thread will be frozen and discussion is closed.
We invite you all to a new thread - follow next link:
https://bitsharestalk.org/index.php/topic,25187.0.html

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: [email protected]
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: [email protected]
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!

Quote from: Frodo on October 23, 2017, 01:58:34 PM
After reading abit's post I realize that I misread the proposal. I was indeed thinking of sidechains for a trustless gateway and not atomic swaps. :-[

So, simply change your vote)