m0wer

#!/usr/bin/env python3
"""Bitcoin Core watch-only descriptor watchdog -> Gotify.

bitcoin.conf (minimal example):
  keypool=5000
  walletnotify=env GOTIFY_URL=https://gotify.example GOTIFY_TOKEN_FILE=/path/to/token /usr/local/bin/bitcoin_core_watchdog.py notify %w %s %b %h

Optional environment:
  WATCHDOG_EVENTS=both|mempool|confirmed   (default: both)
  MEMPOOL_URL=https://mempool.space        (default; only used to build links)

m0wer

Making JoinMarket makers harder to follow

TL;DR. JoinMarket market makers reuse the same coins across many CoinJoins, and what they leave behind (change outputs with predictable values, respent round after round) lets a patient chain analyst cluster a maker's history for free, passively, from public chain data. We spent a while researching and prototyping ways out, and this writeup collects what we found. Everything below is demonstrated with real transactions on Bitcoin signet:

1. Makers should also be Lightning swap providers. No protocol change at

nothingmuch

Collaborative Transaction Privacy

This document examines some challenges for privacy in a variety of multiparty transaction settings, from PayJoin to CoinJoin. None of the attacks described are novel, but some of the cited results of the privacy literature originated in a different setting.

Common misconceptions about how privacy works on chain for such transactions paint a much rosier picture than what the published literature has shown. Unlike in cryptography, where the burden of proof for claims of security is rightfully

AdamISZ

# A reminder of how to "prove" you're Satoshi.

# ("reminder" - this was done (with tongue in cheek, presumably)
# by someone on Twitter a few years ago).

# 1. We need the public key of the receiving address of (e.g.) block 1.

# it is on the blockchain in uncompressed form (P2PK):

block1_uncompressed_output_key_hex = "0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee"

AdamISZ

Chaumian cash in a Bitcoin world - cashu, Fedimint

What's this for?

• More scalable/faster than a blockchain (not enough utxos)
• Much better privacy security model than a blockchain
• Same or better theft security model than TTP but much worse than a blockchain

If it's so great, why hasn't it been done yet?

AdamISZ

PathCoin

Caveat

Before we begin: this post describes a very limited protocol idea. It's possible that what we describe here is a start towards, or a component of, something genuinely useful, but in itself it's really more of a toy, albeit it's fun.

Non-interactive digital cash

Since the 90s, there was a dream that cash could be sent online just like email. We've basically been experimenting with tradeoffs against this pure vision ever since. Sometimes the tradeoff is: there's a central party we have to trust (either with our privacy or our money or the management or inflation or..), but otherwise we get the goal. Often the tradeoff includes: we have to interact with the receiver. In pretty much every case there's an online-ness requirement: we have to exchange messages with a p2p network of active nodes (bitcoin) or a central server and our counterparty, or at least, directly with our counterparty (e.g. Lightning) in the payment transaction.

mspalex

$reboot
bash: /sbin/reboot: Input/output error

$shutdown -r now
bash: /sbin/shutdown: Input/output error

#
# if the above reboot commands doesn't work try either forced reboot or shutdown
#

AdamISZ

On-chain contracting for privacy

(thanks to @fivepiece for significant contributions to these ideas)

"On chain contracting" is of course a very generic term; it applies to multisignature, coinjoin, coinswap or other exotic transactions that involve more than one party in one transaction (coinjoin, multisig) or multiple transactions (swaps with atomic-via-secret).

Here we're going to focus on a broader model that may allow more complex setups, with a focus on how they may apply to gaining privacy, although this model may well be useful in other ways too.

LaurentMT

This document is an attempt to define metrics quantifying the degree of privacy provided by a bitcoin transaction.


Objectives

Definition of metrics measuring the resistance of a transaction to a set of attacks against users privacy.

Attacks considered in the scope of these metrics are:
- Merged Inputs Heuristic: methods identifying the inputs controlled by a same entity
- Coinjoin Sudoku: methods identifying the links existing between the inputs and outputs of a transaction