AdamISZ

Joinmarket fees over Lightning using encrypted signatures

Fees inside Joinmarket coinjoins are one of (arguably, the principal) "metadata" fingerprints that damage the quality of the privacy generated by such coinjoins. At minimum, they force a lot more rounds of coinjoin in order to get a meaningful anonymity set (and realistically, more complex behaviour and a lot more time). It should be noted that there is no claim that removing these fingerprints are a panacea.

But let's consider how off-chain fees could work. It's clearly possible to do it with centralized servers. The more advanced way to use servers would be a Chaumian e-cash server as described by chris-belcher here. However this short note is intended to explain that the same goal can be achieved trustlessly.

First, remember that either with Schnorr or with ECDSA, we can construct "signature adaptors" or preferably "otVES" - one-time verifiably encrypted signatures, in

AdamISZ

""" THIS CODE IS ONLY EDUCATIONAL - NO
    PART OF IT IS FIT FOR PRODUCTION USE.
    NO, SERIOUSLY, I MEAN IT!!
    
    As for reading it, start with the `__main__`
    section at the bottom and go from there.
    Comments are, deliberately, voluminous.

    If you want to run the example, just:
    (a) install Joinmarket (else see the notes on import)

AdamISZ

Concise instructions on setting up Joinmarket for testing on signet

• Install Bitcoin Core v0.21.0+ from bitcoincore.org/en/download
• Edit the bitcoin.conf file (create a new version/back up normal conf file), and put a [signet] section, in which your rpc wallet file is set using a line wallet=..
• Start bitcoind: ./bitcoind -signet
• To check when it's synced you can tail -f ~/.bitcoin/signet/debug.log to watch the sync happen. It should be fast; only took perhaps a couple of minutes for me, even though I have a slow internet connection.
• Once synced configure Joinmarket. As with bitcoind, create a new config file to use by copying an existing mainnet or testnet config file joinmarket.cfg. Settings:
  • rpc_port = 38332
  • network = signet

AdamISZ

import os
from optparse import OptionParser
from jmbase import jmprint
from jmclient import load_program_config, LegacyWallet, VolatileStorage, get_network


def get_parser():
    description = (
        'Use this script to extract keys and addresses from pre-segwit '
        'Joinmarket wallets if you do not have access to Bitcoin Core. Specify '

AdamISZ

** As it stands, this protocol seems not to achieve the intended goal at all, see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-November/018278.html **

Leaving it here for now, but obviously read the above if you read it!

==================================

Bulletin boards without selective censorability for bitcoin fungibility markets

Abstract

AdamISZ

Setup paying hot wallet btcpayserver to joinmarket all on one machine, on regtest:

1. Follow installation instructions from scratch as per: https://docs.btcpayserver.org/LocalDevelopment/ (note, there is another setup description, but it is specifically for coding and debugging, using visual studio, here: https://docs.btcpayserver.org/Contribute/ContributeDev/ContributeDevCode/#visual-studio-setup)

2. after the docker-compose up dev command specified there, run dotnet run --launch-profile Bitcoin from BTCPayServer directory (should not need to change any config)

3. Load http://127.0.0.1:14142 to get the BTCPayServer UI

4. Create an Admin account (check the option) with a random email and password. New screen should show 'Regtest' and 'Server Settings'.

AdamISZ

Some blue sky thinking about Joinmarket architecture (this is about the "client" side of "client-server" in the sense used in the name of the repo; there, the "server" is the communications daemon which can run somewhere else, and I'm not suggesting changing that).

Though the idea has cropped up several times (because it is a very natural concept in software engineering, and is widely used), I started today thinking again about having something like an RPC API for a Joinmarket long-running daemon (this would be *another* daemon to the one mentioned above). Let's call it jmwalletd to distinguish from existing joinmarketd (badly named in retrospect), and called that because as you see below the idea is to bundle the services around the wallet.

The reason I started thinking about it today again, was because of SNICKER; and I'll use that as an example of how this might create benefits (along with some benefits that would exist without new functionality).

Imagine then that jmwalletd.py runs as a service or simi

AdamISZ

#!/usr/bin/env python3

""" This represents a brief check of mainnet transaction:
ba29e5c66bc0ce15a0228d47514f1de2a5737f2eb185c30589bfd4a735d78c1f

in particular, assuming the four inputs identified below as "known_ins",
i.e. there is an assumption they are co-owned by one entity, this identifies
possible combinations of the other inputs, with this set of inputs,
that matches the change output according to taker/maker role, applying a sudoku.

AdamISZ

Fidelity Bonds in an Anonymity set

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.

Concrete case: Joinmarket maker

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

AdamISZ

  BIP: ??
  Layer: Applications
  Title: SNICKER - Simple Non-Interactive Coinjoin with Keys for Encryption Reused
  Author&#58; Adam Gibson <AdamISZ@protonmail.com>
  Comments&#45;Summary&#58; No comments yet.
  Comments&#45;URI&#58; &#45;
  Status&#58; Proposed
  Type&#58; Informational
  Created&#58; &#45;