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.
Topic: Bitcoin HardFork - page 2. (Read 1948 times)
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.
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 è)
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.
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
dovrei "tirarli fuori" e cambiare indirizzo, magari dopo un aggiornamento software?
Non ho davvero idea di cosa sia
Jump to: