No problem. Excellent questions!


…and get money back out again. I assume by this you mean "legacy cash money in hand" and/or "legacy money in the legacy bank."

--- Keep in mind that most transfers will happen inside the OT system, or on the blockchain…
--- That is, while bailing legacy cash in/out of the system is possible, that should not happen for each and every transaction….
--- Also keep in mind that once you bailout BTC or colored coins from an OT server, then it has passed outside the sphere of OT, and you can cash it out in whatever conventional way that you normally would, based on the existing market for Bitcoin services. (This would be an option as well.)
--- …Therefore I restricted my Bitmessage examples to only cases where the two parties both are transacting within OT. (The reason being that we can then assume that OT's powers apply -- such as markets and escrow.)

That having been said, here are various options I can imagine for bailing legacy funds into/out of the system …

=> Bitcoin ATMs. These were at the Bitcoin 2013 Conference in various configurations, and so the option is rapidly approaching to use them.

=> Through your social network: This was always what enamored me of the Ripple idea originally -- that instead of using a centralized exchange, you can just "go through your friends." And if your friend will hand you some cash in return for a Ripple transfer, then similarly he should be willing to hand you some cash in return for an OT or blockchain transfer. (And vice-versa.)

=> Geolocation: Apple has recently publicized the concept of people providing ATM service for each other. Your iPhone just finds someone nearby who hands you $60. (At the same time, $62.50 is charged to your iTunes account.)
The same could clearly work for colored coins in a P2P app. (Even the open-source community could easily build such an app using OT -- though Monetas itself possibly could not, depending on the status of Apple's patent.)

=> SEPA transfer: In Europe, bank users can quickly and easily send transfers to each other's accounts through the SEPA API, and verify whether such transfers have been made.

=> Meetups: There are already local Bitcoin meet-ups; thus it seems like a viable method of exchange for cash.

=> Gateways: (Ripple seems to have popularized this nomenclature, so I'm going to use it here.) This is any business that users are willing to trust for the purposes of sending/receiving bank wires, SEPA transfers, ACH transfers, etc.

===> The main difference here is that in the case of Open-Transactions, your funds would not be stored as an IOU from the gateway. Many have said that on this forum, but that is not actually the case. On OT, you are buying/selling BTC and colored coins, instead of issuing IOUs.
(Issuers do have the ability on OT to issue IOUs, but that is not the solution I've suggested in this thread. Rather, I've suggested to store the actual coins in voting pools so that an OT server can transact them without having to be trusted not to steal them.)

===> In the case of OT, the "gateway" becomes a "trader". Instead of holding IOUs from a gateway, you are purchasing or selling BTC or colored coins from a trader. And that Trader is NOT an OT server -- but another OT user, like you!
And since this transaction is occurring inside an OT server:
- it will be instant, instead of requiring blockchain confirmations.
- It can be performed on a market, where orders are automatically matched according to their criteria.
- It can be performed through the use of escrow -- and the terms of that escrow can be customized by the parties (since the escrow itself is implemented as a smart contract -- and users can customize their own smart contracts.)
- Via Bitmessage, wallets can coordinate cross-server wiring of funds, as well as cross-server order matching, and cross-server discovery of other wallets willing to make transfers in/out of the legacy banking system, by way of OT escrow.

===> In any case, whether you are obtaining IOUs from a gateway (Ripple), or whether you are buying/selling BTC and colored coins from a trader (OT), either way, I assume that such businesses will be willing to take/pay cash at their physical locations, and bank wires otherwise. (Otherwise, why are they even in this business?) Therefore, you can move legacy funds in/out through such businesses.
Personally, I prefer cash-in-hand over IOUs, which is why OT places such a high value on the ability to customize your escrow terms.

=> Bank Wires: One example of why I prefer cash-in-hand: If you purchase precious metals for physical delivery, you will discover that orders can be shipped based on a bank wire, yet the same business is not willing to ship based on a credit card purchase (due to chargeback risk.)
Therefore bank wires are a valid method for getting money in/out of the bank account, albeit slow and expensive.

=> Bitcoin Exchanges: exchanges are one way to trade Bitcoins for national currency and get a bank wire, so it deserves to be on this list. Any BTC traded on an OT server could presumably be bailed-off of OT and cashed-in through a Bitcoin exchange (with the laws in that jurisdiction applying.)

=> The original issuer: In the case of colored coins, there is some issuer in some jurisdiction who originally created--and has agreed to redeem--those colored coins. Presumably he could be paid (and pay others) through BTC or through bank wires or cheques.
NOTE: Most actual users shouldn't have to deal with this guy directly. Another note: Once users have uploaded these coins into multi-sig voting pools, they can then devise basket currencies to hold and transact with. This enables users to distribute the risk of a single currency across many issuers.

=> Prepaid card / bank card: It seems that a prepaid card could be given to the user, with funds placed onto the card easily enough based on whether the user had paid the card issuer on OT.
- Escrow probably not necessary in this case, and card issuers can demand to be pre-paid.




She cannot, although the above examples are all different. This is why I place such a high premium on escrow, reputation, risk limits, and cash streaming protocols.


If the money is stashed inside a smart contract on OT, then the OT server is incapable of forging any receipts internally, nor is it capable of stealing BTC or colored coins from the multi-sig voting pool those coins should be stored in. Therefore the holder (OT server) cannot disappear with those coins.

You might ask, but which party to that smart contract is ultimately going to get the funds, in the event of a dispute?


This is totally determined by the smart contract itself. And since these can be customized (through scripted clauses), then ultimately the open source community will have to decide for themselves, for the various cases, what is an acceptable distribution of risk.

For example, let's say that Jorg is receiving colored coins all day, in return for SEPA transfers. He might deal with scammers all the time, which is why he demands a smart contract where the funds go into escrow and he can verify their existence (safely stashed there) before initiating the SEPA transfer.

Also, let's say that his terms specify that once he notifies the smart contract of the initiation of the SEPA transfer, he is guaranteed that he will receive the escrowed colored coins after X hours, unless Alice files a dispute.

…And in THAT case, say the smart contract terms require the decision to then be rendered by Judge Judy (as the sample escrow contract in OT actually does.) And then things will either be proved to her, or they won't. (And if you don't trust Judge Judy's adjudication skills, then don't use a trader who insists on using Judy's contract.)

Jorg might have to operate based on a whitelist or even a blacklist -- but at $X per transfer, he'll be operating. And remember, he's not issuing IOUs -- he's just buying and selling BTC and colored coins. He's also not operating an OT server, since he is actually just another user, like you.



Here is an article on Open-Transactions smart contracts.

--- To whatever degree that SEPA API calls are possible to automate verification of transfers, then I'm sure those will end up being used.

--- To whatever degree transfer protocols are possible based on parties providing manual notifications to the smart contract of certain payment events, those will be happening as well.

--- To whatever degree that "Judge Judy" has to get involved and make a human decision, in the case of disputes, then smart contracts will have to support that mechanism. (The escrow sample contract that comes with OT, already does this.)

---- To whatever degree that whitelists, blacklists, and other reputations systems become necessary, (monkeysphere ?)

--- …as well as to whatever degree risk limits and cash streaming protocols will be used, they will be, -- wherever they enable new transactions that people could not previously perform.

More step-by-step...

1. Wallet uploads BTC to voting pool, in order to trade them around on an OT server.
    -- AND/OR --
1. Wallet uploads colored coins to voting pool, in order to trade them around on an OT server.

Also notice that the colored coin issuer does not directly issue anything onto an OT server. Issuers can issue directly onto OT servers, but I suggest using colored coins and voting pools in order to break that link.

2. From this point, it's easy to use Open-Transactions for escrow, and for market trading, on that OT server.
   (Server is unable to forge receipts internally, nor steal from multi-sig pools externally.)

3. Using a discovery layer (Bitmessage, IRC, etc) users who are not already on the same OT server can discover each other, and select a server to meet on, to complete the trade / escrow. (This can all be automated inside the client software.)

4. The same discovery layer makes it easy to wire funds from one server to another, through other users.

5. The same discovery layer makes it easy for users to discover each other for SEPA transfers, facilitated by OT's escrow capabilities.

6. These SEPA transfers could also be performed by services, who are themselves just "other users." (This is the basic concept of Ripple "gateways" as far as I can tell.) OT escrow is used here to remove trust.

7. Even credit lines could be issued cross-server, now that the discovery layer is solved.

The specifics of the discovery/OT protocol are in the paste bins at the top of this thread.

All conversions for a particular user are performed by his own wallet, in a user-centric fashion.

We need to move away from a provider-centric mindset, and instead become provider-independent -- demoting servers from "authorities" to mere "cloud commodities." (For examples of this concept, see Diaspoa and Tahoe.)

Nobel prize is a joke these days.

Yes.

Well think about it -- anytime I proposed something related to Open-Transactions, I eventually ended up having to code it myself, too.

Therefore I believe the same is true of Satoshi: he proposed some great idea, and no one did anything with it, so eventually he just coded it himself. Who else would be more likely to have done so, other than "himself" ?  In my own experience, that's the way it goes.

Miner_Willy, this is an excellent point. However, there's no reason why the users can't just cash out colored coins with each other WITHOUT using SEPA. Which they can do, as long as they trust the colored coin issuer to perform redemption "of last resort."

And then the actual "last resort" redemptions (through the issuer himself) can all be legitimate (non-reversible) and can occur through bank wires and AML/KYC.

Therefore I believe this solution still stands, even without SEPA.

P.S. I agree with you about the usefulness of a reputations system. How about Monkeysphere? (I will have to defer to the experts on this...)

> Why did no one think of Satoshi's system before Satoshi?

Have you seen Wei-Dai's bmoney proposal?

Hmm...

--- Wei Dai lives in the UK. Satoshi writes with UK English.

--- Wei Dai invented the cryptopp library. Satoshi wrote Bitcoin using the cryptopp library.

--- Wei Dai is Asian. Satoshi is probably Asian.

--- Wei Dai proposed the original idea for "B Money"...

--- Wei Dai is a professional Windows developer. Satoshi was obviously a Windows developer (see his code...)

--- IMO, Wei Dai IS Satoshi.

A colored coin issuer can demand KYC info from anyone converting in/out directly through that issuer.

Therefore the issuer is compliant. (Consult an attorney -- that's my opinion, and it's not legal advice.)

This is no different than MtGox is today: users are giving each other BTC all the time outside of MtGox -- but only the ones who cash out through a MtGox bank wire actually have to cough up their identification info.

Similarly, people could be giving each other colored coins all the time -- but only the ones who actually cash out through the colored coin issuer will actually have to cough up their identification info. (The coins that circulate outside their reach are comparable to dollars which circulate outside the reach of the Fed.)

... So for example, users could utilize local meetups...

...Or as I have proposed, users could use OT escrow in combination with SEPA to directly redeem...

Open-Transactions is always going to be about a wallet-centric solution, not a provider-centric solution. We want provider independence.


As long as the issuer performs redemptions "of last resort" then technically, you could move fiat in/out through any other user.


This is similar to what I have proposed. Stick the BTC in a multi-sig voting pool for safety, and then use Open-Transactions escrow and Open-Transactions markets for the actual exchanges.

(Except in my proposal, everything is automated.)

From there, Bitmessage provides discovery layer. But there's no reason why OT itself couldn't have its own broadcast net, nor why we couldn't use something like IRC to serve that same purpose.


Well in my proposal, I wrote: The above protocols can be implemented inside OT wallet GUIs, such that they are automated and transparent to users.

Why does that not sound very user-friendly?

People have often complained that OT was "too complicated" -- but I guarantee you they are wrong. (These complaints predate the high-level API.)

For example, see the high-level API -- most financial actions can be done in a single line of code. Developers couldn't ask for easier.

And see the screenshots for the upcoming iPhone app -- Users couldn't ask for easier.

I was trying to be nice by giving everyone a few years head start on creating their own OT clients... That doesn't mean easy clients aren't possible, because I personally haven't released one yet. It just means I wanted to allow others the chance to release them first. (So I could focus on the core library...)


I should point out that most of the solution was latent inside Open-Transactions itself. I'm actually surprised no one else thought of it before -- I mentioned the idea on my FAQ years ago.

Bitmessage is very useful as the discovery layer -- but there's no reason why you couldn't swap in a different discovery layer.

For example, the same solution is basically just as easy to do by using IRC as the discovery layer.


I can't speak for Ripple (I haven't seen their code) but OT doesn't contain central points of failure.

Open-Transactions is user-centric, not provider-centric.

For those asking for hand-holding....


See the docs folder for instructions on installing the pre-requisites.

Once you have those installed, this is usually what I do to build:


(The reason I configure with java is so I can run the test-GUI.)

Then build the project:


You can also do "make -j2" or -j8 etc to make it build faster, depending on how many CPUs you have (and how much RAM.)

There is also now a tarball installable through apt-get though I don't know if it's the most recent version (better to build it yourself, because then you can always "git pull && make install" to update to the latest version.)

Once you have it installed, I suggest you start by copying over the test data:


Then start up the server:


Then you should be able to use the command line tool (in a separate window):


Etc. You can also make scripts by putting "!/usr/bin/env ot" at the top of the script. (See the scripts/samples folder.)

If you want to try to OT test GUI (Moneychanger):


(You will probably have to tell it the /usr/local/lib folder, and then select an image from your harddrive.)

People ask why they have to select an image. The reason is so that hackers cannot do phishing attacks by tricking you with a fake passphrase dialog. They will have no way of anticipating which image you have selected to appear on that dialog, so it will look different for every user.

I should add that the test GUI is not representative of an actual OT GUI. It's just a visual representation of the API, for testing/developing purposes. To see what an actual GUI would look like, check out the screenshots of the upcoming Monetas iPhone app.

You can get support on the OT IRC channel, #opentransactions at irc.freenode.net

Some people have contacted me asking about investing. I suggest you contact our CEO Johann Gevers: johann@monetas.net

If you would like to try your hand at an Open-Transactions logo, that would be great.


I'm a fan of the Ripple idea (credit lines) and have always said that I would eventually build it into OT.

(Perhaps sooner rather than later, now that cross-server discovery is solved.)

As for the current Ripple incarnation, I hope their technology proves out and that they are successful.

There is no need to bash people who are trying to contribute to monetary freedom.


--- The transaction notification is used in server-to-server wiring of funds, to unlock the escrow on both sides.
--- The servers can negotiate this between each other directly (since Alice and Bob have notified each server of the other's existence.)
--- In essence, this piece is negotiated directly by the two smart contracts.
--- This doesn't have to go through Bitmessage; that's only used for discovery process.
--- The parties can also directly notice the servers, but this is not necessary for it to work.

> Txs therefore can be instantaneous, but might also incur a variable delay?

I'd say this is accurate, though I would expect it to basically seem instantaneous.


On the commercial side, we have just closed our seed round, and started our second round.
Screenshots of upcoming Monetas iPhone app

I can say the p2p exchange technology is definitely coming, probably first in some future incarnation of our systray app,  but the timing will depend.

On the open-source side, any donations will be re-donated to various OT contributors for their work.
1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ


For specific step-by-step walkthrus of the Bitmessage-related protocols, see the paste bins I posted at the top of this thread.

Here are more details to help clarify...

CURRENCIES

--- Blockchain-based commodities. (BTC, LTC, etc)

Keep in mind: Blockchain-based currencies such as BTC will not have a proper "issuer" on OT; instead they will be uploaded directly by users into voting pools, where an OT server can issue units based on the BTC yet simultaneously are incapable of stealing those BTC. (They cannot steal them from the voting pool because they are protected by multi-sig, and they cannot steal them internally because the OT servers are incapable of forging receipts.)

--- Colored coins. (These are real-world assets such as gold, dollars, pork bellies, etc which are accounted-for using satoshis on the blockchain, and are redeemed by their issuer upon demand.)

Important things to remember about colored coins:

1. The issuer of colored coins can never be held liable to freeze specific satoshis, because they have no control over the ledger (it's on the blockchain.) Which is to say, the colored coins actually do circulate entirely beyond their control. Just as the Federal Reserve issues dollars which then circulate entirely outside of their control, and thus they cannot be held liable for what happens while they are in circulation.

2. This breaks the link on OT between the issuer and the transaction server, since the issuer no longer needs to directly issue their gold onto the OT server. Instead, the issuer uses colored coins, and then those get issued by wallets into voting pools, to make them available for trading on OT servers. This means that pressure against the issuer can never result in withdrawing their currency from an OT server, because they don't have to issue it directly onto an OT server, for people to still trade it there.

3. Most people will not ever need to redeem their colored coins directly with the issuer of those colored coins. As long as the issuer is good for them, they will be able to redeem their colored coins directly through other wallets. So the issuer only provides redemption "of last resort."

4. Anyone who does redeem colored coins at a colored coin issuer, will be subject to the laws in that jurisdiction, AML/KYC, etc. (So there is no need to violate those laws.)

5. Anyone who buys/sells colored coins will not incur capital gains tax risk, since colored coins, unlike BTC, do not go up in value. (Meaning, a $100 colored coin does not change in value between when it was bought and sold, and thus does not incur capital gains. Consult your attorney on that one BTW.)


LEGACY BANKS

--- Transfers to-and-from the legacy banking system are performed via ACH in the USA, and SEPA in Europe.

--- SEPA transfers are instant. ACH transfers can take 3-5 days. Either way, the OT side of such transactions will use OT's ability to perform escrow.

--- Although people will have the ability to go in-and-out of the banking system, I don't expect this to happen with every transaction. I do expect it to happen sometimes.

--- I expect that some of these transfers will happen P2P (SEPA is particularly suited for this) as well as through professional services (probably similar to Ripple gateways.) Any OT Nym could perform such functions.

--- We can automate such things in the wallets, making the actions user-centric, instead of provider-centric.


OPEN-TRANSACTIONS FEDERATED SERVERS

--- Any Nym will be able to upload BTC or Colored Coins into a voting pool (where the OT server cannot steal them) and the OT server then issues the appropriate units to that Nym via OT's unforgeable receipts.

--- The Nyms are already able to perform escrow with each other, on any OT server.

--- The Nyms are already able to trade one currency against another, on any OT server.

--- Already you can have the same currencies issued onto multiple OT servers.


BITMESSAGE

--- Bitmessage makes it possible for Nyms to discover each other and OT servers. Thus:

--- Bitmessage makes it possible for Nyms to perform currency wires from one OT server to another, through other Nyms.

--- Bitmessage makes it possible for Nyms to perform cross-server trades (by enabling discovery.)

--- Once discovery has taken place, Nyms can perform escrow, as well as market trading, since OT already supports those things.

For specific step-by-step walkthrus of the Bitmessage-related protocols, see the paste bins I posted at the top of this thread.



I suppose so, yes.


Yes, although at some point we are going to have it in the Monetas systray app. (For starters.)


The delay in/out of a legacy bank account will depend on the legacy banking API you are dealing with.

As far as I know, SEPA is near-instantaneous. ACH, not so much.


I can't really say, I haven't seen their code.


It's not the same as credit lines, no.

Not that credit lines are a bad idea -- I will eventually be adding them to OT as well.
(Especially now that cross-server discovery is solved…)


I believe that Bitmessage uses proof-of-work to prevent spamming.

Also consider that most messages can go directly through OT itself -- Bitmessage is only for discovery.

Also -- even if we swap out the discovery layer for something else, OT should continue to work just fine. (But so far I think Bitmessage is perfect.)


This is basically correct.

Bitmessage, however, would only be the network for discovery purposes. All other communications can go directly between OT servers, and P2P between OT wallets.


OT's cash instrument uses Chaumian blinding.

However, there are other instruments on OT which do not use Chaumian blinding: cheques, invoices, recurring payments, market trades, smart contracts, etc.

These other instruments, while not blinded, are still pseudonymous, and the receipts are destructible. (It can still prove everything without the receipt history, as long as you have the last signed receipt.)


It clicked for me.


Yes.


OT is a system for federated issuing and transacting of various currencies. It can work with and without blockchain-based currencies.

Bitmessage is a p2p system for messages as well as subscriptions/broadcasts.

In our proposed protocol, OT federated servers will utilize Bitmessage as a discovery layer to enable cross-server escrow, for the purposes of market trading and wiring of funds between OT servers (and in/out of the legacy banking system.)

You can read more details above.


Please see details above, especially the protocol details in the paste bins I posted.


OT is fully-functional and usable. At least, the server and command line, as well as the API and client-side scripts.

There is also a test-GUI, and Monetas will be coming out with real GUIs very soon.

But the real beauty is the things you can build with OT, by integrating it into your own projects.

We are working on the voting pools, and the p2p exchange stuff will take a bit longer since it was just designed last night.
(Although who knows, if the second round of funding goes well, we might have it out a lot sooner.)

I should mention, BTW, that OT is completely open-source, and any products released by Monetas will be open-source as well.


This isn't entirely correct. OT cash is untraceable. But if you want to prove you paid someone, then use an OT cheque instead. (And you'll have a cheque receipt…)


The exchange protocol wouldn't be over Bitmessage, it would be internal to OT.

Bitmessage would be used for the discovery process. See my paste bins.


I don't think banks will have to run OT servers.

Any colored-coin issuer can fully-obey KYC / AML.

The issuer would be entirely divorced from the OT transaction servers, which could operate on Tor.

------------------------------------------------------

I can also reveal that Adam Back believes he has solved the problem of homomorphic amounts (so the OT server can't see any of the amounts, on any of the transactions it processes.)

I will be integrating credlib into OT soon and also working with Adam on adding his homomorphic code to OT as well.

The name is "Open-Transactions."

The above protocols use Bitmessage for the discovery layer, but any other discovery layer could also be swapped in.

Yes.

Most of the capabilities were already latent in OT. Bitmessage is just what solves discovery.

(In fact you could swap it out for any similar solution which solves discovery.)

Last night, randy-waterhouse and I were experimenting with Bitmessage. (*smooch*!!)

Bitmessage is a p2p messaging (and broadcast / subscription) protocol, based on the Bitcoin protocol.

It uses its own blockchain, but the chain only stores the last 2 or 3 days worth of messages. (It's assumed they were delivered within that time, where they are then safely stored on the recipient's inbox.)

Combining the above Bitmessage capabilities--which we already proved out experimentally--with Open-Transactions, makes possible fully-decentralized p2p markets, as well as p2p escrow across OT federated servers, easy p2p and server-to-server wiring of funds and conversion of currencies, both within OT and also between OT and the conventional banking system.

Furthermore, this is possible with little-to-no changes inside OT itself, and will not require the issuing of credit, nor will it require any pre-mined currency.

How does it work?

-----------------------------------------------------------

A few concepts...

--- First, keep in mind the concept that Bitcoins and Colored Coins (either/both) could be issued onto an OT server, without having to trust the server itself, through the use the multi-sig "voting pools" on the blockchain itself. I've already extensively discussed this on this board, and here's an article on how it's done:  http://bitcoin.stackexchange.com/a/834/309

--- Second, keep in mind that using Colored Coins instead of Bitcoins is advantageous in certain circumstances, as it allows users to buy/sell those colored coins (for the purposes of transmitting other currencies) without incurring any capital gains tax liability. (I'm not a lawyer and that's not legal advice. The basic gist is, if you buy a colored coin for $100, and sell it for $100, there is obviously no gain or loss.)

-----------------------------------------------------------

T H E   H O L Y   G R A I L

Enter Bitmessage! (Which solves discovery across federated OT servers.)

As I said, randy-waterhouse and I already TESTED Bitmessage last night to prove experimentally that this is possible (and it worked.)

-----------------------------------------------------------

Using Bitmessage with OT to effect server-to-server wiring of funds: http://pastebin.com/NjQgDarx

--- The wiring protocol is all about Alice trying to discover Bob so she can move her money from one server to another (and Bob trying to discover Alice so he can make a profit by moving money from one server to another.)

-----------------------------------------------------------

Using Bitmessage with OT to effect escrow-based conversion of currencies across OT federated servers:  http://pastebin.com/S1W5guAQ

--- The currency conversion protocol is about Alice and Bob being able to choose a server they can agree to meet on so they can trade one currency for another inside OT. (For cases where they aren't already trading on the same OT server.)

-----------------------------------------------------------

Using Bitmessage with OT and SEPA so that Alice can p2p send any currency which Bob receives as Euros in his Euro account: http://pastebin.com/SsLrxVP6

--- The SEPA transfer protocol is about Alice being able to send Silver Grams, which Bob receives as Euros in his Euro bank account. It's also about Jorg earning a profit in silver grams, by sending a SEPA transfer to Bob on Alice's behalf.

-----------------------------------------------------------

We already knew that OT offered quite a few benefits to Bitcoin: http://bitcoin.stackexchange.com/a/2710/309

But now, combined with Bitmessage, Open-Transactions becomes a juggernaut!

The above protocols can be implemented inside OT wallet GUIs, such that they are automated and transparent to users.

May a million currencies bloom!

Yet another Ripple thread centered on Open-Transactions...

How to get free support for OT:  irc.freenode.net  #opentransactions

How to build OT from scratch:  https://github.com/FellowTraveler/Open-Transactions/blob/master/docs/INSTALL-Debian_Ubuntu.txt

How to install OT via apt-get:  http://www.openwallet.org/downloads/


Coming soon (screenshots): http://ft.vm.to/files/screenshots/

(There are other clients in the works, but that's just an example.)

There's also, of course, the test GUI, from which people can copy sample code: https://github.com/FellowTraveler/Moneychanger


This is half-correct.

Open-Transactions is an open-source project, not a commercial project.

Similar to Bitcoin itself: there will be commercial projects built on top of it, from various entities.

So OT will be used by commercial projects, including my own, but OT itself is not being developed as a commercial project.


I can see how you'd make this assumption, but Monetas (my commercial effort) has no plans to use closed-source.

We don't even really believe in intellectual property, and we will be releasing the code for our products when those products themselves are released.

(And yes, we know how to monetize our products regardless.)


This is a mischaracterization.

Open-Transactions is free and open-source.

Monetas will also release its products open-source.

The protocol is not proprietary whatsoever.


I was fortunate enough in my previous career, to be able to work for several years full-time on OT, at no benefit to myself.

I paid my own bills.

Hmm do you know the project very well?



Fair enough. Although there's an IRC channel where plenty of support can be had.

(There are nearly 50 people logged in there right now.)


I have too much respect for other developers to be bashing Ripple or any other project. Especially since one of the purposes of OT is to popularize concepts for other developers to adopt. (Success is in all of our interests.)

That having been said, characterizing OT as "failed" is a bit ridiculous in my opinion.

--- Open-Transactions is the only open-source project that does many of the things that it does, or that combines them into a single project.

For example:

1. Untraceable cash.
2. Ricardian contracts.
3. Ability to process transactions without storing a receipt history.
4. Fully-functional smart contracts.
5. Built-in client-side scripting.
6. A full range of instruments such as cheques, cash, cashier's cheques, invoices, etc.
7. Basket currencies.
8. Recurring transactions.
9. Escrow.
10. Issue stocks and pay dividends.
11. Fully cross-platform and cross-language.

Etc. All of this is fully-functional now. And it's free and open-source, with no ulterior motives.

--- OT has been undergoing protocol testing, load testing, and real-world testing for a couple of years now. A unit test suite has started to materialize. The complete code has been available for inspection by the open-source community. There are a number of contributors. (See the commit history...)

--- OT is being integrated into a number of projects, including OpenSim. Independent developers are using it (I would know -- I provide free support for them.)

--- Tarballs and install programs are starting to appear, as well as the ability to install via apt-get.

(And I am not the one doing those things -- the open source community is.)

--- Commercial clients are also being developed for OT, and not just by Monetas (my own effort--which recently closed its seed round.)

I am a fan of Ripple, and I hope their technology proves out and that they are successful. And I'm flattered to see my project compared to it, even through the two projects really are apples and oranges.

I really don't want to turn any Ripple threads into discussions on the benefits of Open-Transactions, but if the discussion begins to hinge on my project instead of theirs, then I'm going to be forced to pop up and respond.

I hope you understand.

It needs to have a screen.

Hi all!

It is I, your good buddy Fellow Traveler, with some Open-Transactions news...


IN THIS ISSUE:
--- Monetas iPhone app (Screenshots!)
--- HUGE progress on OT's SMART CONTRACTS!
--- Many questions answered in recent Reddit thread.

-----------------------------------------------------------

First, I'd like to direct your attention to a recent Reddit thread about Open-Transactions.
A lot of questions are answered in there, so you guys might find it interesting:

"Anyone that has read about OpenTransactions got the feeling this could be the next big thing, and a huge boost to Bitcoin?"

http://www.reddit.com/r/Bitcoin/comments/1e3s82/anyone_that_has_read_about_opentransactions_got/

-----------------------------------------------------------

iPHONE APP!

I thought you guys might like to see a sneak-peek at the up-and-coming ***iPhone app*** for Open-Transactions, from Monetas:

===> http://ft.vm.to/files/screenshots/ <===

Sweet, eh? (Not done yet, but getting close.)


==> You may have heard people refer to OT as overly-complicated...

...But they're behind the times! Since the high-level API "OTMadeEasy" was released, most financial actions can now be performed with a single line of code. (See the demo programs provided in php, python, csharp, java, etc.)

==> You may also have heard naysayervers derisively scoff that OT is difficult-to-use...

...But now with the new iPhone and Android apps nearing completion, such talk is quickly becoming an artifact of the past. (Please be sure to educate the misinformed, whenever you encounter them.)

Indeed, I already gave a little time -- a headstart -- to other developers, over the past few years -- an opportunity to create GUI user apps of their own, before moving on it myself.

...But the headstart is now over! (For user apps, anyway.)

Of course, just using OT in your own projects, will still give you a huge headstart, vs re-inventing the wheel. And there are so many other things which could be built, beyond mere user apps.
(The real vision is RESOURCE ALLOCATION amongst cloud APIs.)

-----------------------------------------------------------

QUESTION:  Is Monetas a commercial version of OT?

===> NO... But Monetas will sell commercial software built using the OT library.
===> (Such as the iPhone app.)

===> To be clear: Open-Transactions is an open-source platform, period.
===> Monetas, on the other hand, is building commercial software that runs on top of the OT open-source platform...
===> ...an iPhone app, an Android app, a Systray app (with plugins for Chrome, Firefox, Skype, etc.) Voting pools, scalable architecture, etc.


===> Another way of looking at it: Open-Transactions is built to make financial transactions easy for PROGRAMMERS...

===> ...Whereas Monetas aims to make OT easy for USERS by providing user apps, and for the ENTERPRISE by providing additional architecture.

-------------------------------------------------------------------


*** Progress on SMART CONTRACTS ***


I'm really excited about this one!

While OT has had smart contracts for a while now, the API didn't expose enough of the functionality to make them useful, beyond a proof-of-concept. For example, it was previously impossible to create smart contracts, or sign them, or activate them, without having to first write a special custom script for each of those steps   :-(

But that has all changed! Over the past few months, A LOT OF WORK has gone into exposing more and more of the smart contracts functionality through the API, enabling us to update the OT tools considerably...

===> You're wondering: WHAT exactly are the new CAPABILITIES?

In a nutshell:

1. Smart contract templates are now fully-functional.
2. The 'opentxs confirm' and 'opentxs propose' commands are now fully-functional!
3. Special 'smartcontract.ot' tool for viewing/editing the templates -- fully-functional!


In greater detail:


EASILY **CREATE AND RE-USE** SMART CONTRACTS

--- There is a special script that allows you to CREATE your own smart contracts. (It's called smartcontract.ot) When you run smartcontract.ot, you can dynamically construct your own smart contracts--defining the parties, the bylaws, the clauses, the agents, etc.

--- This creates a smart contract TEMPLATE. That is, a pre-made template which can easily be re-used many times by different groups of parties. The idea is that the "lawyers" among you can design smart contracts, which many other people can then easily use.

--- (FYI, the smartcontract.ot tool can also be used to load/view existing templates, so you can explore other people's smart contracts dynamically and see all their parts.)

--- A few PRE-MADE templates are bundled with OT, including ***Escrow with Arbitration.***



EASILY **SIGN AND ACTIVATE** SMART CONTRACTS (brand new!)

--- New command-line options have been added to make this functionality easily accessible. For example, you can now use the 'opentxs confirm' command to sign onto a smart contract, which is then automatically sent on to the next party (appearing in his inbox) so he can sign it too, and sends it on to the next party, etc, until the last party ACTIVATES IT to start processing!

--- As a result of this, the scripts/smartcontracts/escrow folder is now EMPTY except for the escrow template itself!  All the supporting scripts have now been erased -- they're simply not needed anymore. Just use smartcontract.ot to view/edit, and use 'opentxs confirm' to sign/activate.

--- Open-Transactions now automates all the work of placing these contracts in your outbox, and in your recipient's inbox, and sending the appropriate notices when the agreements are activated (or when they fail to activate.)

--- Payment plans (recurring payments) are now fully-functional as well. You can create them using the 'opentxs propose' command, and sign/activate using 'opentxs confirm'. They work similarly to the smart contracts. (Inbox, outbox, notifications to all parties, etc.)

--- This means we can FINALLY add smart contracts AND payment plans into the Moneychanger test GUI. Huzzah! (So that's coming soon.) In the meantime, enjoy the new command-line tools!



There's more, but I don't want to overload you guys, so I'll save it for my next announcement (coming soon.)


Your friend,

Fellow Traveler


P.S. BTC donation address: 1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ
All donations will be re-donated to people in the open-source community who work on OT, to reward them for their hard work. Special shout-outs to randy-waterhouse, da2ce7, knotwork, BlueWall, and others.

P.P.S. Anyone interested in the commercial side (Monetas) please contact johann@monetas.net