Files
addressgen/README.md

7.9 KiB

Generatore di Indirizzi Bitcoin

Questo programma permette di generare diversi tipi di indirizzi Bitcoin in modo semplice e interattivo. L'output prodotto include chiavi private, chiavi pubbliche, indirizzi e formati WIF, e può essere salvato in file JSON.

Per la verifica della validità degli indirizzi, è stato utilizzato lo strumento esterno SecretScan.

Attualmente il programma supporta i seguenti tipi di indirizzi:

  • P2PK (Pay-to-PubKey)
  • P2PKH (Pay-to-PubKey-Hash)
  • P2SH (Pay-to-Script-Hash, con supporto multisig)
  • P2WPKH (Pay-to-Witness-PubKey-Hash, SegWit v0)
  • P2TR (Pay-to-Taproot, SegWit v1)

Sono in fase di sviluppo anche:

  • P2WSH (Pay-to-Witness-Script-Hash)

Come funziona il programma

Il file principale è main.py. Quando viene eseguito, mostra un menu interattivo che consente di scegliere il tipo di indirizzo da generare:

python main.py

Esempio di esecuzione:

=== GENERATORE INDIRIZZI BITCOIN ===
Seleziona il tipo di indirizzo:
1. P2PK
2. P2PKH
3. P2SH
4. P2WPKH
5. P2TR

Dopo aver selezionato un'opzione, lo script dedicato verrà eseguito e guida l'utente attraverso:

  • Scelta della rete (mainnet, testnet, regtest)
  • Eventuale utilizzo di chiavi compresse/non compresse
  • Visualizzazione e salvataggio dei dati in un file .json

Ogni script è indipendente (backend/p2pk.py, backend/p2pkh.py, backend/p2sh.py, backend/p2wpkh.py, backend/p2tr.py) e implementa le regole specifiche del relativo standard Bitcoin.


Tipologie di indirizzi supportati

1. P2PK (Pay-to-PubKey)

  • Standard: Formato originale di Bitcoin, definito nel whitepaper di Satoshi Nakamoto
  • Formato indirizzo: Non ha un formato di indirizzo standard, usa direttamente la chiave pubblica
  • Script: <pubkey> OP_CHECKSIG
  • Pro: molto semplice, rappresenta direttamente la chiave pubblica, dimensioni di transazione minime
  • Contro: obsoleto, non compatibile con la maggior parte dei wallet moderni. Espone la chiave pubblica subito alla blockchain, vulnerabile agli attacchi quantistici
  • Uso attuale: Principalmente per coinbase transactions e casi molto specifici

2. P2PKH (Pay-to-PubKey-Hash)

  • Standard: BIP-13 (Base58Check), formato legacy standard
  • Formato indirizzo: Inizia con '1' (mainnet), 'm' o 'n' (testnet)
  • Script: OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG
  • Codifica: Base58Check con prefisso 0x00 (mainnet)
  • Pro: è lo standard "legacy", molto diffuso, supportato da tutti i wallet ed exchange. Protezione contro attacchi quantistici (hash della chiave pubblica)
  • Contro: gli indirizzi sono più lunghi e le fee di transazione sono più alte rispetto a quelli più moderni (SegWit), dimensioni di transazione maggiori

3. P2SH (Pay-to-Script-Hash)

  • Standard: BIP-16 (Pay to Script Hash), BIP-67 (Deterministic Pay-to-script-hash multi-signature addresses)
  • Formato indirizzo: Inizia con '3' (mainnet), '2' (testnet/regtest)
  • Script: OP_HASH160 <script_hash> OP_EQUAL
  • Codifica: Base58Check con prefisso 0x05 (mainnet), 0xC4 (testnet/regtest)
  • Pro: permette indirizzi basati su script arbitrari, ideale per multisig e contratti complessi. Supportato da tutti i wallet moderni. Maggiore flessibilità e funzionalità avanzate
  • Contro: le fee sono leggermente più alte rispetto ai singoli indirizzi e richiede la rivelazione dello script al momento della spesa. Dimensioni di transazione maggiori per il redeem script

Implementazione attuale: Multisig Attualmente il supporto P2SH è limitato agli script multisig, che rappresentano il caso d'uso più comune per P2SH.

Opzioni disponibili per l'utente:

  • Configurazione m-of-n: l'utente può scegliere quante firme sono richieste (m) su un totale di chiavi (n)
    • Esempi: 2-of-3, 3-of-5, 1-of-2, ecc.
    • Limite: 1 ≤ m ≤ n ≤ 16
  • Rete: mainnet, testnet, regtest
  • Chiavi compresse: opzione per utilizzare chiavi pubbliche compresse (33 byte) o non compresse (65 byte)
  • Ordinamento BIP67: le chiavi pubbliche vengono automaticamente ordinate per evitare malleabilità

Funzionalità implementate:

  • Generazione automatica di n coppie di chiavi (privata/pubblica)
  • Creazione del redeem script multisig
  • Calcolo dell'hash160 del redeem script
  • Generazione dell'indirizzo P2SH finale
  • Output JSON strutturato con tutti i dati necessari
  • Esportazione delle chiavi private in formato WIF
  • Salvataggio completo in file JSON per backup e utilizzo futuro

4. P2WPKH (SegWit v0, Bech32)

  • Standard: BIP-141 (Segregated Witness), BIP-173 (Base32 address format)
  • Formato indirizzo: Inizia con 'bc1q' (mainnet), 'tb1q' (testnet), 'bcrt1q' (regtest)
  • Script: OP_0 <pubkey_hash> (20 bytes)
  • Codifica: Bech32 con HRP 'bc' (mainnet), 'tb' (testnet), 'bcrt' (regtest)
  • Witness Program: versione 0, 20 bytes (hash160 della chiave pubblica)
  • Pro: riduce le fee grazie al formato SegWit (witness data separato), indirizzi più compatti, supportato da quasi tutti i wallet moderni, protezione contro transaction malleability
  • Contro: non tutti i vecchi servizi accettano Bech32, richiede supporto SegWit

5. P2TR (Taproot, SegWit v1, Bech32m)

  • Standard: BIP-340 (Schnorr Signatures), BIP-341 (Taproot), BIP-342 (Tapscript), BIP-350 (Bech32m)
  • Formato indirizzo: Inizia con 'bc1p' (mainnet), 'tb1p' (testnet), 'bcrt1p' (regtest)
  • Script: OP_1 <taproot_output> (32 bytes)
  • Codifica: Bech32m con HRP 'bc' (mainnet), 'tb' (testnet), 'bcrt' (regtest)
  • Witness Program: versione 1, 32 bytes (tweaked public key)
  • Pro: sono i più recenti, con maggiore privacy e flessibilità (supporta script complessi nascosti dietro un singolo indirizzo). Le fee sono basse, firme Schnorr più efficienti, aggregazione delle firme
  • Contro: ancora relativamente nuovo, non supportato da tutti i servizi, complessità implementativa maggiore

In sviluppo

  • P2SH (Pay-to-Script-Hash): permette indirizzi basati su script arbitrari, molto usato per multisig e contratti complessi.
  • P2WSH (Pay-to-Witness-Script-Hash): versione SegWit del P2SH, più efficiente e sicura.

Utilizzo pratico

Versione Node.js usata per l'installazione delle dipendenze frontend/backend: v18.20.4.

  1. Clona o scarica il repository.

  2. Assicurati di avere Python 3 installato e i requisiti:

    # Consigliato ambiente virtuale
    python -m venv venv
    source venv/bin/activate
    
    # Installazione requisiti
    pip install -r requirements.txt
    
  3. Esegui il programma principale:

    python main.py
    
  4. Segui le istruzioni sullo schermo per generare e salvare il tuo indirizzo.

I dati saranno salvati in un file .json leggibile e riutilizzabile.


Sviluppo

Per eseguire l'app in modalità sviluppo è necessario avere l'ambiente virtuale Python attivo, altrimenti il backend non trova le dipendenze (es. fastapi).

  1. Attiva il venv e installa i requisiti (se non l'hai già fatto):
    python -m venv venv
    source venv/bin/activate
    pip install -r requirements.txt
    
  2. Avvia tutti i servizi di sviluppo:
    npm run dev
    

Build desktop (GUI unica)

La GUI desktop è unita (frontend + backend) tramite Electron. Il build va eseguito sulla stessa architettura del sistema target (ARM su Raspberry, x86_64 su PC).

  1. Installa le dipendenze:
    npm install
    python -m venv venv
    source venv/bin/activate
    pip install -r requirements.txt
    
  2. Build completo per l'architettura corrente:
    npm run build
    
  3. Oppure build esplicito per architettura:
    npm run build:linux:arm64
    npm run build:linux:x64
    
  4. Trovi l'AppImage in release/.

Nota su x86_64: per eseguire l'AppImage serve FUSE v2 (libfuse2).

Nota: non è possibile creare un singolo eseguibile che funzioni sia su ARM che su x86_64. Servono build separate.


LICENZA

Questo progetto è rilasciato sotto licenza MIT