I have put a binary for Fedora Core 15, built on a 64-bit machine, on the sourceforge downloads site.
I have also added more currencies and still have more to add, will keep plugging away at that.
-MarkM-
Topic: Open Transactions Server: Asset/Bond/Commodity/Cryptocoin/Deed/Share/Stock Exch. - page 10. (Read 42605 times)
December 05, 2011, 11:07:10 PM
December 05, 2011, 08:19:00 AM
Yup it seems to work! (Smartcontracts branch being necessary -- I will merge it back to master ASAP once I fix another 1 or 2 things...)
The default latency in ~/.ot/client.cfg and server.cfg is 200 ms, which I knew would be too short, so I set those to 800 ms and restarted the GUI (Moneychanger.)
Then I added your server contract, as well as your three asset contracts (Digi-BTC, Digi-DVC, and Digi-NMC).
Then we were able to send transfers and cheques, etc back and forth...
Presumably if there were BTC/NMC offers on your market, I could go and make an offer myself...
It's pretty cool to finally use my own software through someone ELSE's server, someone ELSE's contracts....
Thanks for getting it up and running :-)
-FT
PS big announcement coming soon, smart contracts.
The default latency in ~/.ot/client.cfg and server.cfg is 200 ms, which I knew would be too short, so I set those to 800 ms and restarted the GUI (Moneychanger.)
Then I added your server contract, as well as your three asset contracts (Digi-BTC, Digi-DVC, and Digi-NMC).
Then we were able to send transfers and cheques, etc back and forth...
Presumably if there were BTC/NMC offers on your market, I could go and make an offer myself...
It's pretty cool to finally use my own software through someone ELSE's server, someone ELSE's contracts....
Thanks for getting it up and running :-)
-FT
PS big announcement coming soon, smart contracts.
December 04, 2011, 04:07:15 PM
I am glad I did this as "alpha test", wow, getting this "whitespace problem" squashed has been a marathon.
The full set of fixes are in the smartcontracts branch of FellowTraveler's GitHub repo, not yet merged back into the master branch.
I have generated new certificates, used them to create a new nym to serve as admin/signing nym for a new server, and used that nym to sign a new DigitalisOTserver.otc which I have uploaded to the galactic milieu files download directory on SourceForge.
I have also created a sample/example "empty" ~/.ot directory for clients, it has no nyms no currencies no accounts but does have my new server-contract and uploaded it to SourceForge as dot-ot-empty.client.tgz
I have lots of currency contracts to write and sign using the latest fixed versions of the OT server and client, as I create those I will put the .otc files of the contracts on SourceForge and also start putting a dot-ot-clean.client.tgz that will have the main currencies my server intends to work with as well as my server's contract.
We are still in alpha; FellowTraveler intends to check that my contracts work on his installed client and so on tomorrow.
However, even in alpha it is worth being aware that although Open Transactions is not totally married to its past with merkle trees like blockchains are, there is some one thing building upon another involved. So if at any point you feel ready to create some nym or contract or account that might make you not want to totally delete your ~/.ot and start over again from a fresh new dot-ot-empty.client.tgz or dot-ot-clean.client.tgz that is the moment when you should seriously consider the stuff that is in ~/.ot/client_data/certs/special.
In there we have placed a certificate authority (ca.crt) and a certificate signed by that authority (client.pem).
You will probably not want to use those distributed ones for creating any mission-critical nyms, nor presumably any nyms created using them for any mission-critical accounts and especially not for signing any mission-critical contracts.
I am right now going through everything on my side making sure they are not the same ones my server's client_data has nor the same ones my personal ~/.ot has.
Well actually, the ca.crt seems to stay the same, as it is not part of what gets generated when you do the make in the source code's ssl directory to generate new certs for the client and server. So I am not yet sure who the certificate authority actually is or was. But the rest of the special stuff does get made fresh. (In sourcs dir, do cd ssl then touch *.cnf or actually tailor the .cnf files to your needs, then make).
If you have a "real" certificate for your http website or whatever, then maybe you might want to use that for creating your website's client_data so signing things relating to your website using OT will have some kind of actual back-trail all the way back to the root cert that signed the certs of the cert authority that issued you your website cert.
-MarkM-
EDIT: When you "make" OT, it does NOT currently at time of writing use your fresh new ./ssl stuff to create fresh new sample data. We probably should add to OT's make the making of a frsh newdot-ot-yours or somesuch, I don't think (tho not positive) that the ~/.ot make install creates for the user who runs make install (usually root, since it tries to install binary executables into /usr/local/bin) uses fresh new ./ssl date you maybe created, either.
Some of the files in the ./ssl look like they might be intended for use as, or for making, a ca.crt, but I am not clear what exactly is going on there so thus far I have only been copying a newly made fresh client.pem from there into the ~/.ot/client_data/certs/special directory. So possibly I am not actually ending up with a ca.crt that matches the client.pem. All this will have to be thoroughly checked out to figure out exactly what one should end up putting there, especially in cases where you have real certs signed by a real authority (such as yourself heh.
)
The full set of fixes are in the smartcontracts branch of FellowTraveler's GitHub repo, not yet merged back into the master branch.
I have generated new certificates, used them to create a new nym to serve as admin/signing nym for a new server, and used that nym to sign a new DigitalisOTserver.otc which I have uploaded to the galactic milieu files download directory on SourceForge.
I have also created a sample/example "empty" ~/.ot directory for clients, it has no nyms no currencies no accounts but does have my new server-contract and uploaded it to SourceForge as dot-ot-empty.client.tgz
I have lots of currency contracts to write and sign using the latest fixed versions of the OT server and client, as I create those I will put the .otc files of the contracts on SourceForge and also start putting a dot-ot-clean.client.tgz that will have the main currencies my server intends to work with as well as my server's contract.
We are still in alpha; FellowTraveler intends to check that my contracts work on his installed client and so on tomorrow.
However, even in alpha it is worth being aware that although Open Transactions is not totally married to its past with merkle trees like blockchains are, there is some one thing building upon another involved. So if at any point you feel ready to create some nym or contract or account that might make you not want to totally delete your ~/.ot and start over again from a fresh new dot-ot-empty.client.tgz or dot-ot-clean.client.tgz that is the moment when you should seriously consider the stuff that is in ~/.ot/client_data/certs/special.
In there we have placed a certificate authority (ca.crt) and a certificate signed by that authority (client.pem).
You will probably not want to use those distributed ones for creating any mission-critical nyms, nor presumably any nyms created using them for any mission-critical accounts and especially not for signing any mission-critical contracts.
I am right now going through everything on my side making sure they are not the same ones my server's client_data has nor the same ones my personal ~/.ot has.
Well actually, the ca.crt seems to stay the same, as it is not part of what gets generated when you do the make in the source code's ssl directory to generate new certs for the client and server. So I am not yet sure who the certificate authority actually is or was. But the rest of the special stuff does get made fresh. (In sourcs dir, do cd ssl then touch *.cnf or actually tailor the .cnf files to your needs, then make).
If you have a "real" certificate for your http website or whatever, then maybe you might want to use that for creating your website's client_data so signing things relating to your website using OT will have some kind of actual back-trail all the way back to the root cert that signed the certs of the cert authority that issued you your website cert.
-MarkM-
EDIT: When you "make" OT, it does NOT currently at time of writing use your fresh new ./ssl stuff to create fresh new sample data. We probably should add to OT's make the making of a frsh newdot-ot-yours or somesuch, I don't think (tho not positive) that the ~/.ot make install creates for the user who runs make install (usually root, since it tries to install binary executables into /usr/local/bin) uses fresh new ./ssl date you maybe created, either.
Some of the files in the ./ssl look like they might be intended for use as, or for making, a ca.crt, but I am not clear what exactly is going on there so thus far I have only been copying a newly made fresh client.pem from there into the ~/.ot/client_data/certs/special directory. So possibly I am not actually ending up with a ca.crt that matches the client.pem. All this will have to be thoroughly checked out to figure out exactly what one should end up putting there, especially in cases where you have real certs signed by a real authority (such as yourself heh.
) December 01, 2011, 10:55:07 AM
This is great news.
Yeah, I can basically do preferred shares with it already, and common shares but await the planned voting and dividends subsystems...
-MarkM-
December 01, 2011, 10:52:27 AM
This is great news.
December 01, 2011, 10:51:10 AM
I was told there is one. Very ugly apparently but I think its open source so you can pretty it up to suit your own tastes as you choose.
Meanwhile, we found there is a problem with clients adding whitespace to contracts on import that makes contract hashes wrong when client is used to import. So all the currency contracts will have to be re-imported once that is fixed, they will have correct hashes that wont match those used in any transactions that used the broken contracts caused by the whitespace.
Ah well, that is why I labelled current stage as alpha.
-MarkM- (Looking forward to seeing what you do with the web interface...)
Meanwhile, we found there is a problem with clients adding whitespace to contracts on import that makes contract hashes wrong when client is used to import. So all the currency contracts will have to be re-imported once that is fixed, they will have correct hashes that wont match those used in any transactions that used the broken contracts caused by the whitespace.
Ah well, that is why I labelled current stage as alpha.
-MarkM- (Looking forward to seeing what you do with the web interface...
)
December 01, 2011, 09:12:30 AM
Wake me when there's a web interface.
December 01, 2011, 06:24:24 AM
In new news, I now have added Namecoins to its repertoire of currencies.
I'd be willing to add Pecunix Grams of Gold if anyone actually has some they'd like to bail-in to the system, currently I have no Pecunix AUG so no reserves, I am starting with the currencies I actually already have some (if only small in NMC case) reserves of.
I will also be adding some in-game commodities of various kinds from various games, as I already have players wanting to offer bitcoin and/or devcoin for various such things.
EDIT: I have edited the first post to also mention that you need currency contracts too, the server does not "advertise" what currencies it supports. See first post for where to get the server contract AND various currency contracts.
-MarkM-
I'd be willing to add Pecunix Grams of Gold if anyone actually has some they'd like to bail-in to the system, currently I have no Pecunix AUG so no reserves, I am starting with the currencies I actually already have some (if only small in NMC case) reserves of.
I will also be adding some in-game commodities of various kinds from various games, as I already have players wanting to offer bitcoin and/or devcoin for various such things.
EDIT: I have edited the first post to also mention that you need currency contracts too, the server does not "advertise" what currencies it supports. See first post for where to get the server contract AND various currency contracts.
-MarkM-
December 01, 2011, 05:54:09 AM
Watching this ...
doublec ... there is wiki at the github for OT server and Moneychanger also (the client)
https://github.com/FellowTraveler/Moneychanger/wiki
doublec ... there is wiki at the github for OT server and Moneychanger also (the client)
https://github.com/FellowTraveler/Moneychanger/wiki
December 01, 2011, 05:45:35 AM
Is there a tutorial or step by step example on how to get a client running and connecting to the server?
November 30, 2011, 11:31:16 PM
Actually the Open Transactions server seems to also function as a generic "exchange", and with a very nice feature that none of the "exchanges" I have come across so far include: the ability to offer different prices at different volumes of stuff traded.
For example one could offer a cheaper price for 100,000 of a thing bought in one purchase than you offer for lower-volume purchases, thus allowing people to buy wholesale quantities of things and re-sell them in retail quantities. This could be particularly useful for people who are really not interested in selling fractions of a bitcoin at a time, or are willing to pay a premium to obtain some certain quantity of something but really have no use for less than that quantity of it.
For example game tokens are often sold at lower prices per token when you buy more tokens at once. So simply being able to offer a million of them at a millionth of a bitcoin each would not be as useful as being able to offer a million for one bitcoin, a quarter of a million for half a bitcoin, a hundred thousand for a quarter of a bitcoin, ten thousand for an eighth of a bitcoin or some other wholesale-discount type of pricing structure.
The types of markets we have usually been seeing almost do the opposite of wholesale discounts, prices sometimes get higher the more you try to buy. Which is also possible of course. The basic nice additional feature not seen in other exchanges is simply the ability to specify the chunks, the number-at-a-time: the granularity.
EDIT: I have made Open Transactions currency contracts now for DigiBTC and DigiDVC, so now just that easy I have a BTC<->DVC exchange set up.
EDIT2: I have now added I0Coins to its repertoire of currencies.
-MarkM-
For example one could offer a cheaper price for 100,000 of a thing bought in one purchase than you offer for lower-volume purchases, thus allowing people to buy wholesale quantities of things and re-sell them in retail quantities. This could be particularly useful for people who are really not interested in selling fractions of a bitcoin at a time, or are willing to pay a premium to obtain some certain quantity of something but really have no use for less than that quantity of it.
For example game tokens are often sold at lower prices per token when you buy more tokens at once. So simply being able to offer a million of them at a millionth of a bitcoin each would not be as useful as being able to offer a million for one bitcoin, a quarter of a million for half a bitcoin, a hundred thousand for a quarter of a bitcoin, ten thousand for an eighth of a bitcoin or some other wholesale-discount type of pricing structure.
The types of markets we have usually been seeing almost do the opposite of wholesale discounts, prices sometimes get higher the more you try to buy. Which is also possible of course. The basic nice additional feature not seen in other exchanges is simply the ability to specify the chunks, the number-at-a-time: the granularity.
EDIT: I have made Open Transactions currency contracts now for DigiBTC and DigiDVC, so now just that easy I have a BTC<->DVC exchange set up.
EDIT2: I have now added I0Coins to its repertoire of currencies.
-MarkM-
November 30, 2011, 10:41:46 AM
What's an Open Transactions server ?
the server part of the Open Transaction protocol.it is sort of like a centriliziced bitcoin system. but uses some other principles.
November 30, 2011, 10:37:59 AM
What's an Open Transactions server ?
November 30, 2011, 01:48:09 AM
With heroic support from FellowTraveler I now have an Open Transactions server up and running.
Once you let private keys leave your house, you really cannot know whether/when some hacker group has managed to get some employee of a hosting company to slip them a copy, so I really do not want to set it up on third party hosting.
We used to run an ISP from this house I am in, we can easily expand operations right here where we know exactly who can get at the hardware and what their technical skills are.
I have placed the server contract in the same SourceForge download-files directory as the devcoin and groupcoin releases, its filename when in actual use is a hash of the signed contract, which would not mean much at a glance to a human looking for the contract so I have made it available as
https://sourceforge.net/projects/galacticmilieu/files/DigitalisOTserver.otc
I have learned that the server doesn't tell you about currencies it has contracts for, you are expected to go get currency contracts yourself. So the
https://sourceforge.net/projects/galacticmilieu/files/
directory now contains .otc files (Open Transactions Contract files) for various currencies as well as for the server.
(They are in the digitalis-assets.tgz archive file.)
I currently only have a 64 bit Fedora Core 17 machine running, so can only make binary archives of the client for that platform currently. Luckily, making the client is nowhere near as much of a challenge as creating a working server, so maybe we can get client binaries made for other platforms.
-MarkM-
P.S. I should probably point out that this is heavily bitcoin-oriented and that bailing bitcoins in in a way that allows only a number of servers all agreeing to determine where they should be released to is part of the Open Transactions roadmap. We want to get set up to work with bitcoins using Open Transactions and get Open Transactions servers well tested ready for when it will take several, maybe even many, such servers to decide the fate of any bitcoins bailed into the care of federations of such servers...
Once you let private keys leave your house, you really cannot know whether/when some hacker group has managed to get some employee of a hosting company to slip them a copy, so I really do not want to set it up on third party hosting.
We used to run an ISP from this house I am in, we can easily expand operations right here where we know exactly who can get at the hardware and what their technical skills are.
I have placed the server contract in the same SourceForge download-files directory as the devcoin and groupcoin releases, its filename when in actual use is a hash of the signed contract, which would not mean much at a glance to a human looking for the contract so I have made it available as
https://sourceforge.net/projects/galacticmilieu/files/DigitalisOTserver.otc
I have learned that the server doesn't tell you about currencies it has contracts for, you are expected to go get currency contracts yourself. So the
https://sourceforge.net/projects/galacticmilieu/files/
directory now contains .otc files (Open Transactions Contract files) for various currencies as well as for the server.
(They are in the digitalis-assets.tgz archive file.)
I currently only have a 64 bit Fedora Core 17 machine running, so can only make binary archives of the client for that platform currently. Luckily, making the client is nowhere near as much of a challenge as creating a working server, so maybe we can get client binaries made for other platforms.
-MarkM-
P.S. I should probably point out that this is heavily bitcoin-oriented and that bailing bitcoins in in a way that allows only a number of servers all agreeing to determine where they should be released to is part of the Open Transactions roadmap. We want to get set up to work with bitcoins using Open Transactions and get Open Transactions servers well tested ready for when it will take several, maybe even many, such servers to decide the fate of any bitcoins bailed into the care of federations of such servers...
Jump to: