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 7234ECB6 for ; Fri, 28 Jun 2019 17:25:26 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5430B13A for ; Fri, 28 Jun 2019 17:25:25 +0000 (UTC) Received: by mail-pg1-f173.google.com with SMTP id 196so2880554pgc.6 for ; Fri, 28 Jun 2019 10:25:25 -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=Xh6R6TbJib3qnbK/FDiXDjZEdhk37g1ttAiJ3ftURi0=; b=XOe7r7QI0SksvOB5upKaa5UCX2OlF7JVfzwHN/C5UV2E4Tg1wG2SAG117FKWGbwp6g wlggOBfy1hkaqD3CcWKTT5rJhyHH3EaaqkWEWA513k9V7c0lOPVfBS7T485WEfALBQgL HtZtWQ+sFUb3GJpO9C1thhBK9e9/tJ3YDYWvkfVsfNPkWH++tQcO0a5FtQzohtSFFtf/ 3NvTHSVbGpnTU+VfdOdsfhlD0V7xp6CkICfPW/pAavNJWLNFFSCaNCjf6xnoS/37+L/s P7BLVaWEg1A7ofNCuz9jNlOqmOUSDeltueZ4eGboBvT5D0D8AWb7RLFdTZRC/ntje9k/ BR/g== 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=Xh6R6TbJib3qnbK/FDiXDjZEdhk37g1ttAiJ3ftURi0=; b=n8NgLjaKYf7gi96aW/jwOUqNymaJKES8m26Z+w/sYomRiA7Bsi0Ra+4xtxP6iPgukz UQpnybTK/6VzUOZXCjA3UwPJJUVVS709WGWdX/nfctbWX2pfCxgwFPlGqUX1oeLiFYZ0 yV/aBR23VNg3CZOGvtnGT9542pPQrLwBkX7pOEHVMAxvLmyrCSm7ahG2Q/FI0uhr1hTs SXLQPWoM5TXu1e0+LpbHtmDi1t07bKcPT20JaGsufc0aE/2ss2IsImqu7ityYFB+iJvu qrUcAEDiuLRzhzArmdo3IWBY729uhLceNP8uOW0cTdq2rjcsaEEPUbt+WifqaxbjalfX pZiA== X-Gm-Message-State: APjAAAXLQnCxZRz4WzsAA5qA1qk6qxhLM2XSdTH/zvWGD/BZeqymuobg HT7qMR3GPx8TIduMA2Be4FIKLsWNaeA= X-Google-Smtp-Source: APXvYqyk2t8rvxmgwUUPY8W09KLUGPhXTsXHEYth4sftln5dKDDVC4EkgUj9E3Z1UHl0kRiZXOf0ag== X-Received: by 2002:a17:90a:8a15:: with SMTP id w21mr14647442pjn.134.1561742724597; Fri, 28 Jun 2019 10:25:24 -0700 (PDT) Received: from ?IPv6:2600:380:7060:c704:b823:cf89:56e2:ec68? ([2600:380:7060:c704:b823:cf89:56e2:ec68]) by smtp.gmail.com with ESMTPSA id w22sm2778254pfi.175.2019.06.28.10.25.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jun 2019 10:25:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (16F203) In-Reply-To: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com> Date: Fri, 28 Jun 2019 10:25:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7A10C0F5-E206-43C1-853F-64AE04F57711@voskuil.org> References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com> To: Tamas Blummer , Bitcoin Protocol Discussion X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, 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: Gregory Maxwell , Pieter Wuille 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 17:25:26 -0000 Hi Tamas, There are a number of economic assumptions contained herein. While I underst= and you would like to focus on implementation, the worst bugs are requiremen= ts bugs. IMO these should be addressed first. I=E2=80=99ve addressed some po= ssible issues inline. > 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 r= eceives an amount less than P and has to pay back P at a later time point ca= lled maturity. > The difference between the amount received and P is the interest implied b= y the contract. E.g. receiving 1 Bitcoin (=20 > The inherent risk in the contract is that Alice may not honor the agreemen= t 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. I=E2=80=99m not aware of the basis of this statement. While people use the t= erm =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 found= ation of =E2=80=9Cfinancial engineering=E2=80=9D, but I=E2=80=99m not also c= lear and what is intended by =E2=80=9Cengineering=E2=80=9D in this sense. Ge= nerally engineering is the implementation of higher level concepts. It is th= ose concepts that constitute requirements here. At a minimum, interest cannot be guaranteed by this proposal, which implies t= hat at best it guarantees, setting aside changes in purchasing power, a retu= rn of principle minus economic interest on that principle (ie opportunity co= st). Given that purchasing power changes over time, risk increases with the t= erm of the loan. As such this is not riskless - both volatility and opportun= ity cost remain as risks. > A systemic problem with loans is that the lender might operate on fraction= al reserve, that is lending more than his capital. This is not a systemic problem, this is the very nature of lending. Fraction= al reserve is simply a state banking term used to describe the fact that peo= ple 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 econ= omy. Without it there is no investment and therefore no production whatsoeve= r. > Unchecked inflation of money supply through fractional reserve is creating= a mess in the world we live in. Bitcoin could overcome this mess implementi= ng this proposal! You seem to be conflating state banking with the effects of investing. Taxpa= yer support for bank investment creates both a moral hazard (and the resulti= ng misallocation of capital to state-favored projects, creating the famed ec= onomic =E2=80=9Cbusiness cycle=E2=80=9D) and is a manifestation of persisten= t monetary inflation (ie seigniorage is a source taxation. Investment implie= s credit expansion, and the level of this expansion is controlled by time pr= eference alone. > I stop here with finance speak as the purpose of this mail is not to dive i= nto finance, but to show how loans with full reserve check could be implemen= ted in Bitcoin. >=20 > 1. Receiving the loan is a payment from Bob to Alice, but we need a restri= ction how Alice can use the funds, so Bob can get them back unconditionally a= t maturity, so lending is riskless to him. > 2. Bob wants to receive interest, since he gives up his control of the coi= ns until maturity, he can not use them elsewhere until then. That interest c= ould 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 t= hem 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 tap= root path of validation (using http://bitcoin.sipa.be/miniscript/): 'and(tim= e(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 i= t nicely fits with taproot as follows: >=20 > 1. A covenant in the form of '_ covenant C=E2=80=99 on output means that i= t can be spent to an output that maches the covenant pattern with placeholde= r _ and the output(s) will be assigned 'covenant C'. > 2. A covenant that mandates an output script with alternate validation pat= hs can also assign alternate covernants to be inherited by the output(s) dep= ending 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 a= lgebra, 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: 'covena= nt or(and(time(100),pk(Bob)) covenant drop, _ covenant transitive)' which me= ans: > - Alice can send to an output script where she is free to chose the embedd= ed script at the placeholder _ and that output will again have the same cove= nant 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 hi= s 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) c= ovenant 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 i= s why: >=20 > If Charlie accepts an or(b, pk(Charlie) covenant transitive) output then h= e trusts, that Alice will offer a regular payment in exchange for it before m= aturity, 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 Ch= arlie, 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 c= ontrol 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. Thi= s 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 w= ith 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 c= oin, one is earning interest on a fraction of a coin. That fraction creates c= redit expansion and reduces return in direct proportion to the risk that has= been offset. In other words, the risk cost has been converted to opportunit= y 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 cos= t. e > Alice can not issue promissory notes in excess of own capital or capital t= hat she was able to borrow. No coin inflation or fractional reserve here, wh= ich 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 unconditional= ly. >=20 > Should Charlie no longer be comfortable with Alice=E2=80=99s promise or ne= ed final coins (cash) immediatelly, then he could turn to Dan and do a re-pu= rchase (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 befo= re maturity. > Dan would thereby charge high interest through a discount since as he has t= o bear the credit risk of Charlie. This is not a riskless but a plain zero b= ond. >=20 > Why would Dan want to take temporary control of the coins at all? Again, t= o 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 oth= ers. > This again avoids lending in excess of coin supply and reduces the credit r= isk 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, _ covena= nt 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 g= et 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 o= f 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 s= pending inputs with covenants as follows: >=20 > 1. If there are inputs without covenant before the input with covenant tha= n inputs without covenant must be spent exactly with outputs preceeding the o= utputs 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 share input(s) with covenant, the sum of covenant ou= tputs 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 t= hrough promises or defaulted down the transitive chain is irrelevant to him.= > Remark: we might also need a covenant attribute defining the minimum size o= f output, so Bob is not forced to collect dust, which would be expensive or e= ven 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 a= sk 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: h= ttp://fc16.ifca.ai/bitcoin/papers/MES16.pdf > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev