Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 64635C6C for ; Fri, 28 Jun 2019 19:22:02 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f67.google.com (mail-wm1-f67.google.com [209.85.128.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CB07B13A for ; Fri, 28 Jun 2019 19:21:59 +0000 (UTC) Received: by mail-wm1-f67.google.com with SMTP id a15so10121957wmj.5 for ; Fri, 28 Jun 2019 12:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=p0zULb5tlOclcNvMxOnTV1c6Wtdc+LKyFxgeIdEevn0=; b=fnU7UIWrpr5AooaeYNwsW8ZDTJBjysaPMG/24PqD0deMcL68Cwf3/piCuIU4wTBYtR vkrhyZnVeXw6B6lR9857fe3pKYrbvwqeOJd2YAE5mTorYRd7a+wBcV+aTG/WIT2ep4gq dFs4OGaG4EGjfdrQSVD5+4dAxhjOecXTwbl4TNH8H4lFs/yRLqLJyXxl6vcGJvtUZ/XA nuzJ1+dKWCnLgs30+EpFmB024vzWn4NO+WkyaPxsrf4imkG2wliaoB07BXTzUxaTWj7D X78dK9LhnhoYuMtqft4GNhwx0Chk3EX5BMZLghKCnLfXWv0HKt0NhCDyWje2p/Tj927y 2bgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=p0zULb5tlOclcNvMxOnTV1c6Wtdc+LKyFxgeIdEevn0=; b=LtzksMe8LsVBZeKuvgoya1KVvuvWOpqO2GZTGwL0dgBzENAbMTniQZz9nOU20TwfS/ cgi0CL2NBZr1EhQIgFai12a6qbGYZhyRD6TCPchAr2GxktrVLBGGp5wN8ay+YD6Jim1s PIAklk+dWg/e/eTogE1tadAOM/UpL2jXN+yJQMCiLglyH0FDbA5tmLGuqY0Z1dKAWZtv lNvHa6bGIPWBJAE5YSzuUCQuV7kQiMqhbyub0kCTpQaID/zkQ2gwurEI6c30eyfDEsOb xrPsVu6aOudMqMFRltrzsK2dCUnfuIJqusoJ7hleNMj73Xk+0RUmz7piKAhO4ICpJ/oj sL0A== X-Gm-Message-State: APjAAAXphIe0vy3jFgtCXFA04SpgI7vZEFz+VbrnXrjvcUYE7ajz7Dqz zxgrh5apH4e21y5OYyXnKcWfUObN X-Google-Smtp-Source: APXvYqyH/YUHUFVULMC+sUnVPsl5KLcmWXtQOnrb8Oi33e+Sa+YAQOBSOgeuxBKE8St6/3BaDP5bIQ== X-Received: by 2002:a1c:ac81:: with SMTP id v123mr8478701wme.145.1561749718244; Fri, 28 Jun 2019 12:21:58 -0700 (PDT) Received: from [192.168.2.105] (p4FEB9816.dip0.t-ipconnect.de. [79.235.152.22]) by smtp.gmail.com with ESMTPSA id p3sm1990257wrd.47.2019.06.28.12.21.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jun 2019 12:21:57 -0700 (PDT) From: Tamas Blummer Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_7CBDD125-87E0-48A3-8C1D-589A78C155B6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 28 Jun 2019 21:21:56 +0200 In-Reply-To: <7A10C0F5-E206-43C1-853F-64AE04F57711@voskuil.org> To: Eric Voskuil References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com> <7A10C0F5-E206-43C1-853F-64AE04F57711@voskuil.org> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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: Fri, 28 Jun 2019 20:05:14 +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: Fri, 28 Jun 2019 19:22:02 -0000 --Apple-Mail=_7CBDD125-87E0-48A3-8C1D-589A78C155B6 Content-Type: multipart/alternative; boundary="Apple-Mail=_08A88D0A-B5D2-44A0-A549-01AC73AD2B4E" --Apple-Mail=_08A88D0A-B5D2-44A0-A549-01AC73AD2B4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 =E2=80=9Crisk freee rate of return=E2=80=9D, 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 =E2=80=9Crisk free rate of return=E2=80=9D 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-462b21= ae9479 = 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 = > 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 = understand you would like to focus on implementation, the worst bugs are = requirements 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 = 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 (>=20 >> The inherent risk in the contract is that Alice may not honor the = agreement or be bankrupt by then. >>=20 >> 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. >=20 > I=E2=80=99m not aware of the basis of this statement. While people use = the term =E2=80=9Crisk free rate of return=E2=80=9D there has never = actually been such a thing. It=E2=80=99s not clear to me how a unicorn = has been the foundation of =E2=80=9Cfinancial engineering=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 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 = 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. >=20 >> A systemic problem with loans is that the lender might operate on = fractional reserve, that is lending more than his capital. >=20 > 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. >=20 >> 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! >=20 > 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 =E2=80=9Cbusiness cycle=E2=80=9D) 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. >=20 >> 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. >>=20 >> 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. >=20 > Interest cannot be paid in advance. This implies nothing more than a = smaller amount of principle. >=20 >> 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? >>=20 >> 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 >>=20 >> This requires a generalization of the Bitcoin Covenants Idea[1] such = that 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 = 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)=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 the 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: = '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). >>=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(Charlie) covenant transitive) is a promissory note issued by Alice to = Charlie, here 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 before maturity, since that output is worthless to Charlie after = maturity as Bob can just take it. >>=20 >> 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. >>=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) 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. >=20 > 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=E2=80=99t = required. This 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 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. >=20 > So credit expansion and risk remain, in the same proportions as = without such a system. However lack of fungibility introduces an = additional overhead cost. >=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, which also reduces the credit risk Charlie takes. >>=20 >> 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. >>=20 >> Should Charlie no longer be comfortable with Alice=E2=80=99s promise = or need final coins (cash) immediatelly, then he could turn to Dan and = do a re-purchase (repo) agreement with him. >>=20 >> 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. >>=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 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. >>=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, _ = covenant 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 = good 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 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. >>=20 >> 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. >>=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 and 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 = --Apple-Mail=_08A88D0A-B5D2-44A0-A549-01AC73AD2B4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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 =E2=80=9Crisk freee rate of = return=E2=80=9D, 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 =E2=80=9Crisk free rate of return=E2=80=9D= 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-bit= coin-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/abstim= mungen/jahr-2018/2018-06-10/vollgeld-initiative.html

On = Jun 28, 2019, at 19:25, Eric Voskuil <eric@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=E2=80=99ve 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 (=3DP) 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=E2=80=99m not aware of the = basis of this statement. While people use the term =E2=80=9Crisk free = rate of return=E2=80=9D there has never actually been such a thing. = It=E2=80=99s not clear to me how a unicorn has been the foundation of = =E2=80=9Cfinancial engineering=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 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 =E2=80=9Cbusiness = cycle=E2=80=9D) 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=E2=80=99s 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=E2=80=99 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)=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 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=3D'and(time(100),pk(Bob)) covenant drop=E2=80=99= 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=E2=80=99t 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=E2=80=99s 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)=E2=80=99<= br class=3D"">
the transactions offer a fee of 0.0001

Bob gives a riskless credit to Alice:

Input =            Output1 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 =             &n= bsp;      Output
1 = or(pk(Alice) covenant c)        0.5 = or(b,pk(Charlie) covenant c)
1 pk(Alice) =             &n= bsp;  0.5 or(b,pk(Alice) covenant c)
          &nb= sp;       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 =             &n= bsp;          Output
0.5 or(b,pk(Charlie) covenant c) =        0.5 or(b,pk(Alice) covenant = c)
0.5101 pk(Alice) =             &n= bsp;  0.51 pk(Charlie)

alternatively Charlie borrows from Dan at high interest:

Input =             &n= bsp;          Output
0.5 or(b,pk(Charlie) covenant c) =        0.5 or(b,pk(Dan) covenant = c)
0.3001 pk(Dan) =             &n= bsp;  0.3 pk(Charlie)

and Charlie = re-purchases the temporary coins before maturity, making good of the = repo with Dan:

Input =             &n= bsp;           &nbs= p;  Output
0.5 or(b,pk(Dan) covenant c) =            0.5 = or(b,pk(Charlie) covenant c)
0.5001 pk(Charlie) =             &n= bsp;      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<= /a>

= --Apple-Mail=_08A88D0A-B5D2-44A0-A549-01AC73AD2B4E-- --Apple-Mail=_7CBDD125-87E0-48A3-8C1D-589A78C155B6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl0WaNQACgkQ9nKRxRdx ORwzDwf+M0ArahdTue4FJ6XHmKJBzMw/SLO00htzXPTzbb0tftd11Ys0YaizPTog j4gKFdO70kY+HhrI1OJNSNUu+7HPmDhKsovQE1SDmGZR8LICB8tNuwDmTt2rx16P gUyFLM5Tgsxhpc+pH/fQHD0muR9IZmbEjqBUBVIhB0kbckUEzjV5crl/xo/UCIi1 PdLFxRF5ER6LJFI2gZq0U5EJLBVNnUHDxWsqhF+AY56VDbNRpjp1XC21PJgQgexj mP1weKcq1MINfGGIu57gb0mPm5ZTii8y0Rn/KeZUFPi3QGVnAv03zqMJy/VFzsAz Vo5iXp2KqQh/FCwCO1S9rpGtAJtmdA== =SNDL -----END PGP SIGNATURE----- --Apple-Mail=_7CBDD125-87E0-48A3-8C1D-589A78C155B6--