Pages:
Author

Topic: Guida al hard fork di Bitcoin (nel caso capiti) - IMPORTANTE - page 20. (Read 45090 times)

sr. member
Activity: 439
Merit: 252
Get Paid to Play your Media on Current
Scusate non ho letto tutto...
Ma è avvenuto l'hard fork? Se si quando?
Avete "duplicato" i bitcoin che avevate sulla nuova blockchain?


al momento non è avvenuto alcun fork
member
Activity: 87
Merit: 14
Scusate non ho letto tutto...
Ma è avvenuto l'hard fork? Se si quando?
Avete "duplicato" i bitcoin che avevate sulla nuova blockchain?

staff
Activity: 4270
Merit: 1209
I support freedom of choice
Il codice è pubblico da ottobre 2016
https://github.com/bitmaintech/bmminer/blob/b5de92908498590d96d333a1e2570eab0eb321d3/driver-btm-c5.c

Quindi difficile definirla backdoor.

Sembra che sia parte di un servizio che non è andato online e/o non è stato completato.
https://www.reddit.com/r/btc/comments/67qzsn/antbleed_exposing_the_malicious_backdoor_on/dgsmq43/

Cosi pare una grossa disattenzione.
legendary
Activity: 1981
Merit: 1039
eccone un' altra sorpresa da parte di Bitmain  Roll Eyes


Antbleed is a backdoor introduced by Bitmain into the firmware of their bitcoin mining hardware Antminer.

http://www.antbleed.com/
legendary
Activity: 2506
Merit: 1120
...
ma infatti, c'era qualcosa che non mi tornava. Evidentemente questa cosa delle collisioni riguarda solo uno step intermedio del calcolo dell'hash. Anzi, alla fine non è mica la hash dell'hash? Si deve mischiare tutto in qualche modo, bel casino...
sha dividono il file in blocchi da 64Byte e li elaborano in qualche modo (devo capire ancora come ...) e poi usano i risultati mischiando i vari bit di tutti i blocchi.
Se un blocco da 64Byte rimane invariato è inutile rifare gli stessi calcoli e' questo il trucco, se ci si pensa bene però piu' che trucco a me sembra una ottimizzazione.
Una cosa che si rimprovera credo sia il fatto che cambiano il chunk 1 e lasciano invariato il chunk 2 (4byte del merkle root, time, nbits, nonce, padding e size) rimescolando le transazioni mentre il protocollo prevede di cambiare il chunk 2attraverso il nonce.
A questo punto un miner potrebbe crearsi il set di merke root con i 4byte finali uguali con transazioni fittizie tutte sue che non saranno mai inserite in altri blocchi e mina  per ogni nonce tutte queste combinazioni riducendo i calcoli ... non sarebbe molto utile alla rete ma non violerebbe il protocollo. Non riceverebbe fee, quando il premio si abbasserà sara' sempre meno conveniente.
legendary
Activity: 3808
Merit: 2044
Sto cercando di capirci qualcosa... non mi è chiara la parte dove dice che si possono trovare collisioni tenendo fisso il secondo chunk e variando la versione, che è invece all'inizio del primo chunk. Ma a cosa serve tenere fisso il secondo e variare il primo, dato che il target deve avere zeri nei bit più significativi, che quindi interessano solo la metà più "alta" dell'hash?
Quello è l'input e non credo sia collegato all'output quindi basta che cambi un qualunque bit in input che stravolge l'output, se ho intuito bene si risparmia tenendo invariati i blocchi di 80 byte e variando l'altro, l'idea e' di cambiare il nonce ma qui' mi sa che cambiano l'ordine delle transazioni. 

ma infatti, c'era qualcosa che non mi tornava. Evidentemente questa cosa delle collisioni riguarda solo uno step intermedio del calcolo dell'hash. Anzi, alla fine non è mica la hash dell'hash? Si deve mischiare tutto in qualche modo, bel casino...
legendary
Activity: 2506
Merit: 1120
Sto cercando di capirci qualcosa... non mi è chiara la parte dove dice che si possono trovare collisioni tenendo fisso il secondo chunk e variando la versione, che è invece all'inizio del primo chunk. Ma a cosa serve tenere fisso il secondo e variare il primo, dato che il target deve avere zeri nei bit più significativi, che quindi interessano solo la metà più "alta" dell'hash?
Quello è l'input e non credo sia collegato all'output quindi basta che cambi un qualunque bit in input che stravolge l'output, se ho intuito bene si risparmia tenendo invariati i blocchi di 80 (EDIT: sono 64byte) byte e variando l'altro, l'idea e' di cambiare il nonce ma qui' mi sa che cambiano l'ordine delle transazioni. 
legendary
Activity: 3808
Merit: 2044
Sto cercando di capirci qualcosa... non mi è chiara la parte dove dice che si possono trovare collisioni tenendo fisso il secondo chunk e variando la versione, che è invece all'inizio del primo chunk. Ma a cosa serve tenere fisso il secondo e variare il primo, dato che il target deve avere zeri nei bit più significativi, che quindi interessano solo la metà più "alta" dell'hash?
legendary
Activity: 2506
Merit: 1120
Asciiboost: da quello che ho capito a me non sembra un attacco ma una scappatoia per evitare conti inutili, non mi sembra cosa sbagliata usarla se non infrange le regole ...
Alla fine avremmo solo una difficoltà piu' elevata ... il protocollo btc è affascinante proprio per il fatto che ha regole chiare, se si riesce a risparmiare buon per chi ci riesce. Se non si puo' impedire va accettato. Abbiamo il caso ethereum che assomiglia alla finanza classica in quanto hanno cambiato le regole per evitare che il furbacchione se ne approfittasse.

Poi, se si vuole cambiare regole del mining si faccia ma per come e' studiato direi che non sia praticabile un cambio quando tutti i miner sono ottimizzati per sfruttare una caratteristica non credo che nessuno si seghi le gambe volontariamente.
legendary
Activity: 1981
Merit: 1039
sembra che bitmain già lo usi nei suoi cloud miner mentre per gli asic è supportato ma non abilitato, lo hanno anche brevettato immagino ci vogliano profittare, magari con un update a pagamento, anche se lo regalassero il vantaggio potrebbe annientare la concorrenza già adesso hanno il 70% del mercato.


Quote
Exploitation of this vulnerability could result in payoff of as much as $100 million USD per year

https://cryptoinsider.com/100-millionyear-asicboost-attack-bitcoin-blockchain-implemented/


il miner onesto che si rifiutasse di utilizzarlo otterrebbe il 20-30% di profitti in meno, con il rischio di finire fuori mercato.
sr. member
Activity: 439
Merit: 252
Get Paid to Play your Media on Current
ma questo algoritmo è già attualmente in uso o è solo "sulla carta"?
legendary
Activity: 1981
Merit: 1039
no è un exploit e si basa su una collisione delle merkle roots, forse il modo migliore per spiegarlo è citando antonopulos

Quote
The real issue with this ASICBOOST drama is the fact that it incentivizes bizarre Tx selection and resistance to block header changes

https://twitter.com/aantonop/status/849803727686914048


se di fatto incentivizza una discirminazione di Tx andiamo già a violare i principi del bitcoin

https://en.bitcoin.it/wiki/Principles_of_Bitcoin


sr. member
Activity: 439
Merit: 252
Get Paid to Play your Media on Current
Ma quale sarebbe il problema? è semplicemente un metodo per minare in modo più efficiente, alla fine i blocchi prodotti sono comunque validi e non creano alcun problema al funzionamento della rete.
legendary
Activity: 1981
Merit: 1039
nell'articolo di postato da Hostfat c'è questa parte

Quote
This is the reason why Segwit makes the use of transaction reordering more difficult. Transaction reordering is the most efficient covert method for AsicBoost, and the one more suited for FPGA implementation. It forces the covert-AsicBoost miner to mine only blocks not containing Segwit transactions.

The recently proposed method blocks a specific form of covert Segwit using transaction reordering (d1). The other less-efficient covert methods (b1) in a Segwit block still exists.


l'attuale Segwit gli metterebbe un bel po i bastoni fra le ruote ma non risolverebbe definitivamente il problema.
 
legendary
Activity: 2506
Merit: 1120
ma di fatto è una attacco al pow mining se riduce il lavoro necessario per minare, visto che il segwit impedisce di sfruttare questa vulnerabilità è possibile che quelli che la stiano sfruttando siano contrari al segwit.
Sarà ma essendo segwit un softfork presumo che i miner non siano obbligati a minare blocchi compatibili quindi possono minare blocchi non segwit e continuare a sfruttare la falla.
Comunque leggo:
Quote
5. Are SegWit and ASICBOOST are fundamentally incompatible?
No.
legendary
Activity: 1981
Merit: 1039
ma di fatto è una attacco al pow mining se riduce il lavoro necessario per minare, visto che il segwit impedisce di sfruttare questa vulnerabilità è possibile che quelli che la stiano sfruttando siano contrari al segwit.
legendary
Activity: 2506
Merit: 1120
Ammetto di non aver decodificato tutto il documento, mi confermate che l'eseguire 2 volte sha256 non basta a mitigare il problema descritto?
Mi sa che tocca studiare a fondo sha256 ...
sr. member
Activity: 347
Merit: 250

Interessante...quindi oltre alla questione della dimensione del blocco si aggiunge quest'altro problema da risolvere...una compatibilità o no tra segwit e asicboost, tra bitcoin core e i miners.. e questo non porterebbe questi ultimi a puntare ancora di più per Bitcoin unlimited?

Quote
How can we fix this?
There are a few options:

1. Don’t do anything
• Pro: Any changes to Bitcoin are dangerous.
• Con: Status Quo is obviously harming Bitcoin.

2. Change SegWit to be compatible with ASICBOOST
• Pro: If we could start over, it would be easy to do.
• Con: Segwit is already written, reviewed, and adopted in industry.

3. Block just undetectable ASICBOOST
• Pro: Solves the immediate problem.
• Con: We wouldn’t be blocking it because undetectable optimization
is wrong, but because this specific optimization intereferes with pro-
tocol development. The propensity to conflate the two is dangerous.

4. Block all ASICBOOST
• Pro: ASICBOOST is not available to all miners, this levels the field.
• Con: A dangerous precedent to set. Picking winners and losers.

5. Hard fork Bitcoin to a new header format
• Pro: Could leave ASICBOOST intact, put SegWit commitment in
header, and everything else on the Bitcoin Hard-Fork Wish List.
• Con: Dangerous precedent, risk to split network.


staff
Activity: 4270
Merit: 1209
I support freedom of choice
Pages:
Jump to: