In my country software must be certified to be used as a proof in the court. If u sign anything with uncertified soft it means nothing.
I don't think that's a problem. Open-Transactions does all of its crypto through an abstract base class, called OTCrypto. It's very easy to swap in different crypto libs by subclassing OTCrypto. For example, someone could make OTCrypto_GPG and easily make a version of OT that uses GPG. However, the current version of OT uses OpenSSL (through a subclass called OTCrypto_OpenSSL.) Therefore, all the normal x.509 cert stuff should work with OT Nyms. Personally I don't like certificate authorities, I think it's just a big spy network. But if you like 'em, OT should work fine that way. |
|
|
|
Lots of exciting news and updates! Well I want to thank our contributor da2ce7 whose API updates have finally been merged back into the main branch. Great job da2ce7!! I spent a lot of time over the past few weeks updating the scripts and java code to go along with the new API, as well as adding a lot of new opentxs (command line) commands. (Some details below.) As always, we've placed a huge priority on making builds available and easy to replicate, for the Windows, Mac, and Linux platforms, in a variety of languages. --------------------------- Win32 builds of the OT-API! for C++ and Java. Zipfile: https://github.com/FellowTraveler/Open-Transactions/downloadsWith: C++ headers, .java API files, exes, libs, and DLLs. (Source code available at same URL.) --------------------------- FYI: You can also build this same API for PHP, Perl, Python, Ruby, C#, D, etc. Makefiles and MSVC project files ** ARE ** provided with OT! Remember, it's an open-source project, so feel free to pitch in! Bitcoin donation address: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ --------------------------- Moneychanger (Java test-GUI) pre-built jarfile: https://github.com/FellowTraveler/Moneychanger/downloads(Source code available at same URL.) --------------------------- Linux... Thanks to contributor randy-waterhouse: .deb, tarball, etc: https://github.com/randy-waterhouse/opentxs/downloadsTo build your own: https://github.com/randy-waterhouse/opentxs/blob/master/docs/INSTALL-MEMO-Linux.txt#L93Awesome!! --------------------------- Are you a Mac or Linux developer, want to get started with OT? Try this: mkdir ~/Scratch cd ~/Scratch git clone git://github.com/FellowTraveler/Open-Transactions cd Open-Transactions autoreconf -i -f mkdir build cd build ../configure --with-java make make install --------------------------- opentxs -- command-line tool The command-line tool was written in OT-script, courtesy of the chaiscript project: www.chaiscript.comThe opentxs script is entirely contained in this file: https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/opentxsSpecifically, all the commands that you see when you type "opentxs help" or "opentxs list" are implemented in this one file: https://github.com/FellowTraveler/Open-Transactions/blob/master/scripts/ot/ot_commands.ot(So you have plenty of easy-to-copy sample code showing how to properly use the OT API in a software program.) This was all written using an OT-script implementation of the OT high-level API. --------------------------- The OT high-level API The complete code for that high-level API is available here in OT-Script form: https://github.com/FellowTraveler/Open-Transactions/tree/master/scripts/ot--------------------------- There is also a Java version of this same high-level API: https://github.com/FellowTraveler/Moneychanger/blob/master/src/main/java/com/moneychanger/core/util/OTAPI_Func.javaMoneychanger was built using it, so for examples of how this Java API is used, please refer to the Moneychanger source code. --------------------------- Using the High-level API (article): https://github.com/FellowTraveler/Open-Transactions/wiki/Use-Cases--------------------------- Enjoy! Your buddy, -Fellow Traveler P.S. Don't forget to check out the new test script written in bash. It's located in the Open-Transactions/scripts/tests folder. P.P.S. Some info on the new commandline commands: Send a direct transfer from FT's Silver account to Bob's Silver account: opentxs transfer --myacct FT --hisacct "Bob's Silver" Send a cheque, drawn on FT's Silver account, to Trader Bob: opentxs sendcheque --myacct FT --hisnym "Trader Bob" Send an invoice from FT to Trader Bob: opentxs sendinvoice --myacct FT --hisnym Trader You could also: opentxs payinvoice As well as: ... accepttransfers -- accept all transfers in the asset account inbox. acceptreceipts -- accept all receipts in the asset account inbox. acceptinbox -- accepttransfers + acceptreceipts ... acceptinvoices -- accept all invoices in the payments inbox. acceptpayments -- accept all cheques/cash/vouchers in the payments inbox. ... acceptmoney -- accepttransfers + acceptpayments acceptall -- acceptinbox + acceptinvoices + acceptpayments To create a password-protected cash purse: opentxs exportcash --args "passwd true" This way, when you give the cash purse to someone, you don't have to know their public key in advance (to encrypt the purse to their public key.) Instead, you just tell them the passphrase and they can import the cash into their own wallet, using: opentxs importcash It's pretty slick! ...More in a future episode. |
|
|
|
The Open Transaction is good idea for small financing project, but not a good idea for large money. We should not say that "we have to always trust the issuer" for large amount of investment. We should say, we should be able to easily show the evidence to court and claim our rights.
If someone issues a number of shares onto an OT server, you can only trade those shares by importing the currency contract into your wallet. From there, every transaction you perform will result in a signed-receipt, proving your current balance. If you have the signed currency contract, and the signed receipt proving your balance, what else do you need when you go into court? |
|
|
|
|
Very exciting!
I am interested in this for OT. What can you tell us about the platform, OS, RAM, etc? I would like to make sure OT is able to run on your device.
|
|
|
|
The server has been updated to the latest Open Transactions code Mark, OT server is a brilliant concept and fulfillment but is actually quite vulnerable to government attacks in different jurisdictions from legal and regulatory point of view. you are openly running a server in a given jurisdiction, and if that server is being used to process real money (vs, say, game tokens) then I could see how you could come under the jurisdiction of local authorities, and need to comply with AML and KYC requirements. (Also, keep in mind, in OT there is a difference between a "server operator" and a "currency issuer.") However I don't see any technical barriers to running an OT server anonymously on an anonymous network, and being paid to do so in Bitcoin. I'm not recommending that anyone actually do this, but I'm curious how you believe an OT server, in that scenario, is "actually quite vulnerable to government attacks" ? Doesn't the use of Bitcoin for moving funds on/off of an OT server mean that the server can operate in a censorship-resistant fashion? What good is Bitcoin otherwise? I'm also curious how Silk Road could still be operating, if that were true, since it seems like a similar example. Have you ever thought of merging OT server with Electrum server project?
Please be specific about what you are trying to accomplish. For example, why would you integrate the OT server with anything at all? Normally, commands are sent to the OT server from the various clients, using the OT client API. ( https://github.com/FellowTraveler/Open-Transactions/wiki/Use-Cases) So NORMALLY, if you wanted to integrate OT into some other software, you would be integrating the OT client API, not the server. My (limited) understanding is that the "Electrum server" is actually a Bitcoin client. In which case, I could understand the value of integrating the OT client API into it, the same as I could understand the value of integrating the OT API into any other Bitcoin client (or Bittorrent client... or web client... or sip client...) but I'm still not sure exactly what you are trying to accomplish through the integration. Technically you can already link OT to anything else, since OT has a powerful command-line utility that is fully-scriptable. So any UNIX-style scripting to connect OT with other transaction systems is completely possible. If your point is that OT needs a graphical user interface, I agree with you--but Knotwork is a server operator, not a coder, so he is unlikely to be the person who writes the UI integration you desire. I am also unlikely to take on some new project (such as a commercial-grade client), since my free time is already all booked up on OT itself, which represents (so far) 3 years of my life spent working to create software for you, for free. Thus it will have to be left to you (the open-source community) to "stand on the shoulders of giants" and create whatever OT clients or integrations you need. Luckily, it has specifically been designed for this purpose, and so those of you who choose to do so, will find the path has already been cleared. |
|
|
|
Anyone working on this? I can do it, but I don't want to waste my time if someone else already started work.
Also, what are you looking for - desktop Windows client? Crossplat java client? A JS based web client? Can be designed so private stuff don't travel to a 3rd party server.
A cross-platform java client would be best. We have a Java test GUI already but it's just that: a test GUI, not a real client. Therefore we need at least one NICE client that runs on ALL platforms. As for the JS web client, how secure can that be, and will it require a browser plugin for the OT client DLL ? Just curious how that would work. |
|
|
|
The long-term vision is to store the backing Bitcoins in a voting pool on the blockchain (rather than directly with an issuer) in order to protect the users from being ripped off by the issuer. Voting pools aren't coded yet though, so for now, you would have to trust a Bitcoin issuer, the same as a gold issuer or any other kind of issuer.
Payees would have to then bail their BTC-units back off the OT server (and back onto the blockchain), through their BTC issuer. (And eventually, through a multisig-based voting pool on the blockchain, which would act as the "issuer.")
So you could pay dividends using shares of the company (since any asset can be used to pay dividends)? Interesting. No, it won't let you pay a dividend in the same asset type as the shares. For example, you can't pay Pepsi dividends using Pepsi shares. Any other asset type should work though. Could you go into more detail about what this multi-sig based voting pool is?
In Bitcoin it's possible to send a transaction to more than one Bitcoin address in a single spend, such that a vote of the recipients is necessary to transfer back out. Then it's just a matter of setting up a protocol between any group (say, a group of OT servers) where they agree to vote in favor of any bailout requests that are properly signed by both parties (wallet and server in question.) Then if the signatures check out, they just take a 4-out-of-5 vote (or whatever), and transfer the Bitcoins back out. Even if the OT server you are using disappears entirely, you would still be able to submit a recovery request to the other servers and get your vote. I've posted extensively about this, if you are curious to read more. Also check out the OT wiki. |
|
|
|
I guess what I am envisioning would be a front-end client for Open Transactions,
which associates a bitcoin address with the shares,
allowing the issuer to for example, send dividends or coupon payments to share holders.
Here's how you would do that on OT: 1. Have a Bitcoin issuer, who holds actual Bitcoins, and who issues Bitcoin UNITS onto the OT server, where OT users can open BTC Unit accounts, and trade around these units (exchanging them back out with the Bitcoin issuer, whenever they want to get back off the server.) The long-term vision is to store the backing Bitcoins in a voting pool on the blockchain (rather than directly with an issuer) in order to protect the users from being ripped off by the issuer. Voting pools aren't coded yet though, so for now, you would have to trust a Bitcoin issuer, the same as a gold issuer or any other kind of issuer. 2. Have a stock issuer for each type of shares. For example, if you issued "Pepsi shares" onto the server, then you must be the Pepsi issuer. You could issue some Pepsi shares, in that example, and then sell them on the OT market in return for BTC units, or any other currency issued there. 3. Whenever the Pepsi issuer is ready to pay a dividend, he chooses the currency it's paid in (let's say, BTC units, or centicoins or millicoins) and he also chooses the payout per share. OT will then loop through all the Pepsi accounts and send a cheque to each account holder, based on the number of shares in his account. 4. Each payee receives a dividend cheque in his inbox, denominated in BTC units. He can cash the cheque, or deposit it into any BTC-unit denominated account. (This is all working already.) 5. To get actual Bitcoins back off of the OT server, the payee would take his BTC units to the BTC units issuer, and get a blockchain transfer of actual coins. 6. It would be possible to code the OT server itself to act as the BTC issuer, which would automate things without involving any third parties. But then you would have to trust the OT server with your Bitcoins during the time it is holding them, which means you are vulnerable to a malicious server, or a hacked server. I have therefore avoided this in order to protect the OT brand, preferring instead to aim for the eventual "voting pool on the blockchain" solution, which is more secure than having to trust an issuer. It wouldn't be hard to write some scripts that receive Bitcoins (using whatever tools you would use for those already) and then use an OT-Script to issue units onto the OT server, or to remove said units, using whatever rules you devise based on what you are trying to do on the blockchain. The entire OT API is available in script form now, so there's no reason you can't automate behaviors using cron and existing Bitcoin command-line tools. In other words, while OT does enable you to issue shares, and to pay dividends, it doesn't pay those dividends directly in BTC to a blockchain address. Instead, it pays the dividends in OT-BTC-units, internal to OT, by sending a cashier's cheque to each shareholder, just as it might pay dividends in gold, or silver, or other currencies. (Any OT units will work.) Payees would have to then bail their BTC-units back off the OT server (and back onto the blockchain), through their BTC issuer. (And eventually, through a multisig-based voting pool on the blockchain, which would act as the "issuer.") |
|
|
|
The problem I forsee, and it is one shared by bitcoins, is that the distributed hash table just keeps on growing, like the blockchain. The more popular the system becomes, the faster the database grows, and the more memory needed to save it. Is there a way to keep all the necessary data without the ever-growing pile of everybody's data?
To be clear: Open-Transactions does not need to store any historical data, other than the last signed receipt. Most transaction systems break down without their historical data, which is necessary for them to prove the current state of the system. But Open-Transactions is able to prove your balance, as well as which instruments are still valid, and which transactions have closed, without storing the entire history, but instead by merely storing the last signed receipt.Therefore when OT places receipts in a DHT (which it doesn't do yet) it will only be for a temporary period of time, in order to facilitate receipt exchange, and to give auditors access to the receipts. It will not be because of some need to keep them around as "necessary data" and it will not result in some "ever-growing pile." I hope that clears it up. |
|
|
|
|
FYI, for "shares" based asset types, OT actually keeps a list of all the accounts of that asset type. (That's how it is later able to loop through all those accounts and send a dividend cheque to the Nym based on how many shares he owns.)
So it actually wouldn't be hard to provide the account IDs, balances, and owner NymIDs for those shares, to the issuer. We could add a message that requests this data, if the issuers of shares need access to it. Alternately, we could also make it an option inside the shares contract.
|
|
|
|
You probably heard that GLBSE went down recently. I am hoping someone out there can code software that uses BTC address signed contracts and allows companies to issue and track their own stock shares instead of relying on a single third party. In short:
1) Company announces a number of shares for sale.
2) Users bid on shares
3) Once bidders win, they pay for shares, and their BTC addresses become the owners/signature for their shares. I.e. shares are tied to a BTC address, not to users.
4) Company issuing the shares stores the ledger that states "Bitcoin address X owns so many shares," and any dividends get paid directly to those addresses
5) If a user wants to sell/transfer their stock, he sends a transaction message signed by the BTC address that owns those shares, telling the company ledger that the sold shares now belong to a different address
6) Company updates their ledger, and pays dividends to the new address.
This way
- you only have to trust the company issuing shares (and if you can't, you wouldn't buy those shares anyway)
- there are no costs associated with registering or trading stocks unless the issuing company takes a fee themselves
- stocks traded on the open market can be traded through third party auction houses similar to and as simple as eBay style bidding, and can be traded privately among users using OTC.
- shares can be sold by any company in any country, without concern about what regulatory jurisdiction a specific exchange falls under.
I wouldn't think something like this would be TOO difficult, since it doesn't even rely on Bitcoin transactions and blockchain, just signed messages and any means to see what address payments came from. Comments/suggestions/improvements?
Using Open-Transactions, you would still have to build your website or user client (we only have a test GUI and a command line utility.) But OT would save you a lot of work and re-inventing the wheel that you would otherwise additionally end up having to do. OT provides an easy API for financial transactions, specifically allowing you to: --- Issue a currency or shares. (Similar to GLBSE I'm sure.) --- Trade account balances on markets against other asset types. (Similar to MtGox or other market exchanges. I assume GLBSE as well.) --- Pay funds between users (with or without accounts, since a variety of instruments are available, including cash.) --- All account balances are unforgeable and the server cannot change them without the user signing-off first. (This all happens behind the scenes as you perform your transactions.) --- Dividends are functional now, and are paid as a cheque sent to the inbox for any Nyms who are shareholders. (Based on number of shares owned.) After all transactions, each user has the "last signed receipt" which proves the balance of his account. (Even if the server disappears...) I think Open Transactions may be a hell of an overkill for this. Since a single entity is being invested in, that single entity can be the centralized source that keeps all the ledgers and keeps track of all transactions. It doesn't really matter if they decide to change their system or use a different database, either, since all that they have to store is "Address so-and-so owns so many shares, until we get a BTC signed message to tell us otherwise." And if the company goes down, it won't matter which exchange manages the stocks, since they would be worthless. Admittedly, I am only barely familiar with Open Transactions. I just could never figure out the point of using a second layer to send Bitcoin to someone when you can just send Bitcoin directly. Maybe there is a module in OT that already does most of what I described?
Regarding not being able to change someone's balance, I'm not sure why that is required. A centralized exchange can also arbitrarily change people's balances, though that would not be very, um, nice. And not having restrictions on changing balances means a company that controls the stock can do stock splits etc. without needing permission from everyone.
The point is, yes, there would be a single point of failure, and a single entity to trust, but that point of failure and trust is also the company being invested in, meaning the trust is redundant. If you can't trust the company to do basic accounting, you likely shouldn't trust them with your investment. And to get something like this off the ground, I imagine all that's needed is a simple database, and a not-so-simple front-end.
You are correct that a single entity could act as the "issuer" for any given stock, and manage the books offline without needing any software. OT manages the lower-level details for you, such as account security and balances, market trades, paying dividends, etc. You could also do all that stuff by hand if you really wanted to. But OT's API is pretty easy to use, if you check it out. It will probably only save you a lot of time and effort. The reason for using a second layer is because you get instant transactions, and you get a variety of instruments (including market trades.) >"Maybe there is a module in OT that already does most of what I described?" Yes, I believe it does everything described above, although OT currently doesn't directly do anything on the blockchain itself. You will have to make your own scripts to interface between the two. He lied.
I don't think so. He had clear vision about the future of GLBSE. Problems must came after the conference. No he didn't. It needs 4 glbse shareholders to decrypt the database backups in the event of nefarios death. There is nothing in place prior to this in case nefario was lent on by the government and the 4 shareholders disagree on whether hes been compromised or not. Nefario always seemed cool to me, I'm curious to find out what happened. Regarding "needing 4 shareholders to decrypt the database" I think using OT this wouldn't be necessary, since all users would already hold their "last signed receipt" by which balances can be proven. I think Open Transactions may be a hell of an overkill for this.
...
I believe that #assets-otc or #otc-assets project does pretty much what you describe in your original specs minus any automated trading capacity ie open bid/ask. I would much prefer the flexibility of trading market functionality over an OTC functionality. Re: OT. What I like about OT is that it already has P2P asset transfers + a trading market. I'm not sure how mature, robust or resistant to attack this market functionality would be. It is certainly possible to have a single GUI for Nym management and stock market. My only doubt is that OT creates it's own set of virtual assets for trading. Those virtual assets would be backed by BTC and BTC would have to flow in/out of the OT system. Re: Trust. What's nice about digitally signed p2p asset transfers is that parties can prove ownership in cases of malfeasance. A centralized record of ownership, in the example case being held by the asset issuer, creates an opportunity for fraud that the public would be unable to scrutinize. This wouldn't be an effective measure for wholesale fraud (as you point out would be an inherent risk in any of the approaches), but for individual cases where either party can prove ownership or payment with signatures. OT has real markets with bid/ask offers and automated trading. All trades are accompanied by a server-signed receipt (which includes the user's original signed offer.) These receipts also prove the user's current balance. |
|
|
|
|
I know I have already posted this so many times that you guys are sick of me by now.
But I feel the need to say, again, that the Bitcoin community needs to move towards the storage of Bitcoins in voting pools on the blockchain, so that no single server, or hacker of a server, can actually misappropriate and spend the coins belonging to depositors.
I have already proposed a protocol on this forum whereby a combination of OT with the BTC multisig transaction will make it impossible for anyone's funds to be stolen once they have been bailed onto a web-based service (such as MtGox, MyBitcoin, GLBSE, Bitcoinica, etc.) See my posting history for an explanation of how it all works.
|
|
|
|
I'm sure it's been mentioned several times now, but a solution such as Open Transactions could work well to maintain asset tracking, whilst simultaneously avoiding the "long arm of the law" problems. However, even that I don't think is sufficient.
There needs to be a market forming around an agreeable mediation procedure/technique/ruleset wherein we can arbitrate our disputes in an acceptable manner to the parties involved (it must be considered in the beginning of any engagement and it must be binding, IMO). However even then, I don't believe it will ever be completely solved using crypto-like transactions. Contracts always have a way to be misinterpreted, and participants in markets such as ours will almost invariable have a few bad apples.
FYI, you can use OT to create and sign contracts, issue currencies, open accounts, write cheques, trade on markets, withdraw and deposit cash, etc. It's not going to do everything -- you still have to decide your own governance procedures, and OT is only an API so you still have to build your client app or website. But OT will save you a lot of time re-inventing the wheel, for the pieces that it already does. The API is extremely easy and you get lots of functionality. There needs to be a market forming around an agreeable mediation procedure/technique/ruleset wherein we can arbitrate our disputes in an acceptable manner to the parties involved...
FYI, in OT you can make a smart contract between 2 or more parties, which executes according to the terms in the script. (The smart contract has scripted clauses.) If a dispute arises, you can design your smart contract so that an arbiter is listed in advance, who can be activated by the dispute and have powers over all the funds inside the smart contract. This way arbitration firms can operate and provide dispute resolution, who are selected and agreed in advance by all parties to an agreement. Search google for "open transactions tv" if you want to see videos where I walk you through the "behind the scenes" technical aspects of these sorts of contracts. For example, the "escrow" sample contract involves the use of an arbiter. |
|
|
|
OT automates all this stuff.Questions & Answers
How can I open an account?1) Upload your public PGP key using this page: http://assets-otc.com/addkey.php2) The first time you login your account will be automatically created What are the transaction fees?The service does not charge any fees for any transfers of any assets. Though we don't prohibit the AIs to charge fees for processing the contracts. How do I become the asset issuer (AI)?After you have the user account already, just send me the signed contract for the asset and I will add it to the system, putting your account as the AI. Do I need to pay for booking my asset at your service and being its AI?No, you don't. At least not at the moment, so better hurry up..  What if you run away with my bitcoins / assets?I don't hold your bitcoins, neither assets at any moment. Only the AI might run away with your stuff, so make sure you trust him or have a legally binding contract. What happens if the service goes down or an asset is kicked out of it?The AI always has the up-to-date list of all the shareholders and their PGP identities, so he can find another service or just handle it all further manually. Will the source code be open?Yes - I will put it on giuthub. Just not yet, because I need to get some customers first, not letting someone else to get them using my own work. Is it possible for one asset to use both, GLBSE and #assets-otc?Yes, but while you have your assets stored in #assets-otc you cannot sell them at GLBSE and you cannot vote motions there. But you are still entitled to dividends and you can trade them over the counter with other #assets-otc accounts. Also, you may request the AI to withdraw your assets from #assets-otc back to GLBSE or any other exchange - so you could trade them there. How can I transfer my GLBSE assets to this service?Talk to the guy who issued the asset at GLBSE and ask him to do it for you. If he doesn't know how to do it, send him to me - I can guide him through. If I have my assets in this service, will I be able to transfer them to GLBSE or other exchange?As long as the AI agrees to do it for you, I wouldn't be able to prevent that, even if I wanted. Is the service going to help with paying out the dividends?Yes. For this an open source tool has been created, which can (and should) be used offline. Each time before paying dividends you will download from the server a file called like contracts_YOURASSET.tar.gz (it's most recent version). This file contains the entire history of your asset's transfers, the dividend payment addresses and all the customers' public keys. You will only need to specify the total amount you want to pay as dividends - and then just run the script. If all the signatures in the contract chain are OK and all the dividend payments addresses are set, the script will output the exact JSON-RPC "sendmany" command, which you can then execute right away at your bitcoin client. How can I sell my assets which I have stored in #assets-otc? 1) find a buyer and agree on the price 2) ask him to register his PGP key at #assets-otc (if he hasn't yet) 3) sign the contract with both your PGP keys (stating number of assets you want traded and the bitcoin address for the payment) 4) send the signed assets transfer request to the relevant AI, so he could log the change in the system.
|
|
|
|
I don't know exactly Open Transactions, but if it requires something like signing documents with PGP, then it is both 1) quite scary the first time you see it 2) easy, after you spend 5 minutes figuring it out with a good howto. Maybe, having money to recover is just what it takes to push people to make that little mental effort, and move in the realm of serious security at once; so, a great opportunity  The user does not directly do any PGP-signing. If you are using the OT wallet, then it will be signing things behind the scenes, but you will not see this. The most you will see is, it will occasionally ask for your passphrase so that it can sign something. is there a way to program OT in a way that the "notary" part would be commonly shared similar to a blockchain. Basicaly i wanna know if OT is capable to run decentralized.
You can issue the same currency onto multiple OT servers. But each instrument must be redeemed on the same server where it was issued. You can also move funds between servers (by going through any entity who has accounts on both servers, such as the issuer.) There is also a plan to use multisig for placing BTC in voting pools (on the blockchain itself) so that individual servers cannot steal the coins that have been bailed onto them. (Nor could hackers...) Yeah, move to Exchange X. After they rob you, move again.
How many times do you have to get scammed before you wise up?
It is not possible for an OT server to rob you. After every transaction, the most recent receipt is left on your machine. This receipt proves your current balance, as well as which instruments are valid, and which transactions are closed. It proves everything. The server cannot change anything on this receipt (or the next...), because the server cannot forge your signature on the original request. (A copy of your original signed request appears on the server-signed receipt.) This means that "your account" is on your machine. So even if the server later disappears, you can still prove the balance on your account, and prove which instruments are still valid. I like the idea of an Open Exchange. Does that software exists already? If yes, where I can look for more info and downloads?
Open-Transactions is able to act as a market exchange (similar to MtGox or GLBSE.) However OT does a lot more than that. You can make your own custom-scripted smart contracts, and it will execute the terms of your scripted agreements, dropping receipts periodically into your inbox. OT also does untraceable cash. OT also does client-side scripting, with the full OT API available inside the scripts. OT is also able to prove everything it needs to prove, without storing any account history (as long as you store the last signed receipt...)OT also supports a wide range of financial instruments. Not only can you issue currencies/shares and trade them, but you can also open accounts, write cheques, withdraw cash, use cashier's cheques (aka banker's cheques), send account transfers, etc. Sounds like OT is the rough equivalent of what would happen if I open sourced LTC-GLOBAL and built in a cross-site trading module?
Probably. OT is able to act as a market exchange, if that's what you mean. But it is only the core: the library, the receipts, the instruments, the keys, etc. Meaning if you have a website in mind, you still have to build the website part. OT just processes all the finance and legal. It has potential to become a good alternative but at the moment it takes some serious effort to get it up and running. Documentation how to actually use it is nonexisting.
Getting the client (and server) running needs a good step-by-step How To.
===> The actual compiling / linking of the project is not something that actual users will have to deal with (only developers.) ===> Installing the software (and various libraries) on your machine is also not something that actual users will have to deal with (there will be an install script that will automate this for users.) ===> There is not an actual GUI client yet. We do have a test GUI, as well as a command-line utility (opentxs) but I assume that some real client will be written before there are real users. In fact my company Monetas has already started raising our seed round, and we intend to produce a real client over the next year or so. ===> If you copy over the sample data when you first install OT, then you will see that you are able to run the OT server and the test GUI without having to set up any contracts or Nyms at all. You can just start playing with it. ===> If you start up the OT server with no data, it will walk you through the process of creating the necessary Nyms and contracts to get it up and running from scratch. ===> If you start up the OT client with no data (such as the test GUI) then it will automatically create its own blank data folder. From there you can create your first Nym yourself (on the Nyms tab) and import any server contracts or asset contracts that you wish to use, into your wallet. (On the contracts tab.) From there you can go to the Main tab and create accounts (in those asset types, on those servers.) ===> A real GUI would lead you through that initial setup process (including the password image) using a Wizard. The test GUI, obviously, does not. |
|
|
|
|
OT requires the first-time user to choose an image file. (jpg, gif, etc)
This image is displayed on the password dialog.
That way, hackers cannot impersonate your password dialog, because they don't know what image you chose.
|
|
|
|
I'm not very familiar with Open Transactions. Can it hold money in escrow? Yes. |
|
|
|
|
OT is written in C++.
The API is available in a variety of languages, on most platforms.
|
|
|
|
|
Bastiat wrote:
Life, liberty, and property do not exist because men have made laws. On the contrary, it was the fact that life, liberty, and property existed beforehand that caused men to make laws in the first place.
What, then, is law? It is the collective organization of the individual right to lawful defense.
Each of us has a natural right — from God — to defend his person, his liberty, and his property. These are the three basic requirements of life, and the preservation of any one of them is completely dependent upon the preservation of the other two. If every person has the right to defend even by force — his person, his liberty, and his property, then it follows that a group of men have the right to organize and support a common force to protect these rights constantly. Thus the principle of collective right — its reason for existing, its lawfulness — is based on individual right. And the common force that protects this collective right cannot logically have any other purpose or any other mission than that for which it acts as a substitute. Thus, since an individual cannot lawfully use force against the person, liberty, or property of another individual, then the common force — for the same reason — cannot lawfully be used to destroy the person, liberty, or property of individuals or groups.
Such a perversion of force would be, in both cases, contrary to our premise. Force has been given to us to defend our own individual rights. Who will dare to say that force has been given to us to destroy the equal rights of our brothers? Since no individual acting separately can lawfully use force to destroy the rights of others, does it not logically follow that the same principle also applies to the common force that is nothing more than the organized combination of the individual forces?
If this is true, then nothing can be more evident than this: The law is the organization of the natural right of lawful defense. It is the substitution of a common force for individual forces. And this common force is to do only what the individual forces have a natural and lawful right to do: to protect persons, liberties, and properties; to maintain the right of each, and to cause justice to reign over us all.
A Just and Enduring Government
If a nation were founded on this basis, it seems to me that order would prevail among the people, in thought as well as in deed. It seems to me that such a nation would have the most simple, easy to accept, economical, limited, nonoppressive, just, and enduring government imaginable — whatever its political form might be.
|
|
|
|
Is it possible to lower the requirements to be usable also on Windows XP?Visual C++ Redistributable for Visual Studio 2012:
Supported operating systems: Windows 7 Service Pack 1, Windows 8, Windows Server 2008 R2 SP1, Windows Server 2012, Windows Vista Service Pack 2
Windows 7 SP1 (x86 and x64)
Windows 8 (x86 and x64)
Windows Server 2008 R2 SP1 (x64)
Windows Server 2008 SP2 (x64)
Windows Vista SP2 (x86 and x64)
Windows Server 2012 (x64) I guess if somebody wants to make mingw builds of OT they would work fine... The OT Project is moving to C++x11 features, that are supported in the 4.6+ versions of GCC. However from Microsoft compilers, this restricts us to Vista (SP2) and 7 (SP1). The benefit of Windows is the huge install base. Therefore it might be a mistake to move towards a newer version of the compiler, if it's going to automatically slice away hundreds of millions of potential users... Not everyone in the world has a nice new Mac like some of us. |
|
|
|
|
Show Posts
