Hi Eric,
Thank you for your questions as they show what concepts need further explanation, so you understand the potential of this proposal and how it is helpful to the ecosystem.
Riskless zero bond is in fact the most basic concept of financial engineering. Yes, there are engineers of finance, those who create and price financial derivatives (e.g. options, swaps) and structure products such as e.g. ABS, CDO etc.
I used to be one of them.
A zero bond formalizes the observation that 1 unit of currency in the future has different value than 1 unit available now. It is called riskless if it is certain to receive the payment in the future.
If we put this difference of vaue in relation to the amount then we get the “risk freee rate of return”, that you heard of.
E.g if one is willing to exchange 1 BTC unconditionally available now for 1.1 BTC certainly available in a year but not earlier, then the implied “risk free rate of return” is apparently 10% pa. for Bitcoins.
As I implied, I am well aware of the concept of risk free rate of return, which is a hypothetical.
The transaction I construct in the first example achives exactly this, because:
Which implies you have created an actual instance of this heretofore purely hypothetical concept.
Bob forgoes his ability to use his unconditionally available coins by giving them to Alice with a covenant that ensures that Bob will receive them back later.
Bob does this because Alice pays for this in advance.
Alice can further transfer the coins encumbered by the covenant, but they will unconditionally return to Bob in the future.
Why would Alice pay for this at all?
The utility of these encumbered coins is that they prove that the loan is fully covered by reserves.
What loan? Alice has paid Bob for something of no possible utility to her, or anyone else.
Bitcoin is a money, not consumable in any way. Its utility arises strictly from the possibility of eventually being traded for something else. The only reason to accept it in trade is that expectation. Removing that possibility, even transitively and over time, removes all utility immediately. In my previous comments I described a necessary discount to NPV, but it’s safe to say that must be 100%.
How valuable this utility is will be decided by the market
Value is of course subjective, and is determined by individual preferences. Yet what is the value one might place on something of no use? Economically speaking it must be zero, since value is a subjective evaluation of utility (i.e. service to a person).
Consider the case of the 1000 and 500 rupee demonetization. Long lines of people formed at banks to convert to notes to others of equivalent denomination.
Of course, upon announcement of the demonetization, existing 1000/500 rupee notes were discounted for the cost/risk of accomplishing this conversion (several people are reported to have died in the effort). If there was no such conversion possible, making the notes worthless at the future date, the *immediate* effect would necessarily have been 100% discount.
This of course sets aside any consumable value of the “paper” notes, such as burning for heat or trading as novelties (e.g. demonetized Zimbabwean 100T notes currently trading), as Bitcoin is not capable of being consumed. It also sets aside the possibility that some people were unaware of the demonetization.
Who would accept such a note today that was known to be worthless at a future date? If they did, who would would accept it from them? It’s literally an on-chain scamcoin, where the first sucker must find another, and he another, an so on, as soon as possible, before it expires, leaving the last sucker holding the bag. Given an efficient market (i.e perfect knowledge of the scam), zero initial value is implied.
and that value will be interest received by those who temporarily give up control. I am guess the value will be low but positive.
Giving up control of money for a period does not imply the money is useful to someone else. Bob might as well lock his coins in a time capsule, for which he has the only key, and ask Alice to pay him for it.
Lending does not mandate fractional or full reserves.
I didn’t say that it does. Lending implies no “mandate”. But the nature of fractional reservation is inherent in every loan/investment.
These are choices the market or regulators enforce.
Fractional reservation is not a consequence of statutory or market controls. The level of hoarding vs. lending is a consequence of individual time preference.
Full reserve banking is not a fiction but is how things worked before introduction of gold receipts. A bank could only lend gold coins it possesed. Perils of fractional reserve were felt repeatedly by the Bitcoin ecnomy e.g. in the collaps of MtGox.
I don’t believe I called full reserve a fiction. With full reserve there is no possible investment, production or products. Unlikely, and disastrous for humanity, but not provably impossible.
A hazard of viewing economic concepts through a financial lens is that those higher order concepts become obscured by a morass of economically-irrelevant regulation and implementation details.
At this point we are going to end up in a discussion on what fractional reserve actually is. I’d be happy to have a discussion on the topic, but this list is clearly not a good forum for that.
Furthermore the question of whether or not this proposal is relevant to fractional reserve is moot unless it can be shown that the assumed utility actually exists. So I suggest we take this interesting but secondary question on fractional reserve somewhere else.
The idea to return to full reserve banking is not unique to gold bugs or Bitcoin but recently a popular vote was initiated in Switzerland to force Swiss banks to full reserves with respect to lending. This popular vote achived 24% support [1] which is quite remarkable if considered that the topic is not trivial as also our exchange shows.
It shows the breadth of economic ignorance which is not surprising given its counterintuitive nature.
Best,
Eric
I would welcome feedback on the generalized covenant construct or its implementation, as I think it can open up much more uses than the few examples I gave.
Tamas Blummer
Hi Tamas,There are a number of economic assumptions contained herein. While I understand you would like to focus on implementation, the worst bugs are requirements bugs. IMO these should be addressed first. I’ve addressed some possible issues inline.On Jun 28, 2019, at 01:27, Tamas Blummer via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I start with a formalisation of loans as common in finance:
A zero bond is a contract between two parties Alice and Bob whereby Alice receives an amount less than P and has to pay back P at a later time point called maturity.
The difference between the amount received and P is the interest implied by the contract. E.g. receiving 1 Bitcoin (<P) and agree to pay back 1.1 (=P) in a year is the same as getting a loan with 10% p.a. interest.
The inherent risk in the contract is that Alice may not honor the agreement or be bankrupt by then.
If we could programmatically guarantee that Alice honors the contract then we would be able to create a riskless zero bond, the fundation of financial engineering.
I’m not aware of the basis of this statement. While people use the term “risk free rate of return” there has never actually been such a thing. It’s not clear to me how a unicorn has been the foundation of “financial engineering”, but I’m not also clear and what is intended by “engineering” in this sense. Generally engineering is the implementation of higher level concepts. It is those concepts that constitute requirements here.At a minimum, interest cannot be guaranteed by this proposal, which implies that at best it guarantees, setting aside changes in purchasing power, a return of principle minus economic interest on that principle (ie opportunity cost). Given that purchasing power changes over time, risk increases with the term of the loan. As such this is not riskless - both volatility and opportunity cost remain as risks.A systemic problem with loans is that the lender might operate on fractional reserve, that is lending more than his capital.
This is not a systemic problem, this is the very nature of lending. Fractional reserve is simply a state banking term used to describe the fact that people invest (lend) a fraction of their savings and hoard the rest. It matters not that banks or individuals do this, credit expansion is inherent in economy. Without it there is no investment and therefore no production whatsoever.Unchecked inflation of money supply through fractional reserve is creating a mess in the world we live in. Bitcoin could overcome this mess implementing this proposal!
You seem to be conflating state banking with the effects of investing. Taxpayer support for bank investment creates both a moral hazard (and the resulting misallocation of capital to state-favored projects, creating the famed economic “business cycle”) and is a manifestation of persistent monetary inflation (ie seigniorage is a source taxation. Investment implies credit expansion, and the level of this expansion is controlled by time preference alone.I stop here with finance speak as the purpose of this mail is not to dive into finance, but to show how loans with full reserve check could be implemented in Bitcoin.
1. Receiving the loan is a payment from Bob to Alice, but we need a restriction how Alice can use the funds, so Bob can get them back unconditionally at maturity, so lending is riskless to him.
2. Bob wants to receive interest, since he gives up his control of the coins until maturity, he can not use them elsewhere until then. That interest could be paid in advance, this can be solved with Bitcoin as is.
Interest cannot be paid in advance. This implies nothing more than a smaller amount of principle.How do we allow Alice to use the coins, that is: split/merge and transfer them to others, but still ensure Bob can claim them back at maturity?
We ensure that Alice can only send the coins to outputs that inherit a taproot path of validation (using http://bitcoin.sipa.be/miniscript/): 'and(time(100),pk(C))' where C is Bob’s key and 100 is maturity
This requires a generalization of the Bitcoin Covenants Idea[1] such that it nicely fits with taproot as follows:
1. A covenant in the form of '_ covenant C’ on output means that it can be spent to an output that maches the covenant pattern with placeholder _ and the output(s) will be assigned 'covenant C'.
2. A covenant that mandates an output script with alternate validation paths can also assign alternate covernants to be inherited by the output(s) depending on which path was used to spend the input eg. 'covenant or(c covenant C, d covernant D)’
3. The resulting covenant of outputs should be reduced following boolean algebra, e.g. or(b,or(b,a)) to or(b, a)
4. express transitivity with 'covenant transitive’ which means the output will have the same covenant as the input
5. allow to omit covenant on the output with 'covenant drop'
The covenant Bob would assign to the loan output sent to Alice is: 'covenant or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)' which means:
- Alice can send to an output script where she is free to chose the embedded script at the placeholder _ and that output will again have the same covenant as the input.
- After maturity Bob can claim any coin that is transitively rooted in the loan (more on this later) and the covenant will no longer be assigned to his new output(s).
Assuming Alice wants to send some of the borrowed coins to Charlie:
for shorter notation lets use b='and(time(100),pk(Bob)) covenant drop’ for the script that gives Bob control after maturity.
Alice can not send to pk(Charlie), but she can send to or(b, pk(Charlie) covenant transitive)
Sending to pk(Charlie) would be sending cash, sending to or(b, pk(Charlie) covenant transitive) is a promissory note issued by Alice to Charlie, here is why:
If Charlie accepts an or(b, pk(Charlie) covenant transitive) output then he trusts, that Alice will offer a regular payment in exchange for it before maturity, since that output is worthless to Charlie after maturity as Bob can just take it.
It seems at the first sight that there is no value in these outputs for Charlie, since he still has to ensure Alice replaces them before maturity.
The value of these outputs to Charlie is the proof that he has exclusive control of the coins until maturity.
At a minimum, money that predictably depreciates (to zero in this case) must be discounted accordingly. How much is money worth today that is worth zero tomorrow? This can be observed with both inflation and demurrage money. This also implies that each encumbered coin is not fungible with any other of a distinct discount schedule.What is the economic consequence of lending discounted money? Lower interest rates. How much lower? The rate of depreciation. This can also be observed with inflation and demurrage, but observation isn’t required. This is a necessary outcome.So when one lends 1 demurrage coin for a term one cannot earn interest on 1 coin, one is earning interest on a fraction of a coin. That fraction creates credit expansion and reduces return in direct proportion to the risk that has been offset. In other words, the risk cost has been converted to opportunity cost. The discounted fraction earns no interest.So credit expansion and risk remain, in the same proportions as without such a system. However lack of fungibility introduces an additional overhead cost.eAlice can not issue promissory notes in excess of own capital or capital that she was able to borrow. No coin inflation or fractional reserve here, which also reduces the credit risk Charlie takes.
Due to the transitive covenant Charlie could pass on the coins to an other temporary owner until maturity when Bob would re-collect them unconditionally.
Should Charlie no longer be comfortable with Alice’s promise or need final coins (cash) immediatelly, then he could turn to Dan and do a re-purchase (repo) agreement with him.
Charlie would receive final coins from Dan in exchange for the temporarily controled coins and Charlie's promise to replace them with final coins before maturity.
Dan would thereby charge high interest through a discount since as he has to bear the credit risk of Charlie. This is not a riskless but a plain zero bond.
Why would Dan want to take temporary control of the coins at all? Again, to ensure Charlie is not doing yet another repo with Frank on the same coins, the sum of Charlie's repo deals are not in excess of his claims against others.
This again avoids lending in excess of coin supply and reduces the credit risk Dan takes.
Here are the sketches for the transacions for above alternate actions:
lets use shortcut c for 'or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)’
the transactions offer a fee of 0.0001
Bob gives a riskless credit to Alice:
Input Output
1 pk(Bob) 1 or(b,pk(Alice) covenant c)
0.1 pk(Alice) 0.9999 pk(Bob)
Alice could send a 0.5 promissory note to Charlie:
Input Output
1 or(pk(Alice) covenant c) 0.5 or(b,pk(Charlie) covenant c)
1 pk(Alice) 0.5 or(b,pk(Alice) covenant c)
0.9999 pk(Alice)
Alice could make good of the note before maturity, pay some interest and get back temporary control of the coins with:
Input Output
0.5 or(b,pk(Charlie) covenant c) 0.5 or(b,pk(Alice) covenant c)
0.5101 pk(Alice) 0.51 pk(Charlie)
alternatively Charlie borrows from Dan at high interest:
Input Output
0.5 or(b,pk(Charlie) covenant c) 0.5 or(b,pk(Dan) covenant c)
0.3001 pk(Dan) 0.3 pk(Charlie)
and Charlie re-purchases the temporary coins before maturity, making good of the repo with Dan:
Input Output
0.5 or(b,pk(Dan) covenant c) 0.5 or(b,pk(Charlie) covenant c)
0.5001 pk(Charlie) 0.5 pk(Dan)
We need to define further transaction level validations for transactions spending inputs with covenants as follows:
1. If there are inputs without covenant before the input with covenant than inputs without covenant must be spent exactly with outputs preceeding the outputs with covenants.
2. A transaction can have inputs with different covenants, their allocation to outputs should follow input order.
3. For output(s) that share input(s) with covenant, the sum of covenant outputs must exactly add up to the input(s). This allows merging and splitting them.
Bob would re-collect his coins at maturity unconditionally. Who followed through promises or defaulted down the transitive chain is irrelevant to him.
Remark: we might also need a covenant attribute defining the minimum size of output, so Bob is not forced to collect dust, which would be expensive or even impossible. I am not yet happy with this solution, looking for better.
I am very excited about the possibilities this proposal would unlock and ask you verify usefulness of this scheme and join working out the details and how covenants would be integrated with taproot.
Tamas Blummer
[1] Malte Moser, Ittay Eyal, and Emin Gun Sirer. Bitcoin Covenants. URL: http://fc16.ifca.ai/bitcoin/papers/MES16.pdf
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev