Глюк (хотя и не совсем глюк - если понимать как программа работает, то она формально все делает правильно, но для человека кажется что это глюк) который описывает CoinTalk точно есть - я сам его несколько раз уже ловил тут. Он довольно типовой/распространенный на самописных биржах. Пример чтобы понятнее было где копать:
- скажем стакан BTC/RUR, самый верхний ордер на покупку стоит по цене 23102.752873 (по такой цене его выставил пользователь или скорее бот, и по такой он хранится в базе данных на сервере и обрабатывается движком биржи)
- при выводе на экран (в HTML+js код браузера пользователя) он округляется до 4х знаков после запятой и показывается как: 23102.7529 (как положено округлили по правилам математики)
- далее заходит какой-то клиент и хочет продать BTC, смотрит в стакан и цена текущего верхнего ордера на покупку его устраивает, объема ему тоже хватает (так что несколько ордеров нет необходимости использовать), так что он просто щелкает в него мышкой (в заявку на продажу подставляются все данные нужные для подачи встречного к текущему верхнему на покупку) и жмет "продать"
- выставляется заявка на продажу по цене 23102.7529 (так подставил данные js скрипт в браузере, т.к. он работает на клиентской стороне и берет уже только округленные цены)
- с точки зрения движка(который смотрит данные в базе данных на сервере без округлений), в стакане стоят 2 заявки: на продажу по 23102.7529 и на покупку по 23102.752873 - цены хоть и очень близкие, но не совпадают и не пересекаются, так что он ничего не делает
- с точки зрения человека (который смотрит стаканы через браузер куда ему выводятся данный с округлением до 4х знаков после запятой - для удобства восприятия) в стаканах стоят 2 заявки по одинаковой цене: купить по 23102.7529 и продать по 23102.7529 и он не понимает почему его ордер не исполняется - делает вывод, что биржа глючит.

Исправить просто, даже неск. вариантов - или в базе тоже округлять до того же кол-ва знаков или в базе не округлять и хранить все с макс. точностью, но тогда клиентам в браузере округлять не по правилам математики, а в зависимости от направления ордера: на покупку всегда вниз (просто отбрасывать лишние знаки), на продажу всегда вверх (до ближайшего не округляемого знака. Т.е. 0.00000003, до 0.0001) или поправить серверный скрипт который взаимозачет проводит, чтобы он ордера отличающиеся меньше чем на 0.0001 тоже взаимоисполнял (но тогда хоть и микроскопическую разницу но за счет биржи как бы доплата получится - из комиссии сделки)

Но deebosch пишет по-моему совсем про другой глюк. Когда допустим верхний ордер на покупку стоит по 23100, за ним 23097, потом 23092 и т.д.
Человек желающий продать и которому мало объема верхнего ордера ставит цену "с запасом" - ниже текущей рыночной, скажем 23050 руб чтобы собрать сразу пачку ордеров одной заявкой.
А движок вместо того чтобы исполнить заявку по настоящим биржевым правилам (1ю часть по 23100, 2ю по 23097 и т.д.) исполняет заявку по цене введенной клиентом (а разница достается непонятно кому).
Такой глюк на бирже тоже был, но насколько я знаю он уже довольно давно исправлен - об этом во 2й теме (GOC как платежный сервис) писали.

hazarun же вообще что-то 3е описывал (вроде ордера выставленные им в общем стакане не видны были) - с таким я на GOC не сталкивался пока.


P.S.
В качестве демо воспроизвел ситуацию  1м "багом"(округлениями) на LTC/USD (как самой неликвидной, чтобы ордер до утра кто-нибудь не сбил)
Там сейчас 2 моих ордера: купить по 0.01 LTC по цене 8.5346 USD и продать 0.01 LTC по той же цене 8.5346 друг напротив друга стоят 

Заодно про глюк напишу (я его в поддержку отсылал с неделю назад, но какой-то реакции не получил, хотя может просто молча "приняли в работу"?).

У вас на страничках с историей транзакций (https://goc.io/?cmd=deposits и https://goc.io/?cmd=transfers) есть ограничение по количеству выводимых за раз записей (заявлено 300), если в запрашиваемый период их было больше.
Само по себе наверно ОК - наверно нагрузку на сервер так ограничиваете?

Но вот работает как-то очень странно этот лимит: если транзакций за период много, то вместо заявленных 300 он выдает какое-то превдо-случайное число транзакций из запрошенного периода. Конкретно у меня  обычно:
в таблице поступлений где-то 170-230 транзакций выводится
в таблице переводов всего 70-100 транзакций за раз

А остальное обрезается. Кол-во которое при этом будет выведено как-то зависит от заданного периода и характера самих транзакций.
Вообще 70-100 как-то маловато. Но больше всего напрягает не это, а то что кол-во выводимых записей все время меняется и никакого признака что идущие дальше обрезаны в таблице нет, в результате каждый раз гадаешь (и проверяешь методом тыка выбирая другой диапазон дат) - а все ли транзакции за запрошенный период в этой таблице показаны? или только часть, а часть движок биржи молча обрезал и нужно дробить диапазон дат на части?
Было бы неплохо привести это все к фиксированному лимиту (пусть даже и меньше 300 он будет если там какие-то технические ограничения мешают сейчас по 300 выводит) или (а лучше И) в случае если выведены не все транзакции за запрошенный период (из-за сработавшего лимита) как-то на это указывать (типа последней строчкой в таблице "и еще XX транзакций не отображено").

Еще и вопросик в плане юзабилити - обычно такие таблицы пользователи смотрят в первую очередь интересуют самые недавние транзакции. И большинство бирж поэтому их так и выводят в обратном хронологическом порядке - начиная с самых свежих(последних) и дальше в историю.
У вас же выводятся с начала заданного диапазона + по умолчанию этот диапазон ставится на весь текущий месяц. В результате у активно торгующих все свежие транзакции обрезаются лимитом (про который выше). И вместо одного клика - посмотреть последние транзакции, приходится каждый раз задавать какой-то (более короткий чем выставленный по умолчанию -  чтобы самые свежие не обрезались лимитом) диапазон дат вручную и мотать страницу в конец длинного списка (вначале которого идут старые транзакции).
Впрочем насчет сортировки (прямая или обратная) это вопрос личных предпочтений - кому-то может и прямой порядок больше нравится...

Поясните что с выводом в WMR?

Последние разы выводил стало по 2 раза дополнительные 0.8% от выводимой суммы откусывать.
Написал вопрос в поддержку - ответили дескать это мы платежный шлюз на новый сменили, который работает лучше старого но не берет комиссию Webmoney за свой счет и списывает ее с проводимой суммы.

Так предыдущий шлюз вообще-то вся время тоже дополнительные 0.8% (уходящие в итоге WM) помимо стандартных 3% комиссии (бирже) тоже всегда забирал! (ну по крайней мере с момента моей регистрации на биржи - около месяца назад)
А теперь кто-то почему-то по 2 раза эти 0.8% забирает. (о чем я и писал в вопросе).

Так что я такого ответа вообще не понял: в нем ложная информация (что раньше 0.8% не брались) и нет ответа на вопрос (почему теперь 2 раза по 0.8% и всегда ли теперь так будет)

It is not browser issue - i already try to disable plugins and try 2 different browsers (Mozilla FireFox and Google Chrome) before write here - not help.

But now i found source of problem myself: tables in new design not auto-refresh because you for unknown reason use non standard port for script which do auto-refresh (=4446)
And i use strict security polices on computer used for trading (launch of all executables and all Internet connections disabled by default excluding only allowed by manual added rules/list)
So all connections attempts to this port was blocked by firewall without warning/notice. (while all other functions work fine via standard 443/80 ports)
After i found this (in logs) and add rule to allow browser to connect to 4446 and do logout/login cycle tables start auto-refresh after each new order/trade.

Ок, значит скользящие последние 30 дней, а не календарные месяцы.
Значит лимит на пару карта + телефон т.к. если нужно вывести больше 60 тр за месяц нужно И другую карту И другой номер телефона указывать?

Если так возможно из-за этого мои платежи зависали.
Может прикрутите у себя проверку на этот счет, чтобы такие платежи (сверх лимита) сразу еще у вас заворачивались (или заявка не принималась или автомат отменял и возвращал на баланс), чтобы люди потом каждый раз вручную по цепочке не ходили: ждем платеж --> недождались но в истории платежей видим что он вроде бы --> пишем тикет в поддержку GOC WFT? --> поддержка GOC дергает киберплат --> киберплат возращает средства на счет GOC --> поддержка GOC возвращает клиенту на его баланс

Can you add auto-refresh(update) tables with current market orders list after each active user action (like sending  new order or removing old) as it was in old (v.1) CRYPTO-TRADE?

Now it needed to update whole page manual each time to see changes - and its annoying.

Maybe you not understand me...

I meant table shown when choosing a particular trading pairs. For example LTC/USD:
https://crypto-trade.com/currencies/trade/ltc_usd
It have no any filter or sorting options at all

NOT table in my account (https://crypto-trade.com/member/trades/currencies) - this one work normal and shows all my trades correctly.

And yes it is finished trades - i can see them in account trade history, by not see in "my trades" table on trade pairs pages. One more latest example:
Date                         Type   Price (USD)   Amount (LTC)   Total (USD)
2014-07-23 21:33:01   Sell    8.02   10   80.2

Seems i found when this happen:
if i do "market" trades - sell or buy from orders placed by someone else (with instant executions)  this trade included in "my trades" table.
But if i place limit order and later someone buy/sell from/to my waiting order - this trades not included in "my trades" table.

Суточный? Вроде же на бирже при выводе написано что это лимит на весь месяц?

Уточнял кстати этот вопрос в поддержке как связаны карты и номер телефона. Т.е. формулировка написана не очень понятная: "лимит в месяц на один номер карты или номер телефона".
Получил ответ что это значит, что на ту же самую карту но с указанием другого своего номера телефона можно вывести еще 60 тыс. руб.
На практике это похоже оказалось не верным - по крайней мере все переводы свыше 60тр за месяц на одну из моих карт(но с другим номером тел.) либо были отменены через какое-то время на стороне бирже либо зависли в киберплате и пришлось их вручную откатывать.

Some more bugs.

I make my first trade after v. 2.0 upgrade and found what my trades NOT showed in "My Trades" table (under order list of chosen pair)

This is my trades:

It shown in "Trades" table (where list of all trades from all users on this pair) but not listed in "My Trades" table (where list of own trades only)
Seems new engine does not recognize that it was my trades.

Выдимо в очередной раз так "удачно" обновились, что теперь восстанавливать после обновления нужно. 

Заглянул после почти 2х недельного простоя (у меня биржа только 21го заработала вместо 18го обещанного, до этого все загрушку из матрицы показывала) - балансы совсем не соответствуют тому что было до обновления. Частично это похоже из-за того часть ордеров выполнилась (я их снять перед закрытием не успел, т.к. заранее о нем не предупредили), хотел по истории сделок проверить - только в этом дело или еще и базой данных какой-то косяк и...
Не нашел истории сделок вообще - после обновления она выпилилась!

I collect some statistic and do some math about current (after Staking Bonanza end) ORB staking for myself.
But think it may be interesting for other users to, so i post it here.

I collect 5 days of statistic from my own wallet with ~20k ORBs staking 24/7.
It is not new wallet - it staking few month already so all processes stabilize. I do not any manual corrections and allow wallet to manage all automatically.
And at current difficulty level (it fluctuate in range from 0.0075 to 0.012 while i collect statistic) i got this numbers:

average size of inputs in my wallet: 37.6 ORBs (initially i split inputs manual but later allow wallet do all splitting automatically so now it is random set of sizes from 25 to 50 ORBs, with average = 37.6 ORBs)

average time to generate PoS blocks for single input: 11.5 days (5 days to mature enough to start staking + 6.5 days of staking with continuously growing weight)

So with fixed PoS reward (1 ORB per block now) current interest rate: 1/37.6/11.5*100 = ~0.23% per day
Or
0.23%*365 = 84% annual interest rate (by simple % formula)
(1.0023^365-1)*100 = 131% annual interest rate (by complex % formula - if you reinvest all rewards generated and keep them all in wallet staking too)

Not bad at all even after Bonanza end!

Note 1: It is for 24/7 staking wallet with 24/7 Internet connection to ORB network. For example if you run only half day - you got only about half of interest too. (it is a big difference to classic PoS coins where no material stimulus to run wallets 24/7)

Note 2: while PoS reward is fixed in ORBs in % of interest rate it not fixed and highly depends on PoS difficulty(but not linear). Numbers above correct for current diff range (0.0075 - 0.012). If diff goes up (more miners begin staking or same miners add additional coins to staking wallets) % interest rate goes down. And vice versa. So it is nice self-balancing process here.

No wallet split automatically only inputs >= 50 ORBs. Wallet not split inputs < 50 ORBs. So minimum value after auto-split is 25 ORBs.
Wallet also can combine few small (< 20 ORBs) inputs to make one input > 20 ORBs(which needed to form correct PoS block) if one of such small inputs find block, but at current difficulty it will take many time to find block for small inputs (few weeks of staking).

Why trades history hard split to currencies and Securities if custom filter exist at same time?

and in any case it operates at half:
If I choose Securities - sites shows Securities only (as expected)
If I choose Currencies - sites shows both Currencies and Securities

Same with Order History.

У меня на карту еще с 16го 2 платежа висят. После переписок с поддержкой на 6е сутки все-таки получил один застрявший платеж назад. А 2й так до сих пор и висит. И это уже далеко не 1й подобный косяк (именно с картами).
А поддержка все такие проблемы списывает на то что банк не принял/отклонил транзакцию. Хотя использовал 3 разных карты 2 разных банков(российский ПриватБанк - теперь дочка БинБанка и Русский Стандарт) и со всеми часто такие проблемы(примерно 2/3 транзакций сразу проходит, а 1/3 зависает или отменяется), при этом поддержка банков на вопрос по какой причине "отклонили" говорит что вообще никаких запросов на проведения транзакций из платежной системы VISA/MC(которые они якобы отклонили) к ним не поступало.

Явно косячит либо биржа, либо вероятнее всего не биржа а посредник-шлюз используемый для переводов на карты (cyberplat).
Т.к. на все другие платежные системы много раз переводы с GOC делал (КИВИ, Яндекс-Деньги, Webmoney) и все ходит без проблем. Максимум задержка на день-полтора бывает (а так обычно в течении неск. минут - часа все приходит).

С картами же примерно 1/3 транзакций приходится вручную разруливать. Причем хорошо когда транзакция просто повисит какое-то время в ожидании и допустим на 2й день отменяется и автоматом зачисляется обратно на баланс GOC. Хуже когда биржа рисует что перевод успешно выполнен, а на карту так ничего и не пришло. Идешь на киберплат проверять там - так и есть, висит ошибка, перевод не прошел (при этом на бирже отмечен успешным и деньги списаны).
В результате если каждый такой перевод в ручную не проконтролируешь зачисление и тикет по зависшим в поддержку не напишешь - то деньги считай пропали.

About a half of login attempts end by this error for me:


Seems server run out of disk space or exceed some sort of quota...

I thought I explained clearly ...
No, at the initial stage (first few weeks), the difference will be huge:
- if left 10k coins just by one big transaction - after 5 days will generate just 1 block (and awarded 1 coin). and the transaction will be divided into two (2x5000 coins). After a next  5 days will be generated 2 blocks (+2 coin awards, 3 total) and two transactions are divided into four (4x2500) and so on until wallet not split all transactions to <50 ORBs pcs
- if you manual split 10k to many small inputs (for example 250x40) you will get 250 blocks and 250 coins as reward (but it will take not just 5 days but about 2 weeks at current difficulty - because smaller input - longer it staking before find blocks)

But in long term is no any difference between manual and automatic - after some time (depend of size of initial transaction) all transactions will be split by wallet to 25-50 coins inputs.

So you decide - to spend time at the beginning to immediately start earning the highest returns possible or leave everything to automatically wallet control and wait while wallet itself will rump up to maximum revenue.
And any intermediate options also possible: if it's too boring and long to break into small transactions (20-50 coins) can be divided into medium sized - say by 20x500, and leave wallet to finish rest (500==>250==>125==>62.5==>31.25).

You get 1 ORB per each block found.

For detail how it work just read posts from previous page:

https://bitcointalk.org/index.php?topic=586674.msg7744291#msg7744291

https://bitcointalk.org/index.php?topic=586674.msg7778338#msg7778338

Nice list of stores/merchants already accepting ORB payment!

But check list - some of links is broken (stores/services itself working - just part of URL links broken)

ORB have fixed block reward (currently = 1 coin) not matter PoW or PoS generated.
So 1 ORB per block it is a minimum, maximum and average reward at same time. 

Не понял один момент:



Это в начале акция была которая закончилась как число пользователей перевалило за 1000?
Или первая 1000 самых шустрых так 1.5% и пользуется?