Hi @svk, could you please give us some visibility into your immediate roadmap for the GUI?  Which of the ideas in this and other forum threads are making it into upcoming releases?  Also, do you have any questions about my post re: auto-population of the order form?  I think it would be very helpful to have a little more dialog in order to ensure everything important gets buttoned up, and I do have at least one other issue (a pretty critical one, actually) that I'd like to take the time to write up once I know we have some dialog going.  Thanks in advance.

Quote from: tbone on April 08, 2016, 03:05:20 pm

Quote from: abit on April 08, 2016, 11:15:00 am

Quote from: tbone on April 08, 2016, 02:26:24 am

Quote from: abit on April 08, 2016, 12:55:29 am

Quote from: tbone on April 08, 2016, 12:28:52 am

Quote from: abit on April 07, 2016, 11:09:03 pm

For UIAs just ignore the feed_price field. It doesn't matter. Final scores depend on the formula.

The formula depends on distance from the market price.  That can be the feed price in the case of BitAssets.  But for UIAs, it would need to be something like the midpoint of the best bid and best ask.  See what I mean?

I see. But that's not something that have to be included in the basic snapshot data. It's an intermediate result while calculating with the formula.

The distance calculation result doesn't need to be in the snapshot data...but the price that will be used later for that calculation needs to be.  For BitAssets, that price comes from the feed, which you have a field for.  For UIAs, it needs to be something else, probably midpoint of best bid and best ask.  You don't have to calculate that midpoint, but you'll have to include the best bid and best ask so the midpoint can be calculated later.  See what I mean now?

Sorry, I didn't get the point.

For smart coins, the feed_price is simply fetched from the blockchain, which is a value published by the witnesses, so can't be calculated out from the order book. It's a basic data. I put it there, you can either use it or not in your formula.

But for UIA? The formula of "best bid" and "best ask" is yet to be defined, so how can I give out the best middle price? As I said it's an intermediate result, not a basic data.

Ok, I see where the misunderstanding is coming from.  Yes, the midpoint is a calculated value.  But the best bid and best ask are NOT calculated values.  They are values that must be recorded in the snapshot.  So let me define them.    The best bid is the highest bid at a given time.  And the best ask is the lowest ask at a given time.  If those values are not recorded in the snapshot, there is no way to calculate the midpoint, and therefore there is no way to calculate the distance component of the score.

On a given time point, the snapshot comes with an entire order book (which is basic data), say a `bids` field and a `asks` field, both are lists ordered by price, the first element on each list is the best one. So?

I see what you mean now.  I guess I was looking at it a little differently since I was envisioning that at some point (if not immediately), it would be too much data if we snapshot EVERY order on the book and that we'd have to start recording only orders of "registered market makers", which is fine except for one thing -- there would be no way to determine the best bid and ask after the fact.  Because that is a very real possibility, now would be a good time to start identifying best bid/ask and place those values into their own top level fields alongside price_feed.  This way a) the code to do the scoring would not break if we have to start doing the limited snapshots, and b) perhaps more importantly, it will be far easier to visually check the scoring results against the snapshot data.   By the way, I'm not saying you should calculate the midpoint.  That can always be done after the fact.  I'm just suggesting to identify the best bid/ask as part of the snapshot. 

@bytemaster,  this could be a great opportunity to gain exposure and users for the DEX.  Can you chime in on the idea of creating a BitLISK market-pegged asset?  Do you have any thoughts about whether it would make most sense for it to trade against BTS, BitBTC, or OPEN.BTC?  Also, should it use a price feed from YObit.net, which is the one somewhat established exchange where it currently trades?  Or considering that the YObit market for LISK is obviously limited-supply, would it be better to go without a price feed until LISK starts trading widely?  If would be amazing on multiple levels if we could get this to work.  Thanks.

Quote from: tbone on April 08, 2016, 04:57:39 pm

Quote from: Empirical1.2 on April 08, 2016, 04:43:58 pm

Quote from: tbone on April 08, 2016, 03:49:26 pm

Quote from: Empirical1.2 on April 08, 2016, 03:24:27 pm

Quote from: tbone on April 08, 2016, 02:36:00 pm

Quote from: Empirical1.2 on April 08, 2016, 01:39:43 am

Quote from: tbone on April 08, 2016, 01:04:27 am

Quote from: Empirical1.2 on April 07, 2016, 11:39:32 pm

There will be plenty of people willing to short BitLISK at even a 1/4 of what it's trading for on Yobit.

Can/t we create BitLISK and only enable forced settlement once LISK is properly trading?

But what would we use for price feeds in this case?

If there's no forced settlement, I don't think we need price feeds right now because the market will know price feeds & forced settlement are coming and trade accordingly.  Then once it's released we use price feeds from whichever main exchange/s are trading it.

Alternatively you could use the YoBit IOU LISK price as the price feed for now & add other exchanges as real LISK begins being traded though I doubt there will be much LISK demand at YoBit prices.

For some reason I'm having trouble wrapping my mind around the idea of a BitAsset with no price feed.

I don't 'think' it's a major issue because the price feeds and forced settlement will be available once LISK is trading so people should trade accordingly. Perhaps others can give their opinion.

We'd have to move quick but it could create quite a lot of exposure & demand for BTS.

I agree that someone here should do something.  I have been very vocal about my belief that this would create great exposure  for the DEX, both on the forum and in private with Ronny.  I tried to get him to escrow some collateral from me in exchange for issuing an asset representing a portion of my Lisk ICO shares.  But he is too busy with the Moscow conference.  And I don't know that there is another good way to do it that will be trusted.  Thoughts?

If there was a BitLISK, ICO LISK holders could just short it. 

In terms of CCDEK yes that could be successful too. He could make a fortune right now. I would pay a 20% commission to sell some of my LISK at anything near YoBit prices.

Ronny could offer LISK for Sale on CCEDK and then credit it to LISK ICO owning forum members based on a combination of trust and collateral as well as not letting them withdraw the BTC from their account until they've sent actual LISK to the exchange once it's launched.

So for example he could say I trust you're good for 10 000 LISK Empirical1.2. I will credit your account with 8000 LISK which you can sell. However the account will be locked for withdrawals until you deposit 10 000 LISK which must be done within 72 hours of when LISK officially begins trading.

Ronny could easily get 300 000 LISK which could be put up for sale. At current YoBit prices 20% commission on that would be $500 000 profit for CCEDK in a matter of weeks.

(The high commission also allows for a high failure rate even amongst trusted members of this community and as prices are clearly inflated at the moment even if a small % of people failed to provide actual LISK the BTC they would have received for them in their locked account should more than cover the purchase of actual LISK once trading if required.)

Yes, pretty much my sentiments.  Although personally, I was thinking of a lower commission since I'm willing to put up some collateral and give him a screenshot of my Lisk ICO exchanges.  But yes, I think among some of the members of the community who have established some reputation, we could come up with a nice chunk of Lisk to enable a nice little market to trade on the DEX. 

Regarding the BitLisk option, I'm just wondering how we would explain to people (especially outside this community) that they can trust this asset that we just shorted into existence all of a sudden.  I mean, it's not issued by the blockchain, the issuer is not a trusted organization, and this particular asset would have no track record in the marketplace.  That doesn't mean people wouldn't buy into it or that it wouldn't work.  And of course if it did work, it would be awesome for us on several levels.  I'm just having a hard time getting my head around it.

Yeah I would be willing to provide collateral and ICO screenshots too. But I would pay 20% commission at these prices any day of the week.

In terms of BitLISK. I imagine people would be willing to short it at far lower than YoBit prices which means the incentive to be a buyer & take that risk would be that you could get it for much cheaper than elsewhere at this stage. With the knowledge that you could redeem it 1 BitLISK for 1 LISK worth of BTS once LISK trading starts. I think there'll be a market for it but as I say maybe some other people have some opinions on it, there's often things i miss.

Ok, so walk me through this.  What absolutely guarantees that they will be able to redeem 1 BitLISK for 1 LISK worth of BTS?  Forced settlement?  What are the potential pitfalls there?  What if the market becomes extremely volatile and there isn't a lot of liquidity?  What is the risk for those of us shorting BitLISK into existence, both before and after price feeds become available and forced settlement must be instituted?   

As for the price feeds, so they would be coming from external Lisk:BTC markets once real LISK trading begins, correct?  Does that mean that BitLISK needs to trade against BTC?  Would it be BitBTC?  OPEN.BTC?  What about BTS?  I imagine it would be best if it was not fragmented among multiple pairs.  But if it was BTS, how would that work with the Lisk:BTC price feeds?  Don't worry about answering that if you think it should only trade against some version of BTC.

By the way, what prevents people that don't have ICO Lisk keys from shorting BitLISK?  Ok, I guess that doesn't matter as long as they have enough collateral.  But again, I'm having trouble wrapping my mind around that.  Enough collateral based on what?  And would people trust that it's properly collateralized?

I'm certainly not shooting the idea of BitLISK down.  I'm just trying to get comfortable with it.  It would be amazing if this could work.  And I appreciate you advancing the idea.

Quote from: tbone on April 08, 2016, 02:36:00 pm

Quote from: Empirical1.2 on April 08, 2016, 01:39:43 am

Quote from: tbone on April 08, 2016, 01:04:27 am

Quote from: Empirical1.2 on April 07, 2016, 11:39:32 pm

There will be plenty of people willing to short BitLISK at even a 1/4 of what it's trading for on Yobit.

Can/t we create BitLISK and only enable forced settlement once LISK is properly trading?

But what would we use for price feeds in this case?

If there's no forced settlement, I don't think we need price feeds right now because the market will know price feeds & forced settlement are coming and trade accordingly.  Then once it's released we use price feeds from whichever main exchange/s are trading it.

Alternatively you could use the YoBit IOU LISK price as the price feed for now & add other exchanges as real LISK begins being traded though I doubt there will be much LISK demand at YoBit prices.

For some reason I'm having trouble wrapping my mind around the idea of a BitAsset with no price feed.

I don't 'think' it's a major issue because the price feeds and forced settlement will be available once LISK is trading so people should trade accordingly. Perhaps others can give their opinion.

We'd have to move quick but it could create quite a lot of exposure & demand for BTS.

I agree that someone here should do something.  I have been very vocal about my belief that this would create great exposure  for the DEX, both on the forum and in private with Ronny.  I tried to get him to escrow some collateral from me in exchange for issuing an asset representing a portion of my Lisk ICO shares.  But he is too busy with the Moscow conference.  And I don't know that there is another good way to do it that will be trusted.  Thoughts?
 

Quote from: tbone on April 08, 2016, 01:04:27 am

Quote from: Empirical1.2 on April 07, 2016, 11:39:32 pm

There will be plenty of people willing to short BitLISK at even a 1/4 of what it's trading for on Yobit.

Can/t we create BitLISK and only enable forced settlement once LISK is properly trading?

But what would we use for price feeds in this case?

If there's no forced settlement, I don't think we need price feeds right now because the market will know price feeds & forced settlement are coming and trade accordingly.  Then once it's released we use price feeds from whichever main exchange/s are trading it.

Alternatively you could use the YoBit IOU LISK price as the price feed for now & add other exchanges as real LISK begins being traded though I doubt there will be much LISK demand at YoBit prices.

For some reason I'm having trouble wrapping my mind around the idea of a BitAsset with no price feed.

We need to specifically discuss the primary options for stealth implementation.  Should we complete @onceuponatime's version, or should we move forward with the alternative?  What are the pros and cons of each path forward? 

Quote from: abit on April 07, 2016, 10:39:01 pm

Quote from: liondani on April 07, 2016, 06:45:09 pm

Quote from: onceuponatime on April 07, 2016, 02:07:08 am

I am willing to sell to you, @JonnyBitcoin, all of my shares at 8.34 BTS each in order for you to be able to accomplish what you say you would like to see.

Sell STEALTHS openly on OL  and give the opportunity to our community to participate !

sell them in parallel with 5 different prices and give as 2 weeks....   (like a crowd-sale)

1. 20% at 8.0 BTS / STEALTH
2. 20% at 8.5 BTS / STEALTH
3. 20% at 9.0 BTS / STEALTH
4. 20% at 9.5 BTS / STEALTH
5. 20% at 10 BTS / STEALTH

I am sure it will be successful! 

PS just throwing ideas

Selling to public is different from selling back to the DAC (all stake holders). Arhag posted a solution in last page.

What? Unless arhag changed his username there is no post by him in this thread.

I am surprised nobody has responded to kencode's brilliant idea of using the blockchain as a backup medium. Essentially all you need to do is securely encrypt the account owner keys to provide a solid backup solution. I don't know what the size limitation is on the memo field but surely the storage details for such a small quantity of data isn't beyond our capabilities to easily implement. Require a 10 or 20 word brainkey of the users choosing to encrypt the owner keys of the accounts held in the wallet. People who use stealth are surely going to be more careful, and having a backup of your wallet stored in the immutable blockchain is about as safe as it gets. Give the user options concerning the brain key. They provide or wallet generates it. Validate strength of any the user provides and give them feedback on the quality.

Of course the had part is how to make it easy to use. I like the "Backup Required" prompt in the bottom right corner, perhaps it needs to be more obnoxious, like blinking to catch the users attention and give them an incentive to make a backup and stop that damned blinking! Maybe lightbox the whole app until it's done before the wallet can even be used again after operations involving stealth are performed. However it's done it's GOT TO BE INTUITIVE AND SIMPLE.

I disagree with @roadscape on blinded transactions. I think that is riskier than polishing the stealth feature, especially if it's only a matter of implementing a solid backup approach, and I fully agree with Ken that any server side approach has risks.

@Thom, I think you may be losing it.  @arhag most certainly did post on this thread.  Scroll up!  Also, storing the account keys on the blockchain was actually @roadscape's idea.  @kenCode gave him major kudos for that....and I do too because yes, it would be awesome! 

By the way, if the keys are stored on the blockchain, why would the user need a reminder to back up their keys?  Wouldn't it just be done automatically?