fellowtraveler (OP)
|
|
June 21, 2011, 04:13:20 AM Last edit: June 22, 2011, 02:58:14 PM by fellowtraveler |
|
There's been a lot of talk lately regarding Open-Transactions as a "centralized system" (comparable to e-gold or MtGox.)
I wanted to clear up some of these misconceptions...
The vision is not of a central server you must trust. Rather, the vision is of federated servers you don’t have to trust.
My goal with Open-Transactions is for the servers to be able to run on anonymous networks. For this to work, that means the users must be able to trust the system, even if they do not trust the servers.
We must have LOW-TRUST SERVERS—and that is what I have been working towards. The combination of low-trust technology with untraceable cash is what will make it possible to run OT servers on anonymous networks, at a profit.
--------------------------------------------------------
Recent events have stimulated a lot of talk about security issues in Bitcoin, specifically due to the use of centralized servers by the Bitcoin community.
There are some big differences between Open-Transactions and the “typical centralized system”…
1) — The typical centralized system is fully-traceable. You are always under the watchful gaze of the “all-seeing eye”.
But on OPEN-TRANSACTIONS, blind signatures are employed, providing untraceable digital cash.
--------------------------------------------------------
2) — The typical centralized system stores a numerical entry as your “account balance.” The server could change your balance simply by changing that number, and you must trust the server not to change your balance, or steal your money. (Ironically, this is the case on all the Bitcoin-related exchange sites today.)
But an OPEN-TRANSACTIONS server cannot forge any transaction, nor can it change your balance without your signature. Even a malicious server cannot do these things!
How is this possible? Because your “account balance” on OT is whatever appears on your last receipt. And the OT server cannot sign any receipt unless you have first signed the initial request, since a full copy of that request must appear inside the receipt. Thus the server cannot falsify any receipt because the server cannot forge your signature on the request.
Therefore the OT server can never sign any balance, or transaction, that you have not signed first.
--------------------------------------------------------
3) — A typical centralized system has the ability to abscond with your Bitcoins or gold.
But an OPEN-TRANSACTIONS server cannot disappear with the reserves!
Why not? Because it doesn’t have any.
OT follows a philosophy of “separation of powers”. Meaning, the issuer and the transaction server are separate entities. If, for example, your currency is backed in gold, then it is the gold issuer you must trust, not the OT transaction server. Even when an OT transaction server disappears into the night, you still have your account (i.e. the last receipt) and you can still redeem it at your issuer, or have it re-issued onto a new transaction server.
The same will soon be true with Bitcoin: I have been cooperating with certain Bitcoin developers on a new mechanism to allow users to bail their Bitcoins in-and-out of OT servers, without having to trust the server itself. That is, even if the server tried to disappear with your Bitcoin, it would not be able to. The next generation of Bitcoin and OT will have this capability. (The new BTC protocol hasn’t been added to OT yet but is coming soon.) Woe to anyone building a Bitcoin site that doesn’t have this capability! (…Because soon your OT-enabled competitors will eat your lunch.)
More on separation of powers:
— A single currency (such as “Pecunix gold grams” or “Liberty Reserve dollars”) might be issued on a dozen different transaction servers in different jurisdictions, with the same currency contract being used for all of them. (One currency—many servers.)
— Transaction servers can prove which currencies have been issued there, by producing the issuer’s last receipt. (And the currency contract.)
— Issuers and transaction servers can both prove the total amount that has been issued, also by producing the last receipt.
— The same currency might be distributed across a dozen different issuers, using basket currencies. (Basket currencies allow users to distribute the risk of a single currency across multiple trusted issuers.)
— The contents of a single “asset account” might be distributed across a dozen different transaction servers. (If this abstraction is coded into your client GUI, then what appears as a single account is actually spread across X number of servers.)
--------------------------------------------------------
4) — Let’s concede that while OT can’t forge receipts against individual users, a malicious server could still use a dummy account to inflate the currency itself, without having to forge any of the individual users’ receipts, and without having to forge the issuer’s receipt.
This is true, but it would not escape the upcoming OT Audit Protocol!
Why not? Because counterfeit funds cannot be spent without flowing from an illicit account into the other accounts of the general population, where the total amount will show up on an audit and be compared against the amount on the issuer’s last receipt.
As long as receipts are stored between audits (which could be daily) then the users, as above, can simply dump the untrusted server and redeem their receipts at the issuer. (This can all be automated.) Transaction servers, of course, would have a huge incentive not to pull this, since they already can’t get away with it, and since they would instantly lose their daily revenues from transaction fees.
A similar solution is planned for Bitcoin-based accounts on OT, using the same new mechanism described in answer (3). It also doesn’t hurt that Bitcoins are publicly-auditable, but plans go beyond that.
(FYI, the OT Audit protocol is designed but not yet coded.)
--------------------------------------------------------
5) — A typical centralized system is very vulnerable to hackers, who make use of all manner of cross-site-scripting and SQL injection in order to gain access to your server account, and do transactions you never authorized.
But on OPEN-TRANSACTIONS, it is useless to hack the server, since even a malicious server cannot forge transactions on OT! Hacking a user would require gaining access to his private key--which is not stored on the server--as well as installing a keylogger on the user’s machine (in order to get his passphrase.) Furthermore, the hacker would have to do this for each individual user. (The ultimate solution goes even further: store your private key on a crypto-card. People will actually start doing this once enough of them have been hacked.)
By comparison, MtGox recently had hackers sell-off the users’ balances for pennies. This also had the effect of crashing the Bitcoin market and damaging the “bulletproof” reputation of Bitcoin.
There simply shouldn't be any passwords stored, anywhere! Neither should there be any transactions processed that haven't been signed by the user's private key.
--------------------------------------------------------
6) — A typical centralized system is vulnerable to hackers obtaining a copy of their database, and subsequently distributing the users’ email addresses, salted passwords, account balances, and usernames all over the Internet.
These same users are then subjected to an aftermath consisting of hacks on their Tradehill, Facebook, (etc.) accounts, as well as the imposition of frustrating account-validation and password-changing procedures at all of those sites.
But on OPEN-TRANSACTIONS, no passwords are stored on the server OR client side. Instead, public-key cryptography is used, and the server only responds to signed requests. Users will never have to go and change their Gmail password when using OT-based systems.
--------------------------------------------------------
7) — A typical centralized system must store all of its receipts, forever. This is because it cannot prove which instruments are authorized, or which transactions have cleared, without storing them all (in an ever-growing database.) That’s the only way it can prove its case in the event of any dispute. (If parties cannot “prove their case” in a dispute, then the system breaks down.)
But OPEN-TRANSACTIONS uses Triple-Signed-Receipts: Parties can prove which transactions have cleared, and which instruments are authorized, simply by producing their last signed receipt.
--------------------------------------------------------
8 ) — A typical centralized server (such as e-gold) can be pressured to produce transaction data, and made legally responsible to report it. Such data is also vulnerable to hackers (such as happened to MtGox.)
But on OPEN-TRANSACTIONS, users and transaction servers both have the choice to operate in “cash-only” mode, which is completely anonymous. The server cannot be pressured or hacked to reveal your account, if you don’t have one!
The issuer is similarly safe, due to OT’s philosophy of “separation of powers.” Since he has outsourced the transaction processing to the transaction server, the issuer cannot be forced to produce any transaction data—he doesn’t have any!
--------------------------------------------------------
9) — A typical centralized server requires a bailment process to get new funds onto the server, and back off again.
Open-Transactions servers don't require any bailment process, since they don't store any reserves. Instead, the issuer chooses when to issue new units of any currency, and any bailment happens through the issuer directly. (Just like Loom.)
A similar yet more p2p solution is coming soon for Bitcoin-backed currencies--this is the same new mechanism mentioned in (3).
Additional options are coming soon:
Via the Ripple protocol, a user will be able to transfer off of the OT server simply by sending funds to another user on OT (who makes a similar reciprocal transfer on an entirely different system (via Ripple.)
In effect, this allows users to bail out of specific servers without having to “bail out” at all — instead merely sending an internal transfer to another user, who then pays them in a separate account via Ripple.
Ripple client capabilities are being built into Moneychanger (OT Java client.) Since Moneychanger users will likely list different currency types in their wallets, it only makes sense to connect them all via Ripple. Especially since OT clients will be P2P anyway (they need to compare notes on public mint files for various OT servers.)
This is where I see the true value of Ripple: Eliminating any need for server-to-server transfer, by allowing currency flows directly through the users.
Open-Transactions also allows for users to transfer from one server to another through the issuer, since he already exists at both ends. (Therefore the user doesn’t have to “bail out” in-between.)
Open-Transactions will also make use of Bitcoin as a “glue”, or “universal medium”, between OT servers. OT will always use a crypto-currency in this regard (whether Bitcoin or whatever else) since it is a unique solution to this problem.
--------------------------------------------------------
10) — A typical centralized server only supports two financial instruments: account transfer, and sometimes market trades.
But OPEN-TRANSACTIONS currently supports many financial instruments, including cheques, invoices, vouchers, account transfer, receipts, market trades, payment plans, and untraceable digital cash.
Many more instruments are coming soon to OT, including those with scriptable custom behaviors.
--------------------------------------------------------
11) — A typical centralized system does not have contracts.
OPEN-TRANSACTIONS allows users to create Ricardian-style contracts. These can be used to issue currencies, or to make agreements between other users—and these contracts can be enforced by the server.
OT also uses server contracts, meaning that each OT transaction server is identified by a contract, which contains its connection details for various networks, as well as its public key.
In OT, contracts have become the building block of the entire library. These contracts are self-verifying, and if applied to the domain name problem, they have the potential to entirely decentralize the DNS system.
Coming soon: “Smart contracts” (scriptable clauses.) The Bitcoin economy, as well as the DGCs (digital gold currencies) will need more financial instruments in order to grow. Instruments such as Escrow, Real Bills, Stocks, Bonds, etc. There will always be the need for a system that enables that next financial instrument. I propose to make those available through scripts, so that new custom code is not necessary inside OT itself for most new contract types.
----------------------------------------------------------------------
WHAT IS “Open Transactions” ?
Open-Transactions is a software library, as well as a server application and a client API (built on top of that library.) New: A Java client app has also been added.
WHAT DOES IT DO?
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.
The real beauty of Open-Transactions is the as-yet-unwritten future of new ideas that you can build with it, and the future liberty and security of your children that you can help to protect by doing so—in a very real and tangible way.
|
|
|
|
|
|
|
|
Bitcoin addresses contain a checksum, so it is very unlikely that mistyping an address will cause you to lose money.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
Isosceles
Member
Offline
Activity: 71
Merit: 10
|
|
June 21, 2011, 04:23:01 AM |
|
If you want to be taken seriously, write it up as a technical paper & post it.
|
|
|
|
fellowtraveler (OP)
|
|
June 21, 2011, 04:55:41 AM |
|
If you want to be taken seriously, write it up as a technical paper & post it.
The Wiki is available here: https://github.com/FellowTraveler/Open-Transactions/wikiThe FAQ is available here: https://github.com/FellowTraveler/Open-Transactions/wiki/FAQThe core account system, including destruction of account history, is comparable to this system: http://truledger.com/doc/plain-english.htmlAll of the concepts are explained there. The differences between that system and my own are described here: https://github.com/FellowTraveler/Open-Transactions/wiki/Triple-Signed-ReceiptsI also recommend this article, since the above relies on these concepts: http://iang.org/papers/triple_entry.htmlThe Chaumian blinding (untraceable cash) is implemented using this system: http://anoncvs.aldigital.co.uk/lucre/There is a paper there for you to read. I used the C++ version of Lucre, FYI. Regarding the untraceable cash, I also recommend these articles from my Wiki: https://github.com/FellowTraveler/Open-Transactions/wiki/Sample-Cashhttps://github.com/FellowTraveler/Open-Transactions/wiki/Sample-MintThe Ricardian contracts are described in my Wiki, with a sample provided: https://github.com/FellowTraveler/Open-Transactions/wiki/Sample-Currency-ContractHere is a chart of the instruments on OT: https://github.com/FellowTraveler/Open-Transactions/wiki/InstrumentsThey are comparable to the Ricardo implementation of instruments described here: http://www.systemics.com/docs/sox/overview.htmlThe source code is available here for review: https://github.com/FellowTraveler/Open-TransactionsThe API is here: https://github.com/FellowTraveler/Open-Transactions/wiki/APIInstructions for using the API are here: https://github.com/FellowTraveler/Open-Transactions/wiki/Use-CasesA Java implementation of an OT Wallet, coded using the OT API, is here: https://github.com/FellowTraveler/MoneychangerAnyone who has any trouble figuring out the API can use Moneychanger as a reference. (I am also, of course, available to answer questions.) Some technical details about the Messaging is available on the wiki here: https://github.com/FellowTraveler/Open-Transactions/wiki/MessagingTransaction-specific messages are described here: https://github.com/FellowTraveler/Open-Transactions/wiki/TransactionsNew docs are always being written, usually to answer questions that come up. Sorry if it's not enough for you but more is coming I promise If it helps, some people have understood the system better after listening to the Radio interview... part 1: http://agoristradio.com/?p=234part 2: http://agoristradio.com/?p=246Here are some diagrams for you: Overview: http://billstclair.com/ot/ot-diagram.jpgFull-Anon (cash-only): http://billstclair.com/ot/OT-Anon-CashOnly.jpgPseudo-Anon (using accounts): http://billstclair.com/ot/OT-Pseudonym-Instruments.jpgLet me know if any other questions, I'm always glad to help. -FT
|
|
|
|
marcus_of_augustus
Legendary
Offline
Activity: 3920
Merit: 2348
Eadem mutata resurgo
|
|
June 21, 2011, 05:37:51 AM |
|
Want to follow this one ...
|
|
|
|
Meatpile
|
|
June 21, 2011, 05:48:13 AM |
|
I have been reading up on this system for a while and it sounds like an amazing sister application for bitcoin.
However it is definitely not for amateurs yet, highly technical and compiling from source with dozens of dependencies makes me want to pull my hair out!
|
|
|
|
da2ce7
Legendary
Offline
Activity: 1222
Merit: 1016
Live and Let Live
|
|
June 21, 2011, 07:11:25 AM |
|
Open Transactions is the single most important thing that the bitcoin community needs to adopt to be successful. Where bitcoin deals with global 'value' and is good as a standard... The area where we fall-down is in personal trust based transactions.
I have been a long supporter of OT (Open Transactions), and plan to release software based upon it.
OT isn't a easy concept to get your around your head... however once you 'work it out' it changes your prospective of how finance should be done.
|
One off NP-Hard.
|
|
|
marcus_of_augustus
Legendary
Offline
Activity: 3920
Merit: 2348
Eadem mutata resurgo
|
|
June 21, 2011, 08:00:37 AM |
|
I have been a long supporter of OT (Open Transactions), and plan to release software based upon it.
OT isn't a easy concept to get your around your head... however once you 'work it out' it changes your prospective of how finance should be done. Yes, a better than facile understanding of this technology is needed. Please tell us you have developed an exchange based on OT? (it is sorely needed by bitcoin)
|
|
|
|
passerby
Member
Offline
Activity: 112
Merit: 10
|
|
June 21, 2011, 08:07:12 AM |
|
Oh, hi, FT I am very interested in the bailing mechanism, it's very relevant to my project. Especially since we've already secured some funds and domain names for our OT+BC project, and are waiting for coders we've had provisional agreement with to finalize the project they're currently involved in (also BC btw ) and finally get to work @ OT+BTC. P.S.: If you think "is it that guy", yes, it's me. Wanted to email you again regarding that whole expiration thing, but my schedule was, and still is, a mite hectic
|
|
|
|
Batouzo
Member
Offline
Activity: 70
Merit: 10
|
|
June 21, 2011, 09:41:46 AM |
|
OT isn't a easy concept to get your around your head... however once you 'work it out' it changes your prospective of how finance should be done.
This is awesome - it should be possible to make exchange of BTC, and much more options too (say. emit own put-options, or own "bonds" that would work like a loan, etc). And, the messages should be able to one day work as totally pure, separate, contracts. So that everyone can verify that user Foo indeed placed some Ask on BTC (or bonds or other money instrument), and everyone could verify if site, like exchange site, delivered what was promised. All PGP signed or alike. Then we can all be investigator if any exchange or site or seller/buyer would not deliver, while still being decentralized And we can audit without this "auditor" that leaked entire user DB to internetz while auditing
|
|
|
|
fellowtraveler (OP)
|
|
June 21, 2011, 02:45:07 PM |
|
Meatpile: Thank you for your PM. I agree on the usefulness of providing builds of OT :-) I can post a DLL up there pretty soon, for Windows users of Moneychanger. I think I can build 64-bit Mac and 32-bit linux as well. By default I'd post up the Java API build, since that's what Moneychanger uses. (Moneychanger Jar file is already posted, so at least there's one build available.)
passerby: coming soon.
Batouzo: FYI, OT messages *are* signed contracts (everything in OT is a contract) so yes, they can be loaded up, signature verified, etc. And yes, everyone can verify the Issuer's last receipt (including the total amount issued) when the transaction server produces it, and the issuer can't lie about it, without being caught. (And vice-versa.) Because there's his signature on the receipt... The auditing process will involve balances and account IDs (possibly scrambled from each other as well.) Audit data will be stored in a DHT and encrypted to Issuer's public key, so only the Issuer can see it (so he can verify no counterfeiting has occurred.) I don't expect the Issuer to dump the data to the Internet like the mtgox database did, but if that did happen, remember there aren't any passwords, usernames, or email addresses stored. Just balances. Specific to your question about markets: Yes, if someone places a market order, and saves his receipt, he can produce it later to prove what happened. The OT server also stores whatever receipts it needs to, to prove its story in the event of a dispute. (Usually this means only the last signed receipt, but in practice all parties will probably store all receipts between audits.
|
|
|
|
bracek
|
|
June 21, 2011, 10:10:03 PM |
|
we could start pledging some btc, to a bounty fund for this, to speed it up maybe even we could make it an investment that would be payed off to all "donators", out of fees collected later, like we "buy shares" of this thing now, pay them with btc, development team gets the btc, and we collect our dividends later, if/when this starts to work
|
|
|
|
Isosceles
Member
Offline
Activity: 71
Merit: 10
|
|
June 22, 2011, 01:29:18 AM |
|
There's obviously a lot of detail here. I've read some of it but I'm still trying to understand it. The FAQ is missing some obvious high-level questions for newcomers : - How do I transfer my real USD for digital USD? Send it to an issuer? How do I trust the issuer? - If a issuer's assets are stolen, or the issuer is bad actor, the reserves will less than stated, or zero. Presumably everyone who owns digital versions of those assets will see their value wiped out. In effect, owners of a digital USD currency take counterparty risk to the USD issuer that they use? - If a Bad Event happens (eg. MtGoxIssuer is compromised), is there a way to alter the transaction chain similar to "a 51% of Bitcoin Miners" vote?
Assuming I understand this so far : - Would you intend to counteract the requirement to an issuer by diversification? ie. Have 1000 digital USD issuers, and trade a basket of those issued currencies? - If I set myself up as a USD issuer, my reliability would be low. It seem logical that my Isosceles USD would be worth less than 1 USD issued by MegaBank Issuer, right? So I wouldn't bother, I'd just send my funds to MegaBank. This reduces the pool for diversification. What incentive is there to be a large number of digital USD issuers? - CDOs are extremely complicated things, not suitable for retail investors. Why do you have them on your To Do list?
|
|
|
|
aeroSpike
Newbie
Offline
Activity: 41
Merit: 0
|
|
June 22, 2011, 10:21:42 AM |
|
Very interesting topic. I think the idea has a lot of merit. But I think besides a reputation based system I think the system should also allow, **voluntarily* to attach a real world identity to a public key. Suppose I wanted to offer a Euro/Bitcoin exchange. I am new so my reputation is neutral which means that my trustworthiness is zero. But if I attach a real identity to my bids people could verify my identity through conventional channels. Heck, they could even sue me if I didn't deliver. Real identities would also allow you to look for deals inside your own country/jurisdiction which makes deals easier and.
|
|
|
|
fellowtraveler (OP)
|
|
June 22, 2011, 04:03:12 PM |
|
we could start pledging some btc, to a bounty fund for this, to speed it up maybe even we could make it an investment that would be payed off to all "donators", out of fees collected later, like we "buy shares" of this thing now, pay them with btc, development team gets the btc, and we collect our dividends later, if/when this starts to work If you guys want to raise money to do various OT projects, that's cool, but if you ask me what I want: I want volunteers. Think about it: Which allows me to move more mountains? $30K in donations over the next year? Or 3 volunteer coders? Android client, anyone? Mac OS X client? iPhone client also. A real unix command line is important and needed. (This makes OT scriptable.) Firefox plugin, a Chrome plugin... (These allow us to use a new "OTTP" URI format for links in HTML files. Read more about it here: https://github.com/FellowTraveler/Open-Transactions/wiki/OTTP-URI-Format ) I also need some C code that will import a PGP private key into OpenSSL format. (I've already got public keys.) I also need a crypto expert to go over the crypto-specific parts of OT and audit them. Also would like the same expert to update OT to support larger keys. (I'll get to that eventually if no one else does.) In the unlikely event that a C expert actually pops up, it'd be cool if you can update OTMint and OTToken classes to use credlib (Chaum and Brands.) I will also do this eventually if no one else does. I'd also love to see Java and D-language ports of OT. I'd also love someone to write a subclass of OTStorage that goes to some kind of Tahoe or other cool DB (you only have do a few overrides.) Also: the Market screen is incomplete on Moneychanger. I'd love for a Java expert to get in there and finish hooking it up to the OT Market API. Also: The Basket screen as well. Also: Currently Moneychanger uses the Bitcoin JSON-RPC interface. Obviously, this needs to be replaced immediately with internal code that encrypts the Wallet.dat before loading/saving.
|
|
|
|
fellowtraveler (OP)
|
|
June 22, 2011, 04:59:23 PM Last edit: June 22, 2011, 05:45:51 PM by fellowtraveler |
|
There's obviously a lot of detail here. I've read some of it but I'm still trying to understand it. The FAQ is missing some obvious high-level questions for newcomers : - How do I transfer my real USD for digital USD? Send it to an issuer? How do I trust the issuer?
Yes. For any contract-based currency, including commodity-based, you must trust the issuer that he is actually upholding his end of the contract, i.e. holding the appropriate assets in a legally-acceptable fashion. Therefore you must trust his governance: his auditing procedures, his standing in his local jurisdiction, his use of separation of powers, his bonding (eCache uses bonds)... Those are all governance issues (meaning there is no technical solution, since these are issues of governance.) This is one area where I think Bitcoin is actually superior to physical commodities (such as gold), since technical solutions are possible with Bitcoin. - If an issuer's assets are stolen, or the issuer is bad actor, the reserves will less than stated, or zero. Presumably everyone who owns digital versions of those assets will see their value wiped out. In effect, owners of a digital USD currency take counterparty risk to the USD issuer that they use?
This is absolutely true. If the issuer himself is a bad actor, then his digital currencies are suspect. My goal with OT is to eliminate this risk at a technical level (the transaction server), but obviously a piece of software can never fix governance issues such as an issuer's need to audit and insure his warehouse full of gold.The issuer is in the business of trust; my hope with OT is that jurisdictional arbitrage will enable a global trust market, with all of the liabilities and risks of the transaction server itself removed from the equation (by OT). - If a Bad Event happens (eg. MtGoxIssuer is compromised), is there a way to alter the transaction chain similar to "a 51% of Bitcoin Miners" vote?
1) The OT transaction server itself cannot forge transactions or change balances. So the "bad event" that happened, will not happen on OT. (OT cannot forge receipts.) 2) The OT transaction server itself technically could store all of its receipts, and thus roll back the system to any point based on the information in those receipts. (In practice the OT transaction server doesn't need to store any receipts except for the last one for each user.) 3) While the OT transaction server cannot forge receipts, it COULD use an illicit account to counterfeit (inflate) funds, and could do so without having to forge any issuer receipts. This is prevented using an audit protocol between the issuer and the transaction server. (Which could be performed daily.) OT normally allows parties to destroy all receipts except for the last one. However with an audit protocol in place, I recommend that parties store all receipts between audits.4) This way, if a transaction server ever counterfeits, the issuer will catch it out, and yes, would have the ability to roll everyone back to the last audit, and re-issue their funds on a new transaction server.This is described above in my long post. The transaction server has little incentive to pull this, since he wouldn't get away with it, he doesn't hold any of the gold, and he would immediately lose his daily revenues from transaction fees. An even better solution is possible using Bitcoin (coming soon) which I have hinted at recently. Using Bitcoin, unlike any other commodity, it's possible to accomplish these things without even having to trust an issuer. (No one is doing it yet, but they will soon.) Assuming I understand this so far : - Would you intend to counteract the requirement to an issuer by diversification? ie. Have 1000 digital USD issuers, and trade a basket of those issued currencies?
This is one intention of mine, yes. It is possible in OT, using baskets, to distribute the risk of a single currency across multiple issuers. If one issuer ever disappears, the loss could then be made up through insurance, paid for through transaction fees from using the basket. I'm sure there are other creative solutions but that's one I had in mind. - If I set myself up as a USD issuer, my reliability would be low. It seem logical that my Isosceles USD would be worth less than 1 USD issued by MegaBank Issuer, right? So I wouldn't bother, I'd just send my funds to MegaBank. This reduces the pool for diversification. What incentive is there to be a large number of digital USD issuers?
I agree that funds are likely to flow more to trusted parties than to untrusted parties. Due to this, it creates a profit incentive to innovate in trust solutions, which I believe entities will do (and some will succeed, some will fail.) That is why there are markets. There are also other incentives for users to choose one issuer over another, such as bailment policies, jurisdiction, etc. - CDOs are extremely complicated things, not suitable for retail investors. Why do you have them on your To Do list?
Because OT is, first and foremost, a financial crypto library. The OT server and OT API are just examples of what can be built using that library. It makes sense to me that such a library should be technically capable of implementing various instruments, even if they are "complicated" or "not suitable for retail investors". The thing with a library is, you don't know all the ways that people might end up using it. OT's infrastructure is such that, while CDOs may seem complicated, they are rather easy to implement using the same mechanisms used in basket currencies. I don't know when I will actually get around to CDOs, and perhaps they will be implementable using script clauses, I don't know. I tend to prioritize so I doubt you will see CDOS before stocks, for example. -FT
|
|
|
|
fellowtraveler (OP)
|
|
June 22, 2011, 05:20:47 PM |
|
Very interesting topic. I think the idea has a lot of merit. But I think besides a reputation based system I think the system should also allow, **voluntarily* to attach a real world identity to a public key. Suppose I wanted to offer a Euro/Bitcoin exchange. I am new so my reputation is neutral which means that my trustworthiness is zero. But if I attach a real identity to my bids people could verify my identity through conventional channels. Heck, they could even sue me if I didn't deliver. Real identities would also allow you to look for deals inside your own country/jurisdiction which makes deals easier and.
On OT, your Pseudonym is just your public key, and its fingerprint (ID.) If I allowed people to put a "web site" metatag with their key, THEY COULD LIE IN THAT TAG (they could put " www.coke.com" even though they are not related to Coke in any way.) But in the current system, there is nothing stopping Coke from putting their public key, and its fingerprint, on their website so that users know this really is "Coke's key." Therefore the current system probably accomplishes what you meant, in a safer way than actually adding identifying info to the public key.
|
|
|
|
|
|