Skip to content

Instantly share code, notes, and snippets.

View Rucknium's full-sized avatar

Rucknium Rucknium

View GitHub Profile
@Rucknium
Rucknium / Paths-to-majority-hashpower-Qubic-epoch-177.md
Last active September 10, 2025 15:11
Paths to majority hashpower for Qubic epoch 177

Plots for Qubic epoch 177: 2025-09-03 12:00:00 UTC to 2025-09-10 12:00:00 UTC (Monero block heights 3491984 to 3496939)

See "Paths to majority hashpower" section of Temporary rolling DNS checkpoints for explanation.

Table: Blocks mined by pools during Qubic Epoch 177

| | all time blocks| all time share (%)| marathon blocks| marathon share (%)|

Vertcoin (VTC) was 51% attacked

Preamble

Vertcoin is a Bitcoin clone that aims to be ASIC-resistant by hard forking to new mining algorithms whenever ASICs are deployed on the network. Vertcoin was previously 51% attacked in Dec 2018 and has since changed its proof-of-work algorithm to Lyra2REv3. On Nov 30th 2019, a Vertcoin miner noticed a large upswing in hashrate rental prices for Lyra2REv3 on Nicehash. This was combined with workers connected to Nicehash's stratum server being sent work for unknown (non-public) Vertcoin blocks. I contacted Bittrex, Vertcoin's most prominent exchange, to recommend they disable the Vertcoin wallet on their platform once it became clear an attack was in progress, which they subsequently did.

The Attack

On Sunday, 1 December 2019 15:19:47 GMT 603 blocks were removed from the VTC main chain and replaced by 553 attacker blocks. We

@Rucknium
Rucknium / qubic-monero-hashpower-share.md
Last active August 14, 2025 22:39
Qubic Monero Hashpower Share

Qubic Monero Hashpower Share

UPDATE 14 AUGUST 2025: Plots of blocks mined by solo miners and unknown pools are available at moneroconsensus.info.

UPDATE 31 JULY 2025: Qubic has changed the view key of its mining wallet. This Gist can no longer use the previous methodology to estimate Qubic's hashpower share. I am working on a realtime web app to display Qubic-related information.


Qubic claims to be mining a large number of Monero blocks. This note plots apparent Qubic mining data.

@Rucknium
Rucknium / preliminary-OSPEAD-deployment-risk.md
Last active April 2, 2025 16:58
Preliminary results of risk of OSPEAD deployment without hard fork

TL;DR

PRELIMINARY: When an adversary uses possibly non-optimal classification methods, the privacy risk to users of OSPEAD deployment without a hard fork is lower than the status quo of all users using the current decoy selection algorithm.

Introduction

Below are some very preliminary results on the privacy risk of deploying a new OSPEAD-derived decoy selection algorithm (DSA) in the wallet2 reference software without a hard fork.

Having two DSAs used in the wild can potentially split the Monero anonymity pool into two anonymity puddles. Roughly, the tasks of an adversary are:

@Rucknium
Rucknium / OSPEAD-estimates-with-original-rings.md
Created March 7, 2025 19:52
Plots of original rings and OSPEAD estimates (linear and log vertical scale)

Plots of original rings and OSPEAD estimates (linear and log vertical scale)

These plots are modifications of Figures 13.1 and 13.3 here.

"Rings (without nonstandard txs)" exclude transactions that have a nonstandard fee level and/or have nonzero unlock time. About 6 percent of rings were excluded. Note that there are probably still some remaining transactions with nonstandard decoy selection algorithms, whose ring distributions are later separated in the OSPEAD procedure by the Bonhomme-Jochmans-Robin (BJR) estimator. "Rings (with nonstandard txs)" include the nonstandard transactions. Both sets of data have some weeks excluded.

Notice that at the visual scale of the plots, the

@Rucknium
Rucknium / draft-OSPEAD-getmonero-blog-post.md
Last active March 5, 2025 17:06
Draft OSPEAD getmonero.org blog post

TL;DR

New research reveals the timing of Monero spending patterns in probabilistic form. The research could be used to improve Monero user privacy in the future. In the meantime, Monero users with extreme threat models should be aware that anti-privacy adversaries can leverage timing information to increase the probability of guessing the real spend in a ring signature to approximately 1-in-4.2 instead of 1-in-16.

Introduction

Four technologies protect the privacy of Monero users. Dandelion++ protects users' IP addresses from being linked to their transactions. Confidential transactions hide the amount of value that is transferred between users. Monero's stealth address technique produces one-time-use addresses on the blockchain that cannot be linked to specific wallets without voluntary disclosure of view keys. [Ring signatures](https://www.getmonero.org/resources/mo

@Rucknium
Rucknium / ban-list-community-communication.md
Last active July 15, 2025 20:30
monerod Ban List Community Communication

UPDATE: Please go to the MRL issue for the current version of this notice.

MRL recommendation: Ban spy node IP addresses from connecting to your node

The Monero Research Lab (MRL) has decided to recommend that all Monero node operators enable a ban list of suspected spy node IP addresses. The spy nodes can reduce the privacy of Monero users.

cuprate developer Boog900 discovered these spy nodes and created an IP address ban list. Developers and researchers associated with MRL (list names) have indicated their approval of this list by signing it with their PGP keys.

How do I enable the ban list?

@Rucknium
Rucknium / MAX_INPUTS-MAX_OUTPUTS-analysis.md
Last active January 15, 2025 17:36
Monero FCMP MAX_INPUTS/MAX_OUTPUTS empirical analysis

Monero FCMP MAX_INPUTS/MAX_OUTPUTS empirical analysis

Limiting the number of inputs and outputs allowed in a transaction may reduce the storage space and verification computation costs of Full-Chain Membership Proof (FCMP) Monero transactions. See here for initial discussion. This note is a preliminary attempt to measure the likely cost of different values for the proposed MAX_INPUTS and MAX_OUTPUTS blockchain consensus rule parameters. The analysis uses empirical blockchain data from here, estimated cost per input/output cardinality based on modified Python code (see below) here, and the results of an output consolidation algorithm.

TODO: MAX_OUTPUTS analysis

The output consolidation algorithm attempts to consolidate outputs in the fewest number of "rounds

Below are all non-coinbase transactions with nonzero unlock time confirmed on the Monero blockchain between September 1, 2024 (height 3227566) and October 13, 2024 (height 3258526).

Version 0.18.3.4 of the Monero deamon, which prevents these transactions from entering the node's txpool, was released on August 22, 2024: https://github.com/monero-project/monero/releases/tag/v0.18.3.4

Info on lock time interpretation is here: monero-project/research-lab#78

Data on which mining pool mined each block was collected using https://git.gammaspectra.live/WeebDataHoarder/monero-blocks . Blocks are labeled "P2Pool" when the coinbase transaction has multiple outputs. "<NA>" indicates missing data.

Required possession duration of malicious hashpower for successful double-spend attack with a $z$ stopping rule.

An attacker possesses $q$ share of Monero's hashpower for a duration of $d$ blocks. Honest miners possess $p=1-q$ hashpower share.

Let $z$ be the number of blocks that the potential victim waits for "full confirmation" of a transaction. When a transaction is mined in a block on the honest chain, that means that the transaction has one confirmation, i.e. $z=1$. When another block is mined on the honest chain, $z=2$.