Skip to content

Instantly share code, notes, and snippets.

View morcos's full-sized avatar

Alex Morcos morcos

View GitHub Profile

  BIP: <unassigned>
  Title: feefilter message
  Author: Alex Morcos <morcos@chaincode.com>
  Status: Draft
  Type: Standards Track
  Created: 2016-02-13

Abstract

@morcos
morcos / FeeEstimationHighLevel.md
Last active June 14, 2023 10:57
Bitcoin Core Fee Estimation Algorithm

High level description Bitcoin Core's fee estimation algorithm

The algorithm takes as input a target which represents a number of blocks within which you would like your transaction to be included in the blockchain. It returns a fee rate that you should use on your transaction in order to achieve this.

The algorithm is conceptually very simple and does not attempt to have any predictive power over future conditions. It only looks at some recent history of transactions and returns the lowest fee rate such that in that recent history a very high fraction of transactions with that fee rate were confirmed in the block chain in less than the target number of blocks.

Transactions can occur with a nearly continuous range of fee rates and so in order to avoid tracking every historical transaction independently, they are grouped into fee rate "buckets". A fee rate bucket represents a range of fee rates within which the algorithm treats all transactions as having approximately the same fee rate and the answer th

Suggested change to allow second outstanding block request
Request/Process first announcement as we do now, then additionally once we have the block in flight, we are still willing to request a cmpctblock from the first sendcmpct peer which headers us until we have received a new cmpctblock (either in response to our request or from an HB peer, but not counting from the first announcemnt). Then we request blocktxn from that peer as well so we have two blocks in flight, at least the second of which is a cmpctblock.
I think that outstanding requests for cmpct blocks at either the first or second annoucement should only influence whether we request more cmpct blocks. Until we have at least 2 known block or blocktxn requests outstanding, we will continue to respond with getblocktxn to any cmpct blocks we receive. But once we have one outstanding request for anything (cmpctblock, block, blocktxn), we will never request another full block.
@morcos
morcos / cltv.py
Created May 1, 2015 17:18
RPC test for mempool only CLTV
#!/usr/bin/env python2
# Copyright (c) 2015 The Bitcoin Core developers
# Distributed under the MIT software license, see the accompanying
# file COPYING or http://www.opensource.org/licenses/mit-license.php.
#
# Test CLTV code
#
from test_framework import BitcoinTestFramework
@morcos
morcos / 5864.py
Last active August 29, 2015 14:16
Test of pull 5864
#!/usr/bin/env python2
# Copyright (c) 2014 The Bitcoin Core developers
# Distributed under the MIT software license, see the accompanying
# file COPYING or http://www.opensource.org/licenses/mit-license.php.
#
# Test reindex code on bad data
#
from test_framework import BitcoinTestFramework