path: root/86/9156646ffa2a6da3e2309cff5fb64fabdaa2a7

Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7234ECB6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Jun 2019 17:25:25 +0000 (UTC)
Received: by mail-pg1-f173.google.com with SMTP id 196so2880554pgc.6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <eric@voskuil.org>
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 <tamas.blummer@gmail.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <greg@xiph.org>, Pieter Wuille <pieter.wuille@gmail.com>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@list=
s.linuxfoundation.org> 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 (<P) and agree to pay back 1.1 (=3D=
P) in a year is the same as getting a loan with 10% p.a. interest.
>=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