Richard Myers remyers

Route Blinding

Notations

Alice's real node_id is P_a = k_a * G
Bob's real node_id is P_b = k_b * G
Alice's blinded node_id is D_a = d_a * G
Bob's blinded node_id is D_b = d_b * G
Alice <-> Bob real short_channel_id is scid_ab
Alice <-> Bob blinded short_channel_id is blinded_scid_ab

Introduction

I'm Ruben Somsen, Bitcoin Sorcerer. I do protocol design in order to enhance Bitcoin.

I'm sponsored by Spiral, Superlunar/Gemini, HRF, and am currently working on Silent Payments with Josie and assisting Davidson with the implementation of Proof-of-Work fraud proofs into Floresta.

I also help maintain the bitcoin-dev mailing list, am a BIP editor, co-hosted the Unhashed Podcast, founded the Seoul Bitcoin Meetup in 2014, actively co-organizing BitDevs Amsterdam, and on the layer two funding sub-committee of OpenSats.

You can find me on Twitter, Mastodon, and Telegram. You can also join [this Te

Package Mempool Accept Post

Hi there,

I'm writing to propose a set of mempool policy changes to enable package validation (in preparation for package relay) in Bitcoin Core. These would not be consensus or P2P protocol changes. However, since mempool policy significantly affects transaction propagation, I believe this is relevant for the mailing list.

My proposal enables packages consisting of multiple parents and 1 child. If you develop software that relies on specific transaction relay assumptions and/or are interested in using package relay in the future, I'm very interested to hear your feedback on the utility or restrictiveness of these package policies for your use cases.

A draft implementation of this proposal can be found in [Bitcoin Core PR#22290][1].

Splice specification proposal

This gist details various splicing protocol flows as they are currently implemented in eclair. We detail the exact flow of messages for each scenario, which should help the review process.

Terminology

We call "active commitments" the set of valid commitment transactions to which updates (update_add_htlc, update_fulfill_htlc, update_fail_htlc, update_fail_malformed_htlc, update_fee) must be applied. While a funding transaction is unconfirmed, updates must be valid for all active commitments.

Bitcoin has a KYC problem. We don't know any customers. One man's spammer is another man's marketing genius.

This plays into how Bitcoin software handles transactions that are gossiped to it on the network. Your local node does a list of anti-DoS checks, as well as miner compatibility checks, caches the transaction, and forwards it to any nodes connected to yours.

For miner incentives, this is not exactly straight forward, but easy enough to inuit. If you can "make the mempool better", you accept a new transaction, and kick out whatever it replaced.

This isn't the whole story. What it it makes the mempool contents better for miners, but is worse


	[Fund Channel]
	\|
	\|
	\|
	v
	P=Musig(A,B)+scripts (for Taproot script-path spend)
	Q=Musig(A,B) (for Taproot key-path spend)

	OR ----------- [Cooperative Close]

	lightning

	#!/bin/bash
	export PATH=$PATH:/home/adam/data/openwrt/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-8.3.0_musl_eabi/bin
	export STAGING_DIR=/home/adam/data/openwrt/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-8.3.0_musl_eabi
	export target_host=arm-openwrt-linux-muslgnueabi
	export AR=$target_host-ar
	export AS=$target_host-as
	export CC=$target_host-gcc
	export CXX=$target_host-g++

	# install bitcoind via your favorite method

	# start regtest bitcoind
	mkdir -p /tmp/regtest1/bitcoind
	bitcoind -datadir=/tmp/regtest1/bitcoind -regtest -server -fallbackfee=0.0002 -rpcallowip=0.0.0.0/0 -rpcbind=0.0.0.0 -blockfilterindex=1 -peerblockfilters=1 -daemon

	# cookie file location: /tmp/regtest1/bitcoind/regtest/.cookie

	# create test bitcoind wallet
	bitcoin-cli -datadir=/tmp/regtest1/bitcoind -regtest -named createwallet wallet_name="regtest1" disable_private_keys=true blank=true