path: root/98/b3a181102491c7fec87d3b05c6cb04f5cac430

Return-Path: <hildawithin@gmail.com>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id B8BBEC016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 05:23:14 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by whitealder.osuosl.org (Postfix) with ESMTP id A7189884BB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 05:23:14 +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 c3WDfmSjVWU1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 05:23:12 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-oi1-f181.google.com (mail-oi1-f181.google.com
 [209.85.167.181])
 by whitealder.osuosl.org (Postfix) with ESMTPS id 97C65884A3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 05:23:12 +0000 (UTC)
Received: by mail-oi1-f181.google.com with SMTP id k22so16286430oib.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 20 Jul 2020 22:23:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
 bh=cYJ3JpLxFCmuxWoI3zVQkER+WdYcqVDGo3tI2oi/9VM=;
 b=MGaPRXjA9n5hOE58H6KSLczUhukkTRi/Xq0uDJRx5rZ9UyYGfdjJ8UPxloycjhcv/q
 SDBFr7pV8fiLuG3HVsgzyUMYYFlMNcv8VyQucRL2Z48dvUUBqrSJwwKj8lOspe0eTF2S
 eWHu7B2PA41LDbv/psrFpBEytWb6ZDcNU/MtKYGTUeRkKnESmz1rY7eTbIphRHY/SYWu
 tSvZQnQMrGU4stAhG17oWoUgAn8EhpSxLiy8FZ7Qs62FLTPlI7vELlu3rz7d/GR4kTPY
 jcZGPz5q6Br6i8ppqB3cYsm7rXtAMv1CX+51r04sRp/Mj6737EoDsD4N/aj5d/N+8/Ej
 WSoQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20161025;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to;
 bh=cYJ3JpLxFCmuxWoI3zVQkER+WdYcqVDGo3tI2oi/9VM=;
 b=ZJAVNWQlAm4ucPQLab6mqUAg1HWDmwmkIZbazPjd7dW3Inz2oQcayVpFqd7uOrf95I
 yTEmHeisSoSZ5wr8W2xeat/1QxGCEGWQh8++6aWNkTWUGrfJBoUyodQqSyvUKAhjFrbj
 rph3vTztyQsl6lwAjqYafTmbHlEX2LSloO72WlDhsfg6uM8R2chIwvpXNxbvgJlHm+NE
 +Xxdf+mZ9ubnmifDGCOjbOIjNn23SMTr7O7OG1jnA3FbCQkXQfCwyJKeJO+jMYoce5+j
 plhukis1TzlScxf3AI/53DQCEV3zO/5DwZb2q2zFVdFspa4XzLRvP5rqdQuSkFK3If4x
 yPww==
X-Gm-Message-State: AOAM532sJd+kkU2L98rAzQ2mrNkobWABhjbG3CWg3MkHRrA6Gul+Z+3S
 ph0l4L4boprNdlYmRedmIWWnsAO/ZFhKfrH5EOE=
X-Google-Smtp-Source: ABdhPJwi8NJoOZjBMsXX4yWYDkIsJm8THTS3Gfs7BMreDVk822Qmk13PGjNCqkqy/ZIgewDCyT88nCX5X8AcrN10FPY=
X-Received: by 2002:aca:53cc:: with SMTP id h195mr1855815oib.49.1595308991670; 
 Mon, 20 Jul 2020 22:23:11 -0700 (PDT)
MIME-Version: 1.0
References: <C9lZg-0PorjwUrbc9BcSqEC5pwsX7VUpu6dGI9xE7vHuAExyQoL0j9j_DBWOYYpIwQly5PvpLBdu5j9REv16Z0hpJe9Sw7mlFjEpozHpowg=@protonmail.com>
In-Reply-To: <C9lZg-0PorjwUrbc9BcSqEC5pwsX7VUpu6dGI9xE7vHuAExyQoL0j9j_DBWOYYpIwQly5PvpLBdu5j9REv16Z0hpJe9Sw7mlFjEpozHpowg=@protonmail.com>
From: esnierde <hildawithin@gmail.com>
Date: Tue, 21 Jul 2020 01:23:00 -0400
Message-ID: <CALPTSC7s7UJuLLTmnmNHuudgGgM2TAE9mnL-9p311CEyK3hTvQ@mail.gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000c16c4305aaecd10b"
X-Mailman-Approved-At: Tue, 21 Jul 2020 06:36:02 +0000
Subject: Re: [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 05:23:14 -0000

--000000000000c16c4305aaecd10b
Content-Type: text/plain; charset="UTF-8"

Good Day ZmnSCPxj,

Thanks for sharing the idea! I read through the doc and have some concerns
that might be off the topic or outside the scope. Please bear with me.

The traditional banking system provides more than custodial holding of
funds in terms of lending & borrowing. One important function is to match
long term investments with short or variable term deposits. Alice might be
willing to make investments at time 0, but some emergency occurs and she
may need (part of) her bitcoins back at time 1 before the loan due date.

Also, in the banking system, there are usually sophisticated risk analysis
systems covering formulas, due diligence, and funds for loan defaults.
Banks can reinvest partial of what they namely have and obtain profits to
cover possible losses when borrowers cannot pay back 100%. In this way,
they are more resilient to defaults & change of collaterals' value, and
borrowers might be able to leverage 1 unit worth of collateral to get 3
units fund instead of 1.

Thank you,
Hilda

On Mon, 20 Jul 2020 at 23:40, ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Introduction
> ============
>
> 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
> loan: 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
> utilize (or not utilize) that capital, including the decision to lend (or
> not lend).
>
> It has been observed as well that groups of people may have relatively
> small 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
> civilization have expanded, the required capital to create new businesses
> or expand 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
> arisen, in order to take advantage of the larger return-on-investment of
> more 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
> business proposal is likely to give a return on investment, or not, to the
> coordinator itself.
> Further, the coordinator typically acts as a custodian of the funds, thus
> adding 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
> default, 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
> small 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
> decentralized custodial setup.
> In particular, a decentralized custodial setup can be emulated by a
> centralized custodial setup using sockpuppets, and without any decent sybil
> protection (which can be too expensive and price out investments by the
> long tail of small investors, thus leading to centralization amongst a few
> large investors anyway), is likely no better than a centralized custodial
> setup.
> Focusing on non-custodiality rather than decentralization may be a better
> option in general.
>
> A group of small investors may very well elect a coordinator, and since
> each investor remains in control of its funds until it is transferred to
> the lendee, the coordinator has no special power beyond what it has as one
> of the small investors anyway, thus keeping decentralization in spirit if
> not in form.
>
> Non-custodial Investment Aggregation
> ====================================
>
> In principle, if a small investor finds a potentially-lucrative business
> that needs capital to start or expand its operation, and promises to return
> the loaned capital with interest later, then that small investor need not
> store 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
> the business is expected to be lucrative, and that the expected return on
> investment is positive (i.e. the probability of non-default times (1 plus
> interest 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
> taking on risk of default.)
>
> The coordinator need only do something as simple as find a sufficiently
> large set of entities that are willing to indicate their Bitcoin UTXOs as
> being earmarked for investment in a particular business.
>
> The coordinator, upon finding such a set, can then create a transaction
> spending those UTXOs and paying unilaterally to the business taking the
> loan.
> The business provides proof that the destination address is under its
> unilateral 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 the loan, without having additional trust in the coordinator to hold
> their funds in custody).
> Then the individual investors sign the transaction, releasing their funds
> to 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
> first prepare a loan-payback transaction.
> This loan-payback transaction spends from a multisignature of all the
> investors, equal in value to the loan amount plus agreed-upon interest, and
> distributes the money to each of the involved investors.
> Crucially, this loan-payback transaction is signed with a
> `SIGHASH_ANYPREVOUT` signature.
>
> Now, in order for the business to pay back its loan, it only needs to
> gather enough Bitcoins to pay back the loan, and pay back the exact amount
> to the multisignature address of the investors.
> Then, any of the investors can reclaim their funds, plus interest, by
> re-anchoring the loan-payback transaction to this transaction output and
> broadcasting 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
> locate investors and encourage them to invest, and would lose the fee paid
> for its efforts if the business it is proposing as a good investment does
> not pay back), which seems appropriate if it also serves as a basic filter
> against 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
> "business" is really a sockpuppet of the coordinator; the investors should
> also evaluate this when considering whether to invest in the business or
> not, as part of risk of default.)
>
> (the above risk is mitigated somewhat if the investors identify the
> business first, then elect a coordinator to handle all the "paperwork"
> (txes, transporting signatures/PSBTs, etc.) by drawing lots.)
>
> Thus, ***if*** the business is actually able to pay back its loan, the
> coordinator is never in custodial possession of funds.
>
> Cross-business Aggregation
> ==========================
>
> 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
> against complete loss, allowing individual investors to adjust their risk
> exposure 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
> ====================
>
> 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
> being a MuSig of multiple small investors.
> Practically, a coordinator would help facilitate construction of the
> necessary transactions and interaction with the loanee, but as long as
> ownership remains controlled by the individual investors, there should not
> be any custodial issues.
>
> Of course, if the loan defaults, then the collateral needs to be sold in
> order to recoup the loss incurred in loan default case.
> Coordinating this sale amongst the multiple small investors is now
> potentially harder.
>
> An additional service may be willing to pre-allocate Bitcoin funds into a
> timelocked 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
> successfully paying back its loan).
> This additional service earns by arbitraging the time preference: in case
> of default, the investors would prefer to recoup their financial losses
> quickly, while the service is now in possession of the collateral that it
> can resell later at a higher rate.
>
> Note that these are all operations that traditional banks perform; again,
> this idea simply removes the necessity for custodial holding of funds, in
> the way traditional banks do.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000c16c4305aaecd10b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Good Day ZmnSCPxj,<div><br></div><div>Thanks for sharing t=
he=C2=A0idea! I read through the=C2=A0doc and have some concerns that might=
 be off the topic or outside the scope. Please bear with me.<br><div><br></=
div><div>The traditional banking system provides more than custodial holdin=
g of funds in terms of lending &amp; borrowing. One important function is t=
o match long term investments with short or variable term deposits. Alice m=
ight be willing to make investments at time 0, but some emergency occurs an=
d she may need (part of) her bitcoins back at time 1 before the loan due=C2=
=A0date.=C2=A0</div><div><br></div><div>Also, in the banking system, there =
are usually sophisticated risk analysis systems covering formulas, due dili=
gence, and funds for loan defaults. Banks can reinvest partial of what they=
 namely have and obtain profits to cover possible losses when borrowers can=
not pay back 100%. In this way, they are more resilient to defaults &amp; c=
hange of collaterals&#39; value, and borrowers might be able to leverage 1 =
unit worth of collateral to get 3 units fund instead of 1.=C2=A0</div></div=
><div><br></div><div>Thank you,</div><div>Hilda</div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, 20 Jul 2020 =
at 23:40, ZmnSCPxj via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.=
linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.or=
g</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-lef=
t-color:rgb(204,204,204);padding-left:1ex">Introduction<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
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.<br>
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).<br>
<br>
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.<br>
<br>
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.<br>
Traditionally, we call these coordinators &quot;banks&quot;.<br>
<br>
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.<br>
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.<br>
(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.)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
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.<br>
Focusing on non-custodiality rather than decentralization may be a better o=
ption in general.<br>
<br>
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.<br>
<br>
Non-custodial Investment Aggregation<br>
=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<br>
<br>
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.<br>
<br>
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).<br>
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.<br=
>
<br>
(again: not your keys not your coins applies, as always; investors are taki=
ng on risk of default.)<br>
<br>
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.<br>
<br>
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.<=
br>
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).<br>
Then the individual investors sign the transaction, releasing their funds t=
o the business.<br>
<br>
However, the issue now arises: suppose the business succeeds and is able to=
 pay back its loan.<br>
How does the business pay back the loan?<br>
<br>
Thus, prior to the investors ever signing the loan-out transaction, they fi=
rst prepare a loan-payback transaction.<br>
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.<br>
Crucially, this loan-payback transaction is signed with a `SIGHASH_ANYPREVO=
UT` signature.<br>
<br>
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.<br>
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.<br>
<br>
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.<br>
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).<br>
<br>
(investors also need to consider the possibility that the purported &quot;b=
usiness&quot; is really a sockpuppet of the coordinator; the investors shou=
ld also evaluate this when considering whether to invest in the business or=
 not, as part of risk of default.)<br>
<br>
(the above risk is mitigated somewhat if the investors identify the busines=
s first, then elect a coordinator to handle all the &quot;paperwork&quot; (=
txes, transporting signatures/PSBTs, etc.) by drawing lots.)<br>
<br>
Thus, ***if*** the business is actually able to pay back its loan, the coor=
dinator is never in custodial possession of funds.<br>
<br>
Cross-business Aggregation<br>
=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<br>
<br>
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.<br>
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.<br>
<br>
The batch transaction that aggregates the allocated UTXOs of the investors =
can pay out to multiple borrowing businesses.<br>
And each business can be given a loan-payback address, which is controlled =
by the investors that extended their loans.<br>
Investors generate an aggregate loan-payback transaction and signature for =
each business they invest in.<br>
<br>
Collateralized Loans<br>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<br>
<br>
As observed in <a href=3D"https://lists.linuxfoundation.org/pipermail/bitco=
in-dev/2020-July/018053.html" rel=3D"noreferrer" target=3D"_blank">https://=
lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-July/018053.html</a>, =
a Cryptographic Relay would allow collateralized loans.<br>
<br>
Nothing prevents the &quot;loan shark&quot; in the collateralized loan exam=
ple from being a MuSig of multiple small investors.<br>
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.<br>
<br>
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.<br>
Coordinating this sale amongst the multiple small investors is now potentia=
lly harder.<br>
<br>
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).<br>
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.<br>
<br>
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.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000c16c4305aaecd10b--