Tamas Blummer [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-28 📝 Original message:I start with a ...

📅 Original date posted:2019-06-28
📝 Original message: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 (=P) 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’s 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’ 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)’
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’ 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='and(time(100),pk(Bob)) covenant drop’ 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’s 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)’

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190628/25fe4569/attachment-0001.sig>;