From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6244AC000B for ; Sat, 19 Feb 2022 01:17:31 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 5441260B20 for ; Sat, 19 Feb 2022 01:17:31 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gka9860VNovR for ; Sat, 19 Feb 2022 01:17:30 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) by smtp3.osuosl.org (Postfix) with ESMTPS id E08F560ACA for ; Sat, 19 Feb 2022 01:17:28 +0000 (UTC) Date: Sat, 19 Feb 2022 01:17:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1645233445; bh=U0TZB46+Lc9PsdF8SObGjQ6CAeYrY+K+ropWtcA+R48=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: From:To:Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID; b=jlgwQQFGKB3Tp5joKpyf7D5r3eAmnrPmRI3thpjTov+m6XkKvBOHtlWHW/NSKW4u3 oUCxOWbSE9Yc9SUgMj3+zi5CTxu7s/7xuZmTysNbQLpF7m99kZhdIUvdijHoeQrHJP Ujs4PB8+nk3VBEFC1dkTudpotczLxkNSW1SGRI9tdJweU+HwWCEZYaGt7ha1XMzLok 4FaFPmh5q906krEm82JzPT9b16Qmt4x5buzoyozZ75amOY1XT47YwNV25TjUkOEN3X B+G0FOuzM34vGO8uJzx3Jtr9H03Km6cPn2oswvO6DXwa4sS1JTIR8HJNli6BEVBLJO Ea9oOzGuwkA4g== To: Jeremy Rubin , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <3ev2Zqf5SyEHMQvtRbaTBnP8wADZPis-2YvawQr0k6vM4ftjlggJhQHRup44LkMtaoCTUF6EWm5FC86xuMFxOtb7Di7KQza8k4rn5Xs96Hw=@protonmail.com> In-Reply-To: References: <6nZ-SkxvJLrOCOIdUtLOsdnl94DoX_NHY0uwZ7sw78t24FQ33QJlJU95W7Sk1ja5EFic5a3yql14MLmSAYFZvLGBS4lDUJfr8ut9hdB7GD4=@protonmail.com> <0mhhHzTun8dpIcLda1CLFihMsgLoWQUEE8woKUKhf_UHYps2w7jVzbJAUJ302kQEB1ZdvMfakP9IBUHLM8bGns-pg0NHmpuak3yjpphjJnw=@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY` X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2022 01:17:31 -0000 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 pa= rty stays in the pool. Hence OP_EVICT helps also make it so you can kick so= meone 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 evic= t the failure, which creates R * log_R(N) outputs, which can then do a tran= saction 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 peop= le 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 lazi= ly re-join if fees make it worth it/piggybacking another transaction, or op= erate independently or try to find new, better, peers. > > Overall this is the type of application that necessitates *exact* byte co= unting. Oftentimes things with CTV seem inefficient, but when you crunch th= e numbers=C2=A0it 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 pa= rty (radix Q), then you need to do Q times the evictions, but you end up wi= th sub-pools that contain more people/fractional liquidity (this might happ= en 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 c= onfirmation. This overall means you have no real incentive to revive the original CoinPo= ol 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 blockspa= ce world, punishments to incentivize correct behavior (otherwise cheating m= ay look like a free option). > > Thus I'm reluctant to fully embrace designs which do not permit nested tr= aditional punitive channels in favor of Eltoo, when Eltoo might not have pr= oduct-market-fit for higher valued channels. > > If someone had a punitive-eltoo variant that would ameliorate this concer= n almost entirely. Unfortunately, it seems the way to any kind of N > 2 construction *with* pe= nalty 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-Osun= tokun layer pushes through, then its obsolete Poon-Dryja channels will have= all states invalid and unclaimable, but in case of Sybil where some partic= ipants 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 s= ockpuppet. Regards, ZmnSCPxj