npub1cc…ex8m8

📅 Original date posted:2019-06-28
📝 Original message: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.
The transaction I construct in the first example achives exactly this, because:
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.
The utility of these encumbered coins is that they prove that the loan is fully covered by reserves.
How valuable this utility is will be decided by the market and that value will be interest received by those who temporarily give up control. I am guess the value will be low but positive.
Lending does not mandate fractional or full reserves. These are choices the market or regulators enforce. 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.
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.
I published today a writing in medium, that explains the concept of fractional vs. full reserve banking in conjunction with this proposal. Please read: https://medium.com/@tamas.blummer/full-reserve-banking-with-bitcoin-462b21ae9479 <https://medium.com/@tamas.blummer/full-reserve-banking-with-bitcoin-462b21ae9479>
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
[1] Vollgeld Initiative: https://www.bfs.admin.ch/bfs/de/home/statistiken/politik/abstimmungen/jahr-2018/2018-06-10/vollgeld-initiative.html <https://www.bfs.admin.ch/bfs/de/home/statistiken/politik/abstimmungen/jahr-2018/2018-06-10/vollgeld-initiative.html>
> On Jun 28, 2019, at 19:25, Eric Voskuil <eric at voskuil.org> wrote:
>
> 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at 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.
>
> e
>
>> Alice 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 at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190628/b6aef1d2/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190628/b6aef1d2/attachment-0001.sig>