Author

Topic: [51% Attack] Spieghiamolo. (Read 5677 times)

legendary
Activity: 1915
Merit: 2074
April 17, 2015, 09:42:53 AM
#44
(...)
Da quello che ho capito (non ne sono sicuro al 100%) servono soprattutto ad evitare che qualcuno, reiniziando a minare dal blocco 1, inondi la rete di molti blocchi inutili e quindi occupi con catene-spazzatura gli hard disk dei nodi. Con i checkpoint si velocizza la sincronizzazione alla catena principale "corretta" scartando subito le catene che non passano per questi checkpoint.
Ovviamente come molti in rete hanno osservato in questo modo si introduce un elemento di consenso deciso da pochi - gli sviluppatori del codice - contrario alla filosofia decentralizzata a cui si ispira il sistema Bitcoin.
Come al solito, quello che immagino, è gia stato fatto. Meglio cosi', io pero' non vedo un rischio di centralizzazione ma una sorta di condivisione della chain a consenso, credo che se la maggior parte degli utenti usasse un client senza checkpoint tutto potrebbe funzionare allo stesso modo, poi se qualcuno riesce a minare una catena senza mettere quei punti allora creerebbe un fork epico.

Diciamo che il rischio di centralizzazione è mitigato molto dal fatto che utilizzano come checkpoint blocchi molto indietro nel tempo.
Penso che se qualcuno fosse in grado di creare un fork con una catena che andasse ad annullare tutte le transazioni degli ultimi 10-12 mesi, anche se dal punto di vista dell'algoritmo avrebbe ragione lui, sicuramente per la stragrande maggioranza della comunità questo non sarebbe accettabile/auspicabile (altrimenti il Bitcoin da uno dei sistemi di pagamento più veloci diventerebbe uno dei più lenti del pianeta, non potendo considerare definitive neanche transazioni con migliaia di conferme). Per tagliare la testa al toro (e soprattutto per evitare inutile spreco di tempo e risorse nel momento della sincronizzazione dei nuovi nodi) hanno anche secondo me fatto bene ad inserire questi checkpoint.

Diverso sarebbe il discorso se si decidesse invece che tutti i blocchi dell'attuale catena principale che hanno più di N conferme (con per esempio N = 100) diventassero "definitivi".

legendary
Activity: 2506
Merit: 1120
April 16, 2015, 03:47:00 PM
#43
Pensierino: sapete se e' già venuta in mente a qualcuno l'idea di inserire ad ogni nuova relase del client ufficiale una sorta di "chiodo" che analogamente a come funziona il genesis block impone il passaggio della catena in quel blocco ad una determinata altezza?
(...)

C'è stato un mandatory tra la versione 0.6 e la 0.7 se non ricordo male, ovvero intorno al blocco 180.000 e ce ne sarà un'altro pilotato quando si decideranno in maniera definitiva sull' aumento della grandezza delle TX.

Riguardo la chain, a che pro ?

FaSan

Per chi fosse interessato, nel file chainparams.cpp (che è uno dei file sorgenti di Bitcoin Core) si trovano tutti i checkpoint integrati direttamente nel software. Al momento sono questi 13 (l'ultimo si riferisce a un blocco minato circa 1 anno fa):

Quote
       ( 11111, uint256S("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
        ( 33333, uint256S("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
        ( 74000, uint256S("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20"))
        (105000, uint256S("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97"))
        (134444, uint256S("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe"))
        (168000, uint256S("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763"))
        (193000, uint256S("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))
        (210000, uint256S("0x000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e"))
        (216116, uint256S("0x00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e"))
        (225430, uint256S("0x00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932"))
        (250000, uint256S("0x000000000000003887df1f29024b06fc2200b55f8af8f35453d7be294df2d214"))
        (279000, uint256S("0x0000000000000001ae8c72a0b0c301f67e3afca10e819efa9041e458e9bd7e40"))
        (295000, uint256S("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983"))

Da quello che ho capito (non ne sono sicuro al 100%) servono soprattutto ad evitare che qualcuno, reiniziando a minare dal blocco 1, inondi la rete di molti blocchi inutili e quindi occupi con catene-spazzatura gli hard disk dei nodi. Con i checkpoint si velocizza la sincronizzazione alla catena principale "corretta" scartando subito le catene che non passano per questi checkpoint.
Ovviamente come molti in rete hanno osservato in questo modo si introduce un elemento di consenso deciso da pochi - gli sviluppatori del codice - contrario alla filosofia decentralizzata a cui si ispira il sistema Bitcoin.
Come al solito, quello che immagino, è gia stato fatto. Meglio cosi', io pero' non vedo un rischio di centralizzazione ma una sorta di condivisione della chain a consenso, credo che se la maggior parte degli utenti usasse un client senza checkpoint tutto potrebbe funzionare allo stesso modo, poi se qualcuno riesce a minare una catena senza mettere quei punti allora creerebbe un fork epico.
legendary
Activity: 1915
Merit: 2074
April 16, 2015, 09:44:46 AM
#42
Pensierino: sapete se e' già venuta in mente a qualcuno l'idea di inserire ad ogni nuova relase del client ufficiale una sorta di "chiodo" che analogamente a come funziona il genesis block impone il passaggio della catena in quel blocco ad una determinata altezza?

In questo modo si eviterebbe l'inconveniente di trovarsi la chain errata dopo tantissimo tempo.

Inoltre sarebbe interessante che la chain contenesse anche il codice c++ (mi pare ci sia) e tutte le sue patch (magari ci sono ...).

C'è stato un mandatory tra la versione 0.6 e la 0.7 se non ricordo male, ovvero intorno al blocco 180.000 e ce ne sarà un'altro pilotato quando si decideranno in maniera definitiva sull' aumento della grandezza delle TX.

Riguardo la chain, a che pro ?

FaSan

Per chi fosse interessato, nel file chainparams.cpp (che è uno dei file sorgenti di Bitcoin Core) si trovano tutti i checkpoint integrati direttamente nel software. Al momento sono questi 13 (l'ultimo si riferisce a un blocco minato circa 1 anno fa):

Quote
       ( 11111, uint256S("0x0000000069e244f73d78e8fd29ba2fd2ed618bd6fa2ee92559f542fdb26e7c1d"))
        ( 33333, uint256S("0x000000002dd5588a74784eaa7ab0507a18ad16a236e7b1ce69f00d7ddfb5d0a6"))
        ( 74000, uint256S("0x0000000000573993a3c9e41ce34471c079dcf5f52a0e824a81e7f953b8661a20"))
        (105000, uint256S("0x00000000000291ce28027faea320c8d2b054b2e0fe44a773f3eefb151d6bdc97"))
        (134444, uint256S("0x00000000000005b12ffd4cd315cd34ffd4a594f430ac814c91184a0d42d2b0fe"))
        (168000, uint256S("0x000000000000099e61ea72015e79632f216fe6cb33d7899acb35b75c8303b763"))
        (193000, uint256S("0x000000000000059f452a5f7340de6682a977387c17010ff6e6c3bd83ca8b1317"))
        (210000, uint256S("0x000000000000048b95347e83192f69cf0366076336c639f9b7228e9ba171342e"))
        (216116, uint256S("0x00000000000001b4f4b433e81ee46494af945cf96014816a4e2370f11b23df4e"))
        (225430, uint256S("0x00000000000001c108384350f74090433e7fcf79a606b8e797f065b130575932"))
        (250000, uint256S("0x000000000000003887df1f29024b06fc2200b55f8af8f35453d7be294df2d214"))
        (279000, uint256S("0x0000000000000001ae8c72a0b0c301f67e3afca10e819efa9041e458e9bd7e40"))
        (295000, uint256S("0x00000000000000004d9b4ef50f0f9d686fd69db2e03af35a100370c64632a983"))

Da quello che ho capito (non ne sono sicuro al 100%) servono soprattutto ad evitare che qualcuno, reiniziando a minare dal blocco 1, inondi la rete di molti blocchi inutili e quindi occupi con catene-spazzatura gli hard disk dei nodi. Con i checkpoint si velocizza la sincronizzazione alla catena principale "corretta" scartando subito le catene che non passano per questi checkpoint.
Ovviamente come molti in rete hanno osservato in questo modo si introduce un elemento di consenso deciso da pochi - gli sviluppatori del codice - contrario alla filosofia decentralizzata a cui si ispira il sistema Bitcoin.


hero member
Activity: 658
Merit: 502
March 30, 2015, 11:42:30 AM
#41
Penso ti riferissi alle release notes della versione 0.6.3
Quote
Added a block checkpoint at block 185,333 to speed up initial blockchain download.

Si la 0.6.3 è stata l' ultima della serie 0.6.x



Avrei una domanda: ho visto che nelle release notes della versione 0.9.0  si parla del concetto di "coins mature"

Quote
Wallet:
             Consider generated coins mature at 101 instead of 120 blocks

In che senso si considerano "mature" queste monete?





Dopo il mining. Le conferme per le TX ed i blocchi minati sono diverse




FaSan

legendary
Activity: 1915
Merit: 2074
March 30, 2015, 11:22:30 AM
#40
Pensierino: sapete se e' già venuta in mente a qualcuno l'idea di inserire ad ogni nuova relase del client ufficiale una sorta di "chiodo" che analogamente a come funziona il genesis block impone il passaggio della catena in quel blocco ad una determinata altezza?

In questo modo si eviterebbe l'inconveniente di trovarsi la chain errata dopo tantissimo tempo.

Inoltre sarebbe interessante che la chain contenesse anche il codice c++ (mi pare ci sia) e tutte le sue patch (magari ci sono ...).


C'è stato un mandatory tra la versione 0.6 e la 0.7 se non ricordo male, ovvero intorno al blocco 180.000 e ce ne sarà un'altro pilotato quando si decideranno in maniera definitiva sull' aumento della grandezza delle TX.

Riguardo la chain, a che pro ?

FaSan

Penso ti riferissi alle release notes della versione 0.6.3
Quote
Added a block checkpoint at block 185,333 to speed up initial blockchain download.


Avrei una domanda: ho visto che nelle release notes della versione 0.9.0  si parla del concetto di "coins mature"

Quote
Wallet:
             Consider generated coins mature at 101 instead of 120 blocks

In che senso si considerano "mature" queste monete?


hero member
Activity: 658
Merit: 502
March 30, 2015, 10:32:19 AM
#39
Pensierino: sapete se e' già venuta in mente a qualcuno l'idea di inserire ad ogni nuova relase del client ufficiale una sorta di "chiodo" che analogamente a come funziona il genesis block impone il passaggio della catena in quel blocco ad una determinata altezza?

In questo modo si eviterebbe l'inconveniente di trovarsi la chain errata dopo tantissimo tempo.

Inoltre sarebbe interessante che la chain contenesse anche il codice c++ (mi pare ci sia) e tutte le sue patch (magari ci sono ...).


C'è stato un mandatory tra la versione 0.6 e la 0.7 se non ricordo male, ovvero intorno al blocco 180.000 e ce ne sarà un'altro pilotato quando si decideranno in maniera definitiva sull' aumento della grandezza delle TX.


Riguardo la chain, a che pro ?



FaSan
hero member
Activity: 588
Merit: 500
March 30, 2015, 07:05:16 AM
#38
Sono d'accordo con picchio, se io ad esempio facessi parte del sistema bancario e mi accorgessi che le criptovalute rischiano di mettere seriamente in discussione i miei guadagni, un 60 - 100 milioni di euro per dimostrare a tutto il mondo la vulnerabiltà del bitcoin ce le li metterei senza troppi problemi. In tal caso non sarebbe affatto una "truffa" inutile, ma assolutamente conveniente dal punto di vista di chi la attua.

Poi ci sarebbe anche da discutere sul termine "truffa": se io rubo 100 euro sono perseguibile legalmente, se rubo 1 bitcoin ( che non ha alcun valore "legale" se non sbaglio ) di cosa potrei essere accusato? Altro incentivo per tentare l'attacco del 51%.

Vi fermate alla parte economica dei miner... non è solo li il problema.

Prima di tutto, dovete trovare chi ve li produce (i miner), se non crearvi una propria azienda investendo centinaia di milioni.. perchè se per dire li comprate da bitmain ora che vi arrivino e li colleghiate.. ne avete troppo pochi, la rete è aumentata.

Poi la logistica? Farvi arrivare 400mila miner richiederebbe mesi solo per attaccarli insieme, fare i cablaggi della rete dati ed elettrica... e su quest'ultimo, i consumi?

400mila miner consumano appunto 240-250MegaWatt...  Una centrale moderna nucleare (per capirci) produce circa il doppio (600MW)... quindi a voi serve una mezza centrale per alimentare i miner.


Quindi i 60milioni di dollari per comprarli sono il meno... è tutto il resto che rende complicatissimo\impossibile praticare, ad ora, questo attacco. Ed è anche il motivo per cui gli asic non sono certo la fine del bitcoin ma anzi, sono una manna per garantirne la sicurezza.
legendary
Activity: 1915
Merit: 2074
March 30, 2015, 06:46:38 AM
#37
(...)
Il tutto per minare dei blocchi in parallelo, far "crollare" la catena principale che porterebbe ad un crollo del prezzo e quindi renderebbe la "truffa" inutile comunque.
(...)
A qualcuno potrebbe interessare come giochetto, solo che sono ancora molto ignoranti e dalla parte dei BTC ci sono fior di CERVELLI pronti a prendere le contromisure.


Sono d'accordo con picchio, se io ad esempio facessi parte del sistema bancario e mi accorgessi che le criptovalute rischiano di mettere seriamente in discussione i miei guadagni, un 60 - 100 milioni di euro per dimostrare a tutto il mondo la vulnerabiltà del bitcoin ce le li metterei senza troppi problemi. In tal caso non sarebbe affatto una "truffa" inutile, ma assolutamente conveniente dal punto di vista di chi la attua.

Poi ci sarebbe anche da discutere sul termine "truffa": se io rubo 100 euro sono perseguibile legalmente, se rubo 1 bitcoin ( che non ha alcun valore "legale" se non sbaglio ) di cosa potrei essere accusato? Altro incentivo per tentare l'attacco del 51%.


legendary
Activity: 2506
Merit: 1120
March 30, 2015, 01:31:13 AM
#36
Pensierino: sapete se e' già venuta in mente a qualcuno l'idea di inserire ad ogni nuova relase del client ufficiale una sorta di "chiodo" che analogamente a come funziona il genesis block impone il passaggio della catena in quel blocco ad una determinata altezza?

In questo modo si eviterebbe l'inconveniente di trovarsi la chain errata dopo tantissimo tempo.

Inoltre sarebbe interessante che la chain contenesse anche il codice c++ (mi pare ci sia) e tutte le sue patch (magari ci sono ...).
legendary
Activity: 2506
Merit: 1120
March 29, 2015, 07:34:32 PM
#35
(...)
Il tutto per minare dei blocchi in parallelo, far "crollare" la catena principale che porterebbe ad un crollo del prezzo e quindi renderebbe la "truffa" inutile comunque.
(...)
A qualcuno potrebbe interessare come giochetto, solo che sono ancora molto ignoranti e dalla parte dei BTC ci sono fior di CERVELLI pronti a prendere le contromisure.
hero member
Activity: 588
Merit: 500
March 29, 2015, 06:06:29 PM
#34
Nel caso del 51% attack invece è difficile calcolare la probabilità di questo evento ( che ripeto avrebbe una conseguenza sistemica invece gravissima ) e soprattutto la sensazione è che questa probabilità non sia poi così trascurabile.

Che non sia trascurabile mi sembra molto forte dirlo.. io, attualmente, vedo più probabile un indirizzo generato doppio che un 51% voluto...

E ti spiego il motivo che mi fa pensare ciò (ma è un opizione personale, considivisibile o meno).
Attualmente, come sappiamo, servono macchine ASIC per minare... La rete attuale è sui 350-400mila Terahash... per fare un 51% voluto, e magari forkando non solo un blocco ma buona parte della rete, come scritto, biosgna minare vari blocchi in parallelo.

Il che significa o convincere la metà dei miner a spostarsi (cosa che vedo ben infattibile, chi ha speso soldi per minare non ha convenienza a portare un attacco che creerebbe un panic-sell e ne farebbe precipitare il valore).. oppure crearsi un altra rete con potenza superiore a quella principale, staccata... e solo dopo X blocchi metterla online, le potenze si sommerebbero e vincerebbe la nuova chain.

Ora, per metter in piedi 500mila Tera servono, usando uno dei prodotto migliori sul mercato (gli S5) qualcosa come 400mila miner... per una spesa di 60milioni di dollari ed un assorbimento di qualcosa come 240MegaWatt...
Un spesa alta ma che richiederebbe un infrastruttura enorme...
Il tutto per minare dei blocchi in parallelo, far "crollare" la catena principale che porterebbe ad un crollo del prezzo e quindi renderebbe la "truffa" inutile comunque.

Poi, sono calcoli fatti a mente ed a spanne... ma che rendono l'idea del perchè si può definire, secondo me, il bitcoin sicuro dal 51%
legendary
Activity: 1526
Merit: 1010
▇ ▅ ▃ ▇ ▅ █
March 29, 2015, 12:47:42 PM
#33
In tal caso i danni non sarebbero solo gravi ma gravissimi, annullare tutte le transazioni di settimane e settimane danneggerebbe in modo veramente grave se non irrimediabile il bitcoin. E chi risarcirebbe in tal caso coloro che ad esempio hanno venduto un prodotto/servizio/forza lavoro in cambio di btc ?
Quando effettuiamo una transazione con btc, tutti penso diamo per scontato che, al massimo dopo 6 conferme, quella transazione diventa "definitiva"(anche se sappiamo che la logica alla base della blockchain di fatto consente sempre una probabilitá, seppur piccolissima, che la validità di tali transazioni possa venire revocata).

per "prima dell'attacco" non intendo "prima che i cattivi iniziassero ad accumulare blocchi minati per poi fare il fork" ma intendo "prima che i cattivi immettessero il fork in rete" (distruggendo magari tutti i balance della intera blockchain). la perdita potrebbe limitarsi a poche ore o pochi giorni, dipende da quanto ci metterebbe il dev team a intervenire.

Bisognerebbe allora secondo me riflettere un attimo sulla differenza tra "altamente improbabile" e "impossibile", differenza sulla quale si basa tutto l'ecosistema delle criptovalute.
Non abbiamo a che fare con un sistema "sicuro" al 100%, ma facciamo finta che lo sia. Per esempio quando genero un indirizzo bitcoin, dò per scontato che nessun altro possa generare casualmente la mia chiave privata. In quel caso però si riesce almeno a quantificare con precisione il grado di probabilità che questo fatto possa verificarsi (e tra l'altro se avvenisse in un solo caso isolato il malcapitato non se ne accorgerebbe neanche, riterrebbe più plausibile essere stato colpito da qualche hacker).
Nel caso del 51% attack invece è difficile calcolare la probabilità di questo evento ( che ripeto avrebbe una conseguenza sistemica invece gravissima ) e soprattutto la sensazione è che questa probabilità non sia poi così trascurabile.

mi verrebbe da dire "benvenuto nel mondo reale" Cheesy
nulla è certo al 100%, le banche non lo sono, gli stati neanche, il diritto alla vita neppure, tutto ha un punto debole e un punto di morte. non esistono sistemi sicuri al 100%, il 100% esiste solo sui libri di teoria.
legendary
Activity: 1915
Merit: 2074
March 29, 2015, 12:15:09 PM
#32
A pelle direi che investire in un anno di chain parallela è troppo rischioso (devi essere sicuro di essere in vantaggio sempre), secondo me puo' avvenire nell'arco di 120 transazioni ma anche molte meno, mi pare che ci debbano essere 6 blocchi in piu' sulla catena vincitrice.

120 Blocchi intendi?
Secondo me se fai un vero 51% Attack, non butti giù meno di 24 ore di blockchain (1 giorno sarebbero 144 blocchi in linea teorica), se organizzi un 51% Attack con fini di dolo, la tiri per le lunghe, per mesi, solo così distruggerai veramente ogni possibile speranza di riparazione e di riacquisto di fiducia negli utenti.

Io ho una tendenza al catastrofismo, ma da bravo informatico sono convinto che laddove ci sia una falla nota, prima o poi il naso qualcuno ce lo mette.

Ora io non voglio sminuire i tecnici della BFL, KNC, Terrahash etc ma non credo che siano dei luminari dell'elettronica, mi permetto di pensare che siano tecnici capaci come possono esserlo tanti altri nel loro campo.
Quindi se qualcuno col cash (molto cash) decidesse di mettere in piedi un team per costruire asic di generazioni avanti (noi con i suddetti tecnici siamo passati da 333Mh/S a 10Th/S in meno di  anno) e preparare questo disastro, non ne risulterei sorpreso.

Risulto invece sorpreso del fatto che la soluzione a questo problema non sia ancora stata codificata nel core e sembra presa molto sotto-gamba.
Questo davvero mi sorprende e non capisco cosa stiano aspettando, dato che, ripeto, potrebbe già essere stata messo in atto la preparazione di un 51% attack da molto tempo.
io penso che se succedesse un attacco del genere (settimane o mesi di fork) il dev team interverrebbe con un hard fork che escluda la chain "cattiva" a forza dal network "buono" e quindi i danni sarebbero grandi ma verrebbe ripristinata la situazione precedente all'attacco e il bitcoin non verrebbe distrutto

In tal caso i danni non sarebbero solo gravi ma gravissimi, annullare tutte le transazioni di settimane e settimane danneggerebbe in modo veramente grave se non irrimediabile il bitcoin. E chi risarcirebbe in tal caso coloro che ad esempio hanno venduto un prodotto/servizio/forza lavoro in cambio di btc ?
Quando effettuiamo una transazione con btc, tutti penso diamo per scontato che, al massimo dopo 6 conferme, quella transazione diventa "definitiva"(anche se sappiamo che la logica alla base della blockchain di fatto consente sempre una probabilitá, seppur piccolissima, che la validità di tali transazioni possa venire revocata).

Bisognerebbe allora secondo me riflettere un attimo sulla differenza tra "altamente improbabile" e "impossibile", differenza sulla quale si basa tutto l'ecosistema delle criptovalute.
Non abbiamo a che fare con un sistema "sicuro" al 100%, ma facciamo finta che lo sia. Per esempio quando genero un indirizzo bitcoin, dò per scontato che nessun altro possa generare casualmente la mia chiave privata. In quel caso però si riesce almeno a quantificare con precisione il grado di probabilità che questo fatto possa verificarsi (e tra l'altro se avvenisse in un solo caso isolato il malcapitato non se ne accorgerebbe neanche, riterrebbe più plausibile essere stato colpito da qualche hacker).
Nel caso del 51% attack invece è difficile calcolare la probabilità di questo evento ( che ripeto avrebbe una conseguenza sistemica invece gravissima ) e soprattutto la sensazione è che questa probabilità non sia poi così trascurabile.

newbie
Activity: 2
Merit: 0
March 29, 2015, 07:56:27 AM
#31
Wow! mai saputo qualcosa di simile potrebbe essere fatto con bitcoin .
legendary
Activity: 1526
Merit: 1010
▇ ▅ ▃ ▇ ▅ █
March 28, 2015, 10:37:14 PM
#30
A pelle direi che investire in un anno di chain parallela è troppo rischioso (devi essere sicuro di essere in vantaggio sempre), secondo me puo' avvenire nell'arco di 120 transazioni ma anche molte meno, mi pare che ci debbano essere 6 blocchi in piu' sulla catena vincitrice.

120 Blocchi intendi?
Secondo me se fai un vero 51% Attack, non butti giù meno di 24 ore di blockchain (1 giorno sarebbero 144 blocchi in linea teorica), se organizzi un 51% Attack con fini di dolo, la tiri per le lunghe, per mesi, solo così distruggerai veramente ogni possibile speranza di riparazione e di riacquisto di fiducia negli utenti.

Io ho una tendenza al catastrofismo, ma da bravo informatico sono convinto che laddove ci sia una falla nota, prima o poi il naso qualcuno ce lo mette.

Ora io non voglio sminuire i tecnici della BFL, KNC, Terrahash etc ma non credo che siano dei luminari dell'elettronica, mi permetto di pensare che siano tecnici capaci come possono esserlo tanti altri nel loro campo.
Quindi se qualcuno col cash (molto cash) decidesse di mettere in piedi un team per costruire asic di generazioni avanti (noi con i suddetti tecnici siamo passati da 333Mh/S a 10Th/S in meno di  anno) e preparare questo disastro, non ne risulterei sorpreso.

Risulto invece sorpreso del fatto che la soluzione a questo problema non sia ancora stata codificata nel core e sembra presa molto sotto-gamba.
Questo davvero mi sorprende e non capisco cosa stiano aspettando, dato che, ripeto, potrebbe già essere stata messo in atto la preparazione di un 51% attack da molto tempo.
io penso che se succedesse un attacco del genere (settimane o mesi di fork) il dev team interverrebbe con un hard fork che escluda la chain "cattiva" a forza dal network "buono" e quindi i danni sarebbero grandi ma verrebbe ripristinata la situazione precedente all'attacco e il bitcoin non verrebbe distrutto
member
Activity: 154
Merit: 10
March 26, 2015, 03:55:27 PM
#29

Risulto invece sorpreso del fatto che la soluzione a questo problema non sia ancora stata codificata nel core e sembra presa molto sotto-gamba.
Questo davvero mi sorprende e non capisco cosa stiano aspettando, dato che, ripeto, potrebbe già essere stata messo in atto la preparazione di un 51% attack da molto tempo.

Secondo me e' normale.

L'Open Source nasce proprio come "nemico" del Closed Source.

Ed il piu' delle volte falle grandi e lapalissianamente da dover risolvere sono lasciate li perche' sia la comunita' a rendersene conto e trovi una soluzione adeguata.

Soluzione Adeguata: in concordato con tutta la comunita'.
member
Activity: 110
Merit: 94
June 26, 2014, 04:33:24 PM
#28
La blockchain che "vince" non è per forza la più lunga, ma quella che ha la somma delle difficoltà dei blocchi più alta.

Si? Sarebbe meglio così ma il tipino nel video lo dice?

No il tipo del video non mi sembra lo dica, l'ho letto sul wiki: https://en.bitcoin.it/wiki/Block_chain

"Length" is calculated as total combined difficulty of that chain, not number of blocks, though this distinction is only important in the context of a few potential attacks.


legendary
Activity: 2632
Merit: 1040
June 26, 2014, 04:00:50 PM
#27
La blockchain che "vince" non è per forza la più lunga, ma quella che ha la somma delle difficoltà dei blocchi più alta.

Si? Sarebbe meglio così ma il tipino nel video lo dice?
member
Activity: 110
Merit: 94
June 26, 2014, 02:40:29 PM
#26
La blockchain che "vince" non è per forza la più lunga, ma quella che ha la somma delle difficoltà dei blocchi più alta.

Partendo da questo concetto un malintenzionato dovrà disporre di un hashrate decisamente superiore al "50% più qualcosa" se il suo intento è estendere l'attacco su un lungo periodo, in quanto ad ogni retarget deve avere la certezza di raggiungere una difficoltà maggiore rispetto a quella della chain "principale".
Per fare un esempio, mettiamo che l'attacco riesca e che qualcuno riesca a forkare la blockchain con il suo enorme hashrate, se in quel momento i produttori di asic mettessero online le macchine che hanno in magazzino con l'intento di pompare la difficoltà (ovviamente minando sulla vecchia blockchain), al successivo retarget le 2 blockchain avrebbero 2 difficoltà diverse e SE la chain forkata avrà una diff minore la situazione sarebbe ripristinata riportando la vecchia catena ad essere la principale.

Mi sono fatto un viaggio assurdo o quello che ho scritto è vagamente possibile?
member
Activity: 92
Merit: 10
June 25, 2014, 10:55:11 AM
#25
Imho è alquanto improbabile che succeda: spegnere una farm (nel caso di ghash.io più di una) sperando di abbassare la difficoltà si può tradurre in una perdita netta dal momento che nel frattempo entrerebbero altri minatori a colmare il "buco". A questo punto la diff tornando ai livelli precedenti non avvantaggerebbe nessuno, men che meno ghash che avrebbe totalizzato solamente una grossa perdita di btc minati.
discorso che non fa una piega!! Smiley
legendary
Activity: 3766
Merit: 1742
Join the world-leading crypto sportsbook NOW!
June 25, 2014, 05:50:52 AM
#24
Quello che invece potrebbe essere pericoloso è un pump & dump di Ghash.io. Ad es. potrebbe ad agosto staccare la spina e far abbassare l'hashrate drasticamente. A settembre riprendere con una difficoltà più bassa e prendersi un bel po' di bottino facile facile. Da valutare anche in questo caso la convenienza, che secondo me non è ovvia ma meno rischiosa.

Imho è alquanto improbabile che succeda: spegnere una farm (nel caso di ghash.io più di una) sperando di abbassare la difficoltà si può tradurre in una perdita netta dal momento che nel frattempo entrerebbero altri minatori a colmare il "buco". A questo punto la diff tornando ai livelli precedenti non avvantaggerebbe nessuno, men che meno ghash che avrebbe totalizzato solamente una grossa perdita di btc minati.
sr. member
Activity: 410
Merit: 250
June 25, 2014, 04:37:59 AM
#23
Ottima riflessione tecnica di Sampey. Diciamo che un attacco di questo tipo anche con un hashpower del 51% risulta molto improbabile perché molto rischioso. Provate a pensare se ghash.io invece di minare e prendere la sua ricompensa, sceglie il lato oscuro e comincia a minare una blockchain parallela. Deve essere sicuro di mantenere un hashpower per molto tempo oltre il 51% cosa difficile visto il continuo cambiare (in alto) di tale parametro statistico. Se qualcun'altro intanto lo supera, manderebbe in fumo tutto il suo lavoro. Inoltre se riuscisse nell'intento sostituire la blockchain con la sua parallela, farebbe calare la fiducia nella moneta con conseguenze negative su tutta la comunità compreso lui.

Però non bisogna escludere che c'è sempre qualcuno che fa le cose non perché sono convenienti ma solo per il gusto di provarci e cautelarsi è sempre meglio. Vedi hacker che fanno attacchi ddos senza nessuno scopo se non quello di provarci.

Comunque anche secondo me dovrebbero a livello di client cercare di arginare un pericolo simile, evitando ad esempio di sostituire catene troppo lunghe di blocchi (cambiare mesi di blockchain con blocchi confermati sarebbe folle, ma attualmente possibile).

Quello che invece potrebbe essere pericoloso è un pump & dump di Ghash.io. Ad es. potrebbe ad agosto staccare la spina e far abbassare l'hashrate drasticamente. A settembre riprendere con una difficoltà più bassa e prendersi un bel po' di bottino facile facile. Da valutare anche in questo caso la convenienza, che secondo me non è ovvia ma meno rischiosa.

Ciao  Cool

legendary
Activity: 3766
Merit: 1742
Join the world-leading crypto sportsbook NOW!
June 24, 2014, 01:22:44 AM
#22
Ma l'hash power necessario a mantenere la block chain parallela è quello necessario ad avere il 51% nel momento del fork? Se qualcuno stesse forkando in segreto dal primo anno del network gli basterebbe poco hash power?

Puoi provare a fare un 51% attack anche con un block erupter (333mhash), ma la statistica non sarà dalla tua parte e quindi sarà già un immensa fortuna trovare un blocco, figurarsi realizzare una catena di blocchi parallela più lunga di quella originale. Chiaramente l'attacker dovrebbe rimanere al passo con la rete ed aumentare costantemente l'hashrate a sua disposizione per stare al passo con la fisiologica crescita che il mining bitcoin sta avendo.
legendary
Activity: 2506
Merit: 1120
June 23, 2014, 08:53:04 AM
#21
Secondo me non puo' essere automatico che il client consideri valida una diramazione che ha piu' di 120 blocchi differenti da quella che sta "vivendo", immagina se puo', di punto in bianco, cancellare un anno di chain e transazioni, in caso avvenisse si troverebbe una riga di codice che impone una data catena ...
if block = 2222222 then correct hash = 000000000111111111 e il ramo oscuro e' morto. Poi dipende da chi adotta un software e chi l'altro (con l'anaologo per dire che vince l'altro) ... magari a quel punto cambiano qualcosa in piu' per la sicurezza ...

non dico che non sarebbe un problema ma la vedo dura.

Avrebbe invece senso fare sta cosa di tanto in tanto per fare il double spending, allora si che son cazzi. Immagina di vendere la casa a chi ti fa un bel double spending .... oddio, sai dove trovarlo ma non deve essere gradevole.
Magari vendi un automobile. 
Io non ci credo a che ci possa essere qualcosa/qualcuno in grado di fare danno al progetto BTC.
legendary
Activity: 2632
Merit: 1040
June 23, 2014, 08:23:12 AM
#20
Direi di si anche se preferirei avere conferma da qualcuno che conosce l'argomento meglio di me.
hero member
Activity: 484
Merit: 500
June 23, 2014, 08:13:18 AM
#19
No è quello necessario a garantirti di stare dei blocchi avanti alla catena principale.
Potresti avere anche l'80%, chiaramente la difficoltà della tua blockchain sarebbe molto più alta di quella "pubblica".

Tu potresti anche partire con una fork della chain e stare in un numero di blocchi minore rispetto alla catena principale.
Solo che poi dovresti farti il mazzo a recuperare.

Dire che hai il 51% significa solo avere la matematica dalla tua parte, prima o poi passi davanti come numero (altezza) di blocchi.

L'importante è che nel momento dell'attacco l'altezza della tua catena sia più alto.

OK diciamo che quindi per "avere la chain più lunga" vuol dire avere il 51% come media nell'arco di tempo in cui la stai tenendo segreta?
legendary
Activity: 2632
Merit: 1040
June 23, 2014, 08:07:23 AM
#18
No è quello necessario a garantirti di stare dei blocchi avanti alla catena principale.
Potresti avere anche l'80%, chiaramente la difficoltà della tua blockchain sarebbe molto più alta di quella "pubblica".

Tu potresti anche partire con una fork della chain e stare in un numero di blocchi minore rispetto alla catena principale.
Solo che poi dovresti farti il mazzo a recuperare.

Dire che hai il 51% significa solo avere la matematica dalla tua parte, prima o poi passi davanti come numero (altezza) di blocchi.

L'importante è che nel momento dell'attacco l'altezza della tua catena sia più alto.
hero member
Activity: 484
Merit: 500
June 23, 2014, 08:01:09 AM
#17
Ma l'hash power necessario a mantenere la block chain parallela è quello necessario ad avere il 51% nel momento del fork? Se qualcuno stesse forkando in segreto dal primo anno del network gli basterebbe poco hash power?
sr. member
Activity: 367
Merit: 250
June 23, 2014, 07:55:48 AM
#16
OK, quindi diciamo che per essere veramente dannoso l'attaco 51% deve essere portato avanti per veramente lungo tempo...! no?

Se con il caso mtgox sono spariti 800.000 btc e il mercato ha attutito il colpo tranquillamente bisogna che lavorino parallelamente veramente per tanto per creare un danno irreparabile o mi sbaglio?
legendary
Activity: 2632
Merit: 1040
June 23, 2014, 06:42:30 AM
#15
Prendi con le pinze quello che ti dico, ma rifacendomi a questa immagine :



La blockchain valida è la nera perchè più lunga, i rami viola sono "orfani".

Tu immagina se all'ultima biforcazione, la chain nera sia quella del 51% Attack, e la viola quella del 49%.
Si va avanti su 2 binari per X Tempo. Poi viene rilasciata la catena nera (tenuta segreta e non comunicata al network).
Essa prende il posto della viola dalla ramificazione in poi. La viola è cadavere e nessuna transazione è confermata.
sr. member
Activity: 367
Merit: 250
June 23, 2014, 06:36:18 AM
#14
Ma quindi in caso di attacco 51% verrebbero annullate "solo" le transazioni avvenute nella durata dell'attacco prima dello scambio di blockchain giusto??
hero member
Activity: 484
Merit: 500
June 23, 2014, 05:51:17 AM
#13
Compriamo un asic a testa non a scopo di lucro ma a scopo di aumentare l'hash rate totale
legendary
Activity: 2632
Merit: 1040
June 23, 2014, 05:36:50 AM
#12
OMG SEEEEEEEEEELLLL!!!!!!!!!!!SEEEEEELLLL!!!!!



Purtroppo questo è un problema ben diverso dal ban di una nazione o dalla truffa, dove il Panic Sell è spesso frutto di pura paura spesso infondata da parte degli utenti.
E' sempre meglio distinguere il così detto FUD da un problema reale.
legendary
Activity: 2632
Merit: 1040
June 23, 2014, 05:35:03 AM
#11
In poche parole questo attacco potrebbe essere già in atto da tempo.

Ovvio

Quote
In ogni caso non si potrebbe fare una specie di fork e rimettere la vecchia blockchain (manualmente, magari con un aggiornamento importante nel client) nel tal caso avvenisse questo attacco?

Si, certo si potrebbe fare una hard-fork ma il BTC perderebbe talmente tanta fiducia che sarebbe davvero dura ripartire.
Inoltre pensa a tutti gli scambi avvenuti, come li riporti indietro?Huh
Non stiamo parlando di una alt-coin come le altre che viene forkata senza problemi dato che viene utilizzata solo a fini speculativi e non commerciali.

Prendiamo ad esempio qualcuno tra gli ultimi blocchi :

https://blockchain.info/it/block-index/440438 3,513 BTC
https://blockchain.info/it/block-index/440431 4,107 BTC

Come lo spieghi agli utenti???

Il problema deve essere corretto prima che sia troppo tardi, questo è il mio pensiero chiaramente.
Mi piacerebbe tanto essere contraddetto.....
 
hero member
Activity: 728
Merit: 500
June 23, 2014, 05:34:00 AM
#10
OMG SEEEEEEEEEELLLL!!!!!!!!!!!SEEEEEELLLL!!!!!

hero member
Activity: 484
Merit: 500
June 23, 2014, 05:27:49 AM
#9
In poche parole questo attacco potrebbe essere già in atto da tempo. In ogni caso non si potrebbe fare una specie di fork e rimettere la vecchia blockchain (manualmente, magari con un aggiornamento importante nel client) nel tal caso avvenisse questo attacco?

Cioè qualcuno potrebbe già aver il 51% in "sordina" senza che nessuno lo sappia?
legendary
Activity: 1061
Merit: 1283
June 23, 2014, 05:24:25 AM
#8
In poche parole questo attacco potrebbe essere già in atto da tempo. In ogni caso non si potrebbe fare una specie di fork e rimettere la vecchia blockchain (manualmente, magari con un aggiornamento importante nel client) nel tal caso avvenisse questo attacco?
hero member
Activity: 484
Merit: 500
legendary
Activity: 2632
Merit: 1040
June 23, 2014, 03:17:44 AM
#6
Ci sono varie soluzioni ipotizzate.
Però non mi intendo di algoritmi per determinare la validità di 2 strutture che si presentano entrambe come "valide".
Ho sentito dire che l'algoritmo non dovrebbe ragionare sulla catena col blocco confermato più alto  ma ragionare sul contenuto dei blocchi e capire che la catena seppur più corta, è comunque quella valida. Non mi butto dentro un esempio per mancanza di conoscenza.
hero member
Activity: 484
Merit: 500
June 23, 2014, 03:06:38 AM
#5
A pelle direi che investire in un anno di chain parallela è troppo rischioso (devi essere sicuro di essere in vantaggio sempre), secondo me puo' avvenire nell'arco di 120 transazioni ma anche molte meno, mi pare che ci debbano essere 6 blocchi in piu' sulla catena vincitrice.



Risulto invece sorpreso del fatto che la soluzione a questo problema non sia ancora stata codificata nel core e sembra presa molto sotto-gamba.


E questa soluzione ipotetica nel core, esiste già (almeno teoricamente) ?
legendary
Activity: 2506
Merit: 1120
June 22, 2014, 06:03:52 PM
#4
Se l'attacco ha l'obiettivo di screditare bitcoin allora potrebbe essere la banca centrale xy, il governo zk ad avere il colpo in canna.
Io ho sempre associato questo attacco al double spending e tenerlo in serbo per un anno non lo trovo utile.
Bisogna capire quanto costerebbe all'entità x duplicare la potenza di calcolo e provare a sganciarsi, se il sistema è stato studiato a dovere dovremmo essere sempre in vantaggio noi piccoli in quanto numerosi, uno troppo grosso non so quanto dovrebbe esserlo e quali i rischi se fallisce. Al massimo si butta via un pezzo di chain ma credo che le transazioni esistenti possano in qualche modo essere riesumate in quanto pubbliche, ovvio che ci devono essere i fondi all'origine. Se no si fa il double spending e amen.
Rimane il fatto che se succede e' un casino.
legendary
Activity: 2632
Merit: 1040
June 22, 2014, 05:48:21 PM
#3
A pelle direi che investire in un anno di chain parallela è troppo rischioso (devi essere sicuro di essere in vantaggio sempre), secondo me puo' avvenire nell'arco di 120 transazioni ma anche molte meno, mi pare che ci debbano essere 6 blocchi in piu' sulla catena vincitrice.

120 Blocchi intendi?
Secondo me se fai un vero 51% Attack, non butti giù meno di 24 ore di blockchain (1 giorno sarebbero 144 blocchi in linea teorica), se organizzi un 51% Attack con fini di dolo, la tiri per le lunghe, per mesi, solo così distruggerai veramente ogni possibile speranza di riparazione e di riacquisto di fiducia negli utenti.

Io ho una tendenza al catastrofismo, ma da bravo informatico sono convinto che laddove ci sia una falla nota, prima o poi il naso qualcuno ce lo mette.

Ora io non voglio sminuire i tecnici della BFL, KNC, Terrahash etc ma non credo che siano dei luminari dell'elettronica, mi permetto di pensare che siano tecnici capaci come possono esserlo tanti altri nel loro campo.
Quindi se qualcuno col cash (molto cash) decidesse di mettere in piedi un team per costruire asic di generazioni avanti (noi con i suddetti tecnici siamo passati da 333Mh/S a 10Th/S in meno di  anno) e preparare questo disastro, non ne risulterei sorpreso.

Risulto invece sorpreso del fatto che la soluzione a questo problema non sia ancora stata codificata nel core e sembra presa molto sotto-gamba.
Questo davvero mi sorprende e non capisco cosa stiano aspettando, dato che, ripeto, potrebbe già essere stata messo in atto la preparazione di un 51% attack da molto tempo.
legendary
Activity: 2506
Merit: 1120
June 22, 2014, 01:01:11 PM
#2
A pelle direi che investire in un anno di chain parallela è troppo rischioso (devi essere sicuro di essere in vantaggio sempre), secondo me puo' avvenire nell'arco di 120 transazioni ma anche molte meno, mi pare che ci debbano essere 6 blocchi in piu' sulla catena vincitrice.
legendary
Activity: 2632
Merit: 1040
June 22, 2014, 12:15:05 PM
#1
Si parla moltissimo del 51% Attack, ma leggendo in giro è evidente come molte persone prendano per buono il pericolo del 51% Attack senza capire in cosa consista, come si esegue e soprattutto le conseguenze che porterebbe al protocollo bitcoin.

Vi linko 2 video in inglese, spiegati molto bene, il primo parla di quanto costerebbe eseguire un 51% attack, e il secondo di come si esegue

https://www.youtube.com/watch?v=bi2thGzzNSs
https://www.youtube.com/watch?v=Kjtgp5h-jEY

Siccome anche io sto chiarendo le idee per quel che ho capito possiamo affermare che (e correggetemi se sbaglio).

- Se metti in piedi un 51% Attack, il tuo hashpower sparisce dalla rete, stai minando in solo e non confermi i blocchi nella rete.
- Devi minare una blockchain parallela basata sul fatto statistico che se hai il 51%, della potenza prima o poi avrai una blockchain più lunga di quella creata da quelli che detengono il 49% della potenza.
- Nessuno saprà dell'esistenza della tua blockchain parallela.
- Il protocollo Bitcoin fà vincere la blockchain più lunga, quindi un attacco 51% messo in piedi in 1 anno, al momento del rilascio della blockchain parallela annullerebbe tutte le transazioni dell'ultimo anno.
- Esistono soluzioni e devono essere implementate, altrimenti il BTC non potrà mai essere mainstream

Jump to: