Date: Sun, 17 Sep 2023 00:52:13 +0000
To: Anthony Towns <aj@erisian.com.au>
From: jlspc <jlspc@protonmail.com>
Message-ID: <RMoe8oOf6WIwX0yhB-A6-d8Zy5gf56thrD-gkIP5fdSzuR0EjpQo2fMY6FFYz-roCgsY2j0MgQnaF17U0RsUSTkqIRMuhOMjH0LqGlME4wg=@protonmail.com>
In-Reply-To: <ZP5lyA9CCUf138ve@erisian.com.au>
References: <vUfA21-18moEP9UiwbWvzpwxxn83yJQ0J4YsnzK4iQGieArfWPpIZblsVs1yxEs9NBpqoMBISuufMsckbuWXZE1qkzXkf36oJKfwDVqQ2as=@protonmail.com>
 <ZP5lyA9CCUf138ve@erisian.com.au>
Feedback-ID: 36436663:user:proton
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>,
 "lightning-dev@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Scaling Lightning With Simple
	Covenants
Precedence: list


Hi aj,

I completely agree with your observation that there's an important trust/sa=
fety vs. capital-efficiency tradeoff, and I almost completely agree with yo=
ur analysis.

> (There are probably ways around this with additional complexity: eg,
> you could peer with a dedicated node, and have the timeout path be
> "you+them+timeout", so that while you could steal from casual users who
> don't rollover, you can't steal from your dedicated peer, so that $4.5B
> could be rolled into a channel with them, and used for routing)

Yes, that would work, but I think it's better to have dedicated user B pair=
 with another dedicated user C such that each leaf of the timeout-tree fund=
s a hierarchical channel [1] of the
form (A_i, (B, C)), where A_i is a casual user.
If A_i performs an active rollover, all funds not owned by A_i can *always*=
 be used by B and C to route payments that are unrelated to the casual user=
s in the timeout-tree (including both before and after A_i's funds are drai=
ned).
This idea was described in the "Improving Capital Efficiency" section of th=
e post.

Passive rollovers complicate this, as A_i's funds are neither definitely in=
 the old timeout-tree or in the new timeout-tree during the rollover.
However, if one is willing to take on the complexity, it's possible to use =
*your* (very cool!) idea of funding an HTLC from one of two possible source=
s, where one of those sources is guaranteed to eventually be available (but=
 the offerer and offeree of the HTLC don't know which one will be available=
 to them) [2][3].
In this case, B and C could use the funds from the old and the new timeout-=
trees that are not owned by A_i to route payments.
If A_i puts the leaf in the old timeout-tree on-chain, B and C use funds fr=
om the new timeout-tree to fund their HTLC (and vice-versa).

Even if hierarchical channels are used to improve the capital efficiency, I=
 think the "thundering herd" problem is a big concern.
This could play out very poorly in practice, as casual users would gain exp=
erience with ever larger timeout-trees and not have any problems.
Then, suddenly, a large number of dedicated users collude by failing to rol=
l-over timeout-trees at the same time, and they create enough congestion on=
 the blockchain that they're able to steal a large fraction of the casual u=
sers' funds.

I have a proposed change to the Bitcoin consensus rules that I think could =
address this problem.
Basically, rather than have timeout-trees expire at a given block height, t=
hey should expire only after a sufficient number of low-fee blocks have bee=
n added to the blockchain after some given block height.
As a result, if dedicated users colluded and tried to steal funds by not ro=
lling-over a group of timeout-trees, the thundering herd of transactions fr=
om casual users would push up the fees enough to prevent the timeout-trees =
from expiring, thus safeguarding the casual user's funds.
In fact, the impact to the dedicated users (in addition to their loss of re=
putation) would be that their capital would be unavailable to them for a lo=
nger period of time.
Thus, this should be effective in deterring dedicated users from attempting=
 such a theft.
On the other hand, when the dedicated users do roll-over funds correctly, t=
here is no delay in the old timeout-trees' expiries, and thus better capita=
l efficiency.

There are lots of details to the idea and I'm currently in the process of w=
riting a paper and post describing it.
A couple more quick details:
* rather than counting low-fee blocks, time is measured in low-fee windows,=
 where the size of the window is programmable (this makes it much harder fo=
r dishonest miners to collude with the dedicated users by creating enough f=
ake low-fee blocks, not containing the casual users' higher-fee timeout-tre=
e transactions, to enabe the theft; it also reduces the compute cost for co=
unting the low-fee windows),
* the threshold for a "low-fee" block is programmable,
* there is a bound on how long one keeps waiting for low-fee windows (in or=
der to bound the storage and compute overheads), and
* a similar technique supports relative, rather than absolute, delays.

I think such a mechanism is likely to be useful in many areas, including HT=
LCs, but that timeout-trees really highlight the need for something like th=
is.

Regards,
John

[1] Law, "Resizing Lightning Channels Off-Chain With Hierarchical Channels"=
, https://github.com/JohnLaw2/ln-hierarchical-channels
[2] Towns, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Cha=
nnels", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-Apri=
l/003913.html
[3] Law, "Re: Resizing Lightning Channels Off-Chain With Hierarchical Chann=
els", https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/=
003917.html


Sent with Proton Mail secure email.