path: root/7c/8f57e4278cc466897a1c3d5ef7f5d941318b68

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A858CC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 03:40:23 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id 8D0CC8819C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 03:40:23 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id BZZ7ityYyGoU
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 03:40:21 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch
 [185.70.40.140])
 by whitealder.osuosl.org (Postfix) with ESMTPS id DE9C88816A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 03:40:20 +0000 (UTC)
Date: Tue, 21 Jul 2020 03:40:07 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1595302817;
 bh=jAU4WV8TUxzOWOmy6luSSRdvupJIyR9sFqsVX6ePzlc=;
 h=Date:To:From:Reply-To:Subject:From;
 b=dVjb6q3Scxkm+ElBkAu+jVb5vGaXIpt8jM+YkQLam9yjhUeibGL1JOOXMcvsTnby3
 V5ixobwTi+m09mHvivRecqwaj6r1jif6YkUMErhkA9OlRlL6cHJzH0fdND3mDJi2im
 7Zy4HysmU1NV7xVocJKaGCJzX5uJPa5sQBqHyLys=
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <C9lZg-0PorjwUrbc9BcSqEC5pwsX7VUpu6dGI9xE7vHuAExyQoL0j9j_DBWOYYpIwQly5PvpLBdu5j9REv16Z0hpJe9Sw7mlFjEpozHpowg=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: [bitcoin-dev] Implementing Investment Aggregation
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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: Tue, 21 Jul 2020 03:40:23 -0000

Introduction
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In a capitalist economic system, it is allowed for an entity to lend money =
out to another entity, as long as both agree upon the conditions of the loa=
n: how long, how much interest, any collateral, etc.
This is a simple extension of basic capitalist economic thinking: that the =
owner of funds or other capital, is the one who should decide how to utiliz=
e (or not utilize) that capital, including the decision to lend (or not len=
d).

It has been observed as well that groups of people may have relatively smal=
l savings that they can afford to put into investment (i.e. loaning out for=
 an interest rate), but as the technological capabilities of our shared civ=
ilization have expanded, the required capital to create new businesses or e=
xpand existing ones have grown much larger than most single individuals can=
 invest in.

Thus, coordinators that aggregate the savings of multiple individuals, and =
then lend them out for interest to new or expanding businesses, have also a=
risen, in order to take advantage of the larger return-on-investment of mor=
e capital-intensive but high-technology businesses, capturing the long tail=
 of small investors.
Traditionally, we call these coordinators "banks".

However, this typically involves delegating the work of judging whether a b=
usiness proposal is likely to give a return on investment, or not, to the c=
oordinator itself.
Further, the coordinator typically acts as a custodian of the funds, thus a=
dding the risk of custodial default to the small-time investors in addition=
 to loan default.
(In this view-point, central banks that provide fiscal insurance in case of=
 loan default by printing new money, are no different from custodial defaul=
t, as they degrade the monetary base in doing so.)

This writeup proposes the use of features that we expect to deploy at some =
point in the future, to allow for a non-custodial coordinator of multiple s=
mall investors.

This is not a decentralized system, as there is a coordinator; however, as =
the coordinator is non-custodial, and takes on the risk of default as well,=
 the risk is reduced relative to a centralized custodial solution.

Note that custodiality is probably a much bigger risk than centralization, =
and a centralized non-custodial probably has fewer risks than a decentraliz=
ed custodial setup.
In particular, a decentralized custodial setup can be emulated by a central=
ized custodial setup using sockpuppets, and without any decent sybil protec=
tion (which can be too expensive and price out investments by the long tail=
 of small investors, thus leading to centralization amongst a few large inv=
estors anyway), is likely no better than a centralized custodial setup.
Focusing on non-custodiality rather than decentralization may be a better o=
ption in general.

A group of small investors may very well elect a coordinator, and since eac=
h investor remains in control of its funds until it is transferred to the l=
endee, the coordinator has no special power beyond what it has as one of th=
e small investors anyway, thus keeping decentralization in spirit if not in=
 form.

Non-custodial Investment Aggregation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

In principle, if a small investor finds a potentially-lucrative business th=
at needs capital to start or expand its operation, and promises to return t=
he loaned capital with interest later, then that small investor need not st=
ore its money with anyone else: it could just deal with the business itself=
 directly.

However, the small investor still needs to determine, for itself, whether t=
he business is expected to be lucrative, and that the expected return on in=
vestment is positive (i.e. the probability of non-default times (1 plus int=
erest rate) is greater than 1, and the absolute probability of non-default =
fits its risk profile).
We will not attempt to fix this problem here, only the requirement (as with=
 the current banking system) to trust some bank **in addition to** trusting=
 the businesses that are taking on loans to start/expand their business.

(again: not your keys not your coins applies, as always; investors are taki=
ng on risk of default.)

The coordinator need only do something as simple as find a sufficiently lar=
ge set of entities that are willing to indicate their Bitcoin UTXOs as bein=
g earmarked for investment in a particular business.

The coordinator, upon finding such a set, can then create a transaction spe=
nding those UTXOs and paying unilaterally to the business taking the loan.
The business provides proof that the destination address is under its unila=
teral control (so that investors know that they only need to trust that the=
 business itself will do everything in its power to succeed and pay back th=
e loan, without having additional trust in the coordinator to hold their fu=
nds in custody).
Then the individual investors sign the transaction, releasing their funds t=
o the business.

However, the issue now arises: suppose the business succeeds and is able to=
 pay back its loan.
How does the business pay back the loan?

Thus, prior to the investors ever signing the loan-out transaction, they fi=
rst prepare a loan-payback transaction.
This loan-payback transaction spends from a multisignature of all the inves=
tors, equal in value to the loan amount plus agreed-upon interest, and dist=
ributes the money to each of the involved investors.
Crucially, this loan-payback transaction is signed with a `SIGHASH_ANYPREVO=
UT` signature.

Now, in order for the business to pay back its loan, it only needs to gathe=
r enough Bitcoins to pay back the loan, and pay back the exact amount to th=
e multisignature address of the investors.
Then, any of the investors can reclaim their funds, plus interest, by re-an=
choring the loan-payback transaction to this transaction output and broadca=
sting it.

The coordinator, for its services, may extract a fee from the loan-payback =
transaction that all the investors can agree to; thus, it takes on as well =
the risk of default by the business (the coordinator exerts effort to locat=
e investors and encourage them to invest, and would lose the fee paid for i=
ts efforts if the business it is proposing as a good investment does not pa=
y back), which seems appropriate if it also serves as a basic filter agains=
t bad business investments.
Finally, by working in Bitcoin, it cannot have a lender of last resort, and=
 thus must evaluate possible business investments as accurately as possible=
 (as default risks its fee earnings).

(investors also need to consider the possibility that the purported "busine=
ss" is really a sockpuppet of the coordinator; the investors should also ev=
aluate this when considering whether to invest in the business or not, as p=
art of risk of default.)

(the above risk is mitigated somewhat if the investors identify the busines=
s first, then elect a coordinator to handle all the "paperwork" (txes, tran=
sporting signatures/PSBTs, etc.) by drawing lots.)

Thus, ***if*** the business is actually able to pay back its loan, the coor=
dinator is never in custodial possession of funds.

Cross-business Aggregation
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D

Nothing in the above setup really changes if the investors would prefer to =
spread their risk by investing sub-sections of their savings into multiple =
different businesses.
This gives somewhat lower expected returns, but gives some protection again=
st complete loss, allowing individual investors to adjust their risk exposu=
re and their desired expected returns.

The batch transaction that aggregates the allocated UTXOs of the investors =
can pay out to multiple borrowing businesses.
And each business can be given a loan-payback address, which is controlled =
by the investors that extended their loans.
Investors generate an aggregate loan-payback transaction and signature for =
each business they invest in.

Collateralized Loans
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

As observed in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020=
-July/018053.html, a Cryptographic Relay would allow collateralized loans.

Nothing prevents the "loan shark" in the collateralized loan example from b=
eing a MuSig of multiple small investors.
Practically, a coordinator would help facilitate construction of the necess=
ary transactions and interaction with the loanee, but as long as ownership =
remains controlled by the individual investors, there should not be any cus=
todial issues.

Of course, if the loan defaults, then the collateral needs to be sold in or=
der to recoup the loss incurred in loan default case.
Coordinating this sale amongst the multiple small investors is now potentia=
lly harder.

An additional service may be willing to pre-allocate Bitcoin funds into a t=
imelocked contract, where the amount can be claimed conditional on transfer=
 of the ownership of the collateral to the service in the future, or if the=
 fund is not so claimed, to be returned to the service with the collateral =
not claimed (as it might have been reclaimed by the loaner after successful=
ly paying back its loan).
This additional service earns by arbitraging the time preference: in case o=
f default, the investors would prefer to recoup their financial losses quic=
kly, while the service is now in possession of the collateral that it can r=
esell later at a higher rate.

Note that these are all operations that traditional banks perform; again, t=
his idea simply removes the necessity for custodial holding of funds, in th=
e way traditional banks do.