QPC-github

RFC: Tlsnotary-as-a-service

The following are assumed to already exist:

1. A webserver W with high availability, and strongly hardened. A second server C for holding a private key for signing, only communicating with W
2. A tlsnotary browser addon installable by any user on Linux/MacOS/Win with a single toolbar button ('audit button'); configured to use W as auditor without additional setup or configuration, and knowing C's public key.

Process for user:

QPC-github

Data format: binary. Default file extension: '.tlsn'

Contents

Field description (size in bytes)	code in Python version
Header (29)	'tlsnotary notarization file\n\n'

QPC-github

This document is a summary of the line of reasoning leading to an idea I had about secret messaging which is referred to here as 'TLSTweet' (not sure about the name..).

What is "self-evident" about modern crypto.

There are several "truisms" in modern day cryptology (= cryptography + cryptanalysis). One of them is "don't roll your own crypto", which is meant to convey the extraordinary difficulty in creating ciphers and cryptosystems that are genuinely resistant to cryptanalysis, and the tremendous ease with which it's possible for the non-specialist, or even the specialist, to convince themselves that the cipher or system they've created is resistant to cryptanalysis, when it isn't.

Another, related but distinct, actually has a name - Kerckhoff's Principle - which briefly stated means that not only should you not hide the algorithm, but you should endeavour to make it as publically known as possible, because genuine security comes from the sec

QPC-github

import time
from datetime import datetime, timedelta
from calendar import timegm

def write_activity_log(lfn):
    with open(lfn,'rb') as f:
        loglines = f.readlines()
        loglines = [x for x in loglines if 'pubmsg' in x]
    x = {}
    for l in loglines:

QPC-github

Basic background:

See sequence of messages in canonical joinmarket in

https://github.com/JoinMarket-Org/JoinMarket-Docs/blob/master/encryption_protocol.txt

Attack description:

See JoinMarket-Org/joinmarket#156.

QPC-github

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:

QPC-github

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__()

QPC-github

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:

QPC-github

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.

QPC-github

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.