Date: Sat, 19 Feb 2022 01:17:20 +0000
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <3ev2Zqf5SyEHMQvtRbaTBnP8wADZPis-2YvawQr0k6vM4ftjlggJhQHRup44LkMtaoCTUF6EWm5FC86xuMFxOtb7Di7KQza8k4rn5Xs96Hw=@protonmail.com>
In-Reply-To: <CAD5xwhh9JHE0QAfRMeKs7w=L-GB5DaEomsQ0aH4ibSDi9Oe8Rg@mail.gmail.com>
References: <6nZ-SkxvJLrOCOIdUtLOsdnl94DoX_NHY0uwZ7sw78t24FQ33QJlJU95W7Sk1ja5EFic5a3yql14MLmSAYFZvLGBS4lDUJfr8ut9hdB7GD4=@protonmail.com>
 <CALZpt+Ee9kuVjpXYgOb_7dB7Yr8HYmicdRhfgXsQkey2szNDHg@mail.gmail.com>
 <0mhhHzTun8dpIcLda1CLFihMsgLoWQUEE8woKUKhf_UHYps2w7jVzbJAUJ302kQEB1ZdvMfakP9IBUHLM8bGns-pg0NHmpuak3yjpphjJnw=@protonmail.com>
 <CAD5xwhh9JHE0QAfRMeKs7w=L-GB5DaEomsQ0aH4ibSDi9Oe8Rg@mail.gmail.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`
Precedence: list

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