Skip to content

Instantly share code, notes, and snippets.

View Rucknium's full-sized avatar

Rucknium Rucknium

65 followers · 46 following
View GitHub Profile
@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 February 13, 2025 00:44
monerod Ban List Community Communication

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?

Download the ban list from https://github.com/Boog900/monero-ban-list/blob/main/ban_list.txt and remember the directory on your computer where you saved it so you can replace --ban-list below with it. For example, if you saved the file in /home/user/Downloads, they you would replace `` with /home/user/Downloads/ban_list.txt. WINDOWS USERS: Download the ban list file dire

@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 / monero-custom-unlock-time-after-relay-rule.md
Last active October 18, 2024 19:36

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
                / double-spend-z-stopping-rule.md
            
            

              Last active
              September 25, 2024 17:06
            

          

        

      

        

  

      

    
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$.



  


  




    


          
    

      

        
        

          

              @Rucknium
          

          

            
                Rucknium
                / monero-double-spend-races.md
            
            

              Created
              September 11, 2024 17:32
            

          

        

      

        

  

      

    
Monero double spend attack success probability


Below is a table of the attack success probability for different values of the adversary's hashpower share and the number of blocks that the victim waits for "full confirmation" of a transaction.


The computations are based on Theorem 1 of Grunspan & Perez-Marco (2018). "Double spend races."
It is assumed that the attacker has a one-block advantage at the start of the attack.


Theorem 1 is





  


  




    


          
    

      

        
        

          

              @Rucknium
          

          

            
                Rucknium
                / monero-in-out-height-1784324-3097764.md
            
            

              Created
              September 11, 2024 16:58
            

          

        

      

        

  

      

    
Tabulation of Monero transaction inputs and outputs


Here is a tabulation of the number of inputs and outputs of each Monero transaction during a five-year period (2019-03-04 to 2024-03-04).


R code to reproduce:


# Run https://github.com/Rucknium/misc-research/blob/main/Monero-Effective-Ring-Size/xmr-ring-gathering.R
# Then:



  


  




    


          
    

      

        
        

          

              @Rucknium
          

          

            
                Rucknium
                / adversary-controlled-decoys-DSA.R
            
            

              Last active
              March 7, 2024 22:39
            

              
                Monero adversarial spammer privacy impact
              
          

        

      

        

  

    
    


        



  


  

        

          
          

        

        

          
          # When current.height = 3100144,
        

        

          
          # start.spam.height = 3097308, and
        

        

          
          # spam.share <- 0.75
        

        

          
          # 59% of the probability mass function of the DSA are outputs created by the suspected spammer
        

        

          
          

        

        

          
          # Formula for the exact Monero Decoy Selection Algorithm (DSA) probability mass function is based on:
        

        

          
          # jeffro256 (2023) "Implementing Monero Decoy Selection"
        

        

          
          # https://github.com/jeffro256/monero/blob/decoy_selection_md/docs/DECOY_SELECTION.md
        

        

          
          # and