From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Jeremy Rubin <jeremy.l.rubin@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] `OP_EVICT`: An Alternative to `OP_TAPLEAFUPDATEVERIFY`
Date: Sat, 19 Feb 2022 01:17:20 +0000 [thread overview]
Message-ID: <3ev2Zqf5SyEHMQvtRbaTBnP8wADZPis-2YvawQr0k6vM4ftjlggJhQHRup44LkMtaoCTUF6EWm5FC86xuMFxOtb7Di7KQza8k4rn5Xs96Hw=@protonmail.com> (raw)
In-Reply-To: <CAD5xwhh9JHE0QAfRMeKs7w=L-GB5DaEomsQ0aH4ibSDi9Oe8Rg@mail.gmail.com>
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
next prev parent reply other threads:[~2022-02-19 1:17 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-18 2:45 ZmnSCPxj
2022-02-18 13:53 ` Erik Aronesty
2022-02-18 14:48 ` ZmnSCPxj
2022-02-18 15:50 ` Erik Aronesty
2022-02-18 16:06 ` ZmnSCPxj
2022-02-18 13:55 ` Jonas Nick
2022-02-18 18:09 ` Antoine Riard
2022-02-18 23:39 ` ZmnSCPxj
2022-02-19 0:56 ` Jeremy Rubin
2022-02-19 1:17 ` ZmnSCPxj [this message]
2022-02-19 1:46 ` Greg Sanders
2022-02-19 7:21 ` Billy Tetrud
2022-02-19 11:41 ` ZmnSCPxj
2022-02-19 21:59 ` Billy Tetrud
2022-02-22 0:17 ` Antoine Riard
2022-02-23 11:42 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='3ev2Zqf5SyEHMQvtRbaTBnP8wADZPis-2YvawQr0k6vM4ftjlggJhQHRup44LkMtaoCTUF6EWm5FC86xuMFxOtb7Di7KQza8k4rn5Xs96Hw=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jeremy.l.rubin@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox