Skip to content

Instantly share code, notes, and snippets.

Alex Morcos morcos

Block or report user

Report or block morcos

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
@morcos
morcos / FeeEstimationHighLevel.md
Last active Aug 6, 2018
Bitcoin Core Fee Estimation Algorithm
View FeeEstimationHighLevel.md

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

View Block Request Logic
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.
View feefilterbip.mediawiki

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

Abstract

@morcos
morcos / cltv.py
Created May 1, 2015
RPC test for mempool only CLTV
View cltv.py
#!/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 Aug 29, 2015
Test of pull 5864
View 5864.py
#!/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
You can’t perform that action at this time.