Interesting, I have earlier order 17204 and it's still not filled since ordering this morning..  It claims complete, but transaction never arrived at my bitcoin address.  Can you look into this?

Do you know if new stock will be in tonight?

You can use the IRC bot 'AssetBot' in #bitfunder on Freenode, or you can connect to the websocket and listen for the trades there.  If you want a historical copy of data, I can probably generate a json dump for you in a few days, after we've added the data which is currently missing.

The charts should show up now. 
There's some data missing which will be repopulated soon.  We've since moved to a more reliable method of collecting the data than relying on the IRC bot, so new data should be updating and live trades should be showing up.

burnside, if you were to start an exchange from the ground up, with the experience you have now, what would you do differently and what would you avoid?

I checked this against the data sent to the IRC bot and it is reporting the results as expected.  Wherever the site sends a + order to the bot, the trade page reports it as a +.  The [ + ] indicates that an ask was filled, a [ - ] indicates that a bid was filled.  Looking over the data, you'll see that the [ + ] is generally higher than a [ - ] order, which would seem to support the idea.  I think 'S' order on BTCTC site is for asks, in that the holder of the security put it up for sale and it was purchased, and (B) is for bids, in that a user who didn't own a stock put a bid up for one and this was filled.   If this is wrong feel free to correct me, I'd like clarification myself here if this is incorrect.

I'm working on a fix for that.  It seems to be something with nginx not keeping the connection open between the application server and the browser, so it requires a refresh of the page to see the page load.  If you connect to http://coinflow.co:8000/livetrades/ directly then it will work for the live trades, for now.  I'll update when I have a better fix in place for it.


EDIT:  Should be set now.

The only barrier to entry in becoming a moderator is capital.  The moderators have not been chosen because they are any more trustworthy than any other individuals.  It's a bought position, and this should be kept in mind whenever someone attempts to use moderator status to lend legitimacy to any 'proof' they raise.  Namworld's investigation to find that the BTCGrowth website is hosted on the same IP and utilizes the same service providers is more proof of identity than the word of an exchange moderator.  Now, if it was the exchange administrator , burnside, who had instead verified his identity, then I'd have accepted this, or some confirmation posting on the long-standing blog for the man instead of a newly created website.

The https://btct.co/api/tradeHistory ticker will display all trades from last 48 hours, but it's not limited to an individual security.

It sounds like that would require some really precision timing to work right, which I doubt is possible.

However, if you want to maximize your ability to buy through orderbook manipulation, then generating a large number of small orders is the way to go.  When you have insufficient balance, BTCTC will cancel your orders up to the point where you have sufficient balance to cover them on any one specific stock.  So, let's say you place an order on two stocks that have an identical price, stock A and stock B...  with stock A you have 20 bid orders of 10 stocks each, and with stock B you have 2 bid orders of 100 stocks each.   You make a trade on stock C which drops your available balance.   On stock A, the first 2 orders are cancelled, leaving you with 18 bid orders of 10 stocks each, and on stock B your first bid order of 100 is cancelled, leaving you with a single bid order of 100 stocks.   With a larger number of smaller orders, the cancellation leaves more order volume in place.

AFAIK, there's a 10 minute cache.  How long of a delay are you seeing? 

If you want something a little quicker, you can pull from my feed here (I plan on making it a little prettier eventually):

http://coinflow.co/livetrades

There's an SSE stream at /livetradeevents/ which aggregates data from assbot and assetbot on IRC.   It's not the 'definitive' source since it isn't the API (I use API data in the charts for BTCTC, not assbot data), but it's still reliable.

I'll make this prettier eventually, but for now you can watch the trades across all exchanges in realtime here:

http://coinflow.co/livetrades/

I'm trying to prioritize new features.  What would you like to see most.. a cumulative depth graph for the orderbook on those exchanges with API for Orders, or a simple moving average/exponential moving averages, or candlestick charts?

I can provide you with historical JSON trade data from the Coinflow site.  It has several months worth of bitfunder, havelock, and MPEX data pulled from IRC bot logs, since these sites don't have APIs with historical data.

Just replace '/chart/' in the URL of any page with '/json/' for the JSON data.

For example, any bitfunder JSON is at /json/BF/, for example, http://coinflow.co/json/BF/TAT.ASICMINER

I might work on creating a more complete export if there's demand for it...  I record whether it's a bid or ask, but that's not in the JSON currently.

I've had good experience with BTCQuick.com.  They accept credit cards via Google Checkout.

This looks very competitive compared with the other bonds out there, I like it.  Along with the high rate (for a bond) and daily payout, the exchangeability is a nice feature and makes me curious to see the future IPOs from TATI.  This is an interesting offering and looks like a good choice for diversification.

Memcached can work wonders.

This shouldn't affect my charting application...  I've already got a bot up to parse the IRC feeds, in addition to pulling from the API.  I grab the latest trades from the API for ltc-global and btctc, and use the IRC bots for Bitfunder, Havelock, and MPEx.  This shouldn't really impact charting applications, unless you're hammering the orders API endpoint every 30 seconds to get an up to date orderbook for some kind of cumulative depth graph (I'm not sure what the cache rate is on this order book currently).

But like I said, these are just speculative ideas on how to counteract the bot influences.. I don't necessarily think they all need to be implemented, I'm just brainstorming.  You're right that a dedicated botter would find a way around these measures and get their data some other way.  It really all depends on whether bots are really seen as a detriment or not, and whether the cost of inconveniencing the bot operators is worth the effort.. there's a point of diminishing returns where there's only so much you can do.

If we want to limit botting, I think a few other measures could (but not necessarily) be put in place:

• Longer cache on order book API.  This will not affect regular users but will require additional work by bot owners to grab up-to-the-moment data for their bots.  However, this just pushes them off to webscraping the orderbook.  Making the orderbook require authentication helps to identify the bots, and rate limit pageviews (kind of how CloudFlare detects a ratelimit violation when they help protect against DoS).
  
• Rate limiting the OAuth API order creation (or any order creation without 2FA)
• Charging a very minor fee for order creation and cancellation...  minimal enough to not affect normal users, but significant enough to add cost to running a bot 24/7 with constant order updates.  Something like 0.00001 maybe.  Perhaps allow the first 20 order updates per day to be free, to not impact the average user at all.

Really, these are just inconveniences for the bot owners, but they require some work and/or expense to overcome.  More barriers lead to fewer bots, and provide a fun challenge to the people attempting to create a profitable bot.  It is, however, a cat and mouse game..   as people build smarter bots, combatting them becomes more complex.  At some point the cost/benefit isn't worthwhile, and this cuts into dev time spent on new features or bugfixes.

Maybe require the receivers to 'pick up' the transfer by clicking a button, and allow the senders to cancel the transaction up until the pickup point.  This allows some window of opportunity for the sender to recover their error after realizing that he entered the wrong information a couple of times, verified it, and then clicked to transfer before it becomes permanent.  

Adding a unique hash to each user is a good, but really though, how far you go to account for user error can lead to an interesting cost/benefit analysis where much of your effort is focused on solving for the least common denominator.  It's usually more efficient to treat these as one-off cases and fix what can be fixed manually and leave a warning for the user otherwise.

In this case, I think reversing the transaction requires embroiling oneself in the affairs of the transaction --  getting approval from the transfer recipient and confirming that this was transferred to his account by mistake.  Otherwise, this method could be used as a 'reversal' technique for legitimate transactions.  The easiest way to solve this would be to simply ask the recipient to transfer back the shares they were transferred in error (that is, if he still has them).  However, since there's no messaging system between users on the site, there's no way for users to handle this on their own.  With admin intervention, if the accidental recipient disagrees that this was an erroneous transfer then this would place the admin into a position as an arbiter, which he shouldn't be in, especially with no legitimate proof either way on whether it was an erroneous transfer.  In such a case, I'd have to agree with leaving the transfer alone and not reversing it, since ultimately it's the user's responsibility to confirm that the recipient information is correct before they submit it.  

Maybe add a disclaimer about transfers being irreversible.