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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
