Why Nostr? What is Njump?
2023-09-19 10:29:42
in reply to

jlspc [ARCHIVE] on Nostr: 📅 Original date posted:2023-09-16 🗒️ Summary of this message: The paper ...

📅 Original date posted:2023-09-16
🗒️ Summary of this message: The paper presents some interesting ideas, but there are concerns about the increased cost of enforcement. Short-cut transactions could help address this issue. In worst case scenarios, there may be a 2x penalty on the number of on-chain transactions. In cases where the user fails to rollover, relying on legal and custody policies may be preferable.
📝 Original message:
Hi Rusty,

> I've read the start of the paper on my vacation, and am still
> digesting it. But even so far, it presents some delightful
> possibilities.

Great!

> As with some other proposals, it's worth noting that the cost of
> enforcement is dramatically increased. It's no longer one or two txs,
> it's 10+. If the "dedicated user" contributes some part of the expected
> fee, the capital efficiency is reduced (and we're back to "how much is
> enough?").

Yes, this is certainly an issue, and it affects both settling the channel on-chain and resolving HTLCS on-chain.
The paper has a few ideas about how "short-cut" transactions could be used to address the cost of enforcing HTLCs on-chain.
It may be possible to do something similar for the channel itself, but that's more complex because of the value included in the channel and the potential for channels with different capacities in a single timeout-tree.

> But worst case (dramatic dedicated user failure) it's only a 2x penalty
> on number of onchain txs, which seems acceptable if the network is
> sufficiently mature that these failure events are rare.

> Note also that the (surprisingly common!) "user goes away" case where
> the casual user fails to rollover only returns funds to the dedicated
> user; relying on legal and normal custody policies in this case may be
> preferable to an eternal burden on the UTXO set with the current
> approach!

Agreed.

Thanks,
John

> Thankyou!
> Rusty.





Sent with Proton Mail secure email.
Author Public Key
npub1rmlhmgvxk3p6kv9dgr9tpccm8uh9hejycjm5wag033fvhtpn0jqslw5exr