Open-Transactions: Video Walkthru!

[fellowtraveler]

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

[1714835075]

1714835075

[1714835075]

1714835075

[1714835075]

1714835075

[1714835075]

1714835075

[1714835075]

1714835075

[1714835075]

1714835075

[Trader Steve]

I like the idea that this can make bitcoin truly anonymous (and that's just one small piece of OT!). To better understand what FellowTraveler is talking about I recommend listening to this radio interview first:

http://agoristradio.com/?p=246

++1

[Steve]

I like the idea that this can make bitcoin truly anonymous (and that's just one small piece of OT!). To better understand what FellowTraveler is talking about I recommend listening to this radio interview first:

http://agoristradio.com/?p=246

++1

Agreed...very good interview.  Bitcoin+OT+Ripple is very powerful stuff.  Is there a white paper that describes the core protocols of OT in a very simple and straightforward manner?  I imagine at it's core, OT is very simple...but videos of GUIs and interviews obscure that simplicity.  Satoshi's white paper gave me that clarity about bitcoin...is there something similar for OT?

[Meatpile]

So under the MAIN window and "Account list" i assume those are all just your own accounts on your computer?

If you issued something like stock. Is there any way to know exactly how many stock someone else has? I know the issuer can see the total stock out there, but how do you see exactly how much someone else has?

[fellowtraveler]

Is there a white paper that describes the core protocols of OT in a very simple and straightforward manner?  I imagine at it's core, OT is very simple...but videos of GUIs and interviews obscure that simplicity.  Satoshi's white paper gave me that clarity about bitcoin...is there something similar for OT?

Unfortunately I haven't written up an official white paper yet, but there are some resources to understand the concepts...

Open-Transactions is comparable to Ricardo, which is described at the high level, plus diagrams here:
http://www.systemics.com/docs/sox/overview.html

The core account system is designed around "destruction of account history", an idea that was pioneered by Truledger.
"Truledger in Plain English" is the best introduction: http://truledger.com/doc/plain-english.html

The untraceable cash instrument is implemented with the Lucre library.
White paper available here: http://anoncvs.aldigital.co.uk/lucre/

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

I have written quite a few wiki articles, you can see the list here:
https://github.com/FellowTraveler/Open-Transactions/wiki/_pages

Some of the messaging / transaction protocol is explained here:
https://github.com/FellowTraveler/Open-Transactions/wiki/Messaging

So under the MAIN window and "Account list" i assume those are all just your own accounts on your computer?

The accounts are displayed for whatever server they are on.

In the case of the video walkthru, I'm using a test server that is running on my own machine. (Via the "localhost" server contract, a test contract that comes with OT.) So yes, those accounts are "on my computer".

If you issued something like stock. Is there any way to know exactly how many stock someone else has?

Currently there is not a message that allows you to look up someone else's account and view the balance. (Of course, people are free to show you their last receipt.) It wouldn't be hard to add an API call that verifies such receipts, or that downloads the current balance for certain types of accounts.

I like the idea that this can make bitcoin truly anonymous (and that's just one small piece of OT!)

I think the main benefits that OT gives to Bitcoin are:
1) Instant finality of settlement (instead of waiting for the 6 confirmations...)
2) Untraceable and anonymous cash.
3) Convertibility to other asset types on OT markets.
4) (Soon) Safe storage of Bitcoins on OT servers, via voting pools on the Bitcoin blockchain. (To prevent incidents like happened at MtGox and MyBitcoin...)

The benefits that Bitcoin gives OT:
1) A universal medium between OT servers, with no 3rd parties necessary.
2) A publicly-auditable reserve that cannot be confiscated or shut down.
3) A network of existing exchangers and businesses who crave more functionality and safety for their Bitcoin.


-Fellow Traveler

[2_Thumbs_Up]

I'm trying to get my head around this so I have some questions to you. I'm really intrigued by the whole thing though.

As I've understood it, the transaction servers could make money from transaction fees. Is there a similar mechanism for the issuing pools?

Also, how would the issuing pools work if they started to get shut down by governments? Say you need 9 out of 10 pools to vote yes in order to accept a transaction and 2 out of 10 servers get shutdown. Would the bitcoins be lost in the ether forever?

[LightRider]

I don't know what it is you made, but I am both amazed and confused...

Amused.

[fellowtraveler]

I'm trying to get my head around this so I have some questions to you. I'm really intrigued by the whole thing though.

As I've understood it, the transaction servers could make money from transaction fees. Is there a similar mechanism for the issuing pools?

On OT, the issuers must be trusted with the reserve assets. For example, if the issuer was Pecunix, even perfect fidelity on the part of OT software doesn't change the fact that they are holding your physical gold (or paying someone to do so), and therefore you must trust them--you must choose your issuers wisely, and be selective based on audit procedures, separation of powers, local jurisdiction, bonding, reputation, etc etc.

When using OT to issue Bitcoin, you would similarly have to trust the issuer not to take off with your Bitcoins. MY PROPOSED SOLUTION FOR THIS is to exchange-in by transferring the Bitcoins to a list of Bitcoin addresses (instead of to a single one), each controlled by a different trustee. (Most likely each trustee is just another OT server. Their motive for participating is to become more competitive in their own businesses through engendering trust by using a respected pool.) This way, you don't have to worry about a single server stealing your Bitcoins, even if it gets hacked. (Because it can't out-exchange any coins without the approval of the other trustees in the pool.)

There's more description of how it would work here: https://bitcointalk.org/index.php?topic=28565.msg363945#msg363945

Also, how would the issuing pools work if they started to get shut down by governments? Say you need 9 out of 10 pools to vote yes in order to accept a transaction and 2 out of 10 servers get shutdown. Would the bitcoins be lost in the ether forever?

On the Open-Transactions side of this proposed protocol, signed receipts are employed. (The user's out-exchange is signed, then the OT server countersigns it, then it is sent to the pool for a vote.)

The RULES of that vote (whether it is a majority vote, or 2/3rds, or 3/4s, or 9/10s) will be up to the pool members to decide. They might also have rules about each pool member identifying itself and its country of origin to the other pool members, or whatever.  Most of the time, the pool members will vote 100% in the same direction for every out-exchange. It's only in the rare case that a server disappears, that you need some wiggle-room in the vote (9 out of 10, instead of 10 out of 10.)  So you have to leave yourself enough room for that, but otherwise make the vote as strict as possible.

The rules themselves will be coded in the BITCOIN BLOCKCHAIN, using the existing Bitcoin script language. So really you can set it up however you want to, within the confines of that environment. (To answer your question: If you don't want the Bitcoins to be "lost in the ether" then maybe you would set a timeout process on the bitcoin escrow, or maybe you would change it to 7 out of 10 instead of 9 out of 10. Etc. You do all of that in the Bitcoin blockchain.)

-FT

[2_Thumbs_Up]

When using OT to issue Bitcoin, you would similarly have to trust the issuer not to take off with your Bitcoins. MY PROPOSED SOLUTION FOR THIS is to exchange-in by transferring the Bitcoins to a list of Bitcoin addresses (instead of to a single one), each controlled by a different trustee. (Most likely each trustee is just another OT server. Their motive for participating is to become more competitive in their own businesses through engendering trust by using a respected pool.) This way, you don't have to worry about a single server stealing your Bitcoins, even if it gets hacked. (Because it can't out-exchange any coins without the approval of the other trustees in the pool.)

There's more description of how it would work here: https://bitcointalk.org/index.php?topic=28565.msg363945#msg363945

Thanks for your response and the link was quite helpful as well. I have more questions though. I've been doing some reading on bitcoin scripting and contracts, and I find this part especially interesting: https://en.bitcoin.it/wiki/Contracts#Example_4:_Using_external_state

Is it possible to make a bitcoin transaction such that the voting pool can't spend the coin without an unused OT-reciept even if they decided to collude?

Also, transaction-servers can't fake a transaction, but they can fake reciepts, right? The goal is to disincentivice them to do this, through audits etc. But what if they decide to anyway, is there any mechanism for the issuer to recognize the fake receipts from the real?

[fellowtraveler]

Is it possible to make a bitcoin transaction such that the voting pool can't spend the coin without an unused OT-reciept even if they decided to collude?

You will have to talk to your experts on the Bitcoin side of things. My initial impression would be, no. If you give the power to a voting pool, and the POOL ITSELF decides to collude, then I believe the security would break down at that point. Since the pool should always vote 100% in the same direction every time, you can require 90% or 95% votes, which IMO are safer than 51% (or worse: trusting the security of a single server, such as mtgox or mybitcoin, as everyone currently seems to do.)

Also, transaction-servers can't fake a transaction, but they can fake receipts, right? The goal is to dis-incentivize them to do this, through audits etc.

-- The transaction servers cannot forge a user's signature, therefore a transaction server can never fake YOUR receipts.

-- But the transaction server could potentially create a DUMMY account (where it controls the keys on BOTH sides), and then have the dummy account submit a false balance statement (showing a high balance), and then the server signs it. (While this doesn't allow the server to fake any of YOUR receipts, which is impossible, it DOES allow the server to inflate the currency as a whole.)

-- However, these illicit, inflationary funds cannot actually be spent without flowing into real accounts, where they will show up on an audit.

But what if they decide to anyway, is there any mechanism for the issuer to recognize the fake receipts from the real?

Yes, the mechanism is to have the registrations and receipts deposited into a DHT for the users to retrieve, and give the issuer a key to read them. (In the case of Bitcoin, a voting pool acts in the role of the issuer.) If the issuer performs real-time auditing, then he will catch problems the instant they occur. But if instead he audits once per day, then he will probably place a 36+ hour delay on out-exchanges.

-FT