I thought the same thing! Then I started learning about FIX. Unfortunately, it's a disaster.
Worst case of design-by-committee I've ever seen. More of a trainwreck than all the XML standards rolled into one.
I think the meta-problem here is that FIX was created by the big Wall Street firms, and for them hiring ten programmers instead of one to implement some needlessly-overcomplicated protocol is no big deal. In fact, the IT managers kinda like this because it increases the size of their fiefdom. So, sadly, pre-bitcoin the organizations in a position to standardize this kind of thing also had an incentive to make it as complicated as possible.
In principle I'm in favor of standardization, but if an API is designed well it should really only take you 2-4 hours to write a plugin for it. I guess that's part of the reason why I'm so prone to rant about crappy APIs. If the exchange does a good job, the fact that there's no standard isn't really that much of a big deal.
I think you forgot to consider "quality of design" versus "quality of implementation" dichotomy. You also completely neglected "cost of initial implementation" versus "cost of ongoing maintenance". FIX maybe like a camel: a horse designed by a commitee. But it has some of the best and most reliable implementations. I wish that hiring one smart programmer would always guarantee a good solution. But I'm emphatically absolutely positively sure that this isn't a case. Your LiMP design is nice, lean and mean. But for comparison take a bitfury's proposal of mining protocol, where he had made completely newbie mistakes: https://bitcointalk.org/index.php?topic=84791.0I actually have an extensive experience in deploying and maintaining SOA (Service Oriented Architecture). We've been in a good position to be able to charge per-request and per-error, and our TOS contract has special provision to deal with people who believe that "if an API is designed well it should really only take you 2-4 hours to write a plugin for it." Both salespeople and tech support people are trained to recognize them as problem customers and charge/treat them appropriately. I posted about this earlier in slush's thread about Stratum: https://bitcointalk.org/index.php?topic=55842.msg664479#msg664479Anyway, I was going to post links to a quite well designed trading protocol that is easier to implement than FIX. But Interactive Brokers are now require to have a properly funded production acount before they let you play with their API with a "paper trading" account. You may still want to review the freely available demos and documentation. I just post one quote from the "IB gateway" (technically the better term would be "IB proxy") I find crucial: Must remain running to maintain access to IB trading system. Yes Yes
|
|
|
|
I was absolutely floored when I found out that $100 million MBS trades are done by voice telephone call.
Now, the call is recorded, but still… no crypto, nothing. Yow.
Just for the historical explanation purposes: For the telephone trading the primary line of defense is ANI: http://en.wikipedia.org/wiki/Automatic_number_identificationStraight ANI is often strenghtened by either quick comparison with real time billing information or various SS7 tracing/call maintenance features. http://en.wikipedia.org/wiki/Signalling_System_No._7While pikers trade with touch-tones the whales get service of the dedicated VIP staff. It is a form of biometric authentication, people employed in high-value account service have extraordinary auditory memory (or visual memory, for the in-person service). |
|
|
|
Since every part of Bitcoin and largely the web uses JSON it would be better suited.
Just establish some protocol on how to format the messages.
I'm inclinded to agree with this. But just not any JSON. JSON as used in Stratum and Stratum Mining. Mr. slush had made a good compromise between the ease of implementation and the reliability and scalability(power efficiency) requirements. So Stratum Trading protocol would be a great short-term choice. It is also a good long-term choice if your goal is to stay in the Bitcoin wading pool forever. But if you want to sail the seven seas sometime later you'll have to learn the protocols that the sea-faring navigators real traders are using. |
|
|
|
as I was worried that real world financial institutions didn't seem to be concerned about ever being able to prove who ordered what...
For the traditional finserv houses this rarely is a problem. In their very competitve world the main problem is when customer wasn't able to place a trade when s/he wanted to. Besides, whatever authentication was used at the protocol level it will never be a single line of defense. There are always some other form of order-stream monitoring tools running behind. For small-timers the trades are reversible and they are insured. For big-timers there are VPNs and dedicated connections. And pretty much everyone, big or small, can place an order over the analog phone line, including wireless where there still is analog wireless available. Edit: also, FIX (and others) are connection-oriented giving additional measure of monitoring and safety. |
|
|
|
what is the difference between what you propose to be done via satellite and a typical Internet via satellite service?
The main diffrence for the satellite receive-only terminal is related to the required precision of the installation. When terminal is never radiating anything towards the satellite it is much cheaper to install and the terminal itself is also much cheaper and smaller. |
|
|
|
MPEx sort-of started from there, but changes kept being brought to the point what we use now is barely reminiscent.
Can you describe those changes in a paragraph or two? Was there something missing? I'm actualy more interested in the motivation for changes than the actual software changes. I'd like to understand motives, if possible. Technical details I would consider secondary. |
|
|
|
I think we should make an opensource trade lib as a reference implementation.
I just wanted to ask one question to all people here thinking about the exchange API standarization: Why don't use an existing standard like eg. FIX protocol? http://en.wikipedia.org/wiki/Financial_Information_eXchangeTheoretically it alrady has everything that's required. So what are the roadblocks? Are they technical or ideological? Maybe a software architecture mismatch? Is FIX simply too difficult? Or is FIX considered tainted for some reason? Thanks in advance for any light you may shine on this question. |
|
|
|
.NET/WCF supports the publish/subscribe-model, even for multiple clients. But I don't know how connection errors are handled.
All right. So it looks like I've been successfully trolled by flipperfish, and in almost exactly the same way that ruski had trolled me over a year ago on the same forum. @ 2112, are you sure it would be so hard to modify it? My favoured language is VB/VB.NET, and while I can read C++ and it won't take long to pick up, I won't get anywhere trying to read the entire program for what I need. If you could find the initialization code ie. sub Main for the whole program, so I can work from there, it'd be a big help. May not be so difficult as you think.
The take-away for me is that I'm really vulnerable to Microsoft trolls who offer .NET as viable, portable and open sourced implementation of Bitcoin. Props to flipperfish. |
|
|
|
I don't understand the problem you see here. Most RPC standards use TCP as underlying layer, which ensures reliability (and even order of arrival).
Two-way communication is needed anyways, else the server could not send its response back to the client.
By two way communication I mean the conceptual two-way not transport two-way. In other words: client makes one request and server keeps providing multiple replies until canceled. On the conceptional level, 2-way communication can also be achieved by implementing both server and client on both sides. Many RPC-implementations also offer this as part of their protocol (like in the example you mention).
Then please name those implementations! I'm aware of very few and they are all from moderately to very complex. By reliable I mean the following: 1) Can discover a temporary transport failure and provide a way to reconnect at the transport level and to replay the missing notifications from the server to the client. 2) Can garbage collect truely stale connections from the clients that really died. 3) Does 1) and 2) with reasonable overhead. I'm immediately disqualifying any implementation that keeps a per-client queue of outgoing messages on the server. They are just too easy to DDoS, although I'm aware of several vendors actively peddling such solutions (just not in the Bitcoin domain). Any implementation that can replay from a single shared transaction log is fine with me. By the way: "official" JSON-RPC supports asynchronous notifications from the client to the server. This is not what is required here and the slush's contribution is that he had found a productive way to "abuse" the existing implementations to do the inverse notifications. |
|
|
|
OK, so this is the leading architectural misconception: interfaces can be made around it using XMLRPC API
The "node-state-provider" could be implemented in various ways (e.g. as RPC-Stub, ...).
None of the commonly-mentioned RPC standards offer a reliable two-way communication between a client and a server. In the Stratum design slush had found a way to abuse the JSON-RPC "notification" mechanism to implement the inverse notification: from the server to the client. Now I understand better the added value of the trading engines like MetaTrader, etc. : they hide the the essential asynchronous nature of the financial networking: the user isn't just making requests and receiving responses. The financial user needs to be made aware of the changes occuring in the outside world: be it securities exchange trades or P2P bitcoin transactions. MetaTrader (and similar designs) just sandbox the user's program in a way that the aggresive polling is not visible outside of the user's machine. Financial industry had various solutions to this problem available for years. One of the simplest: FIX protocol is about 20 years old now. http://en.wikipedia.org/wiki/Financial_Information_eXchangeUnfortunately I see a long and painful road forward for Bitcoin implementers and integrators. If the prevailing attitude will be that "no deficiency can't be resolved by simply polling more often" then the progess will be exruciatingly slow. The intense trading activity will be indistinguishable from the DDoS attack. The battery life of any portable Bitcoin devices will be very bad. |
|
|
|
I feel the minimal separation which would be desirable is to split current client into hardened transaction server and move the wallet, addressbook, GUI etc. into thin light client.
One could argue that the minimal separation is an already solved problem: Electrum client/server communicating with the Stratum protocol. As far as I understand the main opposition argument against the Stratum-based implementation is that it will be susceptible to the MITM attack. In my opinion assuming single P2P-network module in any design is an oversimplification. Perhaps it would be better to have two kinds of P2P modules: 1) P2P-participant: a module that stores the blockchain (either directly or in cooperation with another module) and is capable of both sending and receiving the Bitcoin transactions. The transactions in this module are always fully verified. 2) P2P-observer: a module that stores only block headers (in the SPV fashion) and can only receive the Bitcoin transactions including the ones that fail verification. The main distinction required for this module is that it doesn't make a direct connection to the P2P-participant module used by the same client. In other words it will report existence of "our" transactions, transactions that our client had sent, only when it had seen them propagating on the outside network. Both version of P2P modules would benefit from a persistent way to store what currently is the volatile mempool: the in-flight transactions that are not yet recorded in the blockchain. This would be of great benefit to the people who are actively mining, either solo or as a pool operators. Obviously there is a lot of overlap in the functionality I described above. So maybe the better design would be to roll them together into a single module, but include an additional "participant/observer" flag in its API? On the other hand the P2P-observer module is significantly less resource intensive. It could also be a quick and neat way to discover MITM attacks on the Stratum (or similar) protocol. So then maybe make a "participant/observer" flag an instantiation choice for an unified P2P module? The P2P modules instantiated in the "participant" mode will be able to respond to the API call with both "participant" and "observer" flag. The P2P instaces created in the observer mode will only respond to the API calls specifying the "observer" mode. I'm quite certain that an architecture for a robust Bitcoin implementation is still an open problem and worth further research and discussion. All current implementations are quite fragile and are incapable of properly dealing with the known failure modes of the Bitcoin network. |
|
|
|
I've read the 2PC Wikipedia page you mentioned, you want the "SQL server" and the "bitcoind daemon" to act as "cohorts" in the protocol. In that case, the "bitcoind daemon" should act as follows: - When a "query to commit" is received, select a sufficient amount of unlocked confirmed unspent transaction outputs for the transaction, and lock these (so they are not used by other transactions). If this fails (insufficient unlocked confirmed unspent tx outputs), reply "NOK", else reply "OK".
- When a "commit" is received, spend the locked tx outputs.
- When a "rollback" is received, unlock the locked tx outputs.
Now, as always, the devil is in the details. These are some I thought of: - The two-phase commit protocol has no time-outs. When one component fails to send "OK" or "NOK" in the first phase, all resources stay locked until the problem is resolved, e.g. by restarting a crashed service.
- After resolving a failure, all in-progress transactions need to be finished. It may be needed to re-send information, but this resending must not result in a transaction happening twice. This can be avoided e.g. by giving each transaction a unique ID.
- If it turns out in the second phase that the transaction fee (selected in the first phase) is too low, then extra bitcoins be needed to increase the fee, but these are not guaranteed to be available. This is a problem, because in the second phase, the transaction is already supposed to be committed. To avoid this, a sufficient amount must be locked in the first phase, to take into account the highest possible fee needed. If the required fee is lower than the maximum, the rest can always be sent back to self.
I think this can be built on top of any bitcoind (including the existing one, without changing anything to bitcoind itself), as long as the implementation of this protocol is the only process which uses that bitcoind. Although it sounds like useful not-yet-implemented functionality, I don't think it's necessary to involve this functionality in the module definitions at this moment. Well, what can I say? Building a Chernobyl-style containment structure around the existing bitcoind is also a form of software architecture. For some Bitcoin users this would be even preferred choice when compared with a clean-slate new design. For those of the readers who are alergic to Microsoft Windows I've found another learning resource. On the Oracle Technology Network there is a compressed virtual machine image called "tuxweb.7z". It contains a simple Apache-based web-store with the Oracle Express and Tuxedo as a backend. I just want to make it clear that the above isn't a preferred solution for the web-store ventors on this site. It would be akin to using a harvester combine to mow the backyard. But for anyone contemplating scaling up the Bitcoin solution this is the way to go. Even if you are ultimately going to come with something different seeing the harvester combine at work will be an usefull learning experience. |
|
|
|
Oh, and by the way: here's a very nice post from DeathAndTaxes in the same vein like the original post of this thread: https://bitcointalk.org/index.php?topic=101686.msg1113573#msg1113573He's coming from the large enterprise background, he had seen the transactional processing being done on the Microsoft software. He's just not a software architect, but more of a data center operations manager. |
|
|
|
If I'm a wallet module that handles orders on behalf of a web storefront, the disposition of the payment isn't immediately useful until I'm ready to ship their order. If I make a query to my "knowledge center" to see if a payment made 3 hours ago is continuing to receive confirmations 5 minutes before I'm about to print the label and ship the product, is an asynchronous notification really necessary?
First, before concluding that the solution is unscalable, the problem needs to be defined. You and I and others might legitimately have a different idea of what the problem is, which is part of why a solution whose parts can be replaced would be so valuable.
I kinda understand your reservations now that I know that you are coming from a fiercely independent small businessman background. To you reinventing the wheel of online transaction processing may sound and look like a worthwhile endeavor. I come from academic background and as a student my school tortured us on a near obsolete mainframe with CISC, ACP& PL/I to imbue us with knowledge of how to avoid reinventing the wheels. The "problem" you are writing about is well defined since about 1970-1980 and it is called http://en.wikipedia.org/wiki/Online_transaction_processing or http://en.wikipedia.org/wiki/Transaction_processing . I don't have an evangelical bent. Anyone is free to peddle their wares here. I'll just call it the way I see it: gold-foil wrapped turd. We could go back and forth like it went in the Stratum thread. But I now understand that people here need to lose their own money to learn something. |
|
|
|
Can you point me to some resources that demonstrate this (e.g. forum threads)?
For one example of a difficult-to-solve problem search the board for the phrase "inversion of control". You can also see for yourself by experimentally comparing "bitcoin-qt -server" and "bitcoind" behave when sending coins via RPC with a fee required. I don't see how a transaction can accidentally be performed twice.
Consider a following (incorrect) attempt to implement an http://en.wikipedia.org/wiki/Two-phase_commit_protocolbetween an SQL server and a bitcoind daemon: 1) START TRANSACTION 2) SELECT amount and destination address 3) call "sendtoaddress" bitcoind via RPC 4) if OK then UPDATE account balances and COMMIT TRANSACTION 5) if not OK then ROLLBACK TRANSACTION Now consider that the bitcoind had a really complex wallet containing mutiple thousands of unspent coins and also a backup was running on the disk cointaining the .bitcoin directory. The RPC call timed out. What do you do now? How to fix this problem? While concepts like ACID are familiar to me, I might not understand everything immediately, especially in the field of accounting-the-official-way.
If you are not allergic to Windows the easiest way to learn how to correctly perform distributed transaction is with Microsoft Office. Just create an Excel macro that causes an update in a separate database running under Access, while Access is running some repeated updates on its own. This can be made to work correctly as far as Windows 95 OSR2 and Office 97 with the help of MS DTC. Obviously, newer version of Microsoft product will work too. |
|
|
|
When properly isolated, a wallet module shouldn't need to deal with asynchronous anything, or anything to do with peers. A wallet module (which I define as something that manages a collection of private keys and produces/signs transactions desired by its owner), should interact only with a "knowledge center" and its user.
It should be able to get by simply by consuming a stream containing notifications of the following:
* A new transaction you(the wallet) may be interested in has arrived. Here it is.
* A transaction you're interested in has had a change in confirmation status (where confirmation statuses include "unconfirmed", "X confirmations", and "invalidated") and/or spend status ("confirmed spent", "unconfirmed spent", "believed unspent").
A wallet doesn't need to listen for notifications if it can simply query for an update on all that information when it's needed.
Correct handling of asynchronicity is a necessary requirement for transactionally correct and efficient implementation of Bitcoin. This has been rehashed in detail in Slush'es "Stratum" thread. Stratum is essentially an attempt to implement RPC-like protocol separating walet client from the p2p network+blockchain storage server. https://bitcointalk.org/index.php?topic=55842.0You can attempt to fake asynchronicity by frequent polling (you called it "query for an update") or hacks like long-poll. But this isn't scalable solution and ultimately it will also fail, just in a different way than the typical damn-the-ACID hacks. |
|
|
|
I'm sorry what are you saying? That it doesn't matter?
I'm sorry I wasn't precise enough. "floating point" doesn't always mean "binary floating point". It could mean "decimal floating point". And decimal floating point is perfect for handling the financial data. Many C compilers support it (GCC since 4.2). Unfortunately no equivalent C++ standard has been developed. Anyway, the rounding errors wont matter for BitFinEx. It will fail as many other bucket shops failed, they aren't even pretending to hedge their leverage. Zhoutong at least made nice story while pretending to hedge. |
|
|
|
|
Show Posts
