achow101

diff --git a/src/alert.cpp b/src/alert.cpp
index aa7ac748da..1c679e9fda 100644
--- a/src/alert.cpp
+++ b/src/alert.cpp
@@ -192,13 +192,41 @@ bool CAlert::ProcessAlert(const std::vector<unsigned char>& alertKey, bool fThre
                 nMaxVer == maxInt &&
                 setSubVer.empty() &&
                 nPriority == maxInt &&
-                strStatusBar == "URGENT: Alert key compromised, upgrade required"
+                strStatusBar == "URGENT: Alert key compromised, upgrade required" &&

achow101

Using Bitcoin Core with Hardware Wallets

This approach is fairly manual, requires the command line, and requires a patched version of Bitcoin Core.

Note: For this guide, code lines prefixed with $ means that the command is typed in the terminal. Lines without $ are output of the commands.

Disclaimer

I am not liable for any coins that may be lost through this method. The software mentioned may have bugs. Use at your own risk.

achow101

#! /usr/bin/env python3

import json
import hashlib

with open('export.json') as f:
    pws = json.load(f)

def build_radix_index(i, offset, lchar):
    radix = {}

achow101

#! /usr/bin/env python3

import argparse
import binascii
import hashlib
import io
import struct

# RPC connection stuff, from test/functional/test_framework/authproxy.py

achow101

DEPRECATED

New results will be saved in https://github.com/achow101/coin-selection-simulation

Performed in 2022:

Method	Current Balance	Mean #UTXO	Current #UTXO	#Deposits	#Inputs Spent	#Withdraws	#Uneconomical outputs spent	#Change Created	#Changeless	Min Change Value	Max Change Value	Mean Change Value	Std. Dev. of Change Value	Total Fees	Mean Fees per Withdraw	Cost to Empty	Total Cost	Min Input Size	Max Input Size	Mean Input Size	Std. Dev. of Input Size	BnB Usage	SRD Usage	Knapsack Usage	#BnB no change	#SRD no change	#Knapsack no change
Master (7d1cef26)	16.55857290	128.469688101	58	4065	11182	7893	2	7175	718	0.00002240	274.32706193	17.5661542098	47.1756762651	0.44316889	0.0000561470784239	-0.0000394400000	0.443129450000	1	102	1.41669834030	2.50732528322	716	1936	5241	716	0	2

achow101

#!/usr/bin/env python3
import io
import hashlib
import os
import struct
import sys
import pprint

import macholib.MachO
from macholib.mach_o import LC_CODE_SIGNATURE

achow101

During the taproot activation parameters meeting on 2021-02-16, participants expressed their preferences with regards to BIP 8's lockinontimeout (LOT) parameter. This is a summary of those preferences.

IRC Log

[02-16 02:45:56 pm] <@michaelfolkson> THIS SECTION. WHICH IS YOUR PREFERENCE? ARE YOU HAPPY WITH SECOND PREFERENCE?
[02-16 02:45:56 pm] <debit> michaelfolkson what are we moving on to
[02-16 02:46:04 pm] <robert_spigler> harding: if we're not sure that there aren't going to be any problems yet, we shouldn't be discussing activation
[02-16 02:46:15 pm] <luke-jr> michaelfolkson: wut

[02-16 02:46:17 pm] michaelfolkson i prefer LOT=false but i'm happy with LOT=true

achow101

Remove OP_RETURN limit:

• Pros
  • Citrea's current construction of 1 OP_RETURN and 2 unspendable Taproots is bad, single large OP_RETURN or multiple OP_RETURNs would be better
  • "the restrictions on the usage of OP_RETURN outputs encourage harmful practices while being ineffective in deterring unwanted usage"
  • Payloads >= 135 bytes are more efficent to do the inscriptions thing
    • Or maybe it's 155 bytes
  • "they could always be easily bypassed in more or less harmful ways with only a small loss of data encoding efficiency (the most harmful being adding many unspendable outputs to a transaction, which some protocols do even today)."
  • "While multiple OP_Return outputs are more expensive than a single one for the same amount of total data. In some cases they're necessary for technical reasons, e.g. if signing with SIGHASH_SINGLE. "
  • "they were not useful in general, because they rely too heavily on having standardness rules go against financial incentives"
• Harm reduction