harding

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

[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

[This is a transcript of Craig Wright's presentation at the Future of Bitcoin conference on 30 June 2017. This transcription should not be seen as an endorsement of Mr. Wright, a person who previously fraudulently claimed to be the creator of Bitcoin, among many other fraudulent claims.

Note that ellipses in the text ("...") represent the speaker trailing off or switching topics mid-sentence, rather than the omission of any text by the transcriber. All comments and additions from the transcriber appear between square brackets.

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

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

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

1195000000000 1aae9d58e8826aa65ce985061a78642ec2d920e8a8bb1679aae35f7d496d25b4 2009-10-22
1225000000000 5d79327054118bfc51475b82319d11e041e23b581d36a4ff47302b95380a735e 2009-10-24
1300000000000 3cd9410fc4642ce3e4591f5f5600965bf5b104c81160d204afb2d9169c5b4ce8 2009-10-27
1550000000000 6029e51c4706c8b12bfdc9bab2311cc99d7fd5ccca3701bff4af2935c4a89215 2009-11-04
1550000000000 1043eb5c8b85764358f21127ed51de772db594222d650be07b45f3a9c68bdc78 2009-11-10
1450000000000 c6dbae4c8ca97a746030b390441cdfc750218a20b07d29b56f07b157cdc0bbd3 2009-11-10
1350000000000 b34d15d7b7e6c2a4333fe13f354de1d715b7d8d00ec86b4cf0f8d24bfa71a2e1 2009-11-10
1250000000000 a40d0843b9868a26792e952851a082442eace99f2c384f0ed6ca991612fd2f60 2009-11-10
1150000000000 0b8f2d77c16afaa08435d71cd31467e62011cc39fe1d1318959bc74f1ad5b064 2009-11-10
1050000000000 214f42239036b95ba5dd94f9969b4b4eb8485de51a458fe76cabe95b510b4468 2009-11-10

harding

Manifest

• gitian-verify/
  • README.md
  • step_1/
    • verify-keys.sh
    • fingerprints.txt
    • signatures/
      • ...
• step_2/

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

#!/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