| /** 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 { |
Darkpool: A chaumian blinded ecash like co-op mixing pool for self custodial savings accompanying Mints
Darkpool is a privacy preserving cooperative self-custody pool on bitcoin, utilizing taproot n-of-n musig on the key path and CTV (OP_CHECKTEMPLATEVERIFY) settlement tree on the script path. Tarpit is the name chosen for the proof of concept implementation project of darkpools.
With multiparty computation multisignatures like FROST [0], it is possible to build a collaborative custodian service that is extremely private for users.
Today's collaborative custodians can see your entire wallet history even if you never require them to help sign a transaction, and they have full liberty to censor any signature requests they deem inappropriate or are coerced into censoring.
With FROST, a private collaborative custodian can hold a key to a multisig while remaining unaware of the public key (and wallet) which they help control. By hiding this public key, we solve the issue of existing collaborative custodians who learn of all wallet transactions even if you never use them.
Further, in the scenario that we do call upon a private collaborative custodian to help sign a transaction, this transaction could be signed blindly. Being blind to the transaction request itself and unknowing of past onchain behavior, these custodians have no practical in
Sats4Files is a protocol for decentralized file hosting. It allows users to request data from untrusted servers, and upon receiving the encrypted data, they can pay for the decryption key via Lightning. The exchange is atomic, ensuring that the user only receives the data if they pay for it, and the seller only gets paid if they deliver the data. The protocol is an efficient form of verifiable encryption, which is similar to verifiable secret sharing using Shamir's algorithm.
This scheme is simplified and does not fully solve the problem, as discussed in the Limitations section. This writeup intends to spark interest to solve the remaining issues beyond the fixes that we suggest.
The client wants to buy from the server the file corresponding to a particular file_id.
Here, we assume we have PTLCs on Lightning instead of HTLCs. That means we can buy a discrete logarithm over Li
Edit: here you can find our research paper describing the protocol more in-depth.
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
| #!/bin/bash | |
| # Usage: yt-whisper URL [OUTPUT_FILENAME_TEMPLATE [LANGUAGE]] | |
| # If OUTPUT_FILENAME_TEMPLATE is empty, output is yt-whisper-video | |
| # If LANGAUGE is empty, it is set to "auto" | |
| # General settings (paths) for whisper.cpp | |
| # Note - this uses whisper.cpp, not official whisper. Get it at | |
| # https://github.com/ggerganov/whisper.cpp | |
| # You will have to adjust these |
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).
Receive private payments from anyone on a single static address without requiring any interaction or extra on-chain overhead.
Update: This now has a BIP and WIP implementation
The recipient generates a so-called silent payment address and makes it publicly known. The sender then takes a public key from one of their chosen inputs for the payment, and uses it to derive a shared secret that is then used to tweak the silent payment address. The recipient detects the payment by scanning every transaction in the blockchain.
This document now exists on the official ASP.NET core docs page.
