Chaser324

Whether you're trying to give back to the open source community or collaborating on your own projects, knowing how to properly fork and generate pull requests is essential. Unfortunately, it's quite easy to make mistakes or not know what you should do when you're initially learning the process. I know that I certainly had considerable initial trouble with it, and I found a lot of the information on GitHub and around the internet to be rather piecemeal and incomplete - part of the process described here, another there, common hangups in a different place, and so on.

In an attempt to coallate this information for myself and others, this short tutorial is what I've found to be fairly standard procedure for creating a fork, doing your work, issuing a pull request, and merging that pull request back into the original project.

Creating a Fork

Just head over to the GitHub page and click the "Fork" button. It's just that simple. Once you've done that, you can use your favorite git client to clone your repo or j

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

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.

fernandonm

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

AdamISZ

Looking for optimally minimal data transfer to send a transaction.

Just throwing this out there; I'm sure we can do better.

Some stuff should be pre-agreed by anyone following this protocol. For example:

• Preagreed: script type (say legacy P2PKH)
• Preagreed: version 1, locktime 0, sequence maxint-1, fee 10K sats (tweak this later)

Receiver has address AR, requests X sats.

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

fiatjaf

venv
*.swo
*.swp
__pycache__

roconnor-blockstream

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