Study & contribute to bitcoin and lightning open source
Interactive AI chat to learn about bitcoin technology and its history
Technical bitcoin search engine
Daily summary of key bitcoin tech development discussions and updates
Engaging bitcoin dev intro for coders using technical texts and code challenges
Review technical bitcoin transcripts and earn sats
Date
21 November, 2024
Topics
Not available
Speakers
Not available
Transcript by
| Benefits | Cost/risks |
|---|---|
| Larger anonsets | Easier/cheaper jpegs |
| Cost effectiveness | Raised script limits - yet unknown possibilities |
| Fixed sighash | Temporary splitting of anonymity set due to new address type |
| Schnorr - batch validation, PTLC/Musig/FROST | More complexity |
| Less bandwidth for signers | Quantum risk |
| Raised script limits -> more capable scripts | General soft fork risks |
| Benefits | Cost/risks |
|---|---|
| Reduced interactivity in some shared UTXO protocols e.g. Ark | General soft fork risks |
| Timeout trees | |
| Congestion control |
| Benefits | Cost/risks |
|---|---|
| Trustless bridging to sidesystems: Scaling, Privacy, More expressivity (safer/easier languages than Script) | General soft fork risks |
| Non-equivocation contracts | Bigger txs could lead to harder knapsack problem -> miner centralization? |
| Makes multiplication in script more efficient | MEVil: Miner enforced tokens |
Question: Did we do this backward? Start with use-cases and see which soft forks enable/fix them?
If no one uses the soft fork, then the drawbacks don't matter (but neither do the benefits) (well, except for the general risk of soft fork, so if we expect no one to use it, why do it?)
Community-maintained archive to unlocking knowledge from technical bitcoin transcripts