Hi aj,

I completely agree with your observation that there's an important trust/safety 
vs. capital-efficiency tradeoff, and I almost completely agree with your 
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 funds 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 users in the 
timeout-tree (including both before and after A_i's funds are drained).
This idea was described in the "Improving Capital Efficiency" section of the 
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 sources, 
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 from 
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 
experience with ever larger timeout-trees and not have any problems.
Then, suddenly, a large number of dedicated users collude by failing to 
roll-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 users' 
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, they 
should expire only after a sufficient number of low-fee blocks have been added 
to the blockchain after some given block height.
As a result, if dedicated users colluded and tried to steal funds by not 
rolling-over a group of timeout-trees, the thundering herd of transactions from 
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 
reputation) would be that their capital would be unavailable to them for a 
longer 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, there 
is no delay in the old timeout-trees' expiries, and thus better capital 
efficiency.

There are lots of details to the idea and I'm currently in the process of 
writing 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 for 
dishonest miners to collude with the dedicated users by creating enough fake 
low-fee blocks, not containing the casual users' higher-fee timeout-tree 
transactions, to enabe the theft; it also reduces the compute cost for counting 
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 order 
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 HTLCs, 
but that timeout-trees really highlight the need for something like this.

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 
Channels", 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003913.html
[3] Law, "Re: Resizing Lightning Channels Off-Chain With Hierarchical 
Channels", 
https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003917.html




Sent with Proton Mail secure email.


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to