path: root/1a/a940d07c79f0c45799c2d8752371de9e7a03e8

Return-Path: <tamas.blummer@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C87C5AB5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Jun 2019 08:27:18 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com
	[209.85.128.49])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 75A7982D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Jun 2019 08:27:17 +0000 (UTC)
Received: by mail-wm1-f49.google.com with SMTP id s15so8084440wmj.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 28 Jun 2019 01:27:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=from:mime-version:subject:message-id:date:cc:to;
	bh=uTTBRo9vewaUDg43dDMvHuMc7n84Abay6kK9qfAW+js=;
	b=HXg5sS+cat2DUUmghC24GFvC6xuNORbDdfKlq5eVYxMWKBtwDcYb8TFuqJieyUM/JC
	PKBTYu4Rhfi9CbKKt3VquD4um/YhX80+EkaDrHJDN/lkZ8m+8fEk3fEvHw/QHfD+v3IU
	bJwAkIVlNblNvJu01h4GHDVNwtaw/BfvAff+0Yh/re4yuRpnkeaHW9LgagqxWecrqhPM
	yn9ri1rIIqg12RfSRMuz9g5NGnx/T7P29G6Y7+I7L76iXL0NNSh9Zrrj/QPIXxz8hsj+
	XGcULX+U89nZIaX/av0tc/4uKvu+PRQeYQmTBKgbsjylEslHlCkzbCdc4tdbxybmBXS2
	VAkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to;
	bh=uTTBRo9vewaUDg43dDMvHuMc7n84Abay6kK9qfAW+js=;
	b=FRpI62N6MC/fVUUCt69g/5o0+7ookFAMX9VMlPGwuZaBLH26irMxR1vs4g1m0h3kSo
	5W1e2+srqWU7y8lojxcFciMKZfwnyubSUZcpk/p1Nx7YLdUETHvLRMf22rMlqrhZZy5U
	8CNoc/6Yl/C+KbAvuBVvrQmfPXJAiq9LV5BBDRSX3ySmDKqNBbC3hT6Izahh7zMnIRxT
	/yjqKyKwcJkmkuDy9AIDRrXsOghkmNcZ7H1eL8YhUwpgo3ldt53/gfh/W7LCk6/ZgB0V
	iVIs0jqHY3hmMGpYrnTBEZj+Dl2iKhoPkLfWrKjXnH0uMDgJjWPeGzbd8WT3miFK21L+
	F5ZA==
X-Gm-Message-State: APjAAAXiUxVRV//nFegi7favKTFTso/boV3YvIl2E8bQ32MoP/L6oW8P
	m+qy5gGzMMJLAJTE2nNVcThM5/P+
X-Google-Smtp-Source: APXvYqw/7mpgrtUm6kjwQsL7ieTwfwUln0YBCViZzQIdOotVRyRreuz1eCif8TM1n9Tps7jaS4Sffg==
X-Received: by 2002:a7b:c776:: with SMTP id x22mr6176165wmk.55.1561710435786; 
	Fri, 28 Jun 2019 01:27:15 -0700 (PDT)
Received: from p200300dd671264584dc4aa4447d14cc6.dip0.t-ipconnect.de
	(p200300DD671264584DC4AA4447D14CC6.dip0.t-ipconnect.de.
	[2003:dd:6712:6458:4dc4:aa44:47d1:4cc6])
	by smtp.gmail.com with ESMTPSA id f2sm1702305wrq.48.2019.06.28.01.27.14
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 28 Jun 2019 01:27:14 -0700 (PDT)
From: Tamas Blummer <tamas.blummer@gmail.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_65DC987B-9B21-44EC-B8D8-31084D187076";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com>
Date: Fri, 28 Jun 2019 10:27:16 +0200
To: bitcoin-dev@lists.linuxfoundation.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,
	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 14:41:40 +0000
Cc: Gregory Maxwell <greg@xiph.org>, Pieter Wuille <pieter.wuille@gmail.com>
Subject: [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 08:27:18 -0000


--Apple-Mail=_65DC987B-9B21-44EC-B8D8-31084D187076
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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.

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

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!

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.

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.
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

the transactions offer a fee of 0.0001

Bob gives a riskless credit to Alice:

Input			Output
1 pk(Bob) 		1 or(b,pk(Alice) covenant c)
0.1 pk(Alice)		0.9999 pk(Bob)

Alice could send a 0.5 promissory note to Charlie:

Input					Output
1 or(pk(Alice) covenant c)		0.5 or(b,pk(Charlie) covenant c)
1 pk(Alice)				0.5 or(b,pk(Alice) covenant c)
					0.9999 pk(Alice)

Alice could make good of the note before maturity, pay some interest and =
get back temporary control of the coins with:
Input						Output
0.5 or(b,pk(Charlie) covenant c)		0.5 or(b,pk(Alice) =
covenant c)
0.5101 pk(Alice)				0.51 pk(Charlie)

alternatively Charlie borrows from Dan at high interest:

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

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

Input							Output
0.5 or(b,pk(Dan) covenant c)			0.5 or(b,pk(Charlie) =
covenant c)
0.5001 pk(Charlie)					0.5 pk(Dan)

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

1. If there are inputs without covenant before the input with covenant =
than inputs without covenant must be spent exactly with outputs =
preceeding the outputs with covenants.
2. A transaction can have inputs with different covenants, their =
allocation to outputs should follow input order.
3. For output(s) that share input(s) with covenant, the sum of covenant =
outputs must exactly add up to the input(s). This allows merging and =
splitting them.

Bob would re-collect his coins at maturity unconditionally. Who followed =
through promises or defaulted down the transitive chain is irrelevant to =
him.
Remark: we might also need a covenant attribute defining the minimum =
size of output, so Bob is not forced to collect dust, which would be =
expensive or even impossible. I am not yet happy with this solution, =
looking for better.

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

Tamas Blummer

[1] Malte Moser, Ittay Eyal, and Emin Gun Sirer. Bitcoin Covenants. URL: =
http://fc16.ifca.ai/bitcoin/papers/MES16.pdf

--Apple-Mail=_65DC987B-9B21-44EC-B8D8-31084D187076
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-----

iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl0Vz2QACgkQ9nKRxRdx
ORxfrgf9EvdBhaTOs2j7s7GXFbuAXcXxI0PvezJ2bei+lVdCstp7aEJ+UTYL2TI7
kc1R7pVird6ZpNRu0Fcxc2A91aTebOMyu9Sj8d09adqIHKntcm7JqI2C+xtV1pHM
3mUXx68CfyWyXxBIh/9lUmTBB06hCPiGQdIoHm3XynJJ+91c964EcPHBW4/gqCZM
65MLpE1GhF5C3Xf3HfmwZOXICAvuia1XIa9axXv+mfQJWLrr+VHVd2VYSEXCkM2i
IQrjlwt3SwiEwW5acWkpyd6tLd6/fz4BCre3MhKxXlt4OrK3je1YkJWIS5DkE8U/
cijaUvRRS93NaBR3zIL7RJJvexrhzA==
=eL9h
-----END PGP SIGNATURE-----

--Apple-Mail=_65DC987B-9B21-44EC-B8D8-31084D187076--