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

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).

I'm all for strategies that reduce the amount of BTC in the exchange wallet.  The BTC in that wallet is a liability to BTC Trading Corp.

Given the confirmation time of BTC transactions, I'm not sure that filling purchase orders with remote coupons or remote funds would work very well.  In your proposal you suggest that users can place a purchase order, but only transfer the BTC when the order is filled.  I think I could accomplish nearly the same thing by setting up notifications triggered when an asset has a sell offer at or below a certain price?  You'd get a notification, transfer the BTC to the exchange, and close the deal.  This would greatly limit your exposure to BTC theft on the exchange.

On the fulfillment of sale orders, I could put in an auto-payout threshold feature similar to my LTC mining pool.  It's very simple.  If your balance goes above a certain amount, it is auto-withdrawn to your preset address.  I like this idea, and it is easy to implement.

There is little to no risk of the exchange operator (me) playing around with other people's shares.  It would be too easily obvious since there is complete visibility to the asset issuers of who has what.  A person making a claim that shares were stolen could go to the asset issuer, who should be able to go back through the emails received (hopefully they're archiving them off somewhere)  and figure out where the assets went.  In a similar manner, the dividends display both the total paid and the payout per share, such that if you check your balance history you can clearly see that nothing is disappearing in the process.  I've gone to great lengths to keep things transparent.

The other thing I'll add is that the MPEx guys (Mircea Popescu?) have a great blog post up here: http://polimedia.us/trilema/2012/a-message-to-bitcoin-wanna-be-scammers/

I think there's more to be made with a legit service than there is with a scam.

Cheers.

Yes, sorry. Mybitcointrade.com doesnt have something to do with burnside as far as i know. The user Mybitcointrade.com is a different entity in this forum. And he ran an exchange that looked normal. When there werent a typical hyip-offer. People warning were there all the time and at the end the warnings were correct.

I wonder if there cant be an exchange that doesnt store btc in itself but instead a user address is used. I mean you create a buyorder then you have to send btc. You get btc from selling a share, then you get the btc directly to your own btc-address outside the website. The same goes for the dividends. You could do the same manually but lazy people wont do, noobs dont know. And manually wouldnt be that fast to take out the btc from there.

Then the amount of btc that are there able to be stolen are held at a minimum all the time. Plus, when its ensured that the issuer always have an actual list of shareholders even when the website is stopped the next point is solved.

The only risks then would be that you buy shares that arent real. The issuer runs with the money or so. Such an security could be created from a scammy exchange owner too.

Second risk would be that the exchange-owner is messing with the numbers. Selling shares from legitimate issuers that dont know about that and cant prove it because the numbers they get only show the correct amount of shares. That could become a real bad problem if someone would have this criminal energy and still can create the trust to use such an exchange. This only could come to light when the userlist holding shares is opened to the public. But only when a user that bought such wrong shares would check this list it would come to light. Not all users would do this.

MPEx doesn't need or really use two-way email communication. It's one way, you send your public key.


Depending on the exact configuration, this may be true. If it's a concern the solution obviously is not to use your desktop for signing. This is something that one can do on MPEx but can't do on a plain website, which is why the plain website NEEDS some form of 2FA: to try and replicate what MPEx does natively.


Yes, as described in the MPEx faq: get an offline computer, sign there.

Next question I suppose...

Would it be possible to reasonably combine gpg + 2fa?