Note to admins: if this post is misplaced, please move it to a more appropriate place, thank you.


Hi everybody!

I made a video walkthrough of Open-Transactions. (Using the "Moneychanger" test-GUI available here: https://github.com/FellowTraveler/Moneychanger)

It includes demos of OT nyms and contracts, issuing a currency, opening accounts, and using financial instruments (including cheques and untraceable cash).
There's also some Bitcoin discussion, and a demo of the new Market screen on Moneychanger.

First video:  http://vimeo.com/28141679
Second video: http://vimeo.com/28142096

I hope you enjoy it!

Your friend,

---FellowTraveler

---------------------------------
Bitcoin donation address for Open-Transactions:
1NtTPVVjDsUfDWybS4BwvHpG2pdS9RnYyQ

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:


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:


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

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

You are correct that OT is a library. Additionally, it is also a server, a client API, and a GUI test client (in Java.)

You described its functions thusly: "for creating digital contracts, exchanging these contracts, signing them, checking signatures & so on. Is that correct?"

Yes, but much more...
OT enables you to issue CURRENCIES based on those contracts,
and it enables anyone else to open ACCOUNTS in those currency types.

It also enables users to withdraw in untraceable digital CASH.
Users may even operate CASH-ONLY (without accounts.)
OT also enables users to take advantage of OTHER INSTRUMENTS,
such as CHEQUES, CASHIER'S CHEQUES, ACCOUNT TRANSFER, etc,
the same as they would normally at the bank down the street.

Users can even trade their digital assets on MARKETS against other
asset types, the same as they do now on sites like MtGox.

OT also does these things with SIGNED RECEIPTS, in such a way that not
even a server can forge a transaction, or change your balance, without
first getting your signature. (The server cannot forge your signature on a
receipt.)

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



The client API, with comments, is here:
https://github.com/FellowTraveler/Open-Transactions/wiki/API

Instructions for using the client API are here:
https://github.com/FellowTraveler/Open-Transactions/wiki/Use-Cases

A sample implementation (in Java) of a test GUI, using the OT API:
https://github.com/FellowTraveler/Moneychanger

I am, of course, available to answer questions, and there is also a mailing list: open-transactions-subscribe@rayservers.com

So that anyone who pleads ignorance is without excuse.

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


The basic principles of its technology?

1) Ricardian Contracts. The contracts are Ricardian-style contracts, and they are used to denote the servers as well as the asset types. Any new currency on OT is issued by the issuer uploading that currency to any OT server. (The currency will have the same ID across all servers.)
You can see a sample currency contract here:  https://github.com/FellowTraveler/Open-Transactions/wiki/Sample-Currency-Contract
The functionality of OT is similar to Ricardo, which is described here (with pictures!):  http://www.systemics.com/docs/sox/overview.html
Here is the Ian Grigg URL on Ricardian Contracts: http://iang.org/papers/ricardian_contract.html

2) Triple-Signed Receipts are employed, so that servers are unable to forge transactions or change balances. (The server cannot forge your signature on the receipt. The receipt is the account.) The core transaction engine is designed in this way, so that the same protection is afforded to all instruments (such as market receipts, cheque receipts, etc.)

3) Destruction of Account History. For its core account system and financial instruments, Open-Transactions uses balance agreement and transaction numbers on every receipt, in such a way that the parties to any transaction can prove their balances, and which instruments are valid, without having to store their entire transaction history, and instead by simply producing their last signed receipt.
I describe how it all works right here:  https://github.com/FellowTraveler/Open-Transactions/wiki/Triple-Signed-Receipts
A similar protocol (Truledger) is very well described here, with examples:  http://truledger.com/doc/plain-english.html

4) Untraceable digital cash. Open Transactions uses Chaumian Blinding to offer the untraceable cash.
You can read about the technology here:
http://www.cs.bham.ac.uk/~mdr/teaching/modules06/netsec/lectures/DigitalCash.html
Here is a sample piece of OT cash and an article: https://github.com/FellowTraveler/Open-Transactions/wiki/Sample-Cash
There are various digital cash libraries floating around out there. Currently I am using this one: http://anoncvs.aldigital.co.uk/lucre/

5) Many Financial Instruments. Cheques, Cash, Markets, Payment Plans (recurring), Withdrawals and Deposits, Account-to-account transfer, Receipts, Inboxes, Contracts, etc. More coming.
Article:  https://github.com/FellowTraveler/Open-Transactions/wiki/Instruments

6) Federated Servers. Instead of a centralized model, OT tries to federate its services wherever possible. For example:
--- The same currency could be issued at multiple servers.
--- The same currency would have the same ID across all servers.
--- The same Nym would have the same ID across all servers.
--- Server-to-server transfers are possible through the issuer, since the issuer already has a presence on every server where he's issued.
--- Users can trade in basket currencies, which distribute risk across multiple issuers.
--- (coming soon) OT Servers will implement voting pools for Bitcoin, meaning a hacker could not steal your Bitcoin from a server unless he'd also hacked 90 of the other servers in the pool, and gotten their private keys and their passphrases.
--- A clever wallet software could distribute the assets of a single "account" across multiple servers, and abstract that away in the user interface.
Article: https://github.com/FellowTraveler/Open-Transactions/wiki/CENTRALIZED
Diagram: http://billstclair.com/ot/ot-diagram.jpg

So if you were to ask me the principles behind Open Transactions, in a nutshell I'd say:
Ricardian Contracts
Signed Receipts
Unforgeable Balances
Destruction of Account History
Chaumian Blinding (Untraceable Cash)
Many Financial Instruments
Federated Servers

Feel free to ask if you have any other questions.

-FT

Hi all,

I need to add some Bitcoin functionality to OT (to enable low-trust servers, since the current crop of servers seems to get hacked every 2 months...)

I do NOT want the full Bitcoin functionality, I just need to be able to do a few basic things, and it would be nice to just link Bitcoin into OT as a library.

Requirements:

1) Should be able to create my own Bitcoin addresses (for receiving payments.)
2) Should be able to check the balance at a specific address.
3) Should be able to send a Bitcoin payment from one of my addresses (to a target address.)

CAN ONE OF YOU PLEASE PROVIDE ME SUCH A LIBRARY? Preferably I just link the library and make a few function calls -- and that's it!

Presumably the code would be a subset of the existing Bitcoin client.

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

One more thing:  I do NOT need this through the RPC JSON interface, which I already have working. Rather, I need this to be C code that I can link directly to my existing C code, without having to also separately run the Bitcoin client.

Please show me some sample code, or point me in the right direction.

As a reward for this, I will provide open-source low-trust servers, which you can use without having to worry about hackers and thieves (like happened recently at MtGox and MyBitcoin.)

-Fellow Traveler

Cash-streaming protocols, incorporating digital cash, will solve issues of resource allocation on anonymous networks and mesh networks. This will cause the Internet to grow rapidly as a decentralized and uncontrollable "organism."

There's always "Conservapedia". They are unlikely to censor the page on Austrian economics.

Open-Transactions is basically a server, a library, and an API. (Many different services could be built on top of it. That's why you may have trouble visualizing exactly what it does.)

For example...

An online web-wallet could be built with it.  (I'd say "like MyBitcoin" except it seems you all have recently had a "bad experience" with that service...)

An online market exchange could also be built with it. (I'd say "like MtGox", except it seems you all have recently had a "bad experience" there as well.)

Those aren't hard to visualize, are they?

Some of OT's improvements:
1) Users could utilize untraceable cash.
2) Users could use instruments such as cheques, cashier's cheques, payment plans, etc.
3) Servers cannot forge transactions, nor can they change balances without the user's signature.
4) Many different currencies might be trading on a single server, such as gold-based contracts, silver-based contracts, dollar-based contracts, etc. There could be dozens of different markets, for different combinations of asset types.
5) The same currency, with the same issuer, could be available on many different servers.
6) Basket currencies are possible.

The other big difference (coming soon) will be voting pools for bitcoin reserves stored by OT servers, to prevent unfortunate incidents where servers are hacked, or otherwise disappear with your funds. I haven't coded voting pools yet, but they will prevent incidents such as those that occurred at MtGox and MyBitcoin.

I hope this clarifies.

PS Here's an example of a user interface built using OT: https://bitcointalk.org/index.php?topic=31032.msg399675#msg399675

Hi guys!

I'm writing from the beautiful desert land of Sedona, AZ, where I'm on vacation for a few days.

I wanted to address this quote. FYI, Open-Transactions currently generates 1024-bit keys by default.  Ultimately I would prefer that it uses 4096-bit keys instead of 1024, but that is not a terribly difficult fix to make. As more software is released based on OT, and as entities move closer towards actual production use, the keysize will be increased. (In other words, I wouldn't look at this as a deal-breaker, but rather as one of a long series of security fixes that naturally occur in this sort of project as it nears production.)

Similarly, the (untraceable) digital cash currently uses Lucre, which uses Wagner's algorithm and incorporates the SHA-1 hash. SHA-1 has had weaknesses uncovered over the past few years, though I'm not sure of their implications towards Chaumian blinding. This is fine: the whole idea of OT is similar to PGP: that it's easy to swap in new algorithms as the old ones expire. So on OT, it's not difficult to make new subclasses of OTToken and OTMint that use new algorithms.

(FYI, I have already obtained the source code for 2 new cash algorithms--Chaum and Brands--so these will be available within OT at some point in the future. Again, this is the sort of easy change that will probably happen once OT starts nearing production use.)

-Fellow Traveler

Hi guys!

I'm writing from the beautiful desert land of Sedona, AZ, where I'm on vacation for a few days.

I wanted to address this quote. FYI, Open-Transactions currently generates 1024-bit keys by default.  Ultimately I would prefer that it uses 4096-bit keys instead of 1024, but that is not a terribly difficult fix to make. As more software is released based on OT, and as entities move closer towards actual production use, the keysize will be increased. (In other words, I wouldn't look at this as a deal-breaker, but rather as one of a long series of security fixes that naturally occur in this sort of project as it nears production.)

Similarly, the (untraceable) digital cash currently uses Lucre, which uses Wagner's algorithm and incorporates the SHA-1 hash. SHA-1 has had weaknesses uncovered over the past few years, though I'm not sure of their implications towards Chaumian blinding. This is fine: the whole idea of OT is similar to PGP: that it's easy to swap in new algorithms as the old ones expire. So on OT, it's not difficult to make new subclasses of OTToken and OTMint that use new algorithms.

(FYI, I have already obtained the source code for 2 new cash algorithms--Chaum and Brands--so these will be available within OT at some point in the future. Again, this is the sort of easy change that will probably happen once OT starts nearing production use.)

-Fellow Traveler

I think this would work, yes.

First, you'd actually issue two bitcoin-like currencies onto an OT server. For example, Bitcoin and Namecoin.

Second, since you don't want to have to trust an issuer, we'd use the "low trust / voting pool" solution I've proposed, which eliminates the need for an issuer, for any Bitcoin-like currencies. (There is no avoiding issuers for gold-based currencies, but for bitcoin-like currencies it is possible to eliminate issuers.)

Third, since OT has markets (like MtGox) the users are now able to make offers on those markets, trading Bitcoins for Namecoins.

Finally, the OT server(s) processes the trades according the rules defined in the various market offers. Whenever a successful trade occurs, receipts are dropped into the parties' inboxes.

(And yes, the trades are atomic, meaning BOTH parties get a receipt, or not at all.)


Not sure what you mean by this...

When you make an offer onto an OT market, you can attach specific terms to your offer. That is, minimum price ($50 per bushel minimum) or minimum amount traded (500 bushel minimum per trade). You can also create stop-orders (do not activate this offer until the price reaches $50 per bushel.) Basically the same sorts of things you would do on a real market: stop orders, limit orders, stop limits, fill-or-kill orders, day orders (date ranges), etc.


(FYI, OT does support basket currencies, so if you actually wanted to define a single currency as a basket of others, you can do that.)

As I said before, the magic of Open-Transactions is that you do not have to trust the transaction servers. IOW, you still do have to trust the issuer.
For example, if the issuer is holding 100 oz of your gold, he could still disappear with your gold. (This is why OT has traditionally focused on securing the transaction server, so that the server itself doesn't become ANOTHER party that you have to trust, since you normally have no choice about trusting the issuer.)

However for Bitcoin-like currencies (crypto-currencies) as I said before, this "issuer risk" can be eliminated on OT using low-trust servers with voting pools. (By eliminating the issuer entirely.) But obviously such solutions are not possible with gold, silver, or other physical commodities, and so the markets will have to decide on their own which gold issuers they will trust. (One thing OT will never be able to do is PHYSICALLY AUDIT your gold warehouse.)  Therefore I don't know how "anonymous issuers" will work, although I've heard that the eCache group is experimenting with a solution for that, based on bonding.


Keeping things simple, let's assume there is only one OT server, and that 2 oil issuers are using it. (They have both issued their own oil currencies onto the OT server.)

Even though we logically know that both contracts are valued in the real world in terms of "oil", the OT server has no way of knowing that. OT just sees two different contracts -- that's all.

An easy way to convert between the two oil-based currencies, in that example, would be to trade on OT markets.  You just trade one for the other, on the market, the same way that people trade dollars for BTC now on MtGox. The trades would be processed automatically by the OT server, based on the terms in the respective offers, with receipts being dropped into the inboxes of the respective parties once the trade is complete.

There are other solutions for this. For example, if each of the 2 issuers honestly believe that the other oil-based currency is comparable to their own, then there is no reason why the issuers themselves couldn't perform such exchanges on behalf of the users. The issuers could also leave standing orders on the oil markets, and thus use the markets themselves to perform this functionality.  That way no one has to worry about being paid the second half of any trade, since the OT markets handle all of this.

Since there are people working on various OT clients, I get images and screenshots in the email sometimes. Below is an example.

I never understood why people say that OT is "way too complicated for the average Joe" since those people have probably never actually SEEN an OT client. Plus, in my own personal opinion, the OT-API is retard-easy to use. In fact, I can't imagine a system doing all the things OT does and having an easier interface than it already does. A trained monkey could code an OT client!



Of course, every OT client will have a different interface, so above is only an example of what could be done.

There are also some screenshots of the test GUI: https://github.com/FellowTraveler/Moneychanger
(But keep in mind that a Test-GUI isn't meant to have the prettiest interface. Rather, it's meant for testing the protocol.)


In OT, the issuer is the one being trusted. (The magical part about OT is not having to trust the transaction server.)

In the case of Bitcoin (using Bitcoin as a "backing currency" on an OT server) then you could have a trusted issuer also, the same as with gold or anything else. While this is no different than what the Bitcoin world is doing now (MyBitcoin, MtGox, etc) it is certainly not good enough for me, which is why I have written on this forum on how to use voting pools to eliminate entirely any need for an "issuer" (for Bitcoin on OT.)


If you want to learn more about OT's concept of "low trust servers", check out the post Stephen already referenced:
http://forum.bitcoin.org/index.php?topic=20425.0

"Seek and ye shall find."

As well as this related post:
http://forum.bitcoin.org/index.php?topic=28565.msg363945#msg363945

FYI, OT is open source.


Given that the first clients haven't been released yet, other than the test client, I think marketing copy is a bit premature.  However, there is a pretty easy description at the top of the OT Wiki:

WHAT IS “Open Transactions” ?

• Open-Transactions allows users to issue and manipulate digital assets. Users may create many pseudonyms (public keys), each of which may own asset accounts of various types. Users can transfer digital assets securely between accounts (even a server cannot change balances or forge transactions.) Users can also operate “cash-only” (without accounts) for maximum anonymity.
• Open-Transactions supports a range of financial instruments, such as cheques, vouchers, and untraceable digital cash. These are all analogous to the same financial instruments that we all use at normal banks today. Everyone already has an intuitive understanding of these financial instruments, because we use them regularly in our normal daily lives.
• Open-Transactions also implements higher-level, contract-based transactions such as payment plans and markets with trades. The markets on Open-Transactions support market orders, limit orders, fill-or-kill orders, day orders, stop orders, and stop limits, just like trading on a real market. OT also supports basket currencies.
• All of this is accomplished in such a way that all parties are able to prove, at all times, which transactions have cleared and which instruments are authorized, without having to store their entire transaction history, but instead by merely keeping the last signed receipt.
  (Without the special mechanism that makes this possible, all parties would otherwise be forced to store all receipts forever--no matter which system you are actually using.)

OT is not a "killer app" but rather, a SOFTWARE LIBRARY. There are MANY possible different interfaces that could be built.

The basic use cases are:

-- Issue a new currency (by uploading the new currency contract to an OT server.)
-- Open accounts of any asset type.
-- Withdraw / Deposit in untraceable digital cash.
-- Use "cash only" (no accounts) for full anonymity.
-- Write cheques, cashier's cheques, and perform account transfers (all with signed and unforgeable receipts.)
-- Trade on markets (like MtGox.)

Who could use OT?
-- A market site (like MtGox) where users are able to trade currencies, including Bitcoin, on markets.
-- A "Wallet" website (like MyBitcoin or whatever).
-- A client application. (OT works on all platforms...Android, Windows, Linux, Mac, etc)
-- A gambling site.
-- Etc.

The above are just basic uses which I mention first, since you are all mostly building such things. However, much more useful applications of the library are possible, such as creating the next generation of file-sharing software, the next generation of anonymous networks, etc.

I think the most disruptive use of OT would be using it to solve issues of resource allocation that arise in anonymous networks, mesh networks, darknet hosting, etc.

OT is also useful in combination with Bitcoin. Why?

Bitcoin gives OT: a universal “glue” between servers, a network of existing exchangers, and a publicly-auditable, reserve currency that cannot be confiscated or shut down.

OT gives Bitcoin: Untraceable cash, instant finality of settlement, and convertibility to other currencies on OT Markets.

(Soon, using the low-trust technology, OT will also give Bitcoin the only servers where Bitcoins can safely be stored, without risk of the server, or a hacker, stealing them.)

Here are some binaries...

https://github.com/FellowTraveler/Open-Transactions/downloads

You will still have to download the code (to get the data_folders, etc), but at least you don't have to actually compile anything.

I posted the OT API for Java, for Windows 32bit, Mac x64, and Ubuntu x86. (i.e. you still need the Java files from the code as well, to use the OT Java DLL.)

===> You may also need to install some of the dependencies. Depending on your platform, I don't know if it's going to try and dynamically load up ZMQ or Protobuf, in which case it would fail without them. I haven't posted full install files -- just binaries so you don't have to build OT. Another example is, for Windows, you may need to install the VC++ 2008 Redistributables as well as the VC++ 2010 Redistributables (which would normally be in the install program, if we had one.)  There are notes in the INSTALL docs that come with OT.

FYI I just checked in more fixes based on your feedback, and will be posting some builds soon as well (I'll announce it.)

I just now built this latest version of OT on Mac Snow Leopard 64 bit, Ubuntu 32bit x86, and Windows Ultimate 32 bit x86. (For Java mode OT-API.)

I had to reinstall Windows anyway, so I went through the whole process tonight from a fresh install, and I updated the INSTALL-Windows notes, as well as the three vcproj files (OTLib, CPP_Windows_API and JNI_Windows_API).

But anyway, sorry about the hassle and I should have some binaries available soon, at least for the above platforms.

The current cash algorithm is Lucre, which uses Sha-1.  I will probably add Chaum this year, depending on demand.

The current keysize for Nyms is 1024 bits. I'll probably increase this to 4096 sometime this year, depending on demand.

I assume people will be testing for a while before going into production so... there is time to do such things.

(Usually my focus is directed first towards the needs of those who are actually developing using OT, since they are the ones asking me for things.)

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

By the way, just because I am being extra-cautious about testing, security, code scans, key sizes, etc, doesn't mean that the typical bitcoin website today is somehow a paragon of security. I'm just honest about it. The whole open source community should kicking the tires on this sort of project. After all, people will be using it to store and transport their money.

Actually, this is untrue:  The Moneychanger (OT GUI) developer works on Windows, and I even build it myself and send him a DLL whenever I update the library.

I only have 32-bit Windows at home though, so I can't vouch for 64-bit Windows at this time.  But I have no problem building it.

I will probably just post the DLL here pretty soon, so you can use it without having to build it.

But! I have to build it depending on the API you will use.  (Usually I build the Java API... if you want it for some other language, let me know and I'll see if I can get you a binary...)

I have always said, I will support people who are using OT. If you have trouble building it, that is no excuse.

Open-Transactions is my project.

I have my hands full with the library... (think of it like OpenSSL, except for financial cryptography.) So if you're waiting for me to write all the apps, too, you might be waiting a long time...

Anyone who needs help getting it built, or using the API, feel free to drop me a line and I'll get you up and running.

Would like a real command line utility, a firefox plugin, chrome plugin, android wallet, and some other pieces.

(Hey, you can code to my easy API, or you can duplicate my effort and re-write OT, but there's no avoiding the financial crypto that must be used to accomplish the things you want to accomplish.)

Open-Transactions (https://github.com/FellowTraveler/Open-Transactions/wiki) is perfect for the "Fast Verification Network" piece of your diagram above...

At the simplest level, you bail the BTC into the OT server, and then OT processes all the transactions for as long as you want (you can use accounts, transfers, untraceable cash, cheques, markets/trades, signed receipts, etc.)
Then the user just bails back out into BTC again, whenever he wants back off of the server.

Benefits?
1) Untraceable transactions
2) Easy convertibility to other currencies on the OT market.
3) Instant finality of settlement
4) The server cannot forge transactions, or change balances without the user's signature.
5) All parties need only to store the last signed receipt, and they can prove their current balance, as well as prove which instruments are valid and which transactions are open or closed.
6) No worries about running out of space on the block chain.


===> YOU MIGHT ASK: But what if I don't want to TRUST the OT server with my Bitcoins? What if it steals them, or disappears, or gets hacked?

===> Based on conversations with Bitcoin developers, I believe I have found the solution to this. I've got the protocol figured out, but I haven't coded everything yet...

===> I've hinted at this before, but I've got a bit more free time now, so here it is:


THE GIST:   LOW-TRUST SERVERS (For Bitcoin on OT. The protocol is different with non-crypto-currencies.)

1) Basically, instead of bailing the BTC into a single server, you bail it into a VOTING POOL of maybe 50 different servers (or however many.) These will operate like a secure escrow in the blockchain. Many of you already have discussed this concept.

2) In my own protocol, the wallet signs the bail-in request, including the amount, the relevant IDs, etc, then the server countersigns it and sends you the receipt. (All the server is doing here is verifying everything in your request, and then signing it, too.)

3) Then your client GUI sends that receipt to the voting pool AND sends the Bitcoins to the pool. (There is no single recipient on the blockchain, but a pool of recipients at once.)

4) This same process happens in reverse when bailing back out. But this time, after the pool members verify that both parties have signed the bail-out request, they then vote on the blockchain to transfer BTC out to the recipient on that request, with a 3/4ths vote (or whatever) which is what actually effects the BTC transfer back to you. Rules can also be enforced here, involving inbox notification, time delays, maximum daily transfers, or whatever we decide.

5) The "vote" between the pool members occurs on the blockchain itself, using the built-in Bitcoin script language. Normally all votes will always be 100% in the same direction, since they will always agree on the truth. So we set it to 3/4ths or 9/10ths, whatever, so that it really takes a supermajority to do any bailment out, yet still leaves enough wiggle-room for the pool to prevent the loss of any BTC, and return it to the rightful owner, even if a server disappears or fails an audit.

6) If a receipt is ever submitted to the pool that's NOT properly signed, then the pool members simply vote to reject the receipt. (And probably to distrust the bad actor who submitted it.)

7) In the event that an OT server disappears, your BTC is still safe in the pool, and it's still possible to send a signed recovery request to the pool members, get your 3/4ths vote, and have your BTC transferred back to you.


There's more to it than that, and it involves the OT audit protocol as well, which is slightly different for issuer-based digital assets than it is for BTC-based digital assets (on OT.)

...But you get the general idea.

I've already got all the code I need on the Bitcoin side, I think, and I've got the new protocol figured out on the OT side (not coded yet).

I think I can swing this with the existing Bitcoin codebase (no changes to Bitcoin itself), and with the existing mining groups, though I'll have to include some Bitcoin code into OT for everything to work. I hope to be able to demonstrate this protocol soon. (Frankly I'm shocked no one else has done this yet.)

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

FYI, the "Point of Sale" and "Cell Phone" devices in your diagram above (as I picture them) are simply OT-API clients -- using the OT financial instruments to send payments to each other. (Cheques, cash, transfers, receipts etc.)  Each GUI is different, which is why OT-client side is an API. That way you can focus on your point-of-sale system, and let the OT-API do all the heavy lifting.

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

Bitcoin adds value to OT as well, in these ways:
1) BTC is a distributed, decentralized, reserve commodity that cannot be confiscated, counterfeited, or shut down.
2) BTC has all (most?) of the unique monetary properties of gold, which properties historically always cause gold, by operation of the invisible hand of the free market, to be used as money, in all cases where force and fraud have not perverted it. (Bitcoin being transferrable p2p, recognizable, limited, homogenous, fungible, divisible, and an efficient store of value in space and time.)
3) Bitcoin has an existing network of exchangers in/out of the various fiat currencies, in the various jurisdictions.
4) Bitcoin can be a "UNIVERSAL MEDIUM" between OT servers... users will be able to store funds in gold, but then convert to BTC on OT markets, whenever they want to hop to another server. This makes Bitcoin very very very useful even for goldbug users.
5) Such transfers will also occur through DGC issuers, who are presumably already at both ends, and more importantly, through Ripple, which is being built into the OT test GUI, Moneychanger. (Thus, I also see this as a potential bridge between Bitcoin and Ripple.)
6) Bitcoin makes it possible to run transaction servers, and other darknet servers, anonymously yet at a profit. That is very useful to OT.

Here's the command line output from actually compiling AND running OT in PHP mode:

http://pastebin.com/cwuS97n6

Hello, I just noticed this thread...

1) There is no need to write an OT server, as the OT server is already written (it's in the transaction folder.)  Read the instructions that come with OT, they will show you how to RUN the server.

2) If you wish to play with OT, I recommend building it in Java mode (see the instructions) and then use the Moneychanger GUI.

3) If you want to write your own GUI, you can copy what Moneychanger does.  For exact instructions, see this link: https://github.com/FellowTraveler/Open-Transactions/wiki/Use-Cases
(Now you have instructions AND sample code.)

FYI, you don't have to learn the internal objects to use OT, just call the API.