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’ve 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 (=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. I’m not aware of the basis of this statement. While people use the term “risk free rate of return” there has never actually been such a thing. It’s not clear to me how a unicorn has been the foundation of “financial engineering”, but I’m not also clear and what is intended by “engineering” 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 “business cycle”) 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’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. 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’t 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’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 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
