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;

AdamISZ

#!/usr/bin/env python
from __future__ import print_function
"""
Find/count JM transactions in blocks.
Ensure your joinmarket-clientserver virtualenv (jmvenv) is activated,
make sure your Bitcoin Core node is available and joinmarket.cfg is appropriately set.

Pass start and end block number:
`python jmtxfinder.py 400000 400200`.

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 '.

(

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

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

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

// 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)