From: Jeremy Rubin <jeremy.l.rubin@gmail•com>
To: Bitcoin development mailing list <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] CTV Meeting Notes #3
Date: Wed, 9 Feb 2022 00:53:12 -0800 [thread overview]
Message-ID: <CAD5xwhhPp9+woDTJW8Mu+sgGP-468krH5oXGw_On0AHP2oyVfA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2855 bytes --]
Bitcoin Developers,
The Third CTV meeting was held earlier today (Tuesday February 8th, 2022).
You can find the meeting log here:
https://gnusha.org/ctv-bip-review/2022-02-08.log
A best-effort summary:
- Not much new to report on the Bounty
- Non Interactive Lightning Channel Opens
Non interactive lightning Channel opens seems to work!
There are questions around being able operate a channel in a "unipolar"
way for routing with the receiver's key offline, as HTLCs might require
sync revocation. This is orthogonal to the opening of the channels.
- DLCs w/ CTV
DLCs built with CTV does seem to be a "key enabler" for DLCs.
The non interactivity provides a dramatic speedup (30x - 300x depending
on multi-oracle setup)
Changes the client/server setup enable new use cases to explore, and
simplify the spec substantially.
Backfilling lets clients commit to the DLC faster and lazily backfill at
cost of state storage.
For M-N oracles, precompiling N choose M groups + musig'ing the
attestation points can possibly save some witness space because
log2(N)*32 + N*32 > log2(N*(N choose M))*32 for many values of N and M.
- Pathcoin
Not well understood yet concretely.
Seems like the API of a "a coin that 1-of-N can spend" shared by N is
new/unique and not something LN can do (which always requires N online to
sign txns)
Binary expansion of coins could allow arbitrary value transfer (binary
expansion can live in a CTV tree too).
Best way to think of Pathcoin at this point is an important theoretical
result that should open up new exploration/improvement
- TXHash
Main concerns: more complexity, potential for recursion, script size
overhead
- Soft Forks, Generally
Big question: Are the fork processes themselves (e.g., BIP9/8/ST
activiations) riskier than the upgrades (CTV)?
On the one hand, validation rules are something we have to live with
forever so they should be riskier. Soft fork rules and coordination might
be bad, but after activation they go away.
On the other hand, we can "prove" a technical upgrade correct, but
soft-fork signalling requires unprovable user behavior and coordination
(e.g., actually upgrading).
If you perceive the forking mechanism as high risk, it makes sense to
make the upgrades have as much content as possible since you need to
justify the high risk.
If you perceive the forking mechanism as low risk, it is fine to make the
upgrades smaller and easier to prove safe since there's not a high cost to
forking.
- Elements CTV Emulation
Seems to be workable.
Questionable if any of the use cases one might want CTV for (Lightning,
DLCs, Vaults) would have much demand on Liquid today.
Feel free to correct me where I've not represented perspectives decently,
as always the logs are the only true summary.
Best,
Jeremy
--
@JeremyRubin <https://twitter.com/JeremyRubin>
[-- Attachment #2: Type: text/html, Size: 7383 bytes --]
reply other threads:[~2022-02-09 8:53 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=CAD5xwhhPp9+woDTJW8Mu+sgGP-468krH5oXGw_On0AHP2oyVfA@mail.gmail.com \
--to=jeremy.l.rubin@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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