Since Taproot (more generally any kind of MAST) spends have variable size which depends on the path being used, the last such input to be signed in a multiparty transaction can always use a larger than estimated witness to unfairly extract a fee contribution from the other parties to the transaction (keeping the absolute fees the same and reducing the feerate for the transaction).
# This script lives in my home manager home.packages. I also have: | |
# | |
# programs.direnv.enable = true; | |
# programs.direnv.nix-direnv.enable = true; | |
# | |
# To enable a language, I use e.g.: | |
# | |
# nix registry add rust-direnv ~/code/dev-templates/rust | |
# | |
# where the directory is my local fork of https://github.com/the-nix-way/dev-templates |
Celsius recent court filings provided a terrible and arguably avoidable loss of privacy for many of its customers, and will likely have chilling ripple effects for a long time to come. The goal of this presentation-turned-writeup is to give some context so that the reader can understand the consequences of such incidents and where to find more detailed information in order to mitigate such risks, and the tradeoffs that entails.
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.
this notes have been largely superseded by discussions in the https://github.com/zkSNACKs/WabiSabi repository.
secondly, this describes a general framework which may be instantiated in different ways, a point that was not made clearly (the specific types described are more like independent examples of possible designs, not a specific proposal)
Modifications to the zerolink Chaumian coinjoin scheme to support:
- CoinShuffle: Practical Decentralized Coin Mixing for Bitcoin | SpringerLink
- Blindcoin: Blinded, Accountable Mixes for Bitcoin | SpringerLink
- P2P Mixing and Unlinkable P2P Transactions
- P2P Mixing and Unlinkable Transactions
- Anonymous CoinJoin Transactions with Arbitrary Values
- Sci-Hub | Sybil-Resistant Mixing for Bitcoin | 10.1145/2665943.2665955
// PoC for 2-of-3 multisig where one of the keys is an opendime (sealed at time of scriptPubKey creation) | |
// see on https://ivy-lang.org/bitcoin | |
// the script ivy generates seems sub-optimal (some unconditional rotation and rolling of stack elements) | |
// but this is just a yucky PoC, and the ivy source is arguably easier to understand anyway | |
contract LockWithKeyHashMultisig( | |
pubKey1: PublicKey, | |
pubKey2: PublicKey, | |
pubKey3hash: Ripemd160(Sha256(PublicKey)), // opendime address | |
dummyKey: PublicKey, // should be a curve point with no known discrete log |
guix hash dependency source file guix revision package file line | |
1wl1x93b5w457ddsdgj0lh7yjq4q6l7wfbgwhagkc8fm2qkkrd0p expat-2.2.6.tar.bz2 HEAD gnu/packages/xml.scm 75 | |
1wm4pv12f36cwzhldpp7vy3lhm3xdcnp4f184xkxsp7b18r7gm7x libXau-1.0.8.tar.bz2 HEAD gnu/packages/xorg.scm 4821 | |
0dbfn5bznnrhqzvkrcmw4c44yvvpwdcsrvzxf4rk27r36b9x865m libXext-1.3.3.tar.bz2 HEAD gnu/packages/xorg.scm 4547 | |
040rcs9fpv4bslhiy43v7dcrzakz4vwwpyqg4jp8bn24sl95ci7f protobuf-2.6.1.tar.bz2 HEAD gnu/packages/protobuf.scm 139 | |
1c2vma9gqgc2v06rfxdiqgwhxmzk2cbmknwf1ng3m76vr0xb5x7k xextproto-7.3.0.tar.bz2 HEAD gnu/packages/xorg.scm 2369 | |
18dighcs333gsvajvvgqp8l4cx7h1x7yx9gd5xacnk80spyykrf3 zlib-1.2.11.tar.gz HEAD gnu/packages/compression.scm 81 | |
0jjirhw6xwz2ffmbg5kr79108l8i1bdaw7szc67n3qpkygaxsjb0 dbus-1.10.18.tar.gz d8048a1212e880ce360aaf1b32f4bf3c84e51028 gnu/packages/glib.scm 78 | |
1wy7svvp7df6bjpg1m5vizb3ngd7rhb20vpclv3x3qa71khs6jdl fontconfig-2.12.1.tar.bz2 ab4e939c50b579eaee634c7c90c600f9c9f3aa3f gnu/packages/fontutils.scm 233 | |
121gm15ayfg3rglby8ifh8384 |
#!/bin/bash | |
set -e | |
echo "Pinging peers..." | |
bitcoin-cli ping | |
sleep 2 | |
# loop until all but 2 slowest peers have responded |
Locking down REST and/or JSON-RPC APIs in a generic way, with an object capability security model.
Given some sort of priviliged access to a backend, this proxy would expose the service with no changes to the API apart from additional requirement for macaroon authorization.
A second mode would also be able to expose such a service to an unrestricted port, by statically configuring a macaroon to be submitted to an upstream endpoint, allowing hardened APIs to be exposed with no macaroon required.