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

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

#!/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

#!/usr/bin/env python
"""
This script implements a handshake with a remote Lightning
Network node; see BOLT8:
https://github.com/lightningnetwork/lightning-rfc/blob/master/08-transport.md
, which is the Noise-based transport protocol
for Lightning network nodes.

Specify server, port and remote node pubkey as three command line arguments;
here's an example invocation:

AdamISZ

Alice has 1 Alice-coin UA on Alice-chain. Bob has 1 BTC UB on Bitcoin. X-rate = 1/1. M() is multisig.

1. CONNECT
2. Negotiate keys: A1,A2, A3, B1. Create M(2,2,A1,B1). Alice create txid from UA to M(2,2,A1,B1), give to Bob. Bob pre-sign backout to A2 with nlocktime L1.
3. Alice gives key A3 as ephem key for BTC side of swap.
4. A and B do C&C ending with Bob receiving H(k) and E_k(sig on M(2,2,A1,B1)->B2_m) for m distinct cases, and note Alice doesn't know the B2 keys.
5. DISCONNECT

(everything else does not require communication)

AdamISZ

// This tests a simple 2 party of coinjoin by first funding a utxo
// for both of Bob and Alice, and then spending both into one
// transaction. The purpose is to test construction and broadcast,
// not sophisticated validation.
func testCospend(r *rpctest.Harness,
	alice, bob *lnwallet.LightningWallet, t *testing.T) {

	// Start building the coinjoin transaction; we'll append
	// inputs and outputs as we build
	tx1 := wire.NewMsgTx(2)

AdamISZ

So, why the current narrative around ETFs, futures and similar is wrong, I believe:

Start with the idea of Darwinian natural selection. People say "evolution is a theory, it isn't proven", now you may think they're stupid because the theory is proven, but the error is much more fundamental: natural selection is not really a theory at all. It's an inevitable logical consequence of a simple set of conditions: basically, reproduction through encoding along with random variation. Natural selection has to happen in this case.

There is a similar story around the famous "Efficient Market Hypothesis". People love to say that this theory is wrong, in fact I get the impression many think they're very smart for realizing that this is

AdamISZ

Looking for optimally minimal data transfer to send a transaction.

Just throwing this out there; I'm sure we can do better.

Some stuff should be pre-agreed by anyone following this protocol. For example:

• Preagreed: script type (say legacy P2PKH)
• Preagreed: version 1, locktime 0, sequence maxint-1, fee 10K sats (tweak this later)

Receiver has address AR, requests X sats.

AdamISZ

from __future__ import (absolute_import, division,
                        print_function, unicode_literals)
from builtins import * # noqa: F401
import os
from optparse import OptionParser
from jmbase import jmprint
from jmclient import load_program_config, open_test_wallet_maybe

def get_wallet_path(file_name, wallet_dir):
    # TODO: move default wallet path to ~/.joinmarket

AdamISZ

General idea; generalise the Schnorr scriptless script atomic swap of A Poelstra to multiple parties.

We consider 3-party case with trivial generalisation. Parties are Alice, Bob, Charlie, A, B, C. Payment destinations are D_x. Transactions are TX_x. Adaptor signature secrets are t_x (scalar), T_x (point). Signatures are "sigma", adaptor signatures will be marked with '.

(