Well, I am generally of the persuasion that given the current state of most Bitcoin exchange APIs, Messaging protocols, etc., it'll be a long time before there is enough genuine incentive for exchanges to offer truly 'real-time' trading protocols.

Take BTC-E which runs a Metatrader server (and regardless of what you think of MT, it's still much snappier than the majority of the BTC Exchanges out there).

Given the majority of order-flow I speculate is still retail, there is little incentive for exchanges to build out algo-oriented communications protocols when the majority of your customers use the website to enter orders.

In short, I don't see 'Bitcoin Exchanges' pushing order messaging as it relates to trading 'forward', though there are some novel approaches to settlement (blockchain) and using multi-sig liquidity verification. At the end of the day if your customer is institutional they'll demand a variety of protocols - if your customer is retail, they probably don't care that much.

Hey jcrubino,

First make a list of the FIX protocols offered by exchanges, to my knowledge the one's offering fix are:

• Coinsetter - https://www.coinsetter.com/api
• There is one other one I can't think of right now...

Than I'd setup a number your benchmark too PING the APIs and record average latencies. I don't know anyone whom has done this yet as the FIX offerings across exchanges are pretty limited versus HTTP-esc and Websockets style protocols.

One gentalman whom is heavily involved in FIX and has an interest in Bitcoin: George Kledaras, http://www.wallstreetandtech.com/author-bio.asp?author_id=1421, see: http://www.wallstreetandtech.com/trading-technology/is-fix-protocol-use-declining/a/d-id/1252798?

I have a friend whom is working with the state-legislature to place Bitcoin in-between the precarious position of the dispensaries and financial institutions! If it works out it'd be a huge win for all involved.

I am running a `bitcoind` installation connected to blockchain.info's JSON-RPC, running testnet.

This is to save on diskspace / speed of a hosted server. This bitcoind is just a proxy to the blockchain.info wallet.

Document: https://blockchain.info/api/json_rpc_api

Is there any documentation about working with testnet via blockchain.info JSON-RPC api?

There documentation is awful.

Is there any way to get a UI to my testnet wallet there? Like running Bitcoin-QT against my proxy? Or am I stuck just tapping in JSON-RPC strings to learn about the state of my testnet wallet?

Interesting theory.

Agree with both people. I just wasn't positive if there wasn't some mechanism by which "holders" of these outputs would notified / capable of stopping additional output generation.

Lots of talk about the https://www.coinprism.com/ offering, but something I can't wrap my head around as people are pointing out how this concept might "decentralize" issuance of debt.

In the spec:


Now in example, say there were 5 "Colored Coin" exchanges and I had an "in-demand" asset, and controlled the private key to said asset. I could go around and issue myself more supply to sell on these exchanges, and the buyers would be none-the-wiser that they were just buying from me.

I mean the concept is great if you trust the exchange to control the private key (or a 3rd party). But you have to trust a 3rd party! Unless there is a mechanism that limits the future issuance "dilution" if you will of the original asset.

Maybe I'm just misunderstanding? Thoughts?


http://www.reddit.com/r/Bitcoin/comments/25my2d/colored_coins_open_the_doors_to_self_issued/

Parting out a mining rig. Have some other accessories as well if interested.

3x MSI 7970 3GB GDDR5, Excellent condition, original packaging and accessories. Still under manufacturers 3 year warranty. Purchased early 2013. Never overvolted.

Asking $200 in BTC each shipped.





1x CORSAIR 1200AX Gold with two bags of braided (black/red) cables. Excellent condition. No problems.

I wouldn't be so sure, there is a lot of legal precedent obviously since it's inception but the S&E Act of 1933 lays out specific guidelines of what constitutes a security, and and exception from registration. Though I think that is hardly the issue here, that would be more a separate criminal / civil case against this person/persons versus those whom may have purchased these securities, or lent this person money!

http://www.mitchell-attorneys.com/legal-articles/securities-registration-and-exemption/

Well best of luck than. It'll be interesting to see how some of these things play out in a legal sense. Obviously an unexplored legal avenue for people issuing "Shares" in a company via a unlicensed stock-exchange is illegal though to what result that has I don't know.

@RyanMilligan1 since you took to posting on my LinkedIn Group about this - perhaps you could share some more about your holdings in this venture (is it via shares you bought directly from this person?) or via Cryptostocks?

Also you have to remember legal fees to litigate against someone in another country (are you in the UK?) against a private party / private party's relationships' company could be an extremely expensive endeavor. A "legal" agreement for him to provide you with 'ownership' in a company or endeavor via 'Cryptostocks' is far from a legally binding agreement. At least in a US court of law.

I would say "Insider Trading" in terms of the Bitcoin trading marketplace as it exists today exists with shady exchanges (whom are not subject to ANY "trading regulation", rule books, oversight, etc.) allowing market-makers to front-run orders, or worse yet, acting as market-makers themselves.

That being said, like currency trading, the only "insiders" are those in central government institution levels that are privy to interest-rate / policy decisions.

HFT is another animal, and a harder one to solve in the disparate market of Bitcoin "exchanges" (I wouldn't call them all real exchanges...) It's still very much impossible to do the kinds of HFT that is common in most existing traditional financial markets, due simply to a lack of infrastructure / capitol / specialized products (futures, options, lending, interest rates).

It (HFT, ULLT, DMA) will happened, but only once Bitcoin or some derivative there-of migrates into more established infrastructure.

I've got an armoryd client running with a watch-only wallet on my web-server.

If I'm making repeated calls too 'getnewaddress' via the JSONRPC interface are their any practical limits on the number of addresses I can create?

I'd also like to know this...

I'm interested in any tools or source-code that might be out there for me to visualize (console print-out/whatever) blocks as they're being built on a local machine.

In the abstract I'd like too observe

• the current block-header, broken down into it's components as they change
• the currently added transactions as they are streamed in from nodes
• the list of transactions would obviously include the coinbase transaction etc.

I realize this is mostly transmitted as HEX data, so any tool that could reverse the components into a readable format would be great.

I know most of the block-chain explorers do this in some capacity - but I'd like to take a look at the inputs of unconfirmed transactions, how the flow works.

As a bonus it'd be cool to unwind the transactions (unconfirmed) and look at the TxIO as a set of addresses, is that possible ?

Update:

Looks like http://luke.dashjr.org/programs/bitcoin/w/eloipool.git is a good solution in Python for doing this sort of thing, doesn't rely on Bitcoind

I have an instance of armoryd fully indexed and running at the same time as bidcoind ( I am watching new blocks being added to the memory pool reported by the armoryd client )

Now I wanted to connect to it via JSON-RPC and being requesting new addresses, checking balances, creating unsigned transactions.

I see these methods in the armoryd.py code, but do I need to manually write my RPC interface to the client? Can I reuse one of the various bitcoind clients pointing toward armoryd? Are they similar enough?

Also..
When I check ~/.armory, I don't see any .conf files? Do I need to manually create one to set my armoryd password, etc. does it share the same structure as the bitcoind.conf?
[/s]

found the configuration file reference in the armoryd.py code.

update
Also here is a related question on SO: https://stackoverflow.com/questions/21049108/connection-refused-with-bitcoin-armory-deamon

I made some successful calls!


Couple of things to note, obviously had to install pyjsonrpc via PIP, and also had to create an `armoryd.conf` file in my ~/.armory/ directory, with the username and password in the format: username:password

This isn't documented so far as I can see, but wanted to point that out

Liteguy: as an active trader on BFX like yourself, I can only assume you were one of the largest account holders on BFX given the holdings you described.

I've been in the same situation with the illiquidity of the LTC orderbook on BFX before (in my case, being force liquidated as a large short went against me when the price rose quickly in Oct.? Or Nov.?) So I can at least empathize with your situation. Once the margin call went into effect, I essentially emptied the orderbook and bought back LTC at any price people were willing to sell to me which more erased my deposits.

That being said, you were trading a very illiquid market with a lot of leverage (4x, I think most would agree is small for normal currency trading / commodity trading) but very large for something as volatile as Bitcoin/Litecoin. Well I cannot judge your risk tolerance, I know that at some points this market becomes akin to a casino with the lack of liquidity and a small loss can become a very big one very quickly and it's prudent to double or triple your expectations of price movement before participating.

I think for those whom are in your situation it would be good to describe trade by trade why you made the decisions you did, and help others learn to better trade. I don't know your background, but given the amount of money you accumulated trading you are either a professional trader or early adopter? That being said, I assume the latter: given I don't consider myself a professional to the degree, I still wouldn't be comfortable taking 4x leverage in such an illiquid market - or with money I couldn't afford to lose.

I don't want to be condescending, but trading illiquid markets is very much a zero-sum game, as Giancarlo mentioned. If there were enough participants or depth the market would move more slowly and the speculative nature of huge price swings wouldn't exist.

Tabi: I know I spoke with you during this period, and I'm not an arbiter by any sense of the imagination for BFX. I will suggest however, that now that liteguy has taken the hit to his pride to disclose what happened that perhaps a bit more of a statement from BFX would help.

If I can vouch for Raphael and Giancarlo - I know that 1.) this is not a DDOS, and 2.) this is the hosting provider not the result of a hack/unannounced maintenance on their part.

ok nm. than sorry I misread and though my issue was related.

I personally have SWIFT wires credited in and out within 24 hours so long as I recognize US business vs. HK business hours. SO I instruct my bank to wire the money before the start of business US time, and than it is waiting when Asia opens (in the evening US) and I am typically credited that same evening / early the following morning.

So far I have had no issues with this. So cheers to BFX for doing such a good job with this! I'm sure it's no easy feat.

( The reverse is also true - withdrawing, but the hours are reversed obviously, because SWIFT is mostly manual for banks )