moved to https://github.com/zkSNACKs/WabiSabi/blob/master/explainer.md
WabiSabi is a protocol (work in progress) for constructing CoinJoin transactions with the aid of a centralized coordinator. It utilizes keyed-verification anonymous credentials, homomorphic value commitments, and zero knowledge proofs to achieve privacy and flexibility.
Ever wanted to delete all your likes/favorites from Twitter but only found broken/expensive tools? You are in the right place.
setInterval(() => {
for (const d of document.querySelectorAll('div[data-testid="unlike"]')) {
d.click()
}
If timelocked outputs are used as fidelity bonds, there is some inevitable degradation in the anonymity of users of a system that requires such bonds. Part of this would be entirely unavoidable - in that when the utxo is spent, the CLTV nature of the scriptPubKey must be revealed, and in most scenarios this would probably watermark that the utxo was being used for a fidelity bond purpose. But what might be avoided is the tracing, or linking, of a particular utxo used repeatedly for the same purpose.
To make the issue clearer, consider the specific case of Joinmarket, and the recent proposal on fidelity bonds by Chris Belcher [1]. Here, the fidelity bond would be used to sign an ephemeral identity used on a message channel. The user, having committed funds to the bond, would perforce re-use that same bond every time he reconnects to the trading pit and so what is currently a completely ephemeral identity (it can be changed as often as
BIP: ?? Layer: Applications Title: SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused Author: Adam Gibson <AdamISZ@protonmail.com> Comments-Summary: No comments yet. Comments-URI: - Status: Proposed Type: Informational Created: -
Litecoin Cash is a Bitcoin Core clone which uses a hybrid Proof-of-Work/Proof-of-Stake consensus algorithm in an attempt to aleviate 51% attacks on its network. LCC's PoW algorithm is SHA256 but its network hashrate is many orders of magnitude smaller than Bitcoin's, making it highly vulnerable to 51% attacks, as was demonstrated last year. The LCC whitepaper describes a system they call "Hive Mining", which is effectively a PoS lottery in which users can purchase "bees" (lottery tickets) that have the potential to be eligible to propose a PoS block for each new PoW block. In the paper, the authors claim this scheme provides "protection" from 51% attacks by interlacing PoW and PoS blocks, and giving PoS blocks more relative weight than PoW blocks in the chain-work calculation for selecting the most-work block.
| // Tracking cursor position in real-time without JavaScript | |
| // Demo: https://twitter.com/davywtf/status/1124146339259002881 | |
| package main | |
| import ( | |
| "fmt" | |
| "net/http" | |
| "strings" | |
| ) |
In my last gist, I described how the BIP158 block filters are technically not quite optimal, though in an inconsequential way since the false positive rate has been made so low.
In this document I'm going to describe how it's possible to significantly beat the bandwidth requirements of BIP158 while also achieving a lower overall false positive rate. The idea is to prepare multiple independent filters per block, each of which which has a higher false positive rate. Practically this can give roughly a factor of two improvement over BIP158, but at the cost of additional complexity.
The BIP158 false positive rate was chosen with a particular size of wallet in mind -- somewhere around 1000 items (addresses) to watch in each block. There is a trade off between the overall size of the filter (which must be do
Last year saw the introduction of BIP158 and Neutrino wallet which use Golomb-coded sets to very efficiently encode which items are in bitcoin blocks.
The basic idea in BIP158 is that we have N items of interest (such as distinct scriptPubKeys) in a block, which we hash to integers in the interval [0,F-1] for some range F that is much larger than N. These are basically short hashes, but with an uneven number of bits. This set of hashes can be queried to check whether a candidate scriptPubKey might be in a block, by computing the hash for the candidate and checking if that integer is in the set. The false positive rate is approximately N/F, and can be therefore tuned by making F larger or smaller.
Golomb-Rice comes into play by providing a very size-efficient way of encoding the list of hashes (by sorting them and encoding just the differences with an entropy-optimized code), which is important for minimizing over
| // cheerlights attempt using that mqtt service somewhere | |
| // buZz NURDspace | |
| // nov 2018 | |
| // rebuilt from adafruits' mqtt_esp8266_callback example | |
| #include <ESP8266WiFi.h> | |
| #include "Adafruit_MQTT.h" | |
| #include "Adafruit_MQTT_Client.h" | |
| #include "Adafruit_NeoPixel.h" |