Skip to content

Instantly share code, notes, and snippets.

View ajtowns's full-sized avatar

Anthony Towns ajtowns

View GitHub Profile
@ajtowns
ajtowns / BIP-hardfork-changes.txt
Last active July 11, 2017 22:55
hard fork proposals guide/timeline
Hard-forking Changes to Bitcoin Core
====================================
A hard-fork change to the Bitcoin consensus validation rules is one that
treats previously invalid blocks as valid. (Such a change may additionally
include soft-forking changes, treating previously valid blocks as invalid)
In order to safely deploy a change of this type, the following process
should be followed:
@ajtowns
ajtowns / COMPAT.png
Last active March 13, 2018 19:45
github conflicting PRs
COMPAT.png
@ajtowns
ajtowns / RESULTS.txt
Last active April 12, 2018 07:27
bitcoin PRs, nits and reviews
veto: (5 PRs)
11653 by:NicolasDorier NAK: luke-jr CONFLICTS -- [RPC] Add utility getsignaturehash
10593 by:luke-jr NAK: sdaftuar CONFLICTS -- Relax punishment for peers relaying invalid blocks and headers
10574 by:practicalswift NAK: luke-jr -- Remove includes in .cpp files for things the corresponding .h file already included
10040 by:JohnDolittle NAK: petertodd CONFLICTS -- wallet: use headers chain for anti fee sniping
9749 by:luke-jr NAK: sdaftuar CONFLICTS -- If -spkreuse=0, ensure transactions in mempool always have unique scriptPubKeys
veto-controversial: (7 PRs)
11802 by:luke-jr NAK: TheBlueMatt conceptACK: jonasschnelli -- RPC/Wallet: Refuse to dumpprivkey for derived addresses
#include <stdio.h>
#include <stdlib.h>
#include <assert.h>
typedef unsigned char u8;
const u8 OP_MASK = 0x50;
const u8 OP_0 = 0x00;
const u8 OP_1NEG = 0x4f;
const u8 OP_1 = 0x51;
@ajtowns
ajtowns / README.md
Last active September 10, 2019 11:42
p2p PR dashboard

As an idea to make it easier to keep track of review work for P2P related stuff, maybe we could use a github project as a dashboard.

Turns out you can do this on a personal project board by creating notes saying things like "bitcoin/bitcoin#16401" and it turns into a bitcoin PR like magic. So I've made a trial:

https://github.com/users/ajtowns/projects/1

Should make it easy to pick what to work on:

@ajtowns
ajtowns / bips.txt
Last active January 2, 2024 01:58
bip-activation-history
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):
@ajtowns
ajtowns / forced_signalling_chaos_cost_sim.py
Last active April 6, 2021 02:44
Estimate losses to miners with forced signalling
#!/usr/bin/env python3
import math
import random
# twitter thread -- https://twitter.com/ajtowns/status/1321277134225043457
class Tester:
good_chain = 0
bad_chain = 0

What do you think of just generalising feature negotiation so it's comprehensive?

Suppose "VERSION 80000+" specifies:

initiator sends a VERSION message responder sends a VERSION message

after having both send and received a VERSION message specifying a version >= 80000, both nodes must specify FEATURE support by

@ajtowns
ajtowns / known-dest-vault.md
Last active September 9, 2021 12:24
vault with fixed destination

Idea is that you go from a "vault" state to "unvault" state to "spend" state via the hot wallet keys, with a fixed delay between unvault/spend, and the ability for the cold wallet holder to verify that the spend tx is valid, and if it's not for the cold wallet holder to be able to recover the funds during the delay, before they're lost/stolen/etc.

  Spend:
    input:
      U:0 - witness: ipk = ColdK, HColdKN, S, []
    outputs: