Topic: [BTC-TC] Virtual Community Exchange [CLOSED] - page 135. (Read 316534 times)

Think you misunderstood his point 3.  He's only saying to mark orders on their OWN asset.  So only orders of mine which would be marked would be ones on LTC-ATF.  That's no problem to me - and shouldn't be a problem to any other asset issuer unless they're trying to mess with the market for their own asset (which they shouldn't be doing).

It wouldn't actually address much though - as anyone messing with the market for their own asset is going to be doing it with an account other than the asset-issuing one anyway (so that the outstanding shares doesn't keep changing).  But it WOULD let investors see whether an asset issuer was actively maintaining liquidity (if they were doing it via the asset-issuing account as I am).

Doh, I missed the "with a delay up to N days part".

That's hard, but not impossible.  Would have to setup a way to store snapshots of the portfolios.  I'll look into it.

1) Show a calendar, where you can see dividend payers for selected date: 2012.12.07 - XYX 0.05 BTC per share. Really cool, if current month or selected security can be downloaded in iCalendar format for importing to other calendars. dates and time must be in UTC obviously.
2) I must have missed it while in testing My bad
3) I as a issuer of security XYX set orders to to buy my issued XYX - those orders are highlighted.Good idea for transparency.
BTW, in real world trading systems, buyer/seller codes (Trader/Bank/etc) are visible to other members/traders and in some markets, even to the general public. This is completely normal. 

You mentioned day trading as a problem, that is why I added "(with a delay up to N days?)"

I had a discussion about this with a fund operator on LTC-GLOBAL yesterday.  As much as I'd like to, I don't think I can.  It works great for longer term investment funds, but some of the funds are day trading funds.  If we publish their portfolio, then competing day trading funds can figure out their strategy and use it against them.

I love the idea to add NAV calculation.  Though it may get tricky given limited depth.


We do support JSON API publishing of the portfolios as well.  If I let users plug in an API key on one site, they could link their portfolios.  I like that.

GLBSE experience was bad and I hope we all can learn form that. Some jokers got really creative with NAV calculations and who wants to repeat that crap


1) What do you mean by a dividends calendar?  Like a history in your portfolio of past dividends?  Or a display of scheduled dividends in the future?

2) LTC-GLOBAL has been doing this for a while.  I'll check it out on BTC-TC.  If it's not already working, it'd be from a CSS snafu most likely.

3) As much as I'd like to do this, I don't think I can.  Problem on this one is similar to why not all funds can have public portfolios.  The day trading funds would get abused horribly if all their orders started getting highlighted.  What I could do though is give asset issuers the option when placing an order of highlighting it.

Appreciate the input, some great ideas!

Cheers.

True, but requesting data from a "sister site" can not be that hard.
GLBSE experience was bad and I hope we all can learn form that. Some jokers got really creative with NAV calculations and who wants to repeat that crap

There is few more feature request, I posted some time ago to GLBSE thread:

1) "Dividends calendar" will be nice to have.
2) Highlight users bid/ask in the order book (btc-e has it well implemented).
3) Mark security issuers orders for their own security with a different colour in the order book.

The fund I manage on litecoinglobal has public portfolio enabled without delay, but since it's charter enables me to purchase outside of litecoinglobal and I currently have assets at both cryptostocks and btct.co(w/ public portfolio), automatic NAV calculation will not work and would just be confusing.

+10!
Excellent. Make it mandatory for funds (with a delay up to N days?) and if you have time, please add also full transaction history and automatic NAV calculation.
This will help avoid all sorts of drama.

Today's Dev Updates:

- Cache strategy changes to the market page.  It should be cached slightly less now, and more up to the second with trades.
- New feature, public portfolios!  On the "Account" page you can now turn on public access to your portfolio.  When you turn it on, you are given a custom URL.  Anyone you give that URL will be able to view your portfolio, all they have to do is log in with their own account first.  This should be especially handy for FUNDS that want to make it easy for their users to see what assets they are holding.

Quick Dev Update.  We have added protection against google auth replay attacks.  This means that you now cannot reuse the same google auth key in a 5 minute window.  If you want to do another transaction quickly, you will have to wait for a new key.  Please let me know ASAP if you find anything broken as a result of this.  eg, if you can't trade.  

Today's Dev Update:

- New api endpoint /api/assetContract, gives you the contract and other details in json.
- Newly created assets are now "Issuer Locked" by default.  This way the issuer can fine tune them before opening them up for moderator voting.
- "Admin Locked" and "Issuer Locked" assets now show up with a reddish background in the Market.
- Bug fix to the Market "Trades" tab, the 24h high and 24h low columns were backwards.
- Bug fix to the textual depost/withdrawal history where the quantity of the sellers entire order was written into the trade log rather than the quantity of the bid the seller filled.  (important note... this was a textual history bug only, not a bug with the actual quantity in the trade itself.)

Yep 

As opposed to the ones you COULD afford, which wouldn't disappear until nefario spoke to a lawyer for the first time in his life.

lol, that figures. 

The original GLBSE allowed unfunded orders. You could literally put up as many orders as you wanted, and the orders which you couldn't afford would just disappear when somebody tried to sell into them.

I don't have any issues with the naming convention.  I'll post a link on our asset creation page and recommend issuers follow it.

Parity on the API is an interesting thought as well.  Definitely worth looking into.

Cheers.

Simple way to make sure customer knows email address. IRC doesn't treat GPG pastes too well.


Uh. I think the problem here is moreover a lack of fundamental understanding. 2FA is a concept, not an object. 2FA != dongle.

MPEx doesn't get in the way of the user's security policies (nor should it). The fact that worse security implementations (such as, any website on the password model) are forced to break this principle by their poor design (and even so fail to really solve the problem) is irrelevant.


Whichever way you want. Some people use QR code readers. You can print it and scan it. You could whistle it, if you wanted to.


In general under 1kb.


This is not a question that can be answered in the abstract. It obviously depends on the user.


Yes, I was. For the record, I'm not saying a public-db exchange is automatically a bad thing. It may be a horrible thing if the (or some) users proceed on the false belief that it's private when in fact it's public. But as long as it's clearly understood to be public I suspect it may turn out to be an interesting and maybe even valuable way to do things. Certainly in the "learning/playing with stocks" niche it would be valuable, and this is not derision in any way - Bitcoin has been more valuable as a tool for people to learn about finance than to actually do it so far.

Related: see if you can stick with the naming convention proposed and maybe review the process standard proposed. Comments welcome (preferably there, so you actually get a competent answer).

Thank you for the more in-depth explanation.

I think that an auto-withdrawal would work for all three of those scenarios.  We could have several options:

[ ] auto withdraw proceeds from sales
[ ] auto withdraw proceeds from dividends
[ ] auto withdraw if my balance ever gets over [     ] BTC

Thank you for the great idea.  I'll work it into the todo list.

Cheers

Ahhh.  Why not a web based form submit then?



What MPEx does natively seems to discourage use of 2FA because it is unnecessarily difficult.



How do you get the signed order to/from the offline computer?  USB stick?  Is this the process?  Format key on offline computer, create file on usb stick, sign file, remove usb stick, put usb stick in networked computer, post file to MPEx?  (...virus installs on usb stick, put it back in offline computer for the next order.  oops...)  Or ... Print it out using offline computer, then type it back into online computer?  How big are the signed files?

And if you have to use the offline computer in place of a yubikey device or google auth app, which do you expect is going to be more user-friendly?

To be clear, I have no qualms with MPEx or anyone at MPEx.  I expect that we can and will all get along nicely, and I very much appreciate the opportunity to discuss design decisions with someone that "gets it".  Thank you for that.


Are you referring to the colored coin proposal?  It is definitely interesting, and you're right, would break anonymity.  The database truly becomes public.


smpake.com looks like a great idea.  I'll read up on it.


Cheers.

burnside... i thought it more this way:

create order -> amount X needed to fulfill -> load up this amount of money + fee -> offer gets live -> its sold, you get shares, the btc are moved to other user and instantly transferred to his external btc-adddress

sell order -> its sold -> you get btc, the buyer your shares -> the btc are transferred to your address instantly.

issuer has to pay dividends -> is loading up the needed btc -> spreads dividend -> every shareholders gets his btc transferred to the btc-address instantly.

Ideally it shouldnt need 6 confirmations. I still dont know why mtgox is doing this. Its a real pain to wait a hour. The more because i have to wait sometimes more than a hour to only get one block. So by chance one can wait way more than a hour only to put money in there. By a nearly not available lower risk gained through that. I have to write the representative of mtgox here in forum about this. Maybe he thinks this over.

But i prefer anything that helps to lower the risks. Not only to not suffer loss but to make life harder for scammers. So that maybe someday scamming is technically harder so that it goes down.

That's indeed MP.

One problem with the signature of coins system proposed is that it breaks anonymity: all transactions become visible from the outside (X deposits m-by-n BTC to exchange, THOSE BTC are used to pay for share Y, etc).

Re the auto-payout etc: one thing that may be worth your while is hooking in with smpake.com (it's a service that allows insta-payments).