bitcoin-core/guix.sigs Repository Workflowexport SIGNER="hebasto"
export GUIX_SIGS_REPO="/home/hebasto/guix.sigs"
export DETACHED_SIGS_REPO="/home/hebasto/bitcoin-detached-sigs"
| 1MB limit (no bip): | |
| commited: 2010-09-07 | |
| flag-day: 79400 2010-09-12 | |
| burial: 2010-09-20 | |
| dup-tx (bip 30): | |
| bip: 2012-02-22 | |
| flag-day: 2012-03-15 | |
| p2sh (bip 16): |
| import requests | |
| import pprint | |
| r = requests.get('https://blockchain.info/rawblock/0000000000000000002540e369b106bfd929585e0f059409bd2a956e6a6af79c') | |
| r = r.json() | |
| txs = r['tx'] | |
| first = True | |
| packages = [] | |
| for i,tx in enumerate(txs): | |
| if first: |
Purpose: Suggest a new method for choosing fees on a transaction. Goal is to get a transaction confirmed as cheap as possible within the provided timeframe, with emphasis on both not missing the time window, and also on not going over the user's maximum fee.
Existing Problems:
Transaction fee setting is currently really 'loose'. Blocks will have transaction fees between 300 sats and 500 sats, which means that, at the very least, everyone at 500 sats could have gotten in at 300 sats. That's a huge spread.
Loose fee markets just generally drives prices up quite a bit. People see '300' and '500' as the 0-1 block confirmation rate, and that's where they set their expectations. They don't like it, but they know that's what the market is, so that's where they put their fees. Basically, we've ended up with a market where people are trying hard to make sure that they are using fees that are good enough instead of using fees that are what they could reasonably get away with.
The emphasis on getting confir
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
| import matplotlib | |
| import numpy.random | |
| import matplotlib.pyplot as plt | |
| from matplotlib.ticker import FuncFormatter | |
| #https://www.reddit.com/r/Bitcoin/comments/4gp28d/how_to_avoid_getting_ripped_off_in_large_btc/ | |
| #https://en.bitcoin.it/wiki/Confirmation | |
| cumulative = True |
