Topic: GLBSE - request for next features (Read 27758 times)

At least he visited the forum today. He didn't do even that for a few days, if I remember correctly.

he did not write any public post since September 26 or 25

Perhaps it is time or Nefario to lock this thread? I don't think he needs suggestions anymore.

i liked the uncertainty more. but good catch, working service is much better than no service.

Hmm, having a working site (or even, any news) would be a definite improvement over the current situation.

I assume that it is safe to use the same Yubikey then on different sites & the key generates a code that is specific only to that site at that time rather than one that could say also be used to also access Mt. Gox if one had the password too, sry for my lack of knowing the tech for these & thanks for having implemented this - I much prefer Yubikeys to other 2FA as I don't have a smart phone.

Please add a P/L (profit loss) statement for all the public investment portfolios that have sold it's shares to the public. 
1) Report has to show all the holding at the beginning of the period and at the end.
2) What has changed
3) Div's received
4) BTC in and out
5) Gain or loss from trades grouped by security and unrealized gain/loss for the period.
6) Share transfers in and out (swaps etc)
7) ... (feel free to update the list)

If this report is delayed by 24 h, it's OK by me. No need to show what happens in real time.
And please, make it mandatory to all investment "companies" or even mining co's, that have bought shares from GLBSE. 

Those whacky spreadsheets, with zero information on what has actually happened in the portfolio, have to go.
Those "reports" are useless and too easily manipulated by portfolio manager.

Yubikeys have been added as a method of two factor authentication.

Currently supported are standard yubikeys (ordered from Yubico).

We will add support for MtGox Yubikeys once I get the key in the post.

Nefario.

is it possible to post a bid/ask via api?

I was referring to more of a history of dividend payments but with the ability to limit the range that the API returns.

Produces a full history of dividends paid.

https://glbse.com/api/dividends/asset/GIGAMINING

The last dividend information was added to the public API last week.  I'm already generating automated statistics using them.

I thought you couldn't pull list of dividends assets paid. 

I think dividend payments should have its own twitter feed or an API like cryptostock has where a user can request the latest trades of x number of days.  Right now if a user wants to get the latest dividend payments for the assets, he needs to call all the active listings and pull the dividend API, which gives the entire history of dividend payments.

Not so bad. People will know that support means less.

Maybe we could provide a "weighted support" separate info, where coins used n times are weighted 1/n?

Now the support could equally disappear overnight, just because the owner decided to rather place an order somewhere else.

Does liquidity mean so little these are real problems? It would be quite an improvement in my view.

+1

Just think about what information all those orders are giving.

Imagine I have 1 btc in my account. I go to my favorite asset and place 100 bids of 1 btc for that asset. Now when anybody looks at the order book they see that asset has 100 btc of liquidity at 1 btc. They then make decisions based on that information, perhaps they decide to buy some since the price has so much support. Then as soon as anybody sells one of those assets to me, even though I only spent 1 btc that 100 btc of support disappears. Essentially, it distorts the information available to the market, resulting in phantom support.

What's wrong with spam orders? Just the graph? That's been useless forever. Other than spam orders that already mess up the graph, there's nothing wrong with them. They'll either get auto-removed or filled by a seller, which makes them real orders.

The way Open Transactions handles multiple offers made with the same assets is to check the offer when someone clicks on it, to see if the person offering still has enough balance to execute the offer.

That way a person with for example 100 bitcoins could make 100 bitcoin offer on every market of every asset, but as soon as one of them is taken up the rest become vapourware that will vanish as soon as someone clicks on one to see if it is still good.

This is kind of a compromise between allowing people to express an interest in "whichever I can get first out of all these possibilities any one of which I will accept" and allowing those who care whether an offer they see in the orderbook is real or not to be able to check by forcing it to go look whether it still has funds enough behind it to make it real.

Since it is in any case extremely inefficient to have people constantly polling the server asking what offers exist most likely a ticker will be added so that offers can all be published somewhere other than the server's own API to take the polling load off of the server, whereupon the concept of "depth" will in any case become moot since it can be expected that most offers that would otherwise be on the books will instead be out in the wild watching the ticker ready to respond to any offers that appear on the ticker that they like.

-MarkM-

Margin trading would definitely increase liquidity since you could place more orders on the same btc balance.