harding

#!/bin/bash -eu

# NO WARRANTY PROVIDED OR IMPLIED.  USE AT YOUR OWN RISK.

###########
## Paths ##
###########
# This is the keypath provided in the Casa recovery email minus the "m"
KEYPATH="/49/0/0"

harding

strategic_hr = 0.25
normal_hr = 0.005
normal_hr = 1 - strategic_hr

a = 1
b = 2
a_1 = 0.9
b_1 = 2.2

assert(a_1 < a)

harding

#!/bin/bash -eu

## Year with the final blocks we want to check.
## Replace with "2024" for market
YEAR=2022
## Block to start scanning backwards from. Replace with "" (empty) to
## scan all blocks.  Use "" (empty) for market
START_BLOCK="770000"

year_epoch=$( date -d "$YEAR-12-31" +%s )

harding

Re: https://twitter.com/super_testnet/status/1725239338533810410

WARNING: this is a five-minute write up in response to a post I saw on X. I haven't thought about this carefully.

Problem: a mobile wallet spender pays a hold invoice that doesn't settle immediately. The spender goes offline. The payment eventually times out far downstream, with each forwarding node settling it offchain until it reaches the initial downstream node. So far, so good, but then the mobile spender is offline when its downstream peer tries to settle with

harding

From a mailing list post I never sent.

The probability of a miner confirming a transaction is directly proportional to that miner's hashrate (ignoring propagation-related effects, including accidental or deliberate selfish mining).

Users who choose to send their unconfirmed transactions directly to miners will likely put more effort into contacting miners with large percentages of total network hashrate and less effort into contacting miners with small percentages of hashrate. For example, if Alice gives

harding

#!/bin/bash -eu

USER=harding
AUTH=FIXME
SCALE_GOAL=withings
MAX_GOAL=maxweight
MAX_WEIGHT=FIXME

current_weight=$( curl -s https://www.beeminder.com/api/v1/users/${USER}/goals/${SCALE_GOAL}.json -G -d auth_token="${AUTH}" | jq .curval ) || exit 1
# bc returns 1 if true, 0 if false

harding

Notice of new option for transaction replacement affecting zero-conf

This version of Bitcoin Core adds a new mempoolfullrbf configuration option which allows users to change the policy their individual node will use for relaying and mining unconfirmed transactions. The option defaults to the same policy that was used in previous releases and no changes to network behavior will occur if everyone uses the default. But, if enough nodes (including nodes used by miners) change their behavior using this option (or a related option provided by other

harding

Covenant-based applications

To compare different proposals to enable [covenants][] on Bitcoin, it would be useful to have a list of everything we would currently like to do with any sort of covenant. My interest is in anything where a plausible case can be made that a significant number of mostly-rational people would pay transaction fees to use the covenant-based application.

For the purpose of this list, I use Anthony Towns's definition of a covenant: "when the scriptPubKey of a UTXO restricts the scriptPubKey in the output(s) of a tx spending that UTXO". This includes (but is not restricted) to the following proposals: BIP118 SIGHASH_ANYPREVOUT (APO), BIP119 OP_CHECKTEMPLATEVERIFY (CTV), OP_CAT in combination with BIP340 schnorr signatures, OP_CHECKSIGFROMSTACK (CSFS), OP_TAPROOT_LEAF_VERIFY (TLUV), and OP_TXHASH/OP_TX.

The covenant-based application doesn't need to be good for Bitcoin as long as there's a reasonable chance people would use it. For example, Bitcoin's main chain may be

harding

    $ gpg --verify SHA256SUMS.asc
    gpg: assuming signed data in 'SHA256SUMS'
    gpg: Signature made Wed 11 Aug 2021 09:10:51 AM HST
    gpg:                using RSA key 637DB1E23370F84AFF88CCE03152347D07DA627C
    gpg: Good signature from "Stephan Oeste (it) <it@oeste.de>" [unknown]
    gpg:                 aka "Emzy E. (emzy) <emzy@emzy.de>" [unknown]
    gpg:                 aka "Stephan Oeste (Master-key) <stephan@oeste.de>" [unknown]
    gpg: WARNING: This key is not certified with a trusted signature!
    gpg:          There is no indication that the signature belongs to the owner.
    Primary key fingerprint: 9EDA FF80 E080 6596 04F4  A76B 2EBB 056F D847 F8A7

harding

Excerpted from http://gnusha.org/taproot-activation/2021-02-16.log

[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