This proposal introduces a self-custodial credit system that sits in front of an existing ecash mint. The users balance is held in a trustless credit contract that can be instantly swapped for ecash tokens offchain at the time of payment. Custodial risk only exists while payments are in flight, which is usually seconds, and only for the amount currently being transacted. The balance is always self-custodial and if the mint disappears or is uncooperative the user can unilaterally exit and reclaim their credits onchain.
The protocol works on Bitcoin today and does not require a soft fork or any new opcodes. Infact it doesn't require any opcodes at all. The protocol is almost entirely off chain, every possible way to execute the trustless credit contract results in a MuSig2 taproot key path spend onchain, no Bitcoin Script required.
This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.
Update: I've disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if someone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.
| #!/bin/bash | |
| # step 1 - generate a new key pair on a YubiKey | |
| yubico-piv-tool -a generate -s 9c -A ECCP256 -o pub.pem | |
| # step 2 - generate data to be signed | |
| jo iss=issuer aud=audience > payload.json | |
| jo alg=ES256 typ=JWT > header.json |
In his article, CAT and Schnorr Tricks I, Andrew Poelstra showed how to emulate OP_CHECKSIGFROMSTACK-like covenants using only OP_CATand Schnorr signatures.
Here, we show that a similar trick is possible to emulate covenants using only OP_CAT and ECDSA signatures.
The following script allows everyone to spend; the shorter your signature the earlier you can spend.
OP_SIZE
OP_CHECKSEQUENCEVERIFY OP_DROP
OP_CHECKSIGVERIFY
The point R = 1/2 G has the smallest known x coordinate -- x = 0x3b78ce563f89a0ed9414f5aa28ad0d96d6795f9c63. If the public key is chosen P = 1 G then the ECDSA signature becomes s=2(H(m)+x). So, the smaller H(m) the smaller s (as long as it is bigger than x ~ 2^165). Thus, the above output is spendable by the miner mining the lowest TX hash.
Eclipse attacks occur when a node is not connected to any honest peers on the network, and instead its peer connections are controlled by an adversary. Once denied connectivity to the honest network, a victim can be attacked in numerous ways, such as with double-spends or funds loss on layer 2 systems (such as the Lightning Network). Mining nodes attacked in this way can be forced to waste hashpower or be commandeered in selfish mining attacks, or generally aid in causing forks on the network.
This document attempts to describe the mechanisms implemented in Bitcoin Core to mitigate eclipse attacks followed by open questions and areas of further research.
A restart-based eclipse attack occurs when the adversary is able to sufficiently saturate the victim's address manager with attacker IPs (a.k.a. addrman flooding), and then the victim restarts. If the attack succeeds, the victim will lose its current outgoing connections due to the restart and be more lik