Topic: Bitcoin HardFork (Read 1949 times)

ah ecco chi è...



grazie

La vita mi ha insegnato a non stupirmi più di niente 



FaSan

siamo sper OT e a caval donato non si guarda in bocca ma suvvia.... rifanno gli indici col pallottoliere ?

Spezzo una freccia in favore di Theymos, visto che conosco molto a fondo il software con cui gira questa forum. Dopo l' ultimo down, dovuto ad un guasto degli HDD è stato ripristinato un backup di poche ore prima. Ripristinando il DB è andata persa tutta l' indicizzazione che và rifatta da zero. Calcolando la mole dei posts presenti, ci vorrà qualche giorno


FaSan


PS: usando google, aggiungendo alla fine della chiave di ricerca l' opzione "site:bitcointalk.org" trovi tutto

e' l'amministratore di questo forum.... quello che ogni volta che lo bucano,
invece che ripararlo, disabilita una funzione.... l'ultima volta ha disabilitato
una funzione di nessuno conto, la search. Adesso te lo pui comodamente
leggere tutto se vuoi trovare qualcosa.

Se ho capito il principio dei BTC:
- al primo blocco maggiore della dimensione massima attuale, valido per i nuovi client, ci sarà una possibile fork.
- la velocità non è al momento "bassa" per minare il blocco successivo ci vuole una potenza di calcolo non indifferente, in sostanza: decidono i miner quale catena portare avanti. Stop dei problemi.
- se hai un clien vecchio non processa e ritiene validi i blocchi successivi: vai in mining solo insieme a chi come te non ha aggiornato. Lecito. Ma alla fine vince la chain piu' lunga. Auguri e buon mining.
- se per caso riesci a broadcastare anche solo una transazione sulla chain errata la stessa transizione dovrebbe essere valida sulla chain "differente" quindi non e' cosi' semplice fare il double spending comunque ... (ma dovrei approfondire) ...

Su questa questione non ci capisco molto. Dovrei appronfondire.
Spero solo che qualsiasi decisione venga presa sia debitamente comunicata non solo sul forum ma ovunque.

Per il resto theymos chi? 

Forkare la chain non è un'operazione così complessa, e non c'è di certo bisogno di aspettare l' aumento di size delle TX per farlo (volendolo fare). E se i Devs si muoveranno bene avere un network parallelo non servirebbe a nessuno. Muoversi bene significa rifutare ogni chiamata da client inferiori alla versione X. In questo modo la chain parallelo avrebbe si nello storico i vecchi balance fino al momento del fork, ma è anche vero che non potendo inviare TX nella nuova vengono completamente esclusi.

Chi si muove in ambito Alt-Coin conosce bene queste cose, poichè il fork della chain e gli hardfork sono all' ordine del giorno. E' vero che il rapporto è sicuramente diverso, ma è anche vero che, e qui mi ripeto, se le cose vengono fatte bene, non c'è da temere nulla.




FaSan

più che un rischio potrebbe essere proprio l'obiettivo di alcuni come popescu. se diverse persone decidono deliberatamente di non aggiornare mai il wallet perché non vogliono le nuove feature, forse puntano proprio a creare una catena separata. che sia fattibile o meno non so, però se c'è gente che spende energie in questo, diventa un possibile problema per tutti gli altri. e mi pare che popescu e i suoi amici stiano già promuovendo l'uso di una versione wallet non oltre la 0.5.3 http://cascadianhacker.com/blog/2014/10/21_instructions-on-building-bitcoin-053-from-source-on-debian-6-squeeze.html

Si mi è suonato un pò così appena l'ho letto 

diciamo che se lo e',  non spreca inutilmente intelligenza nella gestione del forum

Chi lo sà.. magari Theymos in realtà è Nakamoto 



FaSan

dici che suona un po' come  "le chiavi della centrale nucleare le hanno Murray Gell-Mann, Stephen Hawking e Paperino" ?

fortuna che ci possono solo scrivere messaggi....

Infatti, se scoppiasse una bolla adesso che i bitcoiners sono di più il sistema non c'è la farebbe a sopportarlo, e non ho idea di quello che potrebbe succedere.


Comunque il fatto di theymos mi ha un po scosso anche a me.

bisogna anche dire che al momento sembra non ci sia la necessità dell'hardfork perche siamo molto al di sotto della soglia massima di transazioni al secondo supportate, ma guardando i grafici della blockchain nel periodo dei 1000 dollari notiamo un aumento incredibile delle transazioni, e la storia si potrebbe ripetere anche in caso di una nuova bolla ma questa volta il numero di persone che usano bitcoin è molto più alto rispetto a quel periodo.

L' errore stà nel fatto che il wallet và aggiornato. Punto e basta. Chi non l' aggiorna rischia di trovarsi in un network parallelo.

Ma se è vero che l' aumento della size avverrà in forma graduale è pensabile che già dalla prossimo rilascio sia prevista. Quindi magari tra un anno lo switch avverrà in maniera silente e senza farci troppo caso.

Non è il primo fork della storia dei Bitcoin, c'è stato con le vecchia 0.6 -> 0.7 e se non erro anche tra la 0.4 e la 0.5


E sono sicuro che escluderanno il vecchio network in modo da non creare promisquità (si fà facilmente agendo sulla version del wallet).




FaSan

Se ho capito bene, l'unico ad opporsi seriamente e con tanta acrimonia all'aumento della dimensione dei blocchi è Mircea Popescu (mpex.co).

E devo dire che non capisco tanto bene.

L'articolo di Mircea Poescu a proposito sarebbe questo.

E - sempre se ho capito bene - la sua argomentazione sul modo di "svuotare" una blockchain a favore dell'altra (riportata anche nell'articolo su qntra) non sta in piedi. Lui dice:

E' vero che da un indirizzo posso fare un double spend sulle due catene:

Chiamiamo le due catene  L (large) e S (small). Avremo quindi LSBitcoin (validi su ambedue le catene), LBitcoin (validi solo sulla catena L) e SBitcoin (validi solo sulla catena S)

Alice ha 1 Bitcoin che non muove da prima del fork, quindi valido su ambedue le catene. È quindi un LSBitcoin. Sulla catena L lo manda al suo amico Beppe, sulla catena S lo manda a sè stessa.

E' (in un certo senso) un double spend, ma ogni catena è coerente. un LSBitcoin si è sdoppiato in un LBitcoin e in un SBitcoin.

Qui Popescu dice:


Ovvero?

Mi sembra di capire che intenda che Alice (che ha ancora il suo SBitcoin sulla catena S) lo usa per comprare un ULTERIORE LSBitcoin di Carlo, un tizio che ha anche lui 1 Bitcoin vecchio, rimasto buono su tutte e due le catene.

Allora Alice potrebbe usare il LSBitcoin di Carlo, fare un altro pseudo-double spend e mandare 1 LBitcoin  sempre a Beppe sulla catena L, e 1 SBitcoin di nuovo a sé stessa sulla catena S.

Quello che non mi torna è cosa sia questa "vendita" di Bitcoin che Popescu descrive "purchase more legitimate Bitcoins".

Uno non usa Bitcoin per comprare Bitcoin: tutt'al più manda Bitcoin a un indirizzo, in modo che sia provabile (tramite la catena di UTXO) che quel Bitcoin non sia già stato speso.

E' vero che il Bitcoin di Carlo è buono su ambedue le catene, però in definitiva Carlo (quando facesse questo scambio con Alice) deve usare un qualsiasi wallet per ricevere il Bitcoin di Alice e per mandarle il suo.

Si danno qui due ipotesi:

1) Carlo ha deciso di NON AGGIORNARE il suo Wallet, perché non vuole i blocchi grossi. Carlo è quindi rimasto sulla catena S. Ottiene un  SBitcoin da Alice e le manda un LSBitcoin. 

Domanda: Rimane fregato? Verrebbe da dire di sì, perché ha avuto un SBitcoin in cambio di un LSBitcoin (quindi ha un Bitcoin che non potrà mai andare sulla catena nuova, L)

MA lui, restando sulla catena originale S, ha già "votato", dicendo  in pratica "per me i LBitcoin non valgono", quindi per lui un SBitcoin EQUIVALE a un Bitcoin "vero", quindi vale quanto un LSBitcoin

1) Carlo ha deciso di  AGGIORNARE il suo Wallet, perché  vuole i blocchi grossi. Carlo è quindi migrato sulla catena L. Quando Alice gli manda il suo SBitcoin, il suo Wallet lo rifiuta, perché dice "Questa UTXO è già stata spesa".

Quindi non viene danneggiato.

Non vedo come possa avvenire questo "draining away value from the holders of Bitcoin fakes" (farebbe pensare a una qualche meccanismo per cui la catena originale "svaluta" quella L.

E poi, il titolo stesso dell'articolo "If you go on a Bitcoin fork, irrespective which scammer proposes it, you will lose your Bitcoins." farebbe pensare che questo sia valido per QUALSIASI fork, ovvero che non sarà mai possibile fare cambiamenti al protocollo.

Ma se così fosse, allora non sarebbe vero quello che da sempre si dice che "in caso di bisogno, si possono fare cambiamenti al protocollo".

E sopratutto, mettiamo che tra 20 anni ci sono computer quantici per (supponiamo) cui fosse possibile rompere l'ECDSA. Tutti ci hanno detto (a partire da qui, ma basta cercare "Bitcoin quantum computer" per avere decine di discorsi al propositi) che quando, si vederessere i primi computer quantici vagamente capaci di avvicinarsi al risultato, basterebbe cambiare il protocollo e aggiornare le fondamenta crittografiche.

Ma se ha ragione Popescu, questo (aggiornare il protocollo) non è possibile, e allora se ha ragione Popescu Bitcoin sarebbe condannato.

Sbaglio da qualche parte?

l'hardfork è un argomento che va tenuto sott'occhio perché recentemente sta facendo discutere parecchio. C'è anche gente che si oppone fermamente e minaccia di forkare la blockchain rifiutando le transazioni degli eventuali blocchi estesi e mantenendo due catene distinte.

http://qntra.net/2015/01/the-hard-fork-missile-crisis/
http://www.reddit.com/r/Bitcoin/comments/2s2utx/the_hard_fork_missile_crisis/

Si, basta settare una IF sul timestamp o sul blockheight e sei apposto.

E si, c'è anche la possibilità di inviare alert nel network, da parte di chi detiene la pubkey definita qui : https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L113



FaSan

Sì, è possibile.
Cfr https://en.bitcoin.it/wiki/Alerts

> Only alerts that are signed by a specific ECDSA public key are considered valid. The known private key holders are Satoshi Nakamoto, Gavin Andresen and theymos.

Hardfork a mio modo di vedere necessaria (quella del blocksize)
No sapevo della Hardfork dilazionata nel tempo, e quindi a maggior ragione, credo che saranno necessarie parecchie hardfork negli anni e avranno un impatto minimo.
Ora non ricordo se il core è in grado di mandare messaggi tramite la rete (intendo msg automatici che escono come pop up) che avvisano che il tuo sw è obsoleto e che va aggiornato.

> In pratica se non erro (qualcuno mi corregga se sbaglio) è il sistema di cifratura del BTC sia a lato key che al lato transazioni che è cambiato.

NON E' CAMBIATO NULLA!!

Tu ti riferisci a questa pagina:

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

Si tratta di una Wishlist, ovvero di "cose per cui alcuni vorrebbero fare una Hard Fork", non "cose per cui sarà fatta una Hard Fork", meno che mai "cose per cui si è fatta una Hard Fork"

Nulla di quanto elencato in quella pagina è stato fatto né si è deciso di farlo.

L'unica cosa di cui si sta parlando SE farla è la  prima feature (Replace hard-coded maximum block size).

Gavin Andersen  ne parla da un po'.

In pratica, quella modifica aumenterebbe la dimensione dei blocchi della blockchain per permettere di gestire più transazioni all'ora, e non impatterebbe minimamente chiavi, transazioni ecc.

Per come la propone Andersen (qui: https://blog.bitcoinfoundation.org/a-scalability-roadmap/ ), basterebbe aggiornare il wallet che gestisce la blockchain, e senza neppure tanta fretta:

> Roll out a hard fork that increases the maximum block size, and implements a rule to increase that size over time, very similar to the rule that decreases the block reward over time.

Cioè: io sono Gavin, e pubblico oggi la nuova versione che prevede che tra X anni la dimensione dei blocchi aumenta da 1M a 2M. Per questi X anni, tutto funziona come prima, ma tutti sanno che il cambiamento è in arrivo.

Per questi X anni, software vecchi e nuovi sono ancora compatibili e lavorano insieme. Quindi tutti (nodi, sviluppatori di wallet e gente che ha installato i wallet) hanno ampio margine per aggiornare il loro software.

Allo scadere degli X anni si avrebbe la hard fork, ovvero i software aggiornati mettono in atto il cambiamento e la rete si potrebbe ipoteticamente dividere in due (ecco perchè si parla di fork, biforcazione) tra nodi che hanno aggiornato il software e nodi che non l'hanno aggiornato. I nodi vecchi e i nodi nuovi non potrebbero parlare tra di loro, e si avrebbero in pratica due reti parallele, una attuale e l'altra obsoleta.

E' da considerare che:
1) questo sarebbe importante per i soli nodi, non gli utenti con il solo wallet
2) anche se un utente con wallet fosse in ritardo, e quindi restasse per sbaglio sulla versione vecchia, basterebbe aggiornare il software, riscaricare se necessario la blockchain, e sarebbe a posto.

E ovviamente, tutto questo non riguarderebbe minimamente chiavi private e pubbliche (ad esempio, chi ha un paper wallet potrebbe continuare a tenerelo come è)

Changes to hard-coded limits

    Replace hard-coded maximum block size (1,000,000 bytes) and maximum number of signature operations per block (20,000) with .

Major structural changes

    "Flip the chain", instead of committing to new transactions, commit to the summaries of open transactions: [1] [2] [3] [4]
    Increased efficiency for merged mining: restructure the primary header to make the bitcoin specific data non-mandatory. (e.g. the block chain specific stuff would go into second header connected by a header tree), making the primary headers pure timestamps and nonces.
    Switch to block hashing algorithm secure against block withholding attacks.

Transaction behavior changes

    Improved signature types to allow for partial malleability of outputs. (e.g. make it easier to add a fee onto someone else's transaction, or to take fees from a transaction without outputs set aside for that purpose)
    Elimination of output scripts: all transactions pay-to-scripthash, probably with a single byte indicating the scripthash type. Other than reducing effective output script secrecy (which is not possible without OP_EVAL anyways) this is believed to be costless, and the secrecy can be recovered with recursive OP_EVAL. The motivation here is that data in outputs is far more expensive than inputs because some outputs may be never prunable, and pay-to-scripthash minimizes output size without harming total size.
    Allow soft-spending of generation outputs without confirmations (outputs of these transactions might also appear as generation themselves)
    Allow additional inputs to generation transactions
    Add new signature hashtype to include value of TxOut being spent, in the hash to be signed. Doing this would remove the requirement that offline signing devices be sent all supporting transactions with the transaction-to-be-signed, just to confirm the transaction fee.



In pratica se non erro (qualcuno mi corregga se sbaglio) è il sistema di cifratura del BTC sia a lato key che al lato transazioni che è cambiato.

In parole semplici cosa comporterebbe questa hard fork, usando electrum come cold storage cosa cambierebbe,
dovrei "tirarli fuori" e cambiare indirizzo, magari dopo un aggiornamento software?
Non ho davvero idea di cosa sia