Skip to content

Instantly share code, notes, and snippets.

View Rucknium's full-sized avatar

Rucknium Rucknium

View GitHub Profile

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.

@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

@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 / 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 / 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 / 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 / qubic-monero-hashpower-share.md
Last active August 3, 2025 14:13
Qubic Monero Hashpower Share

Qubic Monero Hashpower Share

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.

Qubic's purported Monero wallet view key is here: https://github.com/qubic/outsourced-computing/blob/score-tracker/monero-poc/README.md#qubics-monero-wallet-address