L'avevo già sentita questa, ma a me sembra più una scusa che una motivazione
L'inverter si trova a metà strada tra l'impianto domestico e il contatore, se non viene rilevata attività sulla rete nazionale basterebbe evitare di spingere corrente verso l'esterno invece di spegnere la casa. Infatti la soluzione esiste, ma richiede un premium!

Confermo che attualmente si può godere del 50% di recupero in 10 anni per il fotovoltaico.
I prezzi che avevo visto questa estate per un impianto nuovo (6kW + 10-15 kWh) sono in linea con quelli indicati da gbianchi, ma si può risparmiare qualcosa (intorno al 20-30%) acquistando direttamente i materiali e pagando la manodopera per installazione e connessione.
I prezzi all'ingrosso nel periodo giugno/luglio erano di ~0,5€ / W(h), sia pannelli che accumulo.

Un consiglio paranoico che vorrei dare a gbianchi, visto che prevede di installare delle batterie, è di predisporre anche il funzionamento isolato dalla rete nazionale, per qualche motivo a me oscuro gli inverter tradizionali sono programmati per spegnersi nel momento in cui c'è un black-out, bella presa in giro 
Per l'ultimo punto c'è da stare attenti con le normative che cambiano spesso e in modo imprevedibile, per quanto ne so adesso potrebbe anche essere illegale, ma gli inverter che supportano il funzionamento off-grid ci sono.

Sono quei pirloni di BSV che spammano, inviando pochi sats (quasi sicuramente non spendibili) a una serie di indirizzi che compongono un messaggio promozionale, in fondo ci sono altri output verso indirizzi  più o meno "famosi", in questo modo se vai a cercare su un explorer un indirizzo, ad esempio di satoshi, la prima cosa che vedi è quella pubblicità.
Non è una novità, in molti hanno usato la blockchain di bitcoin allo stesso modo, ma questi sono insistenti e lo fanno in continuazione

EDIT: vedo che hanno smesso dalla scorsa estate, o forse hanno cambiato set di indirizzi o si son resi conto che stavano bruciando troppi soldi, per come sono formati gli indirizzi ho forti dubbi che qualcuno abbia la chiave privata

Magari ricordo male, in caso perdonatemi, ma Bitcoin FIBRE (Fast Internet Bitcoin Relay Engine) non era nato proprio per ridurre al minimo i tempi di propagazione dei blocchi?

EDIT: ricordavo bene, ma vedo che non viene aggiornato dalla versione 0.16 

Lo standard BIP32 è stato proposto nel 2012, ed è stato integrato in Bitcoin Core (ex Bitcoin-qt) diversi anni dopo, probabilmente nel 2016.
Data questa premessa: quasi sicuramente non è un seed di Bitcoin-qt, e se veramente risale al 2010 non è nemmeno un seed standard. Se sei sicuro che si tratti di un Bitcoin-qt devi ritrovare il file wallet.dat, altrimenti bisogna capire di quale wallet stiamo parlando.

BIP32 sono le specifiche per la derivazione delle chiavi a partire da un seed o master key (NON mnemonica, attenzione), mentre BIP39 sono le specifiche per la generazione della mnemonica a partire dal seed (e viceversa, derivazione del seed dalla mnemonica). Le wordlist BIP39 usano 2048 parole che sono state scelte in modo da non avere duplicati sulle prime 4 lettere, o almeno è così per quella inglese.
BIP44, infine, aggiunge il campo "purpose" alla derivazione delle chiavi, permettendo quindi multipli account con lo stesso seed/mnemonica e simili.

Il discorso delle parole aggiuntive, se non ricordo male, è parte di BIP39 e le 2048 parole sono solo la wordlist standard, ma può essere estesa con altre parole, a quel punto però non c'è garanzia che i primi 4 caratteri siano univoci. Inoltre, questo è valido solo se è l'utente a generare/estendere la mnemonica, il wallet di norma restituisce una sequenza di 12/24 parole prese dalla lista ufficiale, o almeno dovrebbe.

Sicuramente è performante, ma Core legge dal disco eventuali transazioni quando importi un nuovo indirizzo (o recuperi un seed), immagino che questo passaggio sia ottimizzato il più possibile e mi viene da pensare che il limite sia proprio la velocità di lettura del tuo drive.
È il metodo migliore? No, ci sono diversi passaggi eseguiti da qualsiasi wallet che risultano inutili nel tuo caso, ad esempio Core/Electrum/ecc andrà a controllare tutte le transazioni passate per un dato indirizzo mentre a te interessa solo sapere se ci sono fondi al momento, la differenza c'è se consideri che il set degli utxo è di circa ~10GB mentre la blockchain sui 300.

Credo che il problema sia dovuto al fatto che Electrum non è un wallet completamente autonomo, senza una copia della blockchain l'unico modo che ha per sapere se ci sono transazioni per un certo indirizzo è di chiederlo a terzi, i server eletrum, e per tutti quegli indirizzi devi fare un sacco di chiamate.

https://github.com/spesmilo/electrum/blob/master/electrum/wallet.py#L2538

È il valore di "for_change", se passi True genera un indirizzo di resto altrimenti un indirizzo normale.
Vedo che False è già l'argomento predefinito, quindi dovrebbe funzionare anche se non metti nulla tra le parentesi.

Non c'è bisogno di salvarli, sono deterministici e verranno generati sempre gli stessi indirizzi a partire da un dato seed. Quello che fa electrum è di nascondere gli indirizzi dopo che ne ha generati un certo numero vuoti.
Il limite di default è 20, che può essere tranquillamente aumentato se uno smanetta un attimo. In più è sempre possibile generare altri indirizzi dalla console di electrum con il comando wallet.create_new_address(False) anche con un loop infinito, gli indirizzi non sono infiniti in senso letterale, ma credo tu possa andare avanti fino a saturare le risorse del PC e far crashare electrum.

Se cerchi un wallet che dato un seed continua a generare indirizzi vuoti, non credo lo troverai, potresti invece trovare qualche script su git adatto allo scopo 

Non mi crederai, ma stavo scrivendo esattamente questa frase sotto ai miliardi, poi ho visto che nel frattempo erano arrivate nuove risposte  

EDIT: a pensarci bene in Italia questa possibilità non è nemmeno così bassa, penso che la inserirei nella categoria "plausibile"

Attenzione
La mente umana non è capace di elaborare numeri molto grandi (o molto piccoli) ed è spesso difficile o addirittura impossibile valutare l'ordine di grandezza.

Considerando circa 30 milioni di indirizzi con saldo positivo, quello 0.000...% ha una quarantina di zeri davanti alla prima cifra utile, se lo scriviamo per esteso viene qualcosa del genere:
0.0000000000000000000000000000000000002%
Per confronto, l'acqua di mare ha circa 0.05 parti per miliardo di oro:
0.000000005%
Probabilità di fare 6 al superenalotto:
0.00000016%

È più probabile che tu vinca un miliardo di miliardi di miliardi di volte il superenalotto che generare un indirizzo con saldo positivo (anche con 1 satoshi   ), e stiamo considerato solo gli indirizzi legacy nel conteggio!


EDIT: fortuna che ogni tanto rileggo le cose che scrivo, l'ultima frase sarebbe dovuta essere "è un miliardo di miliardi di miliardi di volte più probabile che tu vinca al superenalotto ecc...", sorry

A questo si può trovare una pseudo-soluzione: inserire nell'immagine l'hash dell'ultimo blocco minato "N" e un indirizzo bitcoin "X", a quel punto si può eseguire una transazione verso X, includendo un OP_RETURN contenente l'hash dell'immagine "watermarkata".
Questo offre la certezza che il watermark sia stato applicato tra l'emissione del blocco N e la transazione verso X, un tempo che può variare tra qualche minuto e qualche ora; meglio ancora sarebbe includere direttamente nella foto un foglio di carta con su scritti N ed X (o visualizzati su un display, siamo nel 2020), così da poter fare l'hash dell'immagine in formato raw.

L'indirizzo è un dato che puoi conoscere a priori, l'orario della notarizzazione su blockchain corrisponderà all'orario della prima conferma della transazione verso tale indirizzo.
Non è sicuramente quello che chiedeva l'OP, ma in un'aula di tribunale dovrebbe valere qualcosa, almeno secondo me 

A mio avviso l'aggiornamento lo rende meno sicuro.
Perché? Per lo stesso motivo per cui considero authy insicuro, la possibilità di fare il backup!

Questa sottospecie di analisi riguarda esclusivamente la componente "mondo reale".
Immaginiamo un utente standard con un solo smartphone, no permessi di root e backup dei seed fatti al momento dell'attivazione del 2FA.

Se il seed non può essere estratto l'utente ha la (quasi) certezza di avere un 2FA non compromesso, nel momento in cui smarrisce lo smartphone o subisce un furto tutti i codici sono da considerare compromessi, a quel punto l'utente prende i suoi backup, si collega ai vari servizi e reimposta 2FA.
L'unico modo che un attaccante ha di impossessarsi dei codici 2FA (seed o OTP) è impossessarsi del dispositivo, ma a quel punto l'utente se ne accorge e può proteggersi.
Attacco:

• inserire il codice 2FA di fronte alla vittima
• rubare il dispositivo

Difesa:

• no root (permette l'accesso diretto al db contenente i seed)
• possedere il dispositivo

Ora passiamo all'altro scenario, l'utente non ha modo di "verificare" che i suoi seed 2FA siano ancora sicuri perché ad un attaccante basterebbe impossessarsi del dispositivo solo per il tempo necessario a effettuare il backup.
Attacco:

• tutte le precedenti
• "posso fare una telefonata" e backup

Difesa:

• nessuna delle precedenti
• non lasciare mai il dispositivo a terzi

Riassumendo, la funzione backup rimuove uno strato di sicurezza e aggiunge un vettore di attacco.

Sembra che ElectrumX stia rimuovendo il supporto a tutte le monete, incluso bitcoin, lasciando solo BSV  
link: https://github.com/kyuupichan/electrumx/tree/3cc50ee066c90e85fc7c56a639a6300f77cbbc26
file: electrumx/lib/coins.py

Per fortuna le alternative esistono!
Io sto usando electrs (fork: blockstream-esplora) da circa un anno e non ho mai avuto problemi di corruzione del db (rocksDB).
C'è da dire che la versione di Blockstream è il backend di un block-explorer, per questo ha tante cose inutili per un server Electrum ed è pesante come requisiti: 600+ GB (compressi, oltre 1TB durante la sincronizzazione), ~8GB di RAM utilizzati e la sincronizzazione iniziale richiede settimanE se non si usano SSD.
Tornando al punto, Blockstream ha forkato l'originale electrs by romanz che è estremamente più leggero e dovrebbe girare tranquillamente su SBC  

EDIT: i dev di Electrum hanno forkato ElectrumX con l'intento di mantenerne una versione con il supporto a BTC
https://github.com/spesmilo/electrumx

Se non spendi non riveli la chiave pubblica, ti rimane "solamente" la questione privacy. Ma nel momento in cui spendi almeno uno degli output ricevuti all'indirizzo X, la chiave pubblica associata viene scritta su blockchain.


Il discorso deriva dal fatto che bitcoin usa 2 algoritmi per generare un indirizzo: ECDSA per ottenere la coppia chiave pubblica/privata e RIPEMD160 per generare l'indirizzo a partire dalla chiave pubblica.
Ora, sia ECDSA che RIPEMD160 sono sicuri al momento, ma se io volessi provare a "forzare" la cosa, devo prima "rompere" RIPEMD e ricavare la chiave pubblica, e poi devo "rompere" ECDSA per recuperare la chiave privata e rubare i fondi. Se la chiave pubblica è già pubblica (eheh) il primo passaggio non è necessario e posso dedicarmi solo a ECDSA.
Questa cosa non è ancora un problema, ma potrebbe diventarlo in futuro se/quando i computer quantistici saranno più performanti ed ECDSA risulterà vulnerabile, a quel punto tutti i bitcoin che risiedono in indirizzi già utilizzati (con degli output spesi) saranno a rischio. Tra l'altro, è già noto che ECDSA è vulnerabile ai computer quantistici, devono "solo" riuscire a farne uno abbastanza potente e funzionante, fortunatamente non sarà un processo immediato secondo me.

Piccola nota: ethereum ragiona diversamente dalle blockchain di bitcoin e derivati.
Su ethereum hai una specie di "account" e di norma avrai sempre lo stesso indirizzo; al contrario bitcoin (litecoin, ecc) ragiona ad output e usare lo stesso indirizzo per tutti i pagamenti è SBAGLIATO, non ci sono vantaggi nel riutilizzare un indirizzo che ha già ricevuto un pagamento, è solo un problema per la privacy e (per i più paranoici) per la sicurezza #1.

Quindi:

• OK stesso indirizzo su ethereum, è stato pensato così.
• MALE stesso indirizzo su bitcoin/litecoin, il fatto che puoi farlo "è un bug non una feature"

#1: gli output spesi rivelano la chiave pubblica associata all'indirizzo, rimuovendo uno "strato" di cifratura (RIPEMD160)

Se non potesse identificare l'utxo, non avrebbe modo di validare la transazione che va a spenderlo portando a uno split della blockchain, segwit è stato attivato come soft-fork anche per evitare incompatibilità con i vecchi nodi. Sarebbe vero quello che dici nel caso di un hard-fork che introduce nuovi OP_CODE dedicati a segwit (o a qualunque altra cosa), ma in quel caso i nodi obsoleti non potrebbero validare i nuovi blocchi.
Sarei curioso di fare una prova con un vecchio nodo ed avrei anche un vintage bitcoin-qt 0.9 su un vecchio portatile, ma non è sincronizzato da anni ed ho solo un paio di giga liberi su disco 

Comunque, un output segwit (p2wkh o p2wsh) ha come script di blocco qualcosa del tipo "OP_0 OP_PUSHDATA pubkeyhash/scripthash", quindi dovrebbe essere perfettamente riconoscibile ad un vecchio nodo anche se non è presente la condizione per spendere l'output, sicuramente non sarà in grado di decodificare l'indirizzo, ma riconoscerà l'output e lo inserirà nel database degli utxo.
Nel caso di indirizzi segwit P2SH, lo script di blocco è irriconoscibile da un generico P2SH finchè non viene speso; c'è stato qualcuno che ha commesso l'errore di inviare transazioni a quegli indirizzi sulla rete BCH che non supporta segwit ed i miner sono stati in grado di spendere/recuperare quei fondi.

La firma modificata è comunque valida (https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki per maggiori info), per questo la transazione viene comunque accettata dai miner.
Segwit risolve spostando la firma "fuori" dal blocco, in questo modo l'hash della transazione è calcolato senza includere la firma, che viene appunto "spostata" all'esterno del blocco (tipo allegato), da questo deriva la minor dimensione delle transazioni e il conseguente aumento della dimensione massima del blocco.
Il blocco bitcoin è comunque da 1MB, ma le firme delle transazioni segwit non sono incluse al suo interno e quindi si può "sforare" di un po' fino ad un massimo teorico di 4MB (anche se in realtà si è più vicini ai 2).

Un nodo che non ha attivato segwit può comunque sincronizzarsi e verificare le transazioni, ma non vedrà le firme esterne al blocco, per lui le transazioni segwit sono delle "anyone can spend" senza firma.

Durante il mining viene usato il 100% della GPU, è normale che la temperatura salga.
Alcune cose che puoi provare:

• aumenta la velocità delle ventole della GPU
• se hai un case aprilo o migliora la ventilazione, chi fa mining non usa case, si usano dei telai completamente aperti, cerca "mining rig" su un motore di ricerca e guarda qualche foto
• gioca con le configurazioni del software che usi per il mining e/o con i voltaggi/clock della GPU (senza esagerare!), dovrebbe essere possibile guadagnare qualche grado, ma probabilmente ci rimetti in prestazioni

Non ho idea di cosa sia ZEL, quindi sull'ultimo punto non posso aiutarti né posso garantirti che sia fattibile, ma prima pensa alla ventilazione che è fondamentale