From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A724CBF for ; Sat, 29 Jun 2019 21:21:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg1-f196.google.com (mail-pg1-f196.google.com [209.85.215.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B052B2C6 for ; Sat, 29 Jun 2019 21:21:23 +0000 (UTC) Received: by mail-pg1-f196.google.com with SMTP id t132so775891pgb.9 for ; Sat, 29 Jun 2019 14:21:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SSbxuqxsuHZb3iUlQRXkEdWtBtfV46uB2u6Y7rdkeHQ=; b=JEGPZcNVkmdRMY2SW0GHSPSg4VaC5YYT5WnNtc4gDki80muvfZIDbvVkN6FzKBUcJr zDt1nXQTuKG9h70ZmgpbXxklERC+qg8AMGfe0mWCGmXix2A1oF+rM66puzL5eAkiom/1 TxOe1eJcUP+HYz09ad9fr2BmbYf8dH02PaLXUu0RcbPnNZv5Plo+qWIfjZHsokdF3XGb ZmKQ5YuuOJMsc7Iul86cYlYVy7Mt9tifhEAYuA+jTTpXdyUuCVQ78bJWbFwMZR0s69LV KIJamiWftM57YCo/iFfCAKPdaV32fWiH85999BbGpE7oqWkoXp5DVqBw3/zoe/xtg9ek O1JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=SSbxuqxsuHZb3iUlQRXkEdWtBtfV46uB2u6Y7rdkeHQ=; b=Ef1vhBkn0VXtGbm+0nJAf7gl3x3fIgNyWPF0zb3z7and0ARe34G5mR9ZelnF651G9m XyU3EgyroLgxt3SxxfYjqby3DKIEXzhrgNYZ/CjyJd+82J1yY6apD+tgWQZafEp7mg3P 01uA9qCNffluOwGl2GevOXrOxinSspm+z766mx4/6pPKqvOU8ZmGSodavDq6g0F/OcwF eDct9BoTDW36PsHNtagXq9gbabD5y+/MgXj/RNvSQSxHm3TL/fzWiUP9uXFk9oS31wm1 gOVVvNjCMj+A5AwJerIsO7o3Er1rH6vg9q4S35wI+gqp0RTZZV+jEfBfHZMJ9Lx8w+03 nVWA== X-Gm-Message-State: APjAAAVUDj1Xm3fs86plG2toy7VkBzBFZ3FzlZ2NAlOlha+8LSMdATX5 pZQL0SYY1rLTUON/UgUz4g3K3lY6yiw= X-Google-Smtp-Source: APXvYqyGSbDIt7z8LngkuKq4AzFrkUHvRergxz1q1FgEAu/bQ5Lf06DzmvIaGIMiT0eX4vWD7jC8qQ== X-Received: by 2002:a65:64d3:: with SMTP id t19mr5907240pgv.112.1561843282698; Sat, 29 Jun 2019 14:21:22 -0700 (PDT) Received: from ?IPv6:2600:380:8027:8b6d:14f8:e521:300f:c84d? ([2600:380:8027:8b6d:14f8:e521:300f:c84d]) by smtp.gmail.com with ESMTPSA id b11sm6805238pfd.18.2019.06.29.14.21.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 29 Jun 2019 14:21:22 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-A6F96C51-0E07-4567-8329-BE433B666D46 Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (16F203) In-Reply-To: Date: Sat, 29 Jun 2019 14:21:20 -0700 Content-Transfer-Encoding: 7bit Message-Id: <708D14A9-D25E-4DD2-8B6E-39A1194A7A00@voskuil.org> References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com> <7A10C0F5-E206-43C1-853F-64AE04F57711@voskuil.org> To: Tamas Blummer X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 30 Jun 2019 04:10:05 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 21:21:26 -0000 --Apple-Mail-A6F96C51-0E07-4567-8329-BE433B666D46 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Jun 28, 2019, at 12:21, Tamas Blummer wrote: >=20 > Hi Eric, >=20 > Thank you for your questions as they show what concepts need further expla= nation, so you understand the potential of this proposal and how it is helpf= ul to the ecosystem. >=20 > Riskless zero bond is in fact the most basic concept of financial engineer= ing. Yes, there are engineers of finance, those who create and price financi= al derivatives (e.g. options, swaps) and structure products such as e.g. ABS= , CDO etc. > I used to be one of them. >=20 > A zero bond formalizes the observation that 1 unit of currency in the futu= re has different value than 1 unit available now. It is called riskless if i= t is certain to receive the payment in the future. > If we put this difference of vaue in relation to the amount then we get th= e =E2=80=9Crisk freee rate of return=E2=80=9D, that you heard of. >=20 > 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 =E2=80= =9Crisk free rate of return=E2=80=9D is apparently 10% pa. for Bitcoins. As I implied, I am well aware of the concept of risk free rate of return, wh= ich is a hypothetical. > The transaction I construct in the first example achives exactly this, bec= ause: Which implies you have created an actual instance of this heretofore purely h= ypothetical concept. > Bob forgoes his ability to use his unconditionally available coins by givi= ng them to Alice with a covenant that ensures that Bob will receive them bac= k later. > Bob does this because Alice pays for this in advance.=20 >=20 > Alice can further transfer the coins encumbered by the covenant, but they w= ill unconditionally return to Bob in the future.=20 Why would Alice pay for this at all? > The utility of these encumbered coins is that they prove that the loan is f= ully covered by reserves. What loan? Alice has paid Bob for something of no possible utility to her, o= r anyone else. Bitcoin is a money, not consumable in any way. Its utility arises strictly f= rom the possibility of eventually being traded for something else. The only r= eason to accept it in trade is that expectation. Removing that possibility, e= ven transitively and over time, removes all utility immediately. In my previ= ous comments I described a necessary discount to NPV, but it=E2=80=99s safe t= o 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. Y= et what is the value one might place on something of no use? Economically sp= eaking 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 pe= ople formed at banks to convert to notes to others of equivalent denominatio= n. https://en.m.wikipedia.org/wiki/2016_Indian_banknote_demonetisation Of course, upon announcement of the demonetization, existing 1000/500 rupee n= otes were discounted for the cost/risk of accomplishing this conversion (sev= eral people are reported to have died in the effort). If there was no such c= onversion possible, making the notes worthless at the future date, the *imme= diate* effect would necessarily have been 100% discount. This of course sets aside any consumable value of the =E2=80=9Cpaper=E2=80=9D= notes, such as burning for heat or trading as novelties (e.g. demonetized Z= imbabwean 100T notes currently trading), as Bitcoin is not capable of being c= onsumed. 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 futur= e date? If they did, who would would accept it from them? It=E2=80=99s liter= ally an on-chain scamcoin, where the first sucker must find another, and he a= nother, an so on, as soon as possible, before it expires, leaving the last s= ucker holding the bag. Given an efficient market (i.e perfect knowledge of t= he scam), zero initial value is implied. > and that value will be interest received by those who temporarily give up c= ontrol. 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 t= o someone else. Bob might as well lock his coins in a time capsule, for whic= h he has the only key, and ask Alice to pay him for it. > Lending does not mandate fractional or full reserves. I didn=E2=80=99t say that it does. Lending implies no =E2=80=9Cmandate=E2=80= =9D. But the nature of fractional reservation is inherent in every loan/inve= stment.=20 > 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 prefe= rence. > Full reserve banking is not a fiction but is how things worked before intr= oduction of gold receipts. A bank could only lend gold coins it possesed. Pe= rils of fractional reserve were felt repeatedly by the Bitcoin ecnomy e.g. i= n the collaps of MtGox. I don=E2=80=99t believe I called full reserve a fiction. With full reserve t= here is no possible investment, production or products. Unlikely, and disast= rous 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-irrelevan= t regulation and implementation details. At this point we are going to end up in a discussion on what fractional rese= rve actually is. I=E2=80=99d 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 frac= tional reserve is moot unless it can be shown that the assumed utility actua= lly exists. So I suggest we take this interesting but secondary question on f= ractional reserve somewhere else. > The idea to return to full reserve banking is not unique to gold bugs or B= itcoin but recently a popular vote was initiated in Switzerland to force Swi= ss 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 n= ot trivial as also our exchange shows. It shows the breadth of economic ignorance which is not surprising given its= counterintuitive nature. Best, Eric > I published today a writing in medium, that explains the concept of fracti= onal vs. full reserve banking in conjunction with this proposal. Please read= : https://medium.com/@tamas.blummer/full-reserve-banking-with-bitcoin-462b21= ae9479 >=20 > I would welcome feedback on the generalized covenant construct or its impl= ementation, as I think it can open up much more uses than the few examples I= gave. >=20 > Tamas Blummer >=20 > [1] Vollgeld Initiative: https://www.bfs.admin.ch/bfs/de/home/statistiken/= politik/abstimmungen/jahr-2018/2018-06-10/vollgeld-initiative.html >=20 >> On Jun 28, 2019, at 19:25, Eric Voskuil wrote: >>=20 >> Hi Tamas, >>=20 >> There are a number of economic assumptions contained herein. While I unde= rstand you would like to focus on implementation, the worst bugs are require= ments bugs. IMO these should be addressed first. I=E2=80=99ve addressed some= possible issues inline. >>=20 >>> On Jun 28, 2019, at 01:27, Tamas Blummer via bitcoin-dev wrote: >>>=20 >>> I start with a formalisation of loans as common in finance: >>>=20 >>> A zero bond is a contract between two parties Alice and Bob whereby Alic= e 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 (>>=20 >>> The inherent risk in the contract is that Alice may not honor the agreem= ent or be bankrupt by then. >>>=20 >>> If we could programmatically guarantee that Alice honors the contract th= en we would be able to create a riskless zero bond, the fundation of financi= al engineering. >>=20 >> I=E2=80=99m not aware of the basis of this statement. While people use th= e term =E2=80=9Crisk free rate of return=E2=80=9D there has never actually b= een such a thing. It=E2=80=99s not clear to me how a unicorn has been the fo= undation of =E2=80=9Cfinancial engineering=E2=80=9D, but I=E2=80=99m not als= o clear and what is intended by =E2=80=9Cengineering=E2=80=9D in this sense.= Generally engineering is the implementation of higher level concepts. It is= those concepts that constitute requirements here. >>=20 >> At a minimum, interest cannot be guaranteed by this proposal, which impli= es that at best it guarantees, setting aside changes in purchasing power, a r= eturn of principle minus economic interest on that principle (ie opportunity= cost). Given that purchasing power changes over time, risk increases with t= he term of the loan. As such this is not riskless - both volatility and oppo= rtunity cost remain as risks. >>=20 >>> A systemic problem with loans is that the lender might operate on fracti= onal reserve, that is lending more than his capital. >>=20 >> This is not a systemic problem, this is the very nature of lending. Fract= ional reserve is simply a state banking term used to describe the fact that p= eople invest (lend) a fraction of their savings and hoard the rest. It matte= rs not that banks or individuals do this, credit expansion is inherent in ec= onomy. Without it there is no investment and therefore no production whatsoe= ver. >>=20 >>> Unchecked inflation of money supply through fractional reserve is creati= ng a mess in the world we live in. Bitcoin could overcome this mess implemen= ting this proposal! >>=20 >> You seem to be conflating state banking with the effects of investing. Ta= xpayer support for bank investment creates both a moral hazard (and the resu= lting misallocation of capital to state-favored projects, creating the famed= economic =E2=80=9Cbusiness cycle=E2=80=9D) and is a manifestation of persis= tent monetary inflation (ie seigniorage is a source taxation. Investment imp= lies credit expansion, and the level of this expansion is controlled by time= preference alone. >>=20 >>> I stop here with finance speak as the purpose of this mail is not to div= e into finance, but to show how loans with full reserve check could be imple= mented in Bitcoin. >>>=20 >>> 1. Receiving the loan is a payment from Bob to Alice, but we need a rest= riction how Alice can use the funds, so Bob can get them back unconditionall= y at maturity, so lending is riskless to him. >>> 2. Bob wants to receive interest, since he gives up his control of the c= oins 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. >>=20 >> Interest cannot be paid in advance. This implies nothing more than a smal= ler amount of principle. >>=20 >>> How do we allow Alice to use the coins, that is: split/merge and transfe= r them to others, but still ensure Bob can claim them back at maturity? >>>=20 >>> We ensure that Alice can only send the coins to outputs that inherit a t= aproot path of validation (using http://bitcoin.sipa.be/miniscript/): 'and(t= ime(100),pk(C))' where C is Bob=E2=80=99s key and 100 is maturity >>>=20 >>> This requires a generalization of the Bitcoin Covenants Idea[1] such tha= t it nicely fits with taproot as follows: >>>=20 >>> 1. A covenant in the form of '_ covenant C=E2=80=99 on output means that= it can be spent to an output that maches the covenant pattern with placehol= der _ and the output(s) will be assigned 'covenant C'. >>> 2. A covenant that mandates an output script with alternate validation p= aths can also assign alternate covernants to be inherited by the output(s) d= epending on which path was used to spend the input eg. 'covenant or(c covena= nt C, d covernant D)=E2=80=99 >>> 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=E2=80=99 which means t= he output will have the same covenant as the input >>> 5. allow to omit covenant on the output with 'covenant drop' >>>=20 >>> The covenant Bob would assign to the loan output sent to Alice is: 'cove= nant or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)' which m= eans: >>> - Alice can send to an output script where she is free to chose the embe= dded script at the placeholder _ and that output will again have the same co= venant as the input. >>> - After maturity Bob can claim any coin that is transitively rooted in t= he loan (more on this later) and the covenant will no longer be assigned to h= is new output(s). >>>=20 >>> Assuming Alice wants to send some of the borrowed coins to Charlie: >>>=20 >>> for shorter notation lets use b=3D'and(time(100),pk(Bob)) covenant drop=E2= =80=99 for the script that gives Bob control after maturity. >>>=20 >>> 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(Charli= e) covenant transitive) is a promissory note issued by Alice to Charlie, her= e is why: >>>=20 >>> 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 befor= e maturity, since that output is worthless to Charlie after maturity as Bob c= an just take it. >>>=20 >>> It seems at the first sight that there is no value in these outputs for C= harlie, since he still has to ensure Alice replaces them before maturity. >>>=20 >>> The value of these outputs to Charlie is the proof that he has exclusive= control of the coins until maturity. >>=20 >> At a minimum, money that predictably depreciates (to zero in this case) m= ust be discounted accordingly. How much is money worth today that is worth z= ero tomorrow? This can be observed with both inflation and demurrage money. T= his also implies that each encumbered coin is not fungible with any other of= a distinct discount schedule. >>=20 >> What is the economic consequence of lending discounted money? Lower inter= est rates. How much lower? The rate of depreciation. This can also be observ= ed with inflation and demurrage, but observation isn=E2=80=99t required. Thi= s is a necessary outcome. >>=20 >> 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 crea= tes credit expansion and reduces return in direct proportion to the risk tha= t has been offset. In other words, the risk cost has been converted to oppor= tunity cost. The discounted fraction earns no interest. >>=20 >> So credit expansion and risk remain, in the same proportions as without s= uch a system. However lack of fungibility introduces an additional overhead c= ost. >>=20 >> e >>=20 >>> 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, w= hich also reduces the credit risk Charlie takes. >>>=20 >>> Due to the transitive covenant Charlie could pass on the coins to an oth= er temporary owner until maturity when Bob would re-collect them uncondition= ally. >>>=20 >>> Should Charlie no longer be comfortable with Alice=E2=80=99s promise or n= eed final coins (cash) immediatelly, then he could turn to Dan and do a re-p= urchase (repo) agreement with him. >>>=20 >>> Charlie would receive final coins from Dan in exchange for the temporari= ly controled coins and Charlie's promise to replace them with final coins be= fore maturity. >>> Dan would thereby charge high interest through a discount since as he ha= s to bear the credit risk of Charlie. This is not a riskless but a plain zer= o bond. >>>=20 >>> 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 coin= s, the sum of Charlie's repo deals are not in excess of his claims against o= thers. >>> This again avoids lending in excess of coin supply and reduces the credi= t risk Dan takes. >>>=20 >>> Here are the sketches for the transacions for above alternate actions: >>>=20 >>> lets use shortcut c for 'or(and(time(100),pk(Bob)) covenant drop, _ cove= nant transitive)=E2=80=99 >>>=20 >>> the transactions offer a fee of 0.0001 >>>=20 >>> Bob gives a riskless credit to Alice: >>>=20 >>> Input Output >>> 1 pk(Bob) 1 or(b,pk(Alice) covenant c) >>> 0.1 pk(Alice) 0.9999 pk(Bob) >>>=20 >>> Alice could send a 0.5 promissory note to Charlie: >>>=20 >>> 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) >>>=20 >>> 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) >>>=20 >>> alternatively Charlie borrows from Dan at high interest: >>>=20 >>> 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) >>>=20 >>> and Charlie re-purchases the temporary coins before maturity, making goo= d of the repo with Dan: >>>=20 >>> 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) >>>=20 >>> We need to define further transaction level validations for transactions= spending inputs with covenants as follows: >>>=20 >>> 1. If there are inputs without covenant before the input with covenant t= han inputs without covenant must be spent exactly with outputs preceeding th= e outputs with covenants. >>> 2. A transaction can have inputs with different covenants, their allocat= ion to outputs should follow input order. >>> 3. For output(s) that share input(s) with covenant, the sum of covenant o= utputs must exactly add up to the input(s). This allows merging and splittin= g them. >>>=20 >>> Bob would re-collect his coins at maturity unconditionally. Who followed= through promises or defaulted down the transitive chain is irrelevant to hi= m. >>> Remark: we might also need a covenant attribute defining the minimum siz= e of output, so Bob is not forced to collect dust, which would be expensive o= r even impossible. I am not yet happy with this solution, looking for better= . >>>=20 >>> 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 a= nd how covenants would be integrated with taproot. >>>=20 >>> Tamas Blummer >>>=20 >>> [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 >=20 --Apple-Mail-A6F96C51-0E07-4567-8329-BE433B666D46 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Jun 28, 2019, at 12:21, Tamas Blummer <tamas.blummer@gmail.com> wrote:<= br>
Hi Eric,=

Thank you for you= r questions as they show what concepts need further explanation, so you unde= rstand the potential of this proposal and how it is helpful to the ecosystem= .

Riskless zero bo= nd is in fact the most basic concept of financial engineering. Yes, there ar= e 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 c= urrency in the future has different value than 1 unit available now. It is c= alled riskless if it is certain to receive the payment in the future.
<= div class=3D"">If we put this difference of vaue in relation to the amount t= hen we get the =E2=80=9Crisk freee rate of return=E2=80=9D, that you heard o= f.

E.g if one is w= illing to exchange 1 BTC unconditionally available now for 1.1 BTC certainly= available in a year but not earlier, then the implied =E2=80=9Crisk free ra= te of return=E2=80=9D is apparently 10% pa. for Bitcoins.

As I implied, I am well aware of the concept of ri= sk free rate of return, which is a hypothetical.

The transaction I construct in the f= irst example achives exactly this, because:
Which implies you have created an actual instance of this hereto= fore purely hypothetical concept.

Bob forgoes his ability to use his unconditionally= available coins by giving them to Alice with a covenant that ensures that B= ob will receive them back later.
Bob does this because A= lice pays for this in advance. 

Alice can further transfer the coins encumbered by the co= venant, but they will unconditionally return to Bob in the future. 

Why would Alice pay for this at all= ?

The ut= ility of these encumbered coins is that they prove that the loan is fully co= vered by reserves.

What loan? Al= ice has paid Bob for something of no possible utility to her, or anyone else= .

Bitcoin is a money, not consumable in any way. It= s utility arises strictly from the possibility of eventually being traded fo= r something else. The only reason to accept it in trade is that expectation.= Removing that possibility, even transitively and over time, removes all uti= lity immediately. In my previous comments I described a necessary discount t= o NPV, but it=E2=80=99s safe to say that must be 100%.

<= blockquote type=3D"cite">
How valuable this u= tility is will be decided by the market

Value is of course subjective, and is determ= ined by individual preferences. Yet what is the value one might place on som= ething of no use? Economically speaking it must be zero, since value is a su= bjective evaluation of utility (i.e. service to a person).

Consider the case of the 1000 and 500 rupee d= emonetization. Long lines of people formed at banks to convert to notes to o= thers of equivalent denomination.


Of course, upon annou= ncement of the demonetization, existing 1000/500 rupee notes were discounted= for the cost/risk of accomplishing this conversion (several people are repo= rted to have died in the effort). If there was no such conversion possible, m= aking the notes worthless at the future date, the *immediate* effect would n= ecessarily have been 100% discount.

This of c= ourse sets aside any consumable value of the =E2=80=9Cpaper=E2=80=9D notes, s= uch 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 dem= onetization.

Who wou= ld 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=E2=80=99s 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 h= olding 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 w= ho temporarily give up control. I am guess the value will be low but positiv= e.

Giving up control of money fo= r a period does not imply the money is useful to someone else. Bob might as w= ell 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=E2=80=99t say that it does. L= ending implies no =E2=80=9Cmandate=E2=80=9D. But the nature of fractional re= servation is inherent in every loan/investment. 

These are choices t= he market or regulators enforce.

Fractional reserv= ation is not a consequence of statutory or market controls. The level of hoa= rding vs. lending is a consequence of individual time preference.
Full reserv= e banking is not a fiction but is how things worked before introduction of g= old receipts. A bank could only lend gold coins it possesed. Perils of fract= ional reserve were felt repeatedly by the Bitcoin ecnomy e.g. in the collaps= of MtGox.

I don=E2=80=99t belie= ve I called full reserve a fiction. With full reserve there is no possible i= nvestment, production or products. Unlikely, and disastrous for humanity, bu= t not provably impossible.

A hazard of viewing econ= omic concepts through a financial lens is that those higher order concepts b= ecome obscured by a morass of economically-irrelevant regulation and impleme= ntation details.

At this point we are going to end u= p in a discussion on what fractional reserve actually is. I=E2=80=99d be hap= py to have a discussion on the topic, but this list is clearly not a good fo= rum for that.

Furthermore the question of whether o= r not this proposal is relevant to fractional reserve is moot unless it can b= e shown that the assumed utility actually exists. So I suggest we take this i= nteresting but secondary question on fractional reserve somewhere else.

T= he idea to return to full reserve banking is not unique to gold bugs or Bitc= oin but recently a popular vote was initiated in Switzerland to force Swiss b= anks to full reserves with respect to lending. This popular vote achived &nb= sp;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 g= iven its counterintuitive nature.

Best,
E= ric

I pu= blished today a writing in medium, that explains the concept of fractional v= s. full reserve banking in conjunction with this proposal. Please read: = ;https://medium.com/@tamas.blummer/full-reserve-= banking-with-bitcoin-462b21ae9479

I would welcome feedback on the generalized covenant con= struct or its implementation, as I think it can open up much more uses than t= he 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

On Jun 28, 2= 019, at 19:25, Eric Voskuil <eric@voskuil.org> wrote:

Hi Tamas,

There are a numb= er of economic assumptions contained herein. While I understand you would li= ke to focus on implementation, the worst bugs are requirements bugs. IMO the= se should be addressed first. I=E2=80=99ve addressed some possible issues in= line.
On Jun 28, 2019, at 01:27, T= amas Blummer via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote= :

I start with a formalisation of loans as comm= on in finance:

A zero bond is a contract betwee= n 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 d= ifference between the amount received and P is the interest implied by the c= ontract. E.g. receiving 1 Bitcoin (<P) and agree to pay back 1.1 (=3DP) i= n 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 hono= r the agreement or be bankrupt by then.

If we c= ould programmatically guarantee that Alice honors the contract then we would= be able to create a riskless zero bond, the fundation of financial engineer= ing.

I=E2=80=99m not aware of the bas= is of this statement. While people use the term =E2=80=9Crisk free rate of r= eturn=E2=80=9D there has never actually been such a thing. It=E2=80=99s not c= lear to me how a unicorn has been the foundation of =E2=80=9Cfinancial engin= eering=E2=80=9D, but I=E2=80=99m not also clear and what is intended by =E2=80= =9Cengineering=E2=80=9D in this sense. Generally engineering is the implemen= tation of higher level concepts. It is those concepts that constitute requir= ements here.

At a minimum, interest cannot be guaranteed by this proposal, w= hich implies that at best it guarantees, setting aside changes in purchasing= power, a return of principle minus economic interest on that principle (ie o= pportunity cost). Given that purchasing power changes over time, risk increa= ses with the term of the loan. As such this is not riskless - both volatilit= y and opportunity cost remain as risks.

A systemic problem with loans is that the lender might operate on fra= ctional reserve, that is lending more than his capital.

This is not a systemic problem, this is the very nature o= f lending. Fractional reserve is simply a state banking term used to describ= e the fact that people invest (lend) a fraction of their savings and hoard t= he rest. It matters not that banks or individuals do this, credit expansion i= s inherent in economy. Without it there is no investment and therefore no pr= oduction whatsoever.

Unchecked i= nflation of money supply through fractional reserve is creating a mess in th= e world we live in. Bitcoin could overcome this mess implementing this propo= sal!

You seem to be conflating state b= anking with the effects of investing. Taxpayer support for bank investment c= reates both a moral hazard (and the resulting misallocation of capital to st= ate-favored projects, creating the famed economic =E2=80=9Cbusiness cycle=E2= =80=9D) and is a manifestation of persistent monetary inflation (ie seignior= age 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 thi= s mail is not to dive into finance, but to show how loans with full reserve c= heck could be implemented in Bitcoin.

1. Receiv= ing the loan is a payment from Bob to Alice, but we need a restriction how A= lice can use the funds, so Bob can get them back unconditionally at maturity= , so lending is riskless to him.
2. Bob wants to receive inter= est, since he gives up his control of the coins until maturity, he can not u= se them elsewhere until then. That interest could be paid in advance, this c= an be solved with Bitcoin as is.

Int= erest cannot be paid in advance. This implies nothing more than a smaller am= ount of principle.

How do we allo= w Alice to use the coins, that is: split/merge and transfer them to others, b= ut 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=E2=80=99s key and 100 is maturity

This requires a generalization of the Bitcoin Covenants Idea[1] such t= hat it nicely fits with taproot as follows:

1. A= covenant in the form of '_ covenant C=E2=80=99 on output means that it can b= e spent to an output that maches the covenant pattern with placeholder _ &nb= sp;and the output(s) will be assigned 'covenant C'.
2. A coven= ant that mandates an output script with alternate validation paths can also a= ssign alternate covernants to be inherited by the output(s) depending on whi= ch path was used to spend the input eg. 'covenant or(c covenant C, d coverna= nt D)=E2=80=99
3. The resulting covenant of outputs should be r= educed following boolean algebra, e.g. or(b,or(b,a)) to or(b, a)
4. express transitivity with 'covenant transitive=E2=80=99 which means th= e output will have the same covenant as the input
5. allow to o= mit covenant on the output with 'covenant drop'

The covenant Bob would assign to the loan output sent to Alice is: 'covenan= t or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)' which mea= ns:
- Alice can send to an output script where she is free to c= hose the embedded script at the placeholder _ and that output will again hav= e the same covenant as the input.
- After maturity Bob can cla= im 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 C= harlie:

for shorter notation lets use b=3D'and(= time(100),pk(Bob)) covenant drop=E2=80=99 for the script that gives Bob cont= rol after maturity.

Alice can not send to pk(Ch= arlie), 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 regula= r 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 C= harlie, since he still has to ensure Alice replaces them before maturity.
The value of these outputs to Charlie is the proo= f that he has exclusive control of the coins until maturity.
<= /blockquote>
At a minimum, money that predictably depreciates (t= o 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 fun= gible with any other of a distinct discount schedule.

What is the economi= c consequence of lending discounted money? Lower interest rates. How much lo= wer? The rate of depreciation. This can also be observed with inflation and d= emurrage, but observation isn=E2=80=99t required. This is a necessary outcom= e.

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 c= reates credit expansion and reduces return in direct proportion to the risk t= hat has been offset. In other words, the risk cost has been converted to opp= ortunity cost. The discounted fraction earns no interest.

So credit expan= sion and risk remain, in the same proportions as without such a system. Howe= ver lack of fungibility introduces an additional overhead cost.

e<= br style=3D"font-family: Helvetica; font-size: 12px; font-style: normal; fon= t-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-al= ign: start; text-indent: 0px; text-transform: none; white-space: normal; wor= d-spacing: 0px; -webkit-text-stroke-width: 0px;" class=3D"">
Alice can not issue promissory notes in e= xcess of own capital or capital that she was able to borrow. No coin inflati= on or fractional reserve here, which also reduces the credit risk Charlie ta= kes.

Due to the transitive covenant Charlie cou= ld pass on the coins to an other temporary owner until maturity when Bob wou= ld re-collect them unconditionally.

Should Char= lie no longer be comfortable with Alice=E2=80=99s promise or need final coin= s (cash) immediatelly, then he could turn to Dan and do a re-purchase (repo)= agreement with him.

Charlie would receive fina= l coins from Dan in exchange for the temporarily controled coins and Charlie= 's promise to replace them with final coins before maturity.
D= an would thereby charge high interest through a discount since as he has to b= ear the credit risk of Charlie. This is not a riskless but a plain zero bond= .

Why would Dan want to take temporary control o= f the coins at all? Again, to ensure Charlie is not doing yet another repo w= ith Frank on the same coins, the sum of Charlie's repo deals are not in exce= ss of his claims against others.
This again avoids lending in e= xcess of coin supply and reduces the credit risk Dan takes.
Here are the sketches for the transacions for above alternate a= ctions:

lets use shortcut c for 'or(and(time(10= 0),pk(Bob)) covenant drop, _ covenant transitive)=E2=80=99
the transactions offer a fee of 0.0001

Bob gives a riskless credit to Alice:

Input &= nbsp;          Output
1 pk(Bob)        1 or(b,pk(Alic= e) covenant c)
0.1 pk(Alice)      &nb= sp; 0.9999 pk(Bob)

Alice could send a 0.5 p= romissory note to Charlie:

Input   &n= bsp;            =     Output
1 or(pk(Alice) covenant c) &nbs= p;      0.5 or(b,pk(Charlie) covenant c)
1 pk(Alice)          &= nbsp;     0.5 or(b,pk(Alice) covenant c)
            &= nbsp;     0.9999 pk(Alice)

Alice could make good of the note before maturity, pay some interest and g= et back temporary control of the coins with:
Input   = ;            &nb= sp;        Output
0.5 o= r(b,pk(Charlie) covenant c)        0.5 or= (b,pk(Alice) covenant c)
0.5101 pk(Alice)    &n= bsp;           0.51 p= k(Charlie)

alternatively Charlie borrows from D= an at high interest:

Input    &n= bsp;            =        Output
0.5 or(b,pk(C= harlie) covenant c)        0.5 or(b,pk(Da= n) covenant c)
0.3001 pk(Dan)      &n= bsp;         0.3 pk(Charlie)
and Charlie re-purchases the temporary coins befo= re maturity, making good of the repo with Dan:

= Input            &nbs= p;            &n= bsp;  Output
0.5 or(b,pk(Dan) covenant c)  &nbs= p;         0.5 or(b,pk(Charlie)= covenant c)
0.5001 pk(Charlie)      =             &nbs= p; 0.5 pk(Dan)

We need to define further t= ransaction level validations for transactions spending inputs with covenants= as follows:

1. If there are inputs without cov= enant before the input with covenant than inputs without covenant must be sp= ent exactly with outputs preceeding the outputs with covenants.
2. A transaction can have inputs with different covenants, their allocatio= n to outputs should follow input order.
3. For output(s) that s= hare 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 fo= llowed through promises or defaulted down the transitive chain is irrelevant= to him.
Remark: we might also need a covenant attribute defin= ing the minimum size of output, so Bob is not forced to collect dust, which w= ould be expensive or even impossible. I am not yet happy with this solution,= looking for better.

I am very excited about th= e possibilities this proposal would unlock and ask you verify usefulness of t= his scheme and join working out the details and how covenants would be integ= rated with taproot.

Tamas Blummer

[1] Malte Moser, Ittay Eyal, and Emin Gun Sirer. Bitcoin Cov= enants. URL: http://fc16.ifca.ai/bitcoin/papers/MES16.pdf
__________= _____________________________________
bitcoin-dev mailing list=
bitcoin-dev@lists.linuxfoundation.org
htt= ps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
=

= --Apple-Mail-A6F96C51-0E07-4567-8329-BE433B666D46--