Open Transactions Server: Asset/Bond/Commodity/Cryptocoin/Deed/Share/Stock Exch.

[marcus_of_augustus]

It's being worked on right now, I'm a noob trying out the latest builds. No luck on my machine yet though :|

did you try the irc for help? ... normally someone there to step you through, gl.

https://webchat.freenode.net/?channels=opentransactions&uio=d4

http://webchat.freenode.net/?channels=opentransactions&uio=d4

[markm]

Yes try the FreeNode IRC channel #opentransactions for sure.

Like most IRC channels, people lurk there 24/7 so will eventually see any questions etc when they wake up if they happen to be asleep when you type something.

The latest wave of upgrades to Open Transactions has been another massive one, involving setting up ultra-security for your private keys so that they never reside on disk un-encrypted. This initially meant having to enter the passphrase you chose for encrypting the keys over and over and over again, as each time it needed the passphrase it would use it once and scrub it from memory instantly even if it immediately found it needed it again. Now there is a timer available for the secure portion of non-swappable memory used, so that you can configure for how many seconds it should remember your passphrase once you provide it.

This still can involve inputting the passphrase multiple times initially, certainly at least twice when you first choose a passphrase as it wants you to tell it twice to make sure you typed it correctly; but after the initial run all keys should be crypted and it should on future runs be able to remember the phrase for the configured number of seconds (default configuration is 300 seconds aka 5 minutes) before having to ask you for it again.

This has been a horribly annoying feature to work through the development of, but is a very important security feature that should in retrospect have been well worth all the hassle its development and testing has involved.

There is also a very high level API for scripts now, though again the passphrase feature will cause inconvenience since unless a human is going to sit by when scripts are run to provide passphrases to the scripts each developer of scripted systems will have to choose a method of getting around the passphrase security system in order to set up trading bots or whatever with it. Worst case though one could use a completely separate user to run bots, a user that does not crypt its keys on disk thus does not need passphrases, to which they give only a small amount of assets at a time to play with. Or, one can use "expect" or similar software to automate responses to the scripts. Or an openssl agent type system can be used. The choices are actually mindbogglingly diverse, lots of choices on how to do it. All there because some people's disk drives cannot be trusted not to end up some day being read by an attacker. This will not protect you from a keylogger but nonetheless is pretty good protection, along the lines of existing openssl agents, keyring handling apps etc. (In fact it is also planned to add choice of configuring it to use an existing third party keyring handler if the user prefers to do so.)

-MarkM-

[psiborg]

Yea I'm already on there, just commenting on the current state for me. It's getting closer to working for me, hope it'll get worked out soon

[MoneyIsDebt]

Got the thing built and tested with help from you guys on IRC today. Looks good!

[markm]

It is getting to be time to consider upgrading to a newer version, hopefully you will find it has improved.

The latest addition is keyring support, which hopefully will make it possible to resume the use of scripts to test the system.

The Digitalis server is now running the latest code, I am about to start trying to get keyrings set up to see if they will indeed let the testing scripts start running again.

Meanwhile an interesting proposal for "underwriters" of Initial Public Offerings has come up, see https://bitcointalk.org/index.php?topic=92725.0

-MarkM-

[beckspace]

Wake me when there's a web interface.

I'm waiting for the movie.

[MoneyIsDebt]

I'm waiting for the movie.

There is a movie, and it's pretty good IMHO - got me interested at least.

[markm]

There are quite a few I think, though I am not sure where exactly. A few more got made just recently in fact.

EDIT:

Here are a couple

http://vimeo.com/28141679

http://vimeo.com/28142096

-MarkM-

[fellowtraveler]

Wake me when there's a web interface.

I'm waiting for the movie.

re: the movie. As knotwork said, videos have been posted already. Links are also on the OT Wiki (main page.)

FYI: New videos have already been recorded. I am about to post 10 more + and recording a few more tonight.
----------------------------------------------------------------------

re: the web interface. There are only two ways you are going to have a web interface on OT....

1. You trust the web server operator to manage your private keys. (See previous incidents:
Bitcoinica, MyBitcoin, MtGox, etc.) Not only that, but you trust that the code is perfect, with no cross-
site scripting, no buffer overflows, no sql injection, etc being possible. You also trust hackers not to
get in. You also trust the day-to-day security practices of your web site operator, as well as any of
their employees who might have access to your private key, with which your money is ultimately controlled.

I don't know why people prefer this so much but I do understand the market need for a web interface.
I will be happy to work on this project also, but it will need to be a commercial project or otherwise
funded. How much free work do you expect from me? Roll up your sleeves!

2. My preference: Make a commercial-quality client which operates as a systray icon, having only a menu
as its interface (and some dialogs.) Then make lightweight plugins for Chrome, Firefox, i2p, Skype,
Retroshare, AppScale, OpenStack, Magneto, Joomla, etc. This is the most secure way to do it, and also
gives the widest range of integration at the cheapest maintenance cost.


What I'd do, for those preferring ( 1 ) over ( 2 ), is just have a green button on the UI that says something
like, "Click here to download the installed version or Mobile app. It's more secure!" And migrate people over.
And make sure installable versions are available for all platforms.

------

Once people are storing their wallets on their mobile devices, these devices are going to start getting hacked.

We need mobile devices that use smart cards or usb keys, where we can run the OT engine / Bitcoin engine
(any crypto) outside of the device itself. Preferably also where we are using Serval protocol for voice and
CJDNS for data, and Mesh networks--these sorts of things, not centralized providers. And digital cash is
necessary to solve issues of resource allocation that will arise.

What is a good device we can buy now, and use as a normal phone, that we can later upgrade the software on
and it will function as described above?

[ripper234]

re: the movie. As knotwork said, videos have been posted already. Links are also on the OT Wiki (main page.)

1. You trust the web server operator to manage your private keys. (See previous incidents:
Bitcoinica, MyBitcoin, MtGox, etc.) Not only that, but you trust that the code is perfect, with no cross-
site scripting, no buffer overflows, no sql injection, etc being possible. You also trust hackers not to
get in. You also trust the day-to-day security practices of your web site operator, as well as any of
their employees who might have access to your private key, with which your money is ultimately controlled.

I don't know why people prefer this so much but I do understand the market need for a web interface.
I will be happy to work on this project also, but it will need to be a commercial project or otherwise
funded. How much free work do you expect from me? Roll up your sleeves!

Check out Nefario's experience with GLBSE. GLBSE v1 was extremely secure, but didn't see any adoption at all.
GLBSE 2.0 is less secure, but is growing tremendously over the last several months.

People don't want security, they want usability first. If you're aiming to replace banks, you'll need to offer at least the ease of use they offer today.

The great thing about OT is that it allows anyone to open a bank. Customers (99.99% of them) will never run a true OT client, like they'll never run a full Bitcoin node (even though the hardware requirements for an OT client are significantly lower).


Security will eventually come from being open source and open in general as much as possible, having security audits, and having competition, and the option of running a full OT client.

[markm]

Hey if people are willing to pay the service charges then of course full-service bank and full-service brokerage type establishments might well thrive. We are already starting to see the emergence of insurance corps, so full reversibility of transactions might also be possible if the service fees are high enough to provide that degree of insurance.

It is not as if you can go to a website and trade directly on a real stock exchange, right? You go to the website of some broker? Heck do most of those brokers even trade directly from that website to the actual stock exchange?

When we take into account the heists, I wonder how much the service fees, taken in big lumps like that instead of openly up front, add up to?

Frankly I am not hoping to attract multitudes of penny-ante traders. Better that their volume be aggregated at satellite nodes of some kind, relieving the actual market server(s) of huge volumes of trivially small trades. They can all phone their brokers directly even if even running a web browser is too "technical" for them.

The fee system in Open Transactions favours fewer, larger trades, since you pay per API call regardless of the monetary value of the trade.

I actually expect that we will see third party services that run clients for people, insulating them from the whole technical side of things by holding private keys for them and maybe not even bringing up the fact since telling people all about such internal workings of the service could just confuse people. After all if the keys are private and are held by the service, they are a private matter between the service and whatever it uses those keys to communicate with, there is no need for some web-user to even have to wade through mentions of such things except maybe in some legal smallprint where they sign off, likely without reading, on agreeing that the service holds the keys and is not responsible for any employee or hacker abusing such keys.

In other words I agree that people prefer to be ripped off regularly than to be inconvenienced. I am not particularly eager to do the ripping off, and outsourcing it to third parties has other side-advantages too, such as only needing to have KYC info on those third party "brokers" since only they need know on whose behalf they trade.

Maybe at some point it will come down to traffic versus content as in other web applications. Which is king, being the "owner" of eyeballs you can control the gaze of or being the "owner" of something those eyeballs might like to see. Will the "big money" play on websites catering to the masses, or on secure backbone systems the masses maybe do not even qualify for access to (minimum balance requirements, ability to run a secure client, whatever)?

Also bear in mind that people can run plugins or java or javascript in their browsers so if they want to trust their browsers to sandbox financial plugins from cracker plugins phisher plugins and so on they should be able to keep their private keys at their end even while using a browser.

I expect you are right, most people will prefer not to have anything to do with private keys, leaving private keys to be a private matter between websites, hackers, and whatever behind the scenes facilities the websites use the private keys for. Like fellowtraveler said, we can have a big button saying press here to download secure client. The smallprint can mention the contractual effects of not pressing it, such as accepting responsibility for any employee or cracker misuse of the keys that you thereby voluntarily surrender control of.

Its amazing what people will sign. Its a free market though right?

-MarkM-

[MoneyIsDebt]

How does one secure an OT server? If I run one on a VPS f.ex. how do I ensure it's not tampered with? And if it does, would it bring down the whole economy running on it, or can redundancy be ensured by having multiple servers (in the future, I know it's not here yet)?

[Explodicle]

How does one secure an OT server? If I run one on a VPS f.ex. how do I ensure it's not tampered with? And if it does, would it bring down the whole economy running on it, or can redundancy be ensured by having multiple servers (in the future, I know it's not here yet)?

"The vision is not of a central server that you must trust. Rather, the vision is of federated servers you don't have to trust."

They will use multisig to protect Bitcoin holdings.

[markm]

Okay, now there is  http://open-transactions-tv.github.com/

Many more movies coming there soon too.

If by a VPS you mean a machine you do not physically control, then whoever physically controls that machine has access to the server's private key and thus is in effect the operator of the server. You should regard it as their server not yours since they have the key, and then it is immediately obvious it is not secure if they allow you access to the key.

However once all the auditing is in place you could audit it to detect whether they try to issue more of any asset than that asset's issuer authorises for example. Basically though just think of it as their server since whoever has the private keys can "prove" they own that server by signing messages using that server's private key.

So first thing for any kind of security is to have physical custody of the machine. If that means having to use i2p or Tor or whatever to create the ability to have incoming connections then fine, do that. Never put private keys on a machine you do not physically control.

-MarkM-

[MoneyIsDebt]

As I understood it, the issuer need not be the server, so as long as currencies as issued remotely, is this still an issue?
My problem is, I live in Malaysia, and internet here is crap. There's no way hosting a server here would be viable.
So am I out of luck, since I can't possibly be in physical control of the server?

[markm]

As I understood it, the issuer need not be the server, so as long as currencies as issued remotely, is this still an issue?
My problem is, I live in Malaysia, and internet here is crap. There's no way hosting a server here would be viable.
So am I out of luck, since I can't possibly be in physical control of the server?

You could wait for all the auditing stuff to be completed and then find a server that is willing to let you issue assets.

I had not wanted to allow third parties to issue assets on my server as I felt I could not be sure my users could be compensated if the issuer ran away with their backing assets or simply lied about their existence. However some users came up with a suggestion which no on in the securities section of the forum seems to have found fault with: https://bitcointalk.org/index.php?topic=92725

So maybe with such an "underwriting" system third party assets might be feasible.

-MarkM-

[markm]

I have been collecting asset value statistics for a while now, and created some very primitive HTML outputs of that data, and just now have finally gotten around to adding an index page providing links to the various stats pages:

http://galaxies.mygamesonline.org/digitalisassets.html

Also, I have now created fresh new "mints" for the currency type assets (not shares type assets), so now the untraceable Chaumian-blinded cash system for all the currencies should now work. (And if not, well we are in process of making sure it does, so please try it and let us know if there are any bugs.)

-MarkM-

[da2ce7]

New Windows Development Builds...

These builds have a few more dependencies, but have full debugging symbols included.

Follow the instructions here to install the dependencies:

https://github.com/da2ce7/Open-Transactions/blob/master/docs/INSTALL-Windows.txt

Win32:

https://github.com/downloads/da2ce7/Open-Transactions/OT_0.84.e_Win_x32_Debug_2.7z.7z

Win64:

https://github.com/downloads/da2ce7/Open-Transactions/OT_0.84.e_Win_x64_Debug.7z


Common: User Data

(if you already use OT, and upgrading, only update the 'opentxs' folder)

https://github.com/downloads/da2ce7/Open-Transactions/ot_user_data_9300ce0.7z

[markm]

Deployment of market-maker scripts has now been resumed, using the new high level API calls to place offers.

This means that more and more markets, at various scales, should start filling with offers as creation of the full gamut of scripts for more and more asset-pairs proceeds...

These scripts basically aim to bracket the values shown in the asset valuation reports that are online at http://galaxies.mygamesonline.org/digitalisassets.html

-MarkM-

[markm]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In light of discussion in one of the bitcoinica threads, I would like to make clear that because my Open Transactions server represents actual assets such as bitcoins, devcoins, namecoins, or whatever by means of tokens tradeable on the server, it is important to realise that this means any theft, loss, etcetera of any of the "actual" assets those tokens represent is in effect simply the changing of the specific token type into a fractional reserve token, inasmuch as it is no longer fully backed by the asset it had hitherto represented.

Specifically and potentially importantly, this means if bitcoins get stolen but devcoins do not, then bitcoin tokens are, by that theft, rendered fractional reserve whilst devcoin tokens remain fully backed.

To be very clear here: each asset is distinct and separate. To the extent permitted by law and potentially even to the extent permitted by civil disobedience, the intent is that losses of one asset are totally distinct from all other assets. There is to be no dilution or lessening of asset X holdings due to losses of asset Y.

Specifically, upon liquidation or receivership or both of the server, there is to be no compensating of holders of one asset by means of depriving holders of some other asset of that other asset. If dollars are stolen, too bad for dollar holders, cryptocoin holders should not be affected. And vice versa.

- -MarkM-

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJQNxB5AAoJELEgG1tGd2RYUkgP/jPgcp5zS0YSKPjxotYXop6z
184XRMgJF3T0j4JecumrzItvl5AMyzoCTD2DEViar1PFIQE9kBlHpB17QqJgSmjA
y/d3YIaPow4WTC1E6hvwLxm88Md22lNl9dYHvJJlbRKaj0MOUHJzHUh3eZfJsRXz
MuuKBTkeO1/dt90qsfDRww3PRwA5Kiwn/Y4ZQoa6sX1zfqtAXW5aEYu4R+Gj9sYX
Qhu9yMRzA/klFrUMymcAkgQH/JfF87cVQ2aC8Rlo5SHHjnOwJb+yooptEcdq+dro
5wfbssLnxHnbsBsfW2BTgw5xrt1Mwq6Z0aOt0F2ckh3UTZpeU6XnGZMjTDSzwAqY
9DUhFzsXUUEqE/G+siLsrWr0MMGnnnCgXoqCbppZgfhmLho5KONHkvMZ7BiJXVRS
xDDtExr1BQ7trIY3x6yiofGvD6CvRMoorf4OcHa4CzYnsc5tQzll6fGyMTX6cSLF
Ugr+VfCqBXEDk1tVaP4oeHpj8bz1rCZ13hMpGoxkraYYceJcxTER2jH+BFWA5DXR
1R5HE+dshejQcZFDhXHnY/2ivojqokmlxxQJ9YU3eIkMX/Sq1x2LmbpOPNoruTEo
/Sn7l2h0uEdz3C4k3JbugnphjjRmhDXnc/7NOzyIodXb2taUVFhicN9tL5pUECC/
SRJHPD2AINstTPkQLjza
=o2fJ
-----END PGP SIGNATURE-----