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

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

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

""" 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

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

import bitcointx as btc
btc.allow_secp256k1_experimental_modules()
btc.select_chain_params("bitcoin/testnet")
from bitcointx.wallet import CCoinKey
from bitcointx.core import COutPoint, CTxIn, CTxOut, CMutableTransaction, CTxInWitness
from bitcointx.core.script import (CScript, OP_CHECKSIGADD, OP_CHECKSIG, OP_NUMEQUAL,
                                   TaprootScriptTree, CScriptWitness)
from bitcointx.wallet import P2TRCoinAddress
from binascii import hexlify, unhexlify

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.

AdamISZ

#!usr/bin/env python

""" Implementation example of https://eprint.iacr.org/2016/263.pdf
Bootle et al. Section 3, polynomial evaluation protocol which scales
in the square root of the degree.
*Not* zero knowledge form.
"""

import jmbitcoin as btc
import struct

AdamISZ

As per footnote 2 in the draft BIP here, it is possible in MuSig2 to create a partial signature which verifies correctly to the other participants, even though the adversary does not know the secret key corresponding to the given public key, but only by the adversary taking the role of at least one other participant, and in that case it is not possible to create a partial signature for that other public key, even if the corresponding private key is known.

The purpose of this gist is to work through the mathematical details of the above statement, as it isn't, probably, obvious to most readers (although it may be at least somewhat intuitive - think about 'free variables').

Setup: keyset $L = X_1 , X_2 , X_3 , X_4 , X_5$. The adversary will take the roles of indices 4 and 5, and will forge a partial signature on key $X_4$, not knowing the corresponding secret $x_4$, on a given message $m$. Assume the adversary does kn

AdamISZ

RIDDLE

Due to unexpected failures of github's LaTeX parsing (which were not evident until I published this, but have persisted afterwards), and since the mathematical parts are important in this, I have migrated this proposal to a blog post with identical content, but correctly formatted equations.

Please continue to put any comments here.