Skip to content

Instantly share code, notes, and snippets.


David A. Harding harding

View GitHub Profile
View excerpt-taproot-activation.txt
Excerpted from
[9:30:31 am] <viaj3ro> best argument for LOT=false imho is that 91% of
miners signaled support for LOT=false and might activate quickly if
chosen. If LOT=true is chosen, they might refuse and we'll have to wait
the full year
[9:31:14 am] <luke-jr> viaj3ro: that is not based in reality..
[9:32:03 am] <viaj3ro> it's an assumption, obviously. but still based on public information
View broken.txt
[The proposal below is flawed because it doesn't work for presigned transactions that use BIP68,
such as those proposed for LN anchor outputs or for timelock vault proposals. It's probably
flawed in other ways too. I'm posting this in case it helps anyone else learn from my mistakes.]
On Sun, May 03, 2020 at 12:26:02AM +1000, Anthony Towns via bitcoin-dev wrote:
> [After updating the transaction digest to commit directly to
> scriptPubKey] we'd arguably still be missing:
> [...]
> what was the height of the coin? (Coin.nHeight)
harding /
Created Jan 28, 2020
A description of joinpools elided from Optech Newsletter #48

*Bitcoin Optech [Newsletter #48][] described Jeremy Rubin's OP_CHECKOUTPUTSHASHVERY (COSHV) soft fork proposal. Originally, that content included descriptions of several advanced uses of COSHV, but that material was [removed][] shortly due to publication because of concerns that it was not adequately reviewed and so may have contained errors. Optech initially planned to obtain more reviews and publish the extra content the following week but, by then, the COSHV proposal was withdrawn in favor of a modified proposal with a new name, so the extra content went into limbo. The following section comes from that lost content; it has not been updated since the original COSHV proposal

harding / bitcoin-core-pr-reviews-2019-05-01.txt
Created May 1, 2019
First meeting for the Bitcoin Core PR Review Club, hosted by John Newbery
View bitcoin-core-pr-reviews-2019-05-01.txt
13:01 <@jnewbery> Hi folks!
13:01 < harding> Hi!
13:01 < dmkathayat> Hello!
13:01 < schmidty> hola
13:01 < amiti> hi!
13:01 < bilthon> hi there
13:01 <@jnewbery> We usually start Bitcoin Core IRC meetings with a 'hi' so it's clear who's at keyboard. Feel free to say hi here!
13:01 < kcalvinalvin> Hi
13:01 < peevsie> hi!
13:02 < emzy> Hi
View open-rpc-ports.txt
2018-10-20 19:30 UTC
## Trial 1
Nmap done: 8440 IP addresses (4486 hosts up) scanned in 446.64 seconds
$ grep Ports.*/tcp/ -c
$ grep Ports.*/open/tcp/ -c
harding /
Created Aug 8, 2018
Suggestions for how to best get along with other Bitcoiners on the Fediverse (Mastodon/GNU Social/Pleroma/ActivityPub/Etc)

Price toots

Some people really don't want to hear about the price! But this is other people's favorite topic. If you adhear to the following two rules whenever talking about price, or something related to the price like altcoin prices, we should all be able to continue interacting about our common interests in Bitcoin:

  1. Use a Content Warning (the CW in the Mastodon user interface) to allow people to opt-into seeing your price-related information and images. Note that replies to CW-content are also automatically wrapped in the same CW.
harding /
Created Jul 23, 2018
Description of Tim Ruffing's upgrade path to post-quantum in presence of QC attackers

Background: future fast Quantum Computers (QCs) are hypothesized to be much faster at solving various forms of the Discrete Log Problem (DLP) than classical computers (e.g. what we use now). Bitcoin uses the DLP in what's called a trapdoor function: a function that's easy to compute one way (a private key generating a public key) but hard to compute the other way (using a public key to recover the original private key). Fast QCs break that trapdoor, hypothetically allowing the operator of the QC to steal the bitcoins from anyone whose public key is publicly known.

harding /
Created Jul 21, 2018
Quick script to count nodes in Luke's seeder data
#!/bin/bash -eu
while git checkout HEAD~30
date=$( git log -1 --date=unix | grep ^Date | awk '{ print $2 }' )
echo -n "$date " >> $DATA
## $8 is the 30d uptime; 5..100 shows nodes with uptime >= 5%


  • gitian-verify/
    • step_1/
      • fingerprints.txt
      • signatures/
        • ...
    • step_2/
harding / arbitrary-data.txt
Created Mar 19, 2018
Response to a journalist about including arbitrary data in the block chain
View arbitrary-data.txt
On Mon, Mar 19, 2018 at 10:07:12AM -0700, [redacted] wrote:
> Hi David,
> I'm working on a piece about how the Bitcoin blockchain can accommodate
> arbitrary data, potentially making it illegal in certain countries and
> circumstances. The paper about this can be found here:
> I'm wondering whether you might be available to comment before 1pm PT today.