Topic: Cryptographically private loan risk management (Read 1195 times)

Why should I give a loan in the first place? The investor wants to make a good risk-adjusted rate of return (higher than safe interest).

The value of the loan/bond consists of two components: the repayment component and the default component. The bond is worth the sum of both. Loosely speaking if the probability of repayment is P the value is : P * (100 + interest) + (1 - P) * recovery value.

Even if I know the outstanding debts, the expected value in the form of probability of repayment is very small. The value of a bond depends on not only the ability of the borrower to repay, but rather that I can force him to repay. The problem is really that in the default case there is no value left. Recovery value generally is zero. The borrower is not forced to repay. How should I seize his income? There won't be somebody like in the Sopranos coming around with baseball bat (I hope not). However governments are really just a more complex version of a mafia gang. Its more subtle and a bit nicer environment to live in. But in the end if the borrower declares bankruptcy the police will come around and seize his assets. And if the borrowers act in a fraudulent way he will go to jail. In the bitcoin world the lender has no leverage whatsoever.

The DHT used on that page is just a global scribble board used to shift data out of the block chain, it's not very important or interesting. You could stuff all the data into the block chain using OP_RETURN outputs - it'd be simpler but less efficient/more costly for archival nodes.

Re: loan defaults. You can see bond payments being made on the block chain. So you can trivially calculate if a bond is in default by just seeing how often they appear in the chain and if a payment doesn't appear when expected, then it's in default.


So, again, what stops me just asserting to someone that I have no debts? If the bitcoin-otc infrastructure has some mechanism for letting me publish stuff against my identity in a centralised manner, you've got a centralised system that could just be trivially extended to track the loans that have been made to me - it's much simpler and doesn't require any fancy maths.

also regarding collateral, you can build Collateralized Loans although they are not directly described in the Bond Paper.  The Futures/Options paper does describe Collateralized Futures Contracts.  http://www.altchain.org/?q=whitepapers/paper4.html

also an interesting idea was the Crypto Pawn Shop, which is basically a concept where people can take their physical goods and use them as collateral against cryptoloans.  Example, you drop off your gold necklace and you can take out a loan for $1000.  You pay it back, and you can take your necklace home- you default and you lose your property.

http://www.altchain.org/?q=content/crypto-pawn-shop-liquidity-idea

concepts like Bonds, Shares, and Loans DO APPLY, and they can be implemented AS IS in Confidence Chains.  It is explained in detail here: http://www.altchain.org

It's correct to say that these sorts of instruments DO rely on legal judgements, and this is why Confidence Chains does not appeal to 'Proof Of Work' for it's sense of objectivity.  PoW was originally designed for spam prevention and it's even questionable as to whether it can support an digital currency in the long term.  You can do much more with Confidence Chains outside of just exchanges, loans, futures and options.  These features will be explained in upcoming papers, but if you look closely you might find some hints in various threads around the net.

While I do hope that some or many social constructs can be reinvented at present there is a lot of confusion of terms. These kinds of systems are very unlike other before, and concepts like bonds, shares and loans don't really apply. Or rather they apply in new configurations, so it is extremely insightful to study the history of these. Contracts in a modern democracy have to do with courts, governments, lawyers, etc. They are not floating in free space. I can't write on a piece of paper: "this is one Apple Inc stock" and hand that over to someone (I can use a broker and clearing house to do that). I can't make an IPO of my personal stock and hand out pieces of paper: "this is one MyInc stock" (stock listings cost many millions of dollars for good reasons).

The same with bonds. Bonds and stocks require that income is channeled through an account. That would require that a person can not generate new addresses, i.e. a match of ID to account. However, with virtual constructs, such as domains and files it should be possible to bootstrap a market. Proof of owning a TLD is pretty easy to implement. One might imagine using TLD's as collateral. If I take a loan and default, transfer of verycool.com goes over to the lender. Marketprices of domains are possible to verify via sedo or other means.

a lot of information in this thread.

first off, my whitepaper on P2P Bond Auctions: http://www.altchain.org/?q=whitepapers/paper3.html

the concept described in the paper allows for most if not all of what is being suggested above, and it solves these problems in a relatively simple and straightforward way.  Once you've established the features outlined in the paper, then you have the remaining issue of how to rate and price credit risk.  Obviously there are many approaches to this problem, but the solutions are normalized as far as the finance industry is concerned(they behave in the same way that typical credit risk functions work).  It does describe a simple auction functionality which is the standard way in the finance world to price credit risk.

This page: https://en.bitcoin.it/wiki/Distributed_markets , offers a somewhat misleading collection of ideas.  It's not clear how the Distributed Hash Table is used in this scenario, and most leaves open the most important issue of all, how to detect and handle loan defaults.  How do you determine if a loan is in default in a p2p network?  As far as I understand it, Confidence Chains is the only system that offers a device capable of doing this(in a distributed way).


by what timetable?  We all know that there is no objective measurement of time in the Bitcoin network and system that do require some form of objective rely on 3rd party services.  A good example: http://btcoracle.com/, and in this case we must jump out of the world of p2p and into a privatized, centralized server to set our options price.


the implied way the P2P Bond Auction works is the credit ratings are related to an Address(like a bitcoin address).  Thus creating more addresses only dilutes your credit rating.  I tend to think the easiest way to construct a credit market is to compute the ratings based on membership in a social network.  Your rating is based on your past payment behavior and your friend list.  In the system described in the whitepaper the marketing and retail of credit risk is decoupled from the rating system, anyone can purchase(or bid on) a bond for any price they wish.  People can design their own strategies for rating and profiting from risk pricing.


this is where the term 'derivative' came from.  It's the derivative(in the calculus sense) of all potential profits over time.

I asked gmaxwell about the possibility of sybilling (e.g. showing different empty trees to each lender), and he said that the threat model he is dealing with here consists of people who show up on -otc, do a bunch of small, simple trades for a year or so to build up reputation, then finally borrow huge sums of money and disappear. This is a real thing that happens today.

So to coinrevo: the problem this solves is a real one, even though it doesn't solve the "real" problems around lending.

To Mike: re "this protocol is incomplete", it's presumed that you'd attach your tree to your -otc rep, so every fake account would require a new reputation-building phase.

For people new to this line of (very important) research, here are some previous writeups:

Smart property is an attempt to think through how you can do collateral for loans in a fully peer to peer environment. It exploits the fact that physical objects can sometimes have cryptographically controllable locks attached to them.

The distributed markets page sums up previous writings on how to make a p2p bond market.

Not wanting to loan to someone who has built up unsustainable amounts of debt is an important component, but the obvious problem with these sorts of protocols is how to force Alice to have only one hash tree (or whatever construct is used). By itself the above protocol is incomplete because Alice can simply say "I do not have any debts" and how would you know differently?

Whilst modern proof systems are very interesting and exciting (there's a new paper out as of Dec 31st from Eli et al by the way), to me the question of how you prevent people from hiding past debts and creating new identities at whim is equally interesting. Especially because the entities that care the most about ID verification and preventing you from creating fake IDs (governments) mostly still act as if crypto is alien technology that came to us via Roswell.

Very interesting. I think the problem is of a different kind, which has to do with proof of income and collateral. Collateral basically is an asset which can be seized by a different party. For most of history this included the use of force, which in some way is still in effect today via the court system.

The lender looks to earn a profit for his loans, as well as the borrower. If A lends 100$ to B for 1 year, the repayment would be 100$ + interest. Interest is the market rate for expected profits A and B can earn in the mean time, which can be different rates. For example if B has an investment opportunity which will return 100%, while market interest is 10% he should borrow as much as he can to earn the difference. Modern Economics would simply say that interest basically is the output in an Walrasian auction, and every agent has perfect information. However there all kinds of non-linearities involved, which escapes so called economics completely (a field in which true idiots get nobel prizes).

Loans today are based on the fact that income is provable, and future income can be made collateral. In Bitcoin this is not true at all. I'm always free to create new accounts and channel my income through that account. Through most of history collateral used to be land, as this is not movable property. Also labor was not virtual. And the game theory of it had mostly to do with physical power. This is not much different today. Courts will seize assets and freeze income. Say all future income of a lender is known and can be packaged in a sum of money. A loan is nothing else than selling parts of that package. In Bitcoin neither income nor property can be used for collateral.

Incidentally this is what off-shoring is all about. You just create virtual entities on some remote island, outside your jurisdiction. Then you employ lawyers to build that legal fortress, through clever schemes loopholing corporate law. This gets even easier if you have several income streams from various countries.

If one operates outside legal rules much of modern finance breaks down. You can't prove what you own, you can't use courts to enforce contracts. So most of the usual economic relationships of the fiat world are not in place. The best use cases are where property is virtual anyway. For example proof of ownership of a file is trivial, as is the transfer in many cases (how do I prove I have not access to a file?). Domain names are an interesting example. The EPP Protocol defines procedures for proving and transfering ownership. I believe this is the first example of global property transfer, before bitcoin, and would be a very good use case for implementation of a virtual market.
 
Loans don't just exist on a national but international level. In the European Union one can really see the effects of non-enforcement very well. Some countries just borrow more and more. And then they default. Because there are no international bankruptcy laws or working international court, and enforcement of loans not possible, the loan system does not work.

For loan and equity agreements to work in bitcoin, one need a way to restrict inputs of a person to certain addresses, just like one can't open bank accounts arbitrarily. Then enforcement becomes as trivial as enforcing the outputs, based on predefined rules. However, it seems more than unlikely that such a scheme could be implemented in the near term. It is highly doubtful that users of bitcoin / economic majority would want such a restriction.

Alice participates in some web-of-trustish rating community (like #bitcoin-otc or the forum trust ratings) and would like to borrow money from people but generally wants to keep her trading practices private. People would like to loan her money, but don't want the _aggregate_ amount of loans  she has taken across all parties to exceed some risk tolerance threshold. The risk management could be solved by Alice publishing all her loans (and with the lenders making sure theirs show up in the list) but this isn't private.

I propose:

As Alice accepts loans she forms messages like "[lender_onetime_pubkey, nonce/H(terms), amount]" and stores it in a binary hash tree augmented with some of child amounts in the interior nodes, but with the total amount omitted from the root node.

At first the accumulator tree starts off empty, then Alice can add loans, and every time she adds a loan she executes the update inside a publicly verifiable zero-knowledge proof system.   She publishes in the public rating system the final root hash, along with the proof that it was a valid update according to the rules.

No one learns anything about Alices' loans except a upper bound on how many she has (and if batch updating is allowed, maybe not even an upper bound).

When someone wants to make a loan but is concerned that Alice is too risky, they ask Alice to create a proof that the balance of her accumulator tree is less than some amount (a fairly compact proof task, since it's only a test of part of preimage of a hash). They would learn nothing other than the binary result of the test.

When someone makes her a new loan, they ask her to provide a proof that she's updated her tree to include it. (This can be a side effect of the update process if it yields a list of H( added [lenderpubkey, nonce/H(terms), amount])).

When a loan is closed, she produces a proof of correctly removing the a loan, and the proof includes a list of pubkeys for which have been removed. The proof isn't considered valid by anyone, however, unless it comes with signatures by the pubkeys which have been removed. (this keeps ECDSA validation out of the zero knoweldge proof).

This kinda of system could be further extended to do things like track loan terms and dates.  E.g. "Prove you have no past due loans".  Though ideally queries that only touch log(n) nodes are going to result in more efficient proofs.

If loans can be satisfied by Bitcoin transactions, e.g. "payment of X to address Y; nonce" these terms could be hashed and included in the loan entry. This would allow Alice to remove loans from the list without the lender's help. Then after satisfying the loan Alice could produce a removal proof which reveals the hashed terms for the loan being removed, and along side it Alice could go collect a SPV proof from the bitcoin network,  "At least 6 blocks blockhash 0xdeadbeef the terms with hash X are satisfied"... and the peers in the reputation network will accept the pair of proofs so long as block 0xdeadbeef is in the current blockchain.

Something similar could be done to prevent fake lenders from tricking Alice into adding in loans they don't make good on. (e.g. put a specification for the loan payment in the entry, and allow alice to back out loans that were not paid by some deadline)... except that a compact proof of non-payment is not possible. So instead you'd want Alice to prove that a transaction spending a particular coin wasn't the right one agreed in the loan, or that the particular coin was unspent (which needs a utxo proof).

Since all of this requires proofs only over hashes, addition, and comparisons the proofs should be _feasible_ with currently described state of the art techniques, at least no less than any real application is.