Open-Transactions new version: MARKET screen now functional.

[fellowtraveler]

The MARKET screen is now functional on Moneychanger (the OT test-GUI):



You can also use Open-Transactions to create pseudonyms:



Issue currencies:



Use financial instruments:



Including untraceable digital cash:





Sorry the Test-GUI is so ugly, but I promise that a real GUI would be much prettier: http://ft.vm.to/blogimages/ot-sample-gui.jpg

-Fellow Traveler

[markm]

Cool!

Is there a way to tell the client where the server is? I have not been able to find it if it exists, which makes it hard for people to try out the client against whichever server they want to try it with... it looks like you can maybe tell it about a bitcoind but not about an Open Transactions server, which seems a bit strange...

-MarkM-

[fellowtraveler]

Cool!

Is there a way to tell the client where the server is? I have not been able to find it if it exists, which makes it hard for people to try out the client against whichever server they want to try it with... it looks like you can maybe tell it about a bitcoind but not about an Open Transactions server, which seems a bit strange...

-MarkM-

The server location is inside the server contract. You'll notice in the screenshots that Moneychanger has a list of server contracts. Whenever you perform an action on a specific server, OT simply loads up the appropriate contract and derives the connection info from inside of it.

Currently OT ships with a test contract, which expects the server to be running on localhost.

So basically, you need to run the server yourself, on your machine. Here are the steps to build OT and run the server:

Code:

git clone git://github.com/FellowTraveler/Open-Transactions
cd Open-Transactions
make java
cd transaction
./transaction.exe

Once the server is running, then you can connect to it using the Moneychanger client, which you can download here:
https://github.com/FellowTraveler/Moneychanger/downloads

From Moneychanger, put the lib folder, as well as JavaWrapper.jar, into the Open-Transactions/testwallet folder. Then run the GUI like this:

Code:

cd Open-Transactions/testwallet
java -jar JavaWrapper.jar

This also assumes that you have OpenSSL 1.0.0 built properly for your machine, which can be tricky if you are running 64 bit Linux.
See the OT Wiki for install notes, troubleshooting, etc. Here's a good link: https://github.com/FellowTraveler/Open-Transactions/wiki/Install

-FT

[markm]

Thanks!

I now have a BTC<->DVC (and vice-versa) exchange implemented, simply by creating DigiBTC and DigiDVC contracts for Open Transactions, simply assets backed by actual BTC and actual DVC. (I actually have more BTC and much much more DVC than I have issued as assets on the Open Transactions server so reserves are not a problem.)

Now I jsut need to keep going, making (very) similar contracts for umpteen other "alternate cryptocurrencies" to make an exchange that handles many of the current currencies...

Read about the exchange / Open Transactions server in its own thread: https://bitcointalk.org/index.php?topic=53329.0

-MarkM-

[jtimon]

So the untraceable digital cash can be traded (atomically) or it has to be deposited on an account first?
Sorry, I should really study the untraceable cash in deep until I finally understand it.

[markm]

The cash is per server, and you have to check with the server to make sure someone didn't already redeem it, since obviously someone could make umpteen copies of any particular cash-certificate. The server keeps track of which have been turned in so it does not honour them a second time.

-MarkM-

[jtimon]

Thank you.
The markets are per server too, right?
My question would be...imagine you have 10 BTC in untraceable cash and I have 100 DVC in the same way and registered on the same server and issued by different parties.
Can we trade the untraceable cash on that server?

If the answer is yes, my desire would be to have a special trade transaction in which you could make multiple trades atomically.
For example, in the markets of the server there are the offers:
...
1 btc for 10 nmc
10 nmc for 100 dvc
...
And I want to be able to make the trade: "I buy 10 nmc for my 100 dvc only if I also buy 1 btc with those 10 nmc".
Would that be possible too?

Another question. Can the untraceable cash be moved from one server to another?
That makes sense to me, since it is said somewhere that the same currency by the same issuer can be in multiple servers.

[markm]

Transfer from one server to another would require collusion between the operators of the servers.

Possibly most of it would be done by selling off the stuff to be transfered to get a sum of some easily moveable money such as bitcoins, then buying at the other end once those bitcoins arrive.

I am brainstorming now how using a greater level of abstraction might help some situations, such as having different tokens I issue representign coins I have on different servers, but commonly using a generic token that doesn't really care which server's tokens will ultimately end up backing them.

That way maybe you could trade a generic "back by a bitcoin somewhere but not specific as to where" token that I could end up redeeming in the form of a bitcoin at MtGox or a bitcoin at TradeHill or a bitcoin sent to some address you want it sent to or whatever.

With some of the alternate blockchain currencies I am also concerned about double spend / 51% attacks. I am thinking it might be nice if it were possible to operate something like e-gold, where really one does not actually expect anyone to ever demand delivery of the underlying gold.

If I didn't have to worry that everyone would keep wanting the represented coins actually sent out to them over the blockchain, I could use only coins that are old enough to have had hard-coded checkpoints coded in the clients sicne the block the coins are in, and thus back my tokens with highly secure against double-spending coins.

That will fall apart if people keep demanding I send them the coins, as any new coins that come in will be too recent to be secured yet by hardcoded checkpoints.

Basically the idea would be to use market-makers, who buy my tokens and also sell them, and are maybe the only people I actually take real backing-assets from to issue more tokens.

It is still a problem though as I would have to sit on the coins they send me until the next hard-coded checkpoint before issuing tokens based on them.

-MarkM-

[jtimon]

I understand untraceable cash tokens cannot be sent from one server to another.
What about the atomic execution of a set of trades? I don't want to complicate it by implying the tokens must be fungible.
Imagine we have in the same server the offers:

2 markBTC for 5 mtgoxUSD
5 mtgoxUSD for 5 tradehillUSD

I have 5 tradehillUSD and want 2 markBTC but I don't want to get stuck with mtgoxUSD.
Can I execute a set of trades atomically?

Also I don't understand the concerns with the checkpoints. We're already accepting mtgoxBTC for BTC without the warranties OT offers.
Trusting mtgox for issuing OT untraceable cash denominated in BTCs with no visible backing instead of just numbers in their system would be a great improvement for security.
But to offer the fully backed by coins UC I guess you would need to pay with new coins outside of the reserve and keep the tokens for yourself. You could maintain your reserve secure deep under checkpoints and live on purchase/redemption fees.
Still you need to trust someone for the non-coin currencies anyway.

[markm]

Maybe with smart contracts / scripts you could script up something for the kind of roundabout trades you have in mind.

I suppose in meantime you could offer directly the deal you have in mind, who knows someone might take it, or might do the multi part deal in order to be able to take up your deal. I guess it would help to make your deal a little better, basically add in whatever you think the risk cost is of getting stuck partway through the multi-step deal.

By the way, so far I have been implementing all my currency contracts for my server as whole coins.

Do you think that is a bit problem?

I am hoping it will help avoid cluttering up the system with tons of tiny transactions.

For example if you want to sell BTC at 2.99 MtGoxUSD each, you could offer 100 BTC for 299 MtGoxUSD on the units-of-100-BTC market...

I kind of hope to move away from pathetic "I want to but 0.01 BTC" type orders. Real Forex exchanges tend to operate in 1000's at a time, don't they?

-MarkM-

[jtimon]

Maybe with smart contracts / scripts you could script up something for the kind of roundabout trades you have in mind.

I hope so.

I suppose in meantime you could offer directly the deal you have in mind, who knows someone might take it, or might do the multi part deal in order to be able to take up your deal. I guess it would help to make your deal a little better, basically add in whatever you think the risk cost is of getting stuck partway through the multi-step deal.

Actually I was thinking in using this as a ripple implementation in which each participant issues credit as an untraceable cash currency.

By the way, so far I have been implementing all my currency contracts for my server as whole coins.

Do you think that is a bit problem?

I am hoping it will help avoid cluttering up the system with tons of tiny transactions.

For example if you want to sell BTC at 2.99 MtGoxUSD each, you could offer 100 BTC for 299 MtGoxUSD on the units-of-100-BTC market...

I kind of hope to move away from pathetic "I want to but 0.01 BTC" type orders. Real Forex exchanges tend to operate in 1000's at a time, don't they?

I have no clue about what numbers "real exchanges" use. I guess they're higher than what we normally operate in coins exchanges but I wouldn't take professional brokers volumes as a reference for us.
I think it can really be an inconvenience to allow only whole coins. It reduces the prices one can set without getting crazy.
For example, I cannot buy 100 nmc at 0.01652 each for whole BTCs.
Isn't there a minimum volume option for markets or something so you can forbid the pathetic orders without losing flexibility?

[fellowtraveler]

Maybe with smart contracts / scripts you could script up something for the kind of roundabout trades you have in mind.

I hope so.

Sorry, but I don't see doing the entire Ripple implementation through the scripts. I suppose it's maybe theoretically possible, at best, but it's bad optimization and quite impractical.

Ripple is coming to OT eventually but IMO it will require big code changes within OT itself. (Comparable to the changes made with finalReceipt or with adding smart contracts in C++.)

It's on my list -- I'll get to it sometime soon.

Actually I was thinking in using this as a ripple implementation in which each participant issues credit as an untraceable cash currency.

This will not be possible with OT, sorry.

The reason is because the OT cash, while untraceable, must be deposited into an OT account before it can be traded on OT markets.

So you can have pseudonymous Ripple, but not cash-based.

It guess it would be possible to pay the next Nym in the Ripple by withdrawing cash and giving cash to that Nym, instead of paying to its account, but that would take some thought. And even so, it doesn't sound untraceable to do that, so probably not worth it. (The server can still see which people got the cash, since the server is the one calculating the route.)

IMO the best way to have OT cash involved in Ripple would be to have a p2p Ripple protocol between the OT clients, and not to do Ripple the normal way (atomically on the server.) But to do that would be a whole new Ripple protocol than has ever been written before.

I must say though, the first "real" OT client should be p2p, so maybe something like that can be done in that future software.

[jtimon]

Maybe with smart contracts / scripts you could script up something for the kind of roundabout trades you have in mind.

I hope so.

Sorry, but I don't see doing the entire Ripple implementation through the scripts. I suppose it's maybe theoretically possible, at best, but it's bad optimization and quite impractical.

Ripple is coming to OT eventually but IMO it will require big code changes within OT itself. (Comparable to the changes made with finalReceipt or with adding smart contracts in C++.)

It's on my list -- I'll get to it sometime soon.

I still don't see how it can require so much changes if implemented with the paradigm of each user issuing its own (credit) currency and trading it with others. After all, you already have the currencies and the markets.
Sorry for being so obstinate here. I feel you see it complicated because you don't like the "ripple as a market of currencies" paradigm.

Actually I was thinking in using this as a ripple implementation in which each participant issues credit as an untraceable cash currency.

This will not be possible with OT, sorry.

The reason is because the OT cash, while untraceable, must be deposited into an OT account before it can be traded on OT markets.

So you can have pseudonymous Ripple, but not cash-based.

It guess it would be possible to pay the next Nym in the Ripple by withdrawing cash and giving cash to that Nym, instead of paying to its account, but that would take some thought. And even so, it doesn't sound untraceable to do that, so probably not worth it. (The server can still see which people got the cash, since the server is the one calculating the route.)

I see. It could be done with currencies in accounts but not with untraceable cash. In this sense it would be still quite centralized and traceable. The main difference with the current ripplepay implementation (apart from a probably less intuitive interface if based on currencies instead of regular credit) is that the OT server can't do what it wants with the accounts.

IMO the best way to have OT cash involved in Ripple would be to have a p2p Ripple protocol between the OT clients, and not to do Ripple the normal way (atomically on the server.) But to do that would be a whole new Ripple protocol than has ever been written before.

Yes, this would be a whole new story.

I must say though, the first "real" OT client should be p2p, so maybe something like that can be done in that future software.

I don't understand this part. p2p how? They will still need to connect to servers, right?

[fellowtraveler]

I still don't see how it can require so much changes if implemented with the paradigm of each user issuing its own (credit) currency and trading it with others. After all, you already have the currencies and the markets.
Sorry for being so obstinate here. I feel you see it complicated because you don't like the "ripple as a market of currencies" paradigm.

If I, as the programmer, write up a big description of how it will all work (which I did) and estimate that the job will take me at least a couple of weeks, do you really want to argue that it can actually be done in hours, or days? I invite you to fork the code and show me.

Normally the wise thing to do, when a programmer estimates anything, is to double or triple his estimate--not guess lower.

I said it would do it, and it's coming -- it's just not a small job. (Remember I have to work it into OT's existing paradigm, otherwise why bother integrating? Might as well just run one of the existing Ripple servers...) Currently, BTW, I am still debugging the smart contracts in how they are integrated with OT's "destruction of account history" system.

Actually I was thinking in using this as a ripple implementation in which each participant issues credit as an untraceable cash currency.

This will not be possible with OT, sorry.

The reason is because the OT cash, while untraceable, must be deposited into an OT account before it can be traded on OT markets.

So you can have pseudonymous Ripple, but not cash-based.

It guess it would be possible to pay the next Nym in the Ripple by withdrawing cash and giving cash to that Nym, instead of paying to its account, but that would take some thought. And even so, it doesn't sound untraceable to do that, so probably not worth it. (The server can still see which people got the cash, since the server is the one calculating the route.)

I see. It could be done with currencies in accounts but not with untraceable cash. In this sense it would be still quite centralized and traceable. The main difference with the current ripplepay implementation (apart from a probably less intuitive interface if based on currencies instead of regular credit) is that the OT server can't do what it wants with the accounts.

"the OT server can't do what it wants with the accounts" -- Yes, very spot on. The OT server can't just change your balance, or forge any of your transactions, without getting your signature on the transaction first. That is one of the special things about OT.

But another benefit is that the OT server is able to operate without storing any transaction history. (Normally, a server is otherwise forced to store transaction history...) This means that, while the OT server is still capable of tracing the Ripplepays (pseudonymously, anyway), if an adversary or abusive authority breaks into the hard drive, there won't be any transaction history there to be found.

The other benefit is integration with the rest of OT's features. Like, even though the Ripple instrument wouldn't use the OT cash, you would still be able to have access to using the OT cash as part of using the same software, and you would be able to use those same funds in a Ripple-like way also, through the same system. (And cheques, vouchers, smart contracts, etc.)

I must say though, the first "real" OT client should be p2p, so maybe something like that can be done in that future software.

I don't understand this part. p2p how? They will still need to connect to servers, right?

Yes, think of it like Tor directory servers. Tor is still p2p.

Similarly, OT will want to run on I2P or Tor anyway, to gain the anonymity benefits.

The future "real" OT client will need to be p2p for at least one reason:   So the clients can compare notes on the servers and insure they aren't actually tracking them through malicious public mint files. (If you receive a different and unique public mint file, compared to everyone else, then your cash is FULLY TRACEABLE... So clients will want to at least compare the mint hashes...)

[jtimon]

I don't remember hearing any time estimation from you, only complexity. Sorry if I have offended you somehow.
And, yes, the simplest solution doesn't have to necessarily integrate in a clean and coherent manner with the rest of the software. I just wanted to know if that simple solution was possible within OT or there was another limitations I didn't know.
I'm impatient about helping out in ripple, OT, bitcoin; coding a freicoin prototype, etc. But (apart from coding 9 h a day for my company) I have to code my final project to finally forget college. So, no. I won't fork OT for now and I'll just celebrate the progresses.

As you say, having ripple within OT will have more advantages than just "the server can't change the accounts" but that's a really important one.

I think I understand now the p2p thing. The fact that there are servers, trackers or registries is not incompatible with the system being p2p.
Do you also mean the clients will have a a way to communicate between them directly without going through any server?

[fellowtraveler]

I don't remember hearing any time estimation from you, only complexity. Sorry if I have offended you somehow.

No offense taken. My only point is, if I'm saying it can/will be done, but it's not a quick and easy job, most likely it will take much longer than I estimate, not shorter. I wish this wasn't the case since I don't want to spend weeks/months of my life slaving over a Ripple implementation if I could do it in less time :-P  But I'm only trying to be accurate.

And, yes, the simplest solution doesn't have to necessarily integrate in a clean and coherent manner with the rest of the software. I just wanted to know if that simple solution was possible within OT or there was another limitations I didn't know.
I'm impatient about helping out in ripple, OT, bitcoin; coding a freicoin prototype, etc. But (apart from coding 9 h a day for my company) I have to code my final project to finally forget college. So, no. I won't fork OT for now and I'll just celebrate the progresses.

As you say, having ripple within OT will have more advantages than just "the server can't change the accounts" but that's a really important one.

I think I understand now the p2p thing. The fact that there are servers, trackers or registries is not incompatible with the system being p2p.
Do you also mean the clients will have a a way to communicate between them directly without going through any server?

The clients definitely need to compare notes on the public mint file, to prevent the server from removing the untraceability of the cash.

On top of that, the ultimate long-term solution for auditing will need some kind of "central location" (a DHT or whatever) for transferring receipts. This way the auditor can have access to the same place that the users get their receipts, which preferably is stored in a distributed fashion. What that will be in the long term, whether some combination of Namecoin, Tahoe, i2p, Freenet, etc, I cannot say.

[jtimon]

No offense taken. My only point is, if I'm saying it can/will be done, but it's not a quick and easy job, most likely it will take much longer than I estimate, not shorter.

Thank you, I really appreciate your efforts.

This way the auditor can have access to the same place that the users get their receipts, which preferably is stored in a distributed fashion. What that will be in the long term, whether some combination of Namecoin, Tahoe, i2p, Freenet, etc, I cannot say.

I haven't understood all the mint process but this sounds good.
I don't know why there aren't many software projects based on Tahoe-lafs such as diaspora. It's so promising...