| 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: |
| 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; |
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:
| 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): |
| #!/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
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: