PoWER

[hinto-janai]

Implements monero-project/research-lab#133.

[hinto-janai]

Main document describing what PoWER is and how to follow it.

[hinto-janai]

Main PoWER functions/data.

[hinto-janai]

Here's the program that these numbers are from, it tests a few difficulty values using the equivalent Cuprate PoWER impl.

A difficulty somewhere in-between 100~150 seems good if we're targeting 1s of single-threaded compute on consumer hardware.

cargo new power
cd power # replace src/main.rs with the code below 
git clone https://github.com/hinto-janai/cuprate -b power # clone power impl
cargo r -r # run code

//! ```Cargo.toml
//! [package]
//! name = "power"
//! version = "0.1.0"
//! edition = "2024"
//!
//! [dependencies]
//! cuprate-power = { path = "cuprate/power" }
//! rand = "*"
//! ```

fn main() {
    let d = [0, 25, 50, 75, 100, 125, 150, 175, 200, 225, 250, 275, 300];
    let iter = 400;

    println!("Testing {iter} iterations for each difficulty: {d:?}");

    let hashes: Vec<([u8; 32], [u8; 32])> = (0..iter)
        .map(|_| (rand::random(), rand::random()))
        .collect();

    let start = std::time::Instant::now();

    for difficulty in d {
        let mut average = 0.0;
        let mut rate = 0.0;

        for (i, (tx_prefix_hash, recent_block_hash)) in hashes.iter().enumerate() {
            cuprate_power::solve_rpc(*tx_prefix_hash, *recent_block_hash, difficulty);

            let i = i as f64;
            let elapsed = start.elapsed().as_secs_f64();
            average = elapsed / i;
            rate = i / elapsed;
        }

        println!("Difficulty: {difficulty}, Average: {average:.4}s, Rate: {rate:.4}/s");
    }
}

[hinto-janai]

The difficulty functions (and the challenge construction) are derived from Tor's PoW: https://spec.torproject.org/hspow-spec/v1-equix.html, although our functions are slightly different.

[hinto-janai]

Equivalent Rust impl and tests with the same input/output are here: Cuprate/cuprate#568.

[hinto-janai]

The P2P PoWER flow:

1. Node A initiates handshake with node B
2. B sends handshake response which now includes a PoWER challenge
3. A solves the challenge (in do_handshake_with_peer) and sends the solution to B via NOTIFY_POWER_SOLUTION
4. B now skips PoWER checks when receiving transactions from A

Worth noting:

• After A solves PoWER for B, A will also enable PoWER for B for free, i.e. only nodes initiating connections expend compute
• The difficulty is always set to DIFFICULTY although technically it's adjustable, see MAX_DIFFICULTY in power.h
• Sending a NOTIFY_POWER_SOLUTION (solving the challenge) is technically optional, although you won't be able to send high-input transactions without it

[hinto-janai]

monero-project/research-lab#133 (comment)

requiring PoW on connection attempts [...] since it would obligate an attacker to expend the same amount of CPU in order to relay a single bad tx (assuming we modify nodes to ban connections that relay txs that fail to verify)

Sending high-input transactions without PoWER eventually leads to a ban here.

[hinto-janai]

ZMQ-RPC re-uses RPC functions, i.e. each send_raw_tx/send_raw_tx_hex call requires PoW, although I think we can skip it? ZMQ-RPC assumes it isn't public (although there is no check or restricted version).

[hinto-janai]

I've added PoWER here when sending a TX to a daemon, should other wallet code be changed?

[hinto-janai]

https://github.com/tevador/equix/blob/master/LICENSE

https://gitlab.torproject.org/tpo/core/arti/-/blob/main/doc/LGPL-and-rust.md

I'm not sure how this mixes with Monero's current licensing.

[hinto-janai]

Opened for initial review. FYI I think this will have merge conflicts with #184.

edit: resolved conflicts.