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

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

pre-requisite: a Bitcoin Core instance, set up regtest and start running it.
Before starting run, set up a bitcoin conf in say ~/bitcoin.conf and put:

rpcuser=user
rpcpassword=password
txindex=1

Then, ./bitcoind -regtest -daemon -conf=/home/username/bitcoin.conf

or whatever. Make sure to generate some blocks.

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

Chaumian cash in a Bitcoin world - cashu, Fedimint

What's this for?

• More scalable/faster than a blockchain (not enough utxos)
• Much better privacy security model than a blockchain
• Same or better theft security model than TTP but much worse than a blockchain

If it's so great, why hasn't it been done yet?

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

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

# A reminder of how to "prove" you're Satoshi.

# ("reminder" - this was done (with tongue in cheek, presumably)
# by someone on Twitter a few years ago).

# 1. We need the public key of the receiving address of (e.g.) block 1.

# it is on the blockchain in uncompressed form (P2PK):

block1_uncompressed_output_key_hex = "0496b538e853519c726a2c91e61ec11600ae1390813a627c66fb8be7947be63c52da7589379515d4e0a604f8141781e62294721166bf621e73a82cbf2342c858ee"

AdamISZ

Described here is a variant of what has previously been published under the name "P2EP" or Pay-to-endpoint, in which A pays B but B contributes utxos, i.e. it's a coinjoin-payment.

I'm using the term "payjoin" here to refer to using that idea, but not including a URI/endpoint specific to B, and not allowing (as a merchant would) arbitrary payments, which opens up certain problems around snooping attackers (more on this below). So payjoin just means "A pays B but B actively participates and passes across utxos as extra inputs".

I'll defer a more features-focused and non-tech friendly description of what this means to a later blogpost.

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.