instagibbs

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

t-bast

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.

notmandatory

# 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

fernandonm

glozow

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

asoltys

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++

remyers

                                                                                         
  [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]                                                    

RubenSomsen

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, assisting Davidson with the implementation of Proof-of-Work fraud proofs into Floresta, and Raj with continuing the work on Teleport (Belcher's Coinswap protocol).

I also help maintain the bitcoin-dev mailing list, 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](https://twitter.com/SomsenRube

t-bast

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

roconnor-blockstream

{
  "txid": "0e8e133dd88282a4f64919e046027d3b40a572c32d0ce6b646a403bed0d51750",
  "hash": "0e8e133dd88282a4f64919e046027d3b40a572c32d0ce6b646a403bed0d51750",
  "wtxid": "0e8e133dd88282a4f64919e046027d3b40a572c32d0ce6b646a403bed0d51750",
  "withash": "ab3393f4fb64685a4de07ac89c6903d6a0ba107c87fff33c9a981a7590bae48e",
  "version": 2,
  "size": 240,
  "vsize": 240,
  "weight": 960,
  "locktime": 0,