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

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

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

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 argparse
import binascii
import hashlib
import io
import struct

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

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

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

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

Vulnerabilities in the Bitcoin Alert system

Background

The Alert System previously utilized by Bitcoin has several issues (some of which may be classified as vulnerabilities). These issues no longer exist in Bitcoin as of network protocol version 700013 which was released with Bitcoin Core 0.13.0. Many altcoins and Bitcoin client implementations were notified of the Alert System's removal and have since removed the alert system themselves or transitioned to using an Alert system that does not share an Alert Key with Bitcoin.

All of the issues described below allow an attacker in possession of the Alert Key to perform a Denial of Service attack on nodes that still support the Alert system. These issues involve the exhaustion of memory which causes node software to crash or be killed due to excessive memory usage.

Many of these issues were not known until the Alert System was removed as developers inspected the code for vulnerabilities prior to releasing the Alert Key. Due to these issues, the publicat

achow101

Simulations Results for SRD Fallback strategies

SRD Fallback

Simulation File	final value	mean #UTXO	final #UTXO	#received	#spent	#payments sent	#changes created	min change	max change	mean change	stDev of change	total fees	average fees	fees to spend remaining UTXO	total cost	min input set	max input set	mean size of input set	stdev of input set size	BnB Usage	SRD Usage
derived-1I-2O-statoshi-6block.csv	115.55086265	102.27	139	6097	16424	11565	10467.00000000	0.00007778	10.10469422	0.94600269	1.21818317	-2.35333207	-0.00020349	-0.00020572	-2.35353779	1	14	1.42014700	1.17345193	1098	10467
derived-balanced-statoshi-6block.csv	106.49087057	199.77	287	12194	20883	11600	8976.00000000	0.00002474	9.94578008	0.70230363	1.07709449	-2.54395062	-0.00021931	-0.00042476	-2.54437538	0	22	1.80025862	1.622