path: root/13/f6c3beb1fdb2858285e98d65887c749159b059

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 57574C016F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 16:28:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id 462DA84DE6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 16:28:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id x4HY0Jh6Cbh9
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 16:28:08 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40130.protonmail.ch (mail-40130.protonmail.ch
 [185.70.40.130])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id 4C1EA84DD4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Tue, 21 Jul 2020 16:28:08 +0000 (UTC)
Date: Tue, 21 Jul 2020 16:28:03 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail; t=1595348885;
 bh=2qFqVBSmJK8urLve23T0LPsBj7oqPsOk8WefMsdewe8=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From;
 b=NkqfFMTHP9zsPdysjEz1lbAElzxNkoUG/0ALX2g6PHldnfEZ/arhzYOt9rFLKdKMD
 WX1NRsuIBZAW7H/9jf+X4GKW/7Dfrw4KclHYocy58aBQ3dRSNBVBC7EsG0Wpixc6mO
 GU4arVBzjcx5oMfEY4QnEPY6YyJ3cDipLcbaeRS8=
To: esnierde <hildawithin@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <iHBPUP8IZxNlW4YIBROzUqCEQmXqJXAHWZ4pRPXXdE0nEW0B1iXzBYj_GC1NbpRhg0AZtsCSsPPVyALhkzkchT9648OETfrqjGZ0Tu_rzFM=@protonmail.com>
In-Reply-To: <CALPTSC7s7UJuLLTmnmNHuudgGgM2TAE9mnL-9p311CEyK3hTvQ@mail.gmail.com>
References: <C9lZg-0PorjwUrbc9BcSqEC5pwsX7VUpu6dGI9xE7vHuAExyQoL0j9j_DBWOYYpIwQly5PvpLBdu5j9REv16Z0hpJe9Sw7mlFjEpozHpowg=@protonmail.com>
 <CALPTSC7s7UJuLLTmnmNHuudgGgM2TAE9mnL-9p311CEyK3hTvQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 16:28:10 -0000

Good morning Hilda,

> Good Day ZmnSCPxj,
>
> Thanks for sharing the=C2=A0idea! I read through the=C2=A0doc and have so=
me concerns that might be off the topic or outside the scope. Please bear w=
ith me.
>
> The traditional banking system provides more than custodial holding of fu=
nds in terms of lending & borrowing. One important function is to match lon=
g term investments with short or variable term deposits. Alice might be wil=
ling to make investments at time 0, but some emergency occurs and she may n=
eed (part of) her bitcoins back at time 1 before the loan due=C2=A0date.=
=C2=A0

This may be possible by using a Decker-Russell-Osuntokun ("eltoo") mechanis=
m.

The laon-payback transaction (the one that is signed with `SIGHASH_ANYPREVO=
UT`) can, instead of paying out directly to the investors, pay out to a Dec=
ker-Russell-Osuntokun mechanism that is signed by a MuSig of the investors =
plus the coordinator.

The initial state of this mechanism is the payouts of each investor, in pro=
portion to the amounts they lent out.
Thus, if none of the investors need to liquidate early, this initial state =
is what gets posted on the blockchain ***if*** the loaning business success=
fully pays back / does not default.

If one of the investors needs to liquidate its position in this loan agreem=
ent, the coordinator can offer to buy its position (in whole or in part) fo=
r a smaller amount (as the coordinator takes on more risk).
Then all the investors plus the coordinator sign a new state of the Decker-=
Russell-Osuntokun mechanism, with the coordinator getting more funds, and t=
he liquidating investor losing all or part of its allocation.
The investor doing the liquidation can demand a pay-for-signature, so that =
its signature share of the new state is only acquired by the coordinator if=
 and only if it actually gets paid with Bitcoins now.

The position need not be bought by the coordinator --- one of the other sma=
ll investors in the business can "double down" and purchase more of the sha=
re of the eventual loan-payback by the same mechanism, from peer investors =
who need to liquidate their position in the loan-payback early, increasing =
its risk exposure but potentially getting even more profit in case the inve=
sted business pays back the loan.


>
> Also, in the banking system, there are usually sophisticated risk analysi=
s systems covering formulas, due diligence, and funds for loan defaults. Ba=
nks can reinvest partial of what they namely have and obtain profits to cov=
er possible losses when borrowers cannot pay back 100%. In this way, they a=
re 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 i=
nstead of 1.=C2=A0

Similar constructions could be done by the coordinator and / or the investo=
rs directly; unfortunately I know too little of them to give an idea how th=
is can be done.

Regards,
ZmnSCPxj