Pages:
Author

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

legendary
Activity: 1914
Merit: 2071
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: 1914
Merit: 2071
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: 500
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: 1914
Merit: 2071
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: 500
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: 1914
Merit: 2071
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: 1914
Merit: 2071
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
Pages:
Jump to: