grunch / rana

Nostr public key mining tool

Hi there 👋

• 🌎 I'm passionate about the open source and free knowledge to all the people
• ⚡ Interested in Bitcoin, specially on Lightning Network
• 🦀 I love software development and Rust

🐦 https://twitter.com/negrunch

If you want to support my work consider to make a donation to: https://getalby.com/p/grunch

Nostr nip05: [email protected] ln address: [email protected]

rana's Issues

Separate vanity hex search logic from vanity `npub`

The hex and npub vanity searches are both looking at the beginning of the pubkey/npub.

But since the one determines the other, you can't have an arbitrary hex prefix simultaneously searching for an arbitrary npub prefix. For example:

-v 0 -n k

will never find a match.

So the two searches can just be pulled out into their own if/else cases without any overlapping search logic.

NIP06/BIP39/BIP32 seed phrases for key derivation

Following NIP06, generate private keys using derivation path m/44'/1237'/0'/0/0 so the original source seed phrase is known for the derived private key and vanity public key or npub1 public key.

Fix nip13 URL in README

The new URL is: https://github.com/nostr-protocol/nips/blob/master/13.md

Panic when using package installed through cargo

Hey, I'm trying to follow the README but I'm running into an issue when using the --vanity flag. When I use --vanity-n-prefix=testing it seems to work (Started mining process for vanity bech32 prefix[es]:...). I installed rana through via cargo.

Is this expected behaviour or am I doing something wrong?

Thanks!

~|⇒ rustup show
Default host: x86_64-apple-darwin
rustup home:  /Users/philipp/.rustup

stable-x86_64-apple-darwin (default)
rustc 1.67.0 (fc594f156 2023-01-24)
~|⇒ rana --version
Rana 0.5.1
~|⇒ rana --vanity=testing
thread 'main' panicked at 'The vanity prefix can only contain hexadecimal characters.', /Users/philipp/.cargo/registry/src/github.com-1ecc6299db9ec823/rana-0.5.1/src/cli.rs:138:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Non working commands in README.md

I've been trying theses command from the readme without succes:
rana --vanity-n-prefix=rana
I guess commands changed but not README.md

Option to specify a suffix

Some clients show a few characters at the start, and few at the end. Would be awesome to specify in addition or exclusive of other parameters.

rana got very slow

Hi

With commit 65ef1a2 rana got very slow. I tested this on x86 and Apple Silicon hardware. I switched back to commit 627cf1e and got the speed back I was used to with rana.

on my hardware with commit 627cf1e I got about 500k/sec and all newer version only 70-80k/sec.

In both cases I built the binary with cargo build release.

Default `difficulty` issue

In PR #41, a default value was set for the difficulty of CLIArgs, which made it impossible to specify vanity-n-prefix or vanity-n-suffix unless --difficulty=0 is specified.

cargo install rana will install 0.5.1 but version on github is 0.5.0

I might be trippin

Stop mining after finding a key

It would be nice to be able to stop mining key if one key is found.

`Avg. rate` stats inconsistent

I did a test run and got

Started mining process with a difficulty of: 10
Benchmarking a single core for 5 seconds...
A single core can mine roughly 20904 h/s!
Searching for prefix of 10 zero bits
This is estimated to take about 0.00612323 seconds
Mining using 8 cores...
==============================================
Found matching public key: 000ababa0f00221db06d93de44d083cad32e3456e938424b0f934b8d288ac963
Leading zero bits: 12
365 iterations (about 3x10^2 hashes) in 0 seconds. Avg rate 16590 hashes/second
Nostr private key: 09e5cefafa65da27c15cc91fdc63d4879494f4096f1404ca33f2a32ac51baf03
==============================================
Found matching public key: 00053b5d9378f2de342f42269b76108078214072b24ba329f5244f5da589594f
Leading zero bits: 13
2012 iterations (about 2x10^3 hashes) in 0 seconds. Avg rate 16491 hashes/second
Nostr private key: e1cdbb344d99f0e293f93127c6e3eaf8f059f46532cab62953bf986c0d3b6437
==============================================
Found matching public key: 00011964a047969405f12e9108f6c54d119903f4fcd248d54d9a07bae0295eff
Leading zero bits: 15
6729 iterations (about 6x10^3 hashes) in 0 seconds. Avg rate 16533 hashes/second
Nostr private key: 7c2209291010083548bf9ae25bb2b6fbbe5fd8dd755a7f555bee594929f3c346
==============================================
Found matching public key: 00001b461dbf01de2efc44f12b70bdb528aa163db6a7712ccb9c52c0be97c636
Leading zero bits: 19
12143 iterations (about 1x10^4 hashes) in 0 seconds. Avg rate 16365 hashes/second
Nostr private key: 74e70eb2b42ffa50cf0a2e2badd94b418d2b05a26d7b37c52676f7590eea5005
==============================================
Found matching public key: 00000d79d673013b71f38d3483f4f2c5a6c5b7cc853347489ca031e6e3c5e0af
Leading zero bits: 20
53647 iterations (about 5x10^4 hashes) in 3 seconds. Avg rate 16476 hashes/second
Nostr private key: 175111e1142d752eac20c9520a00cafc9babbdf30e4e116c57bcdfae403ec84e
==============================================
Found matching public key: 000003e8edf47c7f80bfc5ec19f3f7372909e19070b1b19bf1d44b13444405ab
Leading zero bits: 22
116162 iterations (about 1x10^5 hashes) in 7 seconds. Avg rate 16472 hashes/second
Nostr private key: 1ce6dd2d8ce17069ba823f060ea50468a175a59dd24914860f627b33f8b417e2
==============================================
Found matching public key: 00000054818d28f99e54b65b2a33be471f17ca1a5dcb14b1a7d92c48eec3641a
Leading zero bits: 25
1586030 iterations (about 1x10^6 hashes) in 102 seconds. Avg rate 15406 hashes/second
Nostr private key: 2d15c21220c07d610cd64af6adb0fe332a7504f8ad56c0853b0c8574a30f1860

Every pubkey found (difficulty 12 - 25) shows avg. rate of about 15-16k hashes/second.

At the top, the benchmark results show a single core can do ~20k h/s.

Yet while it was running and generating those keys, I could see load on all my CPUs (so indeed more than 1 core was used).

So if its using multiple cores, why is the resulting hash rate similar to a single core?

Didn't look at the code yet, but I assume only the iterations of one core (the one that found the key) are counted?

Probably not a proof-of-work

NIP-13 is about id fields (SHA256 hashes) that start with zero bits, not about public keys that start with zero bits.

Although this project generates public keys randomly, there is no proof that anyone presenting a public key that starts with zeroes did so randomly. A public key on the elliptic curve could probably be constructed with lots of leading zeroes if you understood the cryptography well enough (I don't).

So I think this idea doesn't quite work.

Nonetheless I put in a pull request to speed it up.

Syntax for specifying multiple npub prefixes varies

On macOS, the guidance in the README for specifying multiple npub prefixes works fine.

On Linux (bash on Ubuntu) that syntax threw an error...and while cargo run --release -- --vanity-n={pref0,pref2,pref3} and the expanded cargo run --release -- --vanity-n=pref0 --vanity-n=pref2 --vanity-n=pref3 don't throw errors, the program indicates it's only looking for the last prefix:

Started mining process for a vanify prefix of: '' and 'npub1pref3' (estimated pow: 20)

How long?

Is it possible to estimate how long a PoW of 48 will take. lol

Rana binary

Hi @grunch .

I'm wondering if there is any possibility to have the binary of Rana on the releases.

I would like to have the possibility to put Rana in DTails using only final official binaries.
Due the nature of the remaster process, the system to be modified will be never connected to internet.
(It can be connected to internet, but I don't really would like to put the modified OS online in the build process for security reasons)

Thanks for your time and for giving Rana 🐸 to us.
Regards!

6 char postfix

PoW 24 took
707715233 iterations (about 7x10^8 hashes) on RPi 4B 4GB ~175000sec
Could shown estimation be based onto mips/bogomips/CPU or something and show estimated sec/hour/day/months?

regular expressions or multiple parameters

it would be nice to search for several matching parameters
example

$ rana --difficulty=20 --vanity=dead --vanity-n=rana,h0dl,n0strfan

would search for and print: leading zero bits, vanity, vanity-n, etc

Regex is complicated and I know everyone hates it, maybe just running multiple parameters would be equivalent of an OR statement.

mining with GPU

Can rana run with GPU?

Feature Request: Pausing

It would be nice to be able to "pause" execution if that's possible, something like using ctrlc:

use std::sync::atomic::{AtomicBool, Ordering};
use ctrlc;

let running = AtomicBool::new(true);
ctrlc::set_handler(move || {
    running.store(!running.load(Ordering::SeqCst), Ordering::SeqCst);
})?;

while running.load(Ordering::SeqCst) {
    // Your program logic here
    if running.load(Ordering::SeqCst) {
        println!("Running...");
    } else {
        println!("Paused...");
    }
    std::thread::sleep(std::time::Duration::from_secs(1));
}

or perhaps implementing a background thread that listens for keyboard input and use channel to communicate with main thread?

use std::sync::mpsc::channel;
use std::thread;
use std::io::{stdin, Read};

fn main() {
    let (tx, rx) = channel();

    thread::spawn(move || {
        let stdin = stdin();
        let mut stdin = stdin.lock();

        loop {
            let mut input = [0u8; 1];
            if stdin.read(&mut input).unwrap() == 0 {
                break;
            }

            if input[0] == b'p' {
                tx.send("pause").unwrap();
            } else if input[0] == b'r' {
                tx.send("resume").unwrap();
            } else if input[0] == b'q' {
                tx.send("quit").unwrap();
                break;
            }
        }
    });

    let mut running = true;
    while running {
        match rx.recv().unwrap() {
            "pause" => {
                println!("Paused...");
                running = false;
            },
            "resume" => {
                println!("Resumed...");
                running = true;
            },
            "quit" => {
                println!("Quitting...");
                running = false;
            },
            _ => {}
        }

        if running {
            println!("Running...");
            // some work
            std::thread::sleep(std::time::Duration::from_secs(1));
        }
    }
}

Question: estimating time to completion

I am mining a 7 character npub (estimated POW: 28) using all 8 cores of an Apple M1. rana has running for just under 4 days, with no results so far.

Is this within reason, or should I assume that something has gone wrong?