AdamISZ

#!/usr/bin/env python2
from __future__ import print_function

"""Simple illustration of 2 stage process:
1. Prepare a single (input, output) pair from some wallet
you have, and sign it with SIGHASH_SINGLE|SIGHASH_ANYONECANPAY
(the idea is that a utxo splitter service can do this for a client)
2. Take that partial transaction (serialized), and by feeding in
data from an input file gathered from Electrum GUI, add another
input and output (only one input here, should be OK to increase to more inputs),

AdamISZ

Simple Non-Interactive Coinjoins with Keys for Encryption Reused

Gist!

Use pubkeys available on the blockchain (in scriptSigs/witnesses) to encrypt messages to owners of those pubkeys, these messages containing partially signed coinjoins. Broadcast these encrypted messages; owners scan for their own messages and broadcast as they choose. This is intended to be fully non-interactive so anyone can propose such transactions, and anyone who can decrypt such a message can choose to co-sign and broadcast.

Basic Coinjoin background

Each input to a transaction requires (for the transaction to be valid) a signature by the owner of the private key (using singular deliberately, restricting consideration to p2pkh or segwit equivalent here) over a message which is ~ the transaction. Each of these signatures can be constructed separately, by separate parties if indeed the private key for each input are owned by separate parties. The "normal" coinjoining process thus involves the following steps (for now,

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.

AdamISZ

Explanation of how using Schnorr signatures, we can achieve an atomic swap of the "scriptless script" style.

This is based on Poelstra's ideas as summarised in https://download.wpsoftware.net/bitcoin/wizardry/mw-slides/2017-05-milan-meetup/slides.pdf ; also see the earlier outline in https://lists.launchpad.net/mimblewimble/msg00086.html.

Note that the details here are just my thoughts, so if you come to this randomly, don't take it as some kind of well established protocol!

Preliminaries:

We'll use || for concatenation and capitals for elliptic curve points and lower case letters for scalars.

AdamISZ

(Update, this has been moved to https://github.com/AdamISZ/CoinSwapCS/tree/master/docs as part of that project)

These notes refer to the setup described in table and diagram form here.

Why tweak the original Coinswap design.

The original design is explained in the original CoinSwap post. The reason for attempting to come up with a modification is seen in the diagram line E:

AdamISZ

Some definitions and assumptions:

EMM: "economically motivated maker" - defined as purely motivated by immediate largest economic benefit, not bounded by coding skill (so can implement any algorithm not limited to our codebase), not interested in any privacy concerns, and most importantly: not including the intent to either DOS or not DOS the system.

U_n (x) a real utxo (index n) controlling x btc.

U'_n(x) a fake utxo (index n) controlling x btc.

Assumption: the EMM has U₁ ... U_n real utxos, each with corresponding amount x_i.

AdamISZ

This idea is due to @Adlai

This is a rough overview of the idea; there may well be refinements in practice.

Consider the following issue: a Maker is incented to find a way to get chosen more frequently in joins. He can try these approaches:

1. Publish more offers from his single bot, which cover the same btc amount range
2. Create multiple bots which make duplicated offers from the same wallet/utxo set.

Note that there is no "3. create multiple bots referring to different utxo sets"; there is nothing wrong with doing that.

AdamISZ

Username (herafter "nick") construction for message channel:

nick = one "type" byte (currently "J") + one version byte (current jm_version protocol value) + Base58 (not Base58Check) of: first joinmarket.message_channel.NICK_HASH_LEN bytes of sha256 of : ephemeral per-bot-process public key.

If length(X) < joinmarket.message_channel.NICK_MAX_ENCODED, right pad with 'O' char to that length.

Definitions:

AdamISZ

blockchain interface:

class ElectrumWalletInterface(BlockchainInterface):
    """A pseudo-blockchain interface using the existing 
    Electrum server connection in an Electrum wallet.
    Usage requires calling set_wallet with a valid Electrum
    wallet instance.
    """
    def __init__(self, testnet=False):
        super(ElectrumWalletInterface, self).__init__()

AdamISZ

Current work is in this branch.

Reference information at: BIP141, BIP143 (note BIP142 is not in force)

Implementation uses P2SH-P2WPKH - the P2SH is for backwards-compatibility (old wallets can send to P2SH addresses), and P2WPKH not P2WSH for simplicity (no multisig involved).

Modifications made so far:

New ordertypes: