Quote from: Cryddit on March 30, 2014, 05:48:34 PM

First explain carefully what a "repo market" as opposed to, say, a bond exchange or stock exchange or futures market is, or when one or more of the latter counts as a repo market. Second, exactly how an interest rate relates to such a market. The only one of those market types where interest rates are directly measurable seems to me to be some kind of futures market.

A repo market is a collateralised bond market. See e.g. https://en.wikipedia.org/wiki/Repurchase_agreement . It combines elements of futures markets and bond markets to produce one which comes close to capturing the risk free rate. The basic idea is that I sell you an asset (perhaps below market price), and we both sign a contract in which we promise to trade back the asset at some specified price in the future. The specified price may be written as a function of market observables to remove some of the risks associated with fluctuations in the value of the asset. As you point out in a later post, an enforcement method is obviously needed for these contracts, however, if the collateral is appropriate, losses from the other party reneging on the contract may be minimal.

Quote from: Cryddit on March 30, 2014, 05:48:34 PM

If it's a service that we can figure out how to completely decentralize and build into the blockchain itself, then we're cooking with gas. If it's something that would be an external resource, or that would have to be centralized at a website somewhere, then it gets us nothing.

Quote from: markm on March 30, 2014, 06:05:42 PM

Or at least maybe check whether something like bitshares or the like, which already claims to plan decentralised markets that do not rely upon outside "oracles", might be able to or would not suffice to provide the required information.

Yes. OK. The details of the bitshares decentralized market seem a bit sketchy in the white paper, but they seem to have much of the required structure. eMunie also seems to have solved the problem, though I understand from Raxe that their solution isn't really decentralized. Finally, Ripple certainly provides a structure on which something like this could be built, with decentralized trust.

Quote from: Cryddit on March 30, 2014, 05:48:34 PM

The basic requirements here for the automatic reaction that we're looking for is that it has to arise in a decentralized p2p service, where the information that's being reacted to is visible to and checkable by literally everybody who can see the blockchain up to the point where the information matters. Essentially the problem is that if it's an external source of information - if it reflects information not immediately visible to everyone looking at the blockchain - then people will not be able to check the blockchain to see that the response to it was correct at every point. Being part of the blockchain, in turn, means it has to be a fully decentralized P2P application.

I do not pretend to know all the precise implementation details. I was hoping to provide useful guidance on the econ side, but having overused the word "easy" I guess I ought to put my money where my mouth is and conjecture as to how this could be implemented. The version I present here is without any explicit trust mechanism, though perhaps using the Ripple trick for trust would further help. For clarity in the below I call the new currency repocoins.

1) The wallet software would sync both the repocoin block chain, and that of a third party currency (Bitcoin would be the obvious one given its dominance, so I'll call the third party currency bitcoin below).

2)a) You host repocoin-bitcoin exchange orders within the repocoin blockchain, so they're public and verifiable. Each exchange order consists of two quantities: a number of bitcoins, B (possibly negative) and a price in units of repocoins P. The order represents an offer to sell (buy if negative) B bitcoins at the end of the current block at a price of P repocoins per bitcoin.
2)b) At the end of the block, the intersection of the supply and demand schedules are calculated, and the market exchange rate is set at this point. We will call this P* in the below. Since this is a deterministic function of the orders, it may be calculated by all nodes and verified en mass. All sell orders below P* will be executed (to be described), as will all buy orders above P*.
2)c) The repocoins and bitcoins in the orders to be executed are transferred as prescribed, with the bitcoin transactions going through first, and the repocoin ones only happening once the bitcoin ones have been verified en mass. Since the network can enforce the removal of repocoins, but not the removal of bitcoins, this order is required.

3)a) You host repocoin-bitcoin repo orders within the repocoin blockchain, so they're public and verifiable. Each repo order consists of two quantities: a number of bitcoins, B (possibly negative), and a gross interest rate R (e.g. 1.02 representing 2% interest). The order represents an offer to sell (buy if negative) B bitcoins at the end of the current block for a price of P* repocoins per bitcoin and buy (sell) them back at the end of the next block for a price of P*R repocoins per bitcoin. Note: the seller has borrowed BP* repocoins and will pay back BP*R, i.e. R is the gross nominal interest rate on their loan.
3)b) As before, we calculate the market interest rate R* from the intersection of the supply and demand schedules.
3)c) We mark (R*-1)BP* repocoins in the wallet of each seller as locked and untrasferable. This is enforced by consensus.
3)d) At the end of the current block, as before, the repocoins and bitcoins in the orders to be executed are transferred as prescribed, with the bitcoin transactions going through first, and the repocoin one only happening once the bitcoin ones has been verified. If a seller's bitcoin sale transaction fails for some reason then their previously locked repocoins are unlocked.
3)e) At the end of the subsequent block, the reverse transaction has to take place. This only happens if the seller's wallet has the required BP*R* repocoins (including the locked ones). If the seller doesn't have this number of repocoins, then the previously locked repocoins are unlocked and sent to the buyer. This leaves the buyer a total of B bitcoins and (R*-1)BP* repocoins, which are worth BP** + (R*-1)BP* repocoins, where P** is the new exchange rate. Providing the exchange rate fluctuations have not been excessive, this should still represent a moderate gain for the buyer. If the seller does have the required number of repocoins, then, as before, the bitcoins are transferred back first, and then the seller's locked repocoin are unlocked and the required repocoin are sent the other way. If the bitcoin transaction fails (e.g. because they do not have enough), then the seller keeps their repocoins, and the previously locked ones are unlocked. This leaves the seller with BP*R* repocoins, which (given small exchange rate fluctuations) they ought to prefer to B repocoins.
3)f) So, given the locking mechanism, it is only following large exchange rate movements that people will have an incentive to default. At worst then, R* will be the market gross nominal interest rate plus a bit of a risk premium. But fluctuations in the risk premium should be small compared to the fluctuations in the value of e.g. bitcoin, so targeting R* will still result in a stable currency.

4) Once the market rate in the repo market is observable, it's then just a matter of applying sufficient PoS interest on the next block when the repo market rate is below target, and demurrage if its above target. For example, suppose the target is 4%. Then, if the market rate were to be 3%, sellers in the repo market would gain interest on the repocoins they borrowed during the block in which they'd borrowed them, and hence they'd be more inclined to borrow in the first place, pushing up the market interest rate.