FWIW: I (@rondy) am not the creator of the content shared here, which is an excerpt from Edmond Lau's book. I simply copied and pasted it from another location and saved it as a personal note, before it gained popularity on news.ycombinator.com. Unfortunately, I cannot recall the exact origin of the original source, nor was I able to find the author's name, so I am can't provide the appropriate credits.
| ### | |
| ### | |
| ### UPDATE: For Win 11, I recommend using this tool in place of this script: | |
| ### https://christitus.com/windows-tool/ | |
| ### https://github.com/ChrisTitusTech/winutil | |
| ### https://www.youtube.com/watch?v=6UQZ5oQg8XA | |
| ### iwr -useb https://christitus.com/win | iex | |
| ### | |
| ### |
Originally posted on bitcoin-dev.
This post describes a fully decentralized two-way peg sidechain design. Activating new sidechains requires a soft fork, hence the name softchains. The key aspect is that all softchains are validated by everyone via Proof-of-Work Fraud Proofs (PoW FP) -- a slow but very efficient consensus mechanism that only requires the validation of disputed blocks. This does increase the validation burden of mainchain full nodes, but only by a minimal amount (~100MB per chain per year). It's similar to [drivechains][0], but without the major downside of having to rely on miners, since all Bitcoin full node users can efficiently validate each sidechain.
Last year I posted the idea of [PoW FP to the Bitcoin mailing list][1] ([follow-up here][2]). The idea is that we can use the existence of a fork in Bitc
This document now exists on the official ASP.NET core docs page.
zkCoins is a novel blockchain design with strong privacy and scalability properties. It combines client-side validation with a zero-knowledge proof system. The chain is reduced to a minimum base layer to prevent double spending. Most of the verification complexity is moved off-chain and communicated directly between the individual sender and recipient of a transaction. There are very few global consensus rules, which makes block validation simple. Not even a global UTXO set is required.
In contrast to zk-rollups there is no data availability problem, and no sequencer is required to coordinate a global proof aggregation. The protocol can be implemented as an additional layer contained in Bitcoin's blockchain (similar to RGB[^5] or Taro[^6]) or as a standalone sidechain.
The throughput scales to hundreds of transactions per second without sacrificing decentralization.
The core design principle is to *"use the chain for what the chain is good for, which is an immutable order
I'm Ruben Somsen, Bitcoin Sorcerer. I do protocol design in order to enhance Bitcoin.
I'm sponsored by Spiral, Superlunar/Gemini, HRF, and am currently working on Silent Payments with Josie, assisting Davidson with the implementation of Proof-of-Work fraud proofs into Floresta, and Raj with continuing the work on Teleport (Belcher's Coinswap protocol).
I also help maintain the bitcoin-dev mailing list, co-hosted the Unhashed Podcast, founded the Seoul Bitcoin Meetup in 2014, actively co-organizing BitDevs Amsterdam, and on the layer two funding sub-committee of OpenSats.
You can find me on [Twitter](https://twitter.com/SomsenRube
Note: This guide may be slightly outdated. It may be still useful for older releases, but nowadays the vast majority of releases are correctly tagged as WEB-DL (unless it's RARBG/rartv). Protip: prefer looking at file names instead of release names, as they tend to be more accurate.
This is a short cheatsheet to help you determine whether a release from Amazon, Hulu, or Netflix contains the lossless/untouched (as in no further loss of quality compared to what the streaming services provide) video/audio or not. Most newer P2P releases are correctly tagged, but for older releases, it cannot be reliably determined based on the tags alone.
In most cases, non-lossless rips from these services are screen captures (which, when done by professional releasers, should be high quality and contain little to no glitches – see the history section for details), but in some cases they may be simply reencoded from the untouched stream, for example to crop black bars or reencode from a
FROST's distributed key generation involves N parties each creating a secret polynomial, and sharing evaluations of this polynomial with other parties to create a distributed FROST key.
The final FROST key is described by a joint polynomial, where the x=0 intercept is the jointly shared secret s=f(0). Each participant controls a single point on this polynomial at their participant index.
The degree T-1 of the polynomials determines the threshold T of the multisignature - as this sets the number of points required to interpolate the joint polynomial and compute evaluations under the joint secret.
T parties can interact in order to interpolate evaluations using the secret f[0] without ever actually reconstructing this secret in isolation (unlike Shamir Secret Sharing where you have to reconstruct the secret).
| /** By LnRouter.app */ | |
| function bitShift(n: number, shiftBy: number): number { | |
| let base = n; | |
| for (let i = 0; i < shiftBy; i++) { | |
| base = base * 2; | |
| } | |
| return base; | |
| } | |
| export function shortChannelIdToDecimalId(shortChannelId: string): string { |
