📅 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 and the complexity of implementing them.
📝 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.
jlspc [ARCHIVE] /
npub1rm…w5exr
2023-09-19 12:19:29
in reply to nevent1q…6rr4
Author Public Key
npub1rmlhmgvxk3p6kv9dgr9tpccm8uh9hejycjm5wag033fvhtpn0jqslw5exrPublished at
2023-09-19 12:19:29Event JSON
{
"id": "df5bc9586d572ab28ca2dcb9e7294607437b22eea48d186c577a820a68843bf4",
"pubkey": "1eff7da186b443ab30ad40cab0e31b3f2e5be644c4b747750f8c52cbac337c81",
"created_at": 1695118769,
"kind": 1,
"tags": [
[
"e",
"d705225603124a2ef60fcdc827f38d6df484d447ef207fd791c9af052939f94a",
"",
"root"
],
[
"e",
"ae055e0ab75585759438cc838359dfd1d18981ba52073f09dc9fbb8882cf0939",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2023-09-16\n🗒️ Summary of this message: The paper presents some interesting ideas, but there are concerns about the increased cost of enforcement and the complexity of implementing them.\n📝 Original message:\nHi Rusty,\n\n\u003e I've read the start of the paper on my vacation, and am still\n\u003e digesting it. But even so far, it presents some delightful\n\u003e possibilities.\n\nGreat!\n\n\u003e As with some other proposals, it's worth noting that the cost of\n\u003e enforcement is dramatically increased. It's no longer one or two txs,\n\u003e it's 10+. If the \"dedicated user\" contributes some part of the expected\n\u003e fee, the capital efficiency is reduced (and we're back to \"how much is\n\u003e enough?\").\n\nYes, this is certainly an issue, and it affects both settling the channel on-chain and resolving HTLCS on-chain.\nThe paper has a few ideas about how \"short-cut\" transactions could be used to address the cost of enforcing HTLCs on-chain.\nIt 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.\n\n\u003e But worst case (dramatic dedicated user failure) it's only a 2x penalty\n\u003e on number of onchain txs, which seems acceptable if the network is\n\u003e sufficiently mature that these failure events are rare.\n\n\u003e Note also that the (surprisingly common!) \"user goes away\" case where\n\u003e the casual user fails to rollover only returns funds to the dedicated\n\u003e user; relying on legal and normal custody policies in this case may be\n\u003e preferable to an eternal burden on the UTXO set with the current\n\u003e approach!\n\nAgreed.\n\nThanks,\nJohn\n\n\u003e Thankyou!\n\u003e Rusty.\n\n\n\n\n\nSent with Proton Mail secure email.",
"sig": "464bb630cd5294c6fc5693ee1106cdfd424a435a2bb3551fcca48d2817bf82b1014c5cb22a94f88b8add2d54874b774a9a6de005589270a0d79a0e3a36955dba"
}