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

Pages: [1] 2
1
I would like to hear more about how BitShares can benefit from connecting to the EVM.  What sort of DAPPs do you think can be facilitated on the BTS blockchain with this development?
Valid question, John! I have mentioned some of them in my original post, but generally speaking, there may be any of them - just look at Ethereum and EOS, any of smart contract that is available there can be implemented on Bitshares when the solution is active. Considering that Bitshares already have DEX and stable coins, building DApps on top of it may be more reasonable than using Ethereum or EOS. Low fees and fast operation are another reasons to select Bitshares for your business app.

Ultimately I can see this as being a way to reinvigorate the perception of BitShares.  If you're reading this you are likely aware of the vast capability of the BTS blockchain.  However, it has become abundantly clear that the term 'smart contract' itself has a social currency all of its own and getting exposure to that may be rewarding for stakeholders.
This is totally inline with our vision. This solution is intended to expand adoption of Bitshares, attract more businesses and users, allow stakeholders to benefit.

2

I tend to think BitShares needs to A) define target audiences and B) list the features and functionality (in priority order) required for each audience identified, including completed, in development and what's next. Yes, that's marketing, but unless we can all point to a document or source that embodies these things BitShares will bounce from one pinball bumper to the next in reaction to the community concern of the day. We won't be focused and progress will be what it is now.

How does the upcoming HTLC functionality affect this discussion? Will you utilize HTLC to accomplish this?

Thanks a lot for your interest, Thom! I would like to highlight, this solution is not about an interface from Bitshares to any other blockchain (like Ether or EOS), this is Bitshares core update that allows to run custom smart contracts inside Bitshares blockchain. I do agree every blockchain shall has it target audience and designation, but as the technology evolves, some of the functionality is becoming mandatory for a decent ecosystem. I see no reason for Bitshares stay away from the progress just because other networks have custom smart contracts already implemented. Bitshares needs this feature as well. HTLC is another nice feature to have, but has no direct connection to the proposed solution. 

3
Dear BitShares community members,
 
While the best minds of the community are doing their best to find new options to expand BitShares adoption worldwide and add more business use cases, the OpenLedger team just cannot stand still.

We’re proud of our previous work, and now we have come up with another big feature that can bring thousands of businesses to the BitShares ecosystem: on-chain smart contracts.

We all know that BitShares is the nearest thing to a perfect blockchain — fast, secure and cost effective, it also provides many valuable features to its users: UIAs, MPAs, DEX, multi-signature accounts, voting. Other valuable standard features are being constantly implemented.

Still, when it comes to business operations, you often find yourself limited by the standard functionality and are not able to implement your custom business logic. Of course, you can create a script on your server and execute BitShares operations in auto mode, but this is not what a true DApp needs. You need on-chain logic executed inside the consensus.

Smart contracts unleash a unique ability for counterparties to operate in a trustless environment and add more traction to BitShares perfect products like MPAs, allowing people to build a complex business logic operating price stable currencies in a decentralized environment.

Numerous business cases can be implemented: scheduled and ongoing (aka token streams) payments, insurance contracts, sophisticated financial products, funds escrow and vesting, crowdfunding automation and many others.

The examples of blockchains like Ethereum and EOS show us that smart contracts and DApps are here to stay and bring with them a new type of economy and a new way of doing business: DAOs, Decentralized Autonomous Organizations. BitShares, of course, will be a part of this bright future.

Although EOS is the most modern technology at the moment, it is still in its childhood and it is probably too early to be considered a trusted operation environment.

On the other hand, Ethereum Virtual Machine has proven its ability to operate, with thousands of smart contracts already implemented and a huge army of developers ready to implement new DApps. This is the reason we selected Ethereum VM to be integrated into BitShares core and allow on-chain smart contracts to be executed.

OpenLedger team has spent several month working on the solution and at this time we believe it is mature enough to be presented to the public!

Here you can find the solution description: https://drive.google.com/file/d/1NZHPojlyNGaGbAR6L9YmvjJu7_AAXDoY/view?usp=sharing

There has already been a testnet operating for several months, where you can run your smart contracts in Btishares environment. See details here: https://drive.google.com/file/d/1Pfe246M82gPfBF3zbabkYEUazjV-k3kj/view?usp=sharing

There is a technical discussion in GitHub: https://github.com/bitshares/bitshares-core/issues/1182
 
 
We are convinced that this solution can bring many new users to the ecosystem, stimulate its usage and adoption across business environments all over the world, and raise BTS demand and therefore price. 

However, community members have raised concerns, so we would like to start a public discussion of this opportunity and decide if it should be processed as a new WP.
 
Here are some of the concerns raised by BitShares members:

1. BitShares was not originally designed to run custom smart contracts, this is something totally different from the original idea.
==================================
Well, when BitShares were originally started in 2015, custom smart contracts were something extremely new and were not in the scope of the ecosystem. Nowadays, using on-chain scripts and DApps is a mainstream trend in the blockchain industry and there is no reason for BitShares to stay away from it.
 
2. Custom smart contracts may spam, contaminate and flood the blockchain, make it slow and heavy.
==================================
With the implementation of an appropriate fee management process, no spam contract is allowed — any operation is paid, raising BTS demand and price. The blockchain is meant to be used, this is what it was created for, so it doesn’t make sense to limit its usage.

Of course, the service must be well paid, and the BitShares committee will keep an eye on the fee schedule to regulate smart contracts fees and make sure they pay reasonable compensation to block producers.

According to many stress tests, BitShares is able to cope with at least 4,000 TPS, and at the moment the average number of transactions is around 20 TPS, so the blockchain seems to be massively underutilized and still has huge unused capacity.
 
3. There may be fraudulent or illegal contracts running in the network.
===================================
Unfortunately, this is true for any public blockchain and there is no sure remedy against it. Even at the moment there are scam coins and MPAs with 100% market fees operating and trading in BitShares. Implementation of VM changes nothing in this area.   


We do encourage public discussion of this proposal, your feedback is extremely welcomed!

4
Stakeholder Proposals / Re: Proxy: xeroc
« on: October 11, 2018, 01:19:34 pm »
Just to be totally clear, do I understand correctly that you evaluate risk of undercollateralization as very low?
I do believe undercollatarlization must be avoided at all costs!
But I also realize that
a) black swan isn't as bad as world armageddon, but in fact can be recovered through BSIP18 and
b) the risk of *OVER-ALL* undercollateralization is much smaller than the risk of an individual position going below 100% collateral.

Point b) is very crucial to understand and while I do not believe we should bail out individual short positions with too little collateral (but instead would rather penalize
them), I do see a fine line between risking the entire asset through global settlement just because of a single position being undercollateralized and temporarily tune
price feeds to potentially "hide" a few undercollateralized positions (that will have a margin call that can be filled!).

Again, to me, this is a short-term solution and I would prefer any undercollateralization to be *obvisous* and *transparent*, but we first need to fix the backend to provide us
with the necessary means to get there. In the mean time, plenty of discussion is being done to figure out the "how"

I've got your point, thanks a lot!

5
General Discussion / Re: Announcement on BSIP42 relevant actions
« on: October 11, 2018, 07:51:45 am »
bitUSD/CNY face chronic shortages partially because it is expensive to hold the .75 x of surplus collateral.  Widgets that are expensive get supplied in lower quantity.

I have brought the idea in another branch, but would like to raise it one more time in this discussion. Although I'm not fond of the way BSIP42 was pushed, I agree that smart coins shall be enhanced to foster mass adoption. IMO there should be more incentive for people to borrow an MPA.
How about adding one more incentive to those who takes the risk? MPA generally is a good service/product, it has big demand. And therefore it can generate revenue stream (e.g. market fees). IMO it would be nice if those who take the risk and support (borrow) MPA shall have a cut from the revenue. To avoid passive yield harvesting, the borrower shall release borrowed MPA to the open market:
1. An MPA owner specifies market fee portion he would like to share with borrowers.
2. A user borrows the MPA providing the collateral.
3. To receive the cut of the MPA market fees, the user has to place market sell order on MPA:Collateral asset (e.g. bitUSD:BTS) market.
4. As the MPA is being bought and sold by other users, market fee goes to the MPA's owner vesting balance, particular part of it (as specified in 1st step) is proportionally sharedropped to all borrowers who has executed step 3.

6
Stakeholder Proposals / Re: Proxy: xeroc
« on: October 11, 2018, 07:36:52 am »
With those things in mind, I believe there is more value in keeping BSIP42 for now than to ditch it away
without replacement.

Thanks a lot for the elaboration, Fabian!
Just to be totally clear, do I understand correctly that you evaluate risk of undercollateralization as very low?

7
Stakeholder Proposals / Re: Proxy: xeroc
« on: October 09, 2018, 10:08:32 am »
Dear Xeroc, could you please clarify you point here? What is the reason for you to not unvote those witnesses who feed updated prices to bitUSD?
1. You believe applying BSIP42 is safe for bitUSD.
2. You have concerns regarding BSIP42 applied to bitUSD, but you don't want or afraid to make a decision and take actions.
3. Any other?

Thank you very much in advance!

8
Stakeholder Proposals / Re: BSIP22
« on: October 08, 2018, 10:23:36 am »
I have a big concern, if implementation of this BSIP will put the network into hands of major stakeholders. Obviously, most of the users are not interested in things like voting, politics, etc - they just use the service. This means that as soon as those votes will decay, we end up with only major stakeholders (having big amount of BTS) are actually voting. This may kill decentralization (which is quite weak even now), and turn Bitshares into private blockchain, owned by several major whales.   

9
Does the above analysis make sense to you?  We can concentrate our collective efforts on supply side solutions if so.

I would mostly agree with the analysis. To go further regarding the supply side, IMO people are not motivated enough to create (borrow) MPAs because the risk being margin called is quite high in volatile/bear market as of now.
How about adding one more incentive to those who takes the risk? As mentioned above, MPA is a good service/product, it has big demand. And therefore it can generate revenue stream (e.g. market fees). IMO it would be nice if those who take the risk and support (borrow) MPA shall have a cut from the revenue. To avoid passive yield harvesting, the borrower shall release borrowed MPA to the open market:
1. An MPA owner specifies market fee portion he would like to share with borrowers.
2. A user borrows the MPA providing the collateral (this may be BTS or any other MPA or UIA, as specified in the MPA collateral settings).
3. To receive the cut of the MPA market fees, the user has to place market sell order on MPA:Collateral asset (e.g. bitUSD:BTS) market.
4. As the MPA is being bought and sold by other users, market fee goes to the MPA's owner vesting balance, particular part of it (as specified in 1st step) is proportionally sharedropped to all borrowers who has executed step 3.

10
As a witness I would like to suggest add a "Witness Key" to update signing key and publish price feed only.

Thanks for your input, Bangzi. Could you please elaborate more, what is the purpose and the logic behind it?

11

Some implementation concerns/details:

1. the user account is a multi-sig account, e.g. 2/4, one key in a hot wallet, one key in cold storage, one key controlled by a trusted 3rd party, one key on a special device;
2. every time when creating a transaction with the hot wallet, it adds a special ID hash into it, for example, set it into a custom operation. In this process, a proposal can be used;
3. The ID hash should be different for every transaction (a one-time key). For example, the user have a secret phrase only known by himself or probably shares with the trusted 3rd party, can be "mysecret123", when crafting the transaction (with the hot wallet), the wallet generates a random number, hash the phase plus the random number, put the random number and the hash in a custom operation;
4. the 3rd party or the special device knows the phase, so can check whether the transaction is proposed by the real user, then add one more signature automatically or not.

Actually this approach doesn't need to change anything in core, but all can be done in UI. The hard thing is how to make it noob friendly.

Thank you very much for your input, Abit!
The original idea was not to sign every transaction, because this won't work for traders. Once a device is "authorized", all further transactions coming from it are auto signed. The exact "device tagging" mechanizm may vary and your approach may also be implemented. Still, we believe it is not client app to tag the transaction, because it may be compromised. It shall be done on a node IMO. Anyhow, this is what investigation phase is for - assess different options and select the best one.
 

12
Thanks a lot for your feedback, Fabian!

I, too, support efforts to bring more security to the blockchain.
The costs for 50k$ for specifications and research is somewhat difficult to understand given that
many community contributors already have a list of features that overlap 80% with your desires.
At this time I am only aware of proposal from Stefan about custom active permissions, and still it needs more technical investigation. Could you please advise, what other features you have on your mind?

I would like to kindly request that the Openledger development team gets in contact with the
bitshares-core development to discuss which specs already exist or are near completion, rather
than duplicate efforts.
Sure, this is what we are going to do.

Quote
Further, I have made contact with the developer of Scatter already and he would love to help
integrate BitShares into Scatter after his refactoring. So, I would rather get things started with
the existing foundations of scatter than re-invent the wheel.
It may be the good option, but there are some concerns as well.
I had a closer look at Scatter and here is this app is compared to our proposal IMO:
- Scatter is one wallet per device for many keys for many blockchains, while our app shall be able to handle many wallets for one blockchain, each protected with a separate password.
- Scatter is not able to show accounts and keys relationships (e.g. multisigs, accounts hierarchy, etc).
- Scatter can't generate new Bitshares keys for you.
- Scatter does not have auto sign functionality.
- Scatter does not have blockchain listener and notifications mechanizm
And finally, Scatter is an independent app. Today it is opensource, but we have no idea if it will be opensource in a year. We also have to rely on the app owner and align to his app roadmap. Being integrated into Scatter is nice, but we believe we shall also have a separate Bitshares dedicated open source app. 

Quote
Last but not least, I would like to iterate over the existance of a Proof-Of-Concept implementation
for Steem/Graphene for the original Trezor. Specs are more or less complete and we could go into
implementations any time there is funding and human resources that support development.
Nice option, but same concerns as for Scatter.

Quote
Finally, I much enjoyed reading this proposal. OpenLedger established itself long ago as a solid pillar
in the BitShares ecosystem. Glad to see your desire to give back to the community.

Thanks a lot, Fabian! Your opinion is extremely important and your contribution to Bitshares can't be overestimated.

13
Thanks a lot Milos for your feedback!
Please see my comments below.

Dear Stefan, it seems we are very close in terms of the security approach and specific features implementation. We launched the worker as it is, but also would like to get in touch with BBF to find the best ways to deliver. If needed, we will create another worker to implement the approach that works best for all parties.

I would be supporting any contribution to a Core Team Worker with funds designed for integrations/developments as these are, and I would be giving my vote to the new worker when all steps mentioned are done and confirmed by all parties.
Awesome! We will do our best to be integrated into Core Team Worker.


The idea is to make a node to generate the device id and store it along with the transaction, so a client has nothing to do with that. 
Ok, so that would basically be some kind of hashing of user given values (e.g. MAC adress or IP, some kind of hardware hash etc.). Sending that information to the node (server) brings aspects of user identification and anonymity in play. Question in my head: Is there a way to tighten security without compromising identity?

I would not be supportive towards centralized server that will host all of that private information from a user/client when we don't even have basic KYC form. It's creating another security risk plus illegally compromising privacy information of individual without previous signed agreement to it. E.g. "Terms of Use" thick box with defined legal obligations and limits of the service, clearly stating which information is being obtained, how is being stored and what would happen if it gets compromised. Everything would be in a need to be legally defined, and each user has agreed to it during registration of his account, which still brings us back how we would process all accounts already created without it and as mentioned how it would affect all that anonymity hype with account creation we currently present ?

Thanks in advance for feedback and will be following up on communication progress and new worker.

Cheers
It seems to me that in the worker text we were not specific enough and this causes some misunderstanding. Let me try to provide more detailed workflow, I do hope this will make the idea more clear.
1. A User has an account with 2 Active keys.
2. He submits a "device tagged" transaction to a node, signed with 1st Active key.
3. The node takes user's device ID (e.g. hashed IP) and stores along with transaction. There is no way to guess IP knowing the hash, so we don't store any private information.
4. On another device (e.g. mobile) the user sees that a transaction with specific ID has been submitted. He know he has submitted this transaction on another device, so the ID attached to the transaction must be "safe". Now he can auto approve all transactions having this ID.

With this approach we do not store any private info and do not violate user's anonymity, we just allow him to identify which transactions were created by him from another device, by tagging them with unique device ID.

14

I appreciate that you are collecting feedback like mentioned in your initial post. I just noticed that the worker proposal has already been created, leaving no margin for alteration in terms of its approach. I personally would have loved explicit collaboration of the UI and core worker to include OpenLedger into the community development. Disclaimer: I don't carry any significant voting or proxy weight. I am part of the BitShares UI team and managing the infrastructure worker that is done by Blockchain Projects BV.

Dear Stefan, it seems we are very close in terms of the security approach and specific features implementation. We launched the worker as it is, but also would like to get in touch with BBF to find the best ways to deliver. If needed, we will create another worker to implement the approach that works best for all parties.

15
Another thing I'd like to add to my comment as a question:

Many things will need to be handled by the core. This worker is for analyzing and architectural planning. That means the proposal will end with a really detailed BSIP for those cases that will then be voted on, correct? Afterwards, if approved, it would be picked up by the core team so a consecutive proposal for that might not be needed.

 I agree with fav, focusing the proposal on the external Scatter like tool and integrating your devs for the parts that touch the core into the core worker might be beneficial, as it would also open up a line of collaboration of OpenLedger and the core team.

Dear Stefan and Fav! Thanks a lot for your opinion on that, collaboration with the core and UI teams may be a good option. I will reach Ryan to find the best way to move forward. Will keep everyone posted! Thanks again!

Pages: [1] 2