ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2022-02-18 📝 Original message:Good morning Jeremy, > ...

📅 Original date posted:2022-02-18
📝 Original message:Good morning Jeremy,

> This is a fascinating post and I'm still chewing on it.
>
> Chiming in with two points:
>
> Point 1, note with respect to evictions, revivals, CTV, TLUV:
>
> CTV enables 1 person to be evicted in O(log N) or one person to leave in O(log N). TLUV enables 1 person to leave in O(1) O(log N) transactions, but evictions take (AFAICT?) O(N) O(log N) transactions because the un-live party stays in the pool. Hence OP_EVICT helps also make it so you can kick someone out, rather than all having to leave, which is an improvement.
>
> CTV rejoins work as follows:
>
> suppose you have a pool with 1 failure, you need to do log N txns to evict the failure, which creates R * log_R(N) outputs, which can then do a transaction to rejoin.
>
> For example, suppose I had 64 people in a radix 4 tree. you'd have at the top level 4 groups of 16, then 4 groups of 4 people, and then 1 to 4 txns. Kicking 1 person out would make you do 3 txns, and create 12 outputs total. A transaction spending the 11 outputs that are live would capture 63 people back into the tree, and with CISA would not be terribly expensive. To be a bit more economical, you might prefer to just join the 3 outputs with 16 people in it, and yield 48 people in one pool. Alternatively, you can lazily re-join if fees make it worth it/piggybacking another transaction, or operate independently or try to find new, better, peers.
>
> Overall this is the type of application that necessitates *exact* byte counting. Oftentimes things with CTV seem inefficient, but when you crunch the numbers it turns out not to be so terrible. OP_EVICT seems promising in this regard compared to TLUV or accumulators.
>
> Another option is to randomize the CTV trees with multiple outputs per party (radix Q), then you need to do Q times the evictions, but you end up with sub-pools that contain more people/fractional liquidity (this might happen naturally if CTV Pools have channels in them, so it's good to model).

Do note that a weakness of CTV is that you *have to* split up the CoinPool into many smaller pools, and re-merging them requires waiting for onchain confirmation.
This overall means you have no real incentive to revive the original CoinPool minus evicted parties.
`OP_EVICT` lets the CoinPool revival be made into the same transaction that performs the evict.

> Point 2, on Eltoo:
>
> One point of discomfort I have with Eltoo that I think is not universal, but is shared by some others, is that non-punitive channels may not be good for high-value channels as you do want, especially in a congested blockspace world, punishments to incentivize correct behavior (otherwise cheating may look like a free option).
>
> Thus I'm reluctant to fully embrace designs which do not permit nested traditional punitive channels in favor of Eltoo, when Eltoo might not have product-market-fit for higher valued channels.
>
> If someone had a punitive-eltoo variant that would ameliorate this concern almost entirely.

Unfortunately, it seems the way to any kind of N > 2 construction *with* penalty would require bonds, such as the recent PathCoin idea (which is an N > 2 construction *with* penalty, and is definitely offchain for much of its operation).

Having a Decker-Russell-Osuntokun "factory" layer that hosts multiple Poon-Dryja channels is not quite a solution; if old state on Decker-Russell-Osuntokun layer pushes through, then its obsolete Poon-Dryja channels will have all states invalid and unclaimable, but in case of Sybil where some participants are sockpuppets, it would still be possible for a thief to claim the funds from an "invalidated" Poon-Dryja channel if that channel is with a sockpuppet.


Regards,
ZmnSCPxj