Mi accodo alla richiesta di altri utenti: una piccola guida che spieghi i passi principali per mettere su una vps e per gestirla da remoto, installandoci Bitcoin Core (o Classic).  
Finora qui sul forum c'è solo un thread nel quale si spiega come configurare un full node (sostanzialmente come settare alcuni parametri nel file bitcoin.conf).
Lavorare con una vps non è un'operazione abituale per la grande maggioranza degli utenti di questo forum; probabilmente molti sarebbero disposti a pagare anche qualche euro al mese per provare, magari non hanno intenzione però di investire tempo per studiare da soli come fare.

Forza informatici!  
Date il vostro contributo alla rete con una bella guida!  

Appunto, la banda e lo spazio sul disco sono costi significativi solo per un full node "semplice", non per un miner + full node



Già adesso nessuno impedisce a un miner di limitare autonomamente la dimensione del blocco da minare a 700kB o anche a 0 (il minimo è inserire nel blocco solo la coinbase transaction) --> https://bitcointalk.org/index.php?topic=1085800.msg11577559#msg11577559

Osservazione: i miner sarebbero sicuramente avvantaggiati dalla modifica (+ transazioni, + fee ,  il tutto a lavoro per loro  sostanzialmente immutato). Per i full node, invece, l'aumento della dimensione dei blocchi vuol dire più banda e più lavoro per verificare un numero medio di transazioni al minuto crescente, quindi in sostanza più costi.

Bitcoin Classic è un fork molto recente di Bitcoin Core, gli stessi sviluppatori nella home page del sito sconsigliano i miner di utilizzare il loro software perchè potrebbe esserci qualche baco (e se qualcosa non funziona a dovere i miner ci rimettono molti soldi, a differenza dei full node).

Penso sia solo questo il motivo per cui i miner non sono passati ancora al Classic.

Per quanto riguarda la rete dei full node sospetto che il ritardo con cui verrà rilasciata la versione 0.12 di Core abbia anch'esso giocato un piccolo ruolo nell'indurre i full node a provare Classic; i full node sono più agili nei cambiamenti rispetto ai miner, ma il loro consenso politico è decisivo: a che cosa servirebbe ai miner votare adesso con il 75% dei loro voti i blocchi da 2 mega, se poi la gran parte dei full node non fosse disposta a riconoscere questi blocchi validi per assemblarli nella blockchain?
Sono proprio i full node, quelli più penalizzati da questa modifica, i primi che devono dichiararsi disponibili al cambiamento; i miner lavorano in funzione dei full node, non viceversa!

Sì, se da quell'indirizzo non è mai stata effettuata alcuna transazione vuol dire che la chiave pubblica dell'indirizzo non è mai stata esposta pubblicamente nella blockchain; è solo quando si firma una transazione con la chiave privata di un proprio indirizzo (cioè quando si autorizza l'invio di fondi da quell'indirizzo) che bisogna rendere effettivamente pubblica la chiave pubblica. L'anello "debole" (debole si fa per dire!) è il collegamento chiave privata - chiave pubblica, non il collegamento chiave pubblica - indirizzo. Dall'indirizzo è impossibile*** ricavare la chiave pubblica, dalla chiave pubblica forse un giorno lontano potrebbe essere possibile risalire alla chiave privata.

***EDIT: sarebbe meglio specificare, più che impossibile  --> impraticabile; mentre nel caso dell'algoritmo che genera la chiave pubblica da quella privata si può pensare di trovare un domani un modo efficiente di invertire il processo, nel caso si abbia invece come unico dato di partenza solo l'indirizzo, non rimane che utilizzare la forza bruta: si iniziano a generare tutte le chiavi private possibili (sono poco meno di 2^256), e per ciascuna di queste si genera la chiave pubblica corrispondente e il relativo indirizzo; poichè gli indirizzi sono dell'ordine di 2^160, probabilmente ci sono in media 2^96 chiavi private distinte che generano 2^96 chiavi pubbliche distinte che producono esattamente lo stesso indirizzo. Quindi "basterebbe" trovare una di quelle 2^96 chiavi private a furia di tentativi nell'universo di tutte le 2^256 chiavi possibili; in media ci vorrebbero 2^160 tentativi per ogni indirizzo (contro i 2^128 passi necessari attualmente per risalire dalla chiave pubblica alla chiave privata)


In realtà non è proprio possibile non spendere interamente un output di una transazione che fa riferimento a un certo indirizzo; poi succede che alcuni wallet sono impostati per inserire automaticamente nella transazione di spesa decisa dall'utente come indirizzo del resto proprio l'indirizzo di partenza; questo meccanismo rende tutto più intuitivo per l'utente che quasi non si accorge neanche di aver mosso tutti i fondi dal proprio indirizzo e non solo una parte, come erroneamente si potrebbe pensare; però in questo modo si espone il resto che è tornato indietro a un teorico piccolissimo (e assolutamente improbabile) rischio di furto.

Quindi il protocollo di funzionamento del sistema Bitcoin già prevede naturalmente l'azzeramento di un singolo UTXO ogni volta che si prova a spenderne anche solo una parte, ma l'implementazione del meccanismo di gestione dei resti nei vari wallet può vanificare la logica di estrema sicurezza (e di privacy) che è alla base delle transazioni.

Se invece ci sono 2 output di 2 transazioni diverse collegati al mio indirizzo ( es: 5 e 8 btc) e io voglio spendere solo 1 btc di norma il mio wallet spenderà completamente solo uno dei due output, ma l'altro output non speso (in gergo UTXO) rimarrà lì, quindi l'indirizzo non verrà "azzerato".
Non ho capito se gbianchi sostiene che ci siano wallet che azzerano automaticamente tutti gli UTXO associati a un indirizzo alla prima spesa effettuata da quell'indirizzo; quali sono?

Penso convenga innanzitutto cercare di cancellare la transazione non confermata dal proprio wallet (ovviamente se non è stata effettivamente trasmessa alla rete) con l'opzione -zapwallettxes

https://bitcointalk.org/index.php?topic=35214.msg5689840#msg5689840


http://bitcoin.stackexchange.com/questions/25612/how-to-remove-a-transaction-from-the-memory-pool

Spesso parliamo di full node, nella realtà i nodi si stanno ulteriormente specializzando.

Ci sono nodi che possono limitarsi a tenere copia della blockchain e a fornire blocchi su richiesta senza mai validare nulla,
ci sono nodi che validano tutto ma mantengono solo una piccola parte della chain,
ci sono nodi che controllano solo i blocchi e non le transazioni (e questo tipo di lavoro ha requisiti hardware molto contenuti)

Vi rimando a proposito a questo interessante post:

https://bitcointalk.org/index.php?topic=1348256.msg13752092#msg13752092

Ho inserito un indice (all'inizio del primo post) per mettere un po' di ordine in questo thread.

Ho aggiunto anche la parte relativa alla firma e alla verifica, più avanti vedo di inserire magari anche qualche esempio specifico.

Comunque io continuo a non capire il problema della dimensione della blockchain

1) adesso c'è un'opzione (pruning) per cui chi vuole può buttare via quasi tutti i blocchi

2) l'unico problema è il sync iniziale, ma appunto si fa una volta sola

3) i problemi più grossi oggi sono legati alla potenza computazionale richiesta per verificare le transazioni, sono legati alla quantità di banda necessaria per scambiarsi i blocchi e le transazioni, sono legati allo spazio occupato in RAM dal database dell'UTXO e dalla mempool, tutti questi fattori incidono in maniera davvero determinante sulle prestazioni di un full node.

Invece 60 GB per conservare i dati cosa saranno mai oggi? Con poche decine di euro ti prendi un hard disk esterno di 2 TB e sei a posto per anni (e inoltre non è più obbligatorio ripeto mantenere copia di tutta la chain per far girare un full node!)

La risposta alla tua domanda è no, un nuovo utente che adesso deve entrare nella rete non si limita a scaricare la blockchain, quindi non si fida proprio di nessuno!

Il nuovo utente che utilizza Bitcoin Core deve, prima di poter utilizzare i dati della "propria" blockchain per effettuare transazioni o per conoscere semplicemente il bilancio del proprio wallet, compiere le seguenti due operazioni su questi dati:

1) controllare che la propria blockchain sia corretta, cioè che dalla prima transazione del primo blocco all'ultima transazione dell'ultimo blocco siano state rispettate tutte le regole condivise del protocollo bitcoin

2) assicurarsi che la propria blockchain sia tra quelle presenti in rete quella che metta insieme i blocchi che nel loro insieme hanno richiesto più lavoro da parte dei miner per validarli; se il nuovo utente scopre che ci sono altri nodi nella rete che hanno una versione piú "costosa" della blockchain, allora è capitato su una diramazione non valida, è come se a un certo punto avesse sbagliato snodo nell'assemblare la catena e deve quindi provvedere a tornare indietro, cioè deve sostituire alcuni blocchi (per come è concepita la blockchain, una sua riorganizzazione prevede nella pratica solo il cambio degli ultimi blocchi, questo è il motivo per cui nel caso di grosse transazioni si raccomanda di attendere almeno 6 conferme); per non farla troppo lunga la riorganizzazione della blockchain è dovuta al fatto che in un sistema decentralizzato, se due blocchi vengono minati quasi contemporaneamente, l'ordine con cui vengono minati non è subito noto (ad alcuni nodi arriverà prima un blocco, ad altri l'altro); la blockchain ha proprio lo scopo di fissare un ordine temporale al susseguirsi delle transazioni, e riesce a farlo, nonostante i nodi siano dislocati in punti diversi del pianeta, giocando su una temporanea flessibilità della sua parte finale che viene risolta grazie a un discorso probabilistico.



La differenza tra un genesis block sintetico e il genesis block della chain attuale è sostanziale.

Quando è stato creato il genesis block 7 anni fa, non c'erano bitcoin. Quel genesis block rappresenta semplicemente un punto da cui partire; sottolineo "punto", nel senso che non aveva "dimensione", cioè in pratica non c'era nulla su cui si poteva imbrogliare. Quel piccolo punto è inserito nel codice di Bitcoin Core e puoi considerarlo a tutti gli effetti come facente parte delle regole del bitcoin.

Creando un nuovo genesis block adesso (a parte che bisognerebbe cambiare alcune regole del protocollo) si otterrebbe al posto di un semplice punto una complessa figura che descrive la distribuzione attuale di 16 milioni di Bitcoin (su 21 milioni).  Non è proprio la stessa cosa.

Facciamo un paragone con la matematica.
In geometria per esempio si parte da un minimo numero di assiomi (regole condivise dalla comunità dei matematici) e poi da lí si costruiscono tutti i teoremi. Se uno cambia anche un solo assioma, si costruisce una geometria diversa (tipo quella non euclidea).

Gli assiomi di Euclide sono come il genesis block di Satoshi (+ le regole del protocollo). Se adesso la comunità dei matematici dicesse: va bene, ormai gli assiomi non ci servono più, nè molte dimostrazioni in cui ormai crediamo, prendiamo solo i risultati dei teoremi più importanti, e partiamo da quelli, decidiamo ad esempio che un certo insieme variegato di teoremi come quello di Pitagora (o anche teorema più evoluti) sono la nostra nuova base di partenza, e facciamo il pruning delle dimostrazioni (che sono il collegamento logico fra assiomi e risultati dei teoremi attuali), mi pare che avremmo perso moltissimo. O no?

Di questo articolo molto interessante vorrei soffermarmi sui seguenti aspetti:

1) ormai ci sono almeno 3 diversi attori (per semplificare) con interessi non sempre convergenti: miner, full node, "semplici" utenti che vogliono solo effettuare delle transazioni

2) per i miner, più transazioni possono inserire nei blocchi, meglio è (il loro lavoro non aumenta di conseguenza e quindi aumenta la loro redditività)
per i full node al contrario la dimensione dei blocchi e il numero di transazioni incide pesantemente sul loro lavoro, che consiste nel far circolare queste transazioni e nel verificarle una a una (oltre a rendere gli altri nodi in grado di verificarle in modo autonomo fornendo loro anche i blocchi vecchi)
per il semplice utente, più transazioni è in grado di processare il sistema meno tempo dovrà aspettare e minori saranno i costi per le commissioni;
da questo punto di vista sembra che gli interessi di miner e utenti coincidano (blocchi più grandi, più transazioni) mentre per i full node sarebbe meglio il contrario

3) quindi miner e utenti vorrebbero velocità e tante transazioni, i full node che stanno in mezzo e hanno il compito di controllare in modo indipendente queste transazioni sono i regolatori/"rallentatori" che devono aumentare le loro prestazioni e aumentare i costi per le verifiche;
il sistema comunque potrebbe bilanciarsi quasi da solo, nel senso che il bisogno di full node (cioè il bisogno di controllo indipendente delle transazioni) non può non crescere grazie sia a coloro che attiveranno dei servizi sulla blockchain e grazie anche ai singoli che avranno investito somme importanti nel bitcoin e quindi avranno il loro interesse a monitorare il proprio investimento


In sostanza la possibilità di controllare con sicurezza la validità delle proprie transazioni deve avere un costo, costo che sarà sostenibile, come è logico che sia, solo da coloro che devono tutelare grossi volumi.
È impensabile che, qualora io possieda pochi centesimi di Bitcoin (ho visto un thread nella sezione internazionale dove la maggior parte degli utenti sosteneva di possedere appunto solo pochi centesimi) pretenda di avere comunque la possibilità di essere in grado di controllare in modo conveniente per me (ma con il grado di sicurezza incredibile che offre questo sistema!) anche l'acquisto di un caffè. A me pare economicamente insensato, chi paga?
La sicurezza di questo sistema di pagamento la deve pagare in prima persona chi usa i bitcoin. Se uno ne usa troppo pochi allora rinuncerà per forza di cosa alla sicurezza del controllo in prima persona e si fiderà di servizi terzi.

3) se il valore del sistema Bitcoin dipende dal numero di transazioni effettuate (quindi dipende più dal numero degli utenti coinvolti che dal numero dei nodi fisici che le propagano) allora è meglio avere meno full node ma più prestazionali, quelli che ci sono devono quindi essere in grado di gestire blocchi più grandi e un maggior traffico, in modo da mantenere bassi i costi delle transazioni per gli utenti

4) se si perseguisse invece come obiettivo assoluto la decentralizzazione (non nel senso di permettere a tutti di effettuare delle transazioni a basso costo, ma nel senso di permettere a tutti di verificare a basso costo le transazioni mettendo in piedi un loro full node), dovremmo avere blocchi ancora più piccoli in modo che anche dispositivi modesti come il raspberry possano processarli, ma per ridurre così drasticamente i costi per i full node dovrebbero aumentare allora i costi di transazione per gli utenti (meno transazioni costi più alti).

Rimane la domanda di fondo: lo scopo di un mezzo di pagamento è che tutti possano utilizzarlo (con basse commissioni) o che tutti siano in grado di controllare autonomamente le transazioni di tutti? Il secondo caso è possibile solo se manteniamo molto limitato il numero di scambi (ma allora il sistema servirebbe solo per scambi grossi, scambi per i quali sia ragionevole pagare alte fee).
Io non vedo alternative: o si rende il sistema utile per tutte le transazioni, anche quelle piccole (aumentando di conseguenza il lavoro di verifica dei full node, ogni volta che spostate anche solo 10000 satoshi state aumentando il lavoro di verifica) e si limita quindi il numero dei possibili controllori, o viceversa si limita l'accesso al sistema delle transazioni a poche e importanti transazioni (così poi tutti saremmo in grado di verificarne l'autenticità a basso costo, ma a che pro se io non posso partecipare a nemmeno una transazione?)

5)
se questi sono i veri requisiti che un full node deve avere per essere veramente utile alla rete allora mi sorge spontanea una domanda: non è che un full node lento è come un'auto che va ai 60 km/h in autostrada, cioè crea più che altro disagi alla circolazione degli altri veicoli ?
Mi stanno sorgendo grossi dubbi sull'utilità, per la rete, di mettere in piedi full node lenti

Per quanto riguarda la scelta dei sei parametri che definiscono la curva secp256k1 (tra tutte le curve ellittiche possibili):



p non è stato scelto a caso, si tratta di un numero primo di Marsenne generalizzato, la cui forma è utile per effettuare velocemente i calcoli.
In particolare t=977 è il più grande intero sotto 1024 che fa diventare un numero della forma 2^256 - t primo.

https://bitcointalk.org/index.php?topic=289795.msg3187990#msg3187990

https://bitcointalk.org/index.php?topic=289795.msg3204734#msg3204734


n dovrebbe discendere di conseguenza, come h e anche a e b.

Nulla si sa invece del criterio di scelta di G.

Che tu sappia si può inserire latex nei post del forum? Io so per esempio che su mathstackexchange è possibile

http://meta.math.stackexchange.com/questions/5020/mathjax-basic-tutorial-and-quick-reference

ma dubito che si possa fare anche qui su bitcointalk.

Veramente ottimo articolo, grazie del link.

Secondo me andrebbe segnalato anche nel thread apposito di gbianchi https://bitcointalk.org/index.php?topic=1327707.0 in cui si parla proprio nello specifico della questione centralizzazione vs decentralizzazione.

Letture consigliate:


http://www.math.vt.edu/people/brown/doc/ellip.pdf   (Da dove vengono queste curve ellittiche? Che connessione hanno con l'ellisse? Quale tipo di problemi permettono di affrontare in teoria dei numeri?)

http://www.math.brown.edu/~jhs/Presentations/WyomingEllipticCurve.pdf (Un'ottima presentazione delle curve ellittiche stile PowerPoint di una summer school; vi sono molte rappresentazioni grafiche delle curve)

Certo, ma visto che il nostro problema è definire un'operazione tra punti della curva, delle rette che non intersecano la curva non ci importa nulla.

La retta x=x_1 che passa per il punto di coordinata x_1 è il caso limite, e poichè essa è tangente alla curva in quel punto A, è come se incontrasse in due punti "coincidenti" la curva; in quel caso si ha :


( A in questo caso è opposto a se stesso, tutti i punti che stanno sull'asse x sono opposti a se stessi, come nel caso D(5,0) di E(F11) )


Questo succede perchè in tal caso a e p sono sempre coprimi (hanno MCD = 1 in quanto p appunto è primo). Quindi, poichè per ogni coppia di numeri naturali a,b vale la formula:


segue che per la coppia a,p con a<p il mcm è sempre a*p (=0 modulo p). Quindi a*1, a*2, a*3, ... , a*(p-1) sono per forza p-1 elementi distinti, cioè ogni a genera tutto il gruppo dei numeri minori di p (se per assurdo due di quei multipli fossero uguali, ad esempio se a*3 e a*8 fossero uguali, allora a*8 -a*3 =0, quindi a*5=0, cioè a*5 sarebbe un multiplo sia di a che di p minore di a*p, il che contraddice l'asserzione per la quale è a*p il più piccolo multiplo comune di a e p.)


Inizialmente avevo pensato di moltiplicare tra loro semplicemente gli scalari; cioè, fissato il generatore G, supponiamo A=3*G , B=7*G, definisco A*B=(7*3)*G=21*G

Il problema è che questa operazione dipende dal generatore scelto e quindi dal modo di ordinare i punti rispetto al generatore; per esempio si avrebbe che ogni punto A moltiplicato per G  darebbe come risultato sempre A ( poichè qui G vale come 1, l'elemento neutro della moltiplicazione) ma se scegliessi viceversa A come generatore, si avrebbe allora A*G = G.
Un'operazione per essere ben definita non può produrre risultati diversi a seconda del modo con cui si rappresentano e indicano gli elementi su cui opera.

Ho riscritto in gran parte il post precedente dal momento che non ero soddisfatto della risposta che avevo dato a picchio sul perchè si definisce in modo così strano la somma tra due punti.

Mi piacerebbe trovare un modo efficace di "confezionare" questo thread, inizialmente pensavo che lo spazio che mi ero riservato nei primi post fosse sufficiente, in realtà non si è rilevato tale, l'argomento richiede troppe spiegazioni, precisazioni e integrazioni varie che sto aggiungendo qua e là (ma il tutto rischia di diventare un po' dispersivo, grazie comunque a picchio per le sue numerose e puntuali domande e osservazioni)

Forse conviene creare un altro thread che si occupi nello specifico solo dell'algoritmo ECDSA (firma di un messaggio mediante chiave privata e verifica tramite relativa chiave pubblica, magari con esempi pratici che devo ancora preparare)

Questo thread potrebbe continuare ad occuparsi solo della struttura matematica delle curve ellittiche, con l'aggiunta magari del discorso di quantificare l'intrattabilità del problema di risalire dalla chiave pubblica alla chiave privata privata corrispondente (in sostanza il problema del logaritmo discreto), giusto per dare una dimensione della sicurezza su cui si basa tutta la crittografia a cui si affida il sistema Bitcoin.

Discende da una questione geometrico-algebrica; visto che l'equazione di Weierstrass contiene il termine x^3, se metto quella equazione a sistema con una retta si troveranno in genere uno, due o tre punti di intersezione (l'equazione risolvente diventerà polinomiale di terzo grado in x)

y = mx + q
y^2 = x^3 + ax + b

--> (mx + q)^2 = x^3 + ax + b

(escludiamo invece i casi patologici delle curve con nodi o punti angolosi - grazie al concetto di discriminante - altrimenti non potremmo tracciare le tangenti in ogni punto, cioè ci sarebbero punti per i quali non sarebbe possibile definire la somma con se stessi)

Cosa c'entra una retta con il concetto di addizione?

Se dobbiamo definire un'operazione, dobbiamo trovare una regola per associare fra loro 3 elementi della curva, in modo che la relazione (A,B) -> C diventerà la nostra addizione. Il legame è quindi dato dalla retta che collega tra loro i punti della curva.
L'idea di base è che 3 punti allineati devono dare sempre somma "zero".

Se una retta ha in comune 3 punti con la curva, allora si pone semplicemente:

A+B+C= "zero" , cioè si dice che A+B = -C  

Chi è quindi -C ? Per capire chi è -C, l'opposto di C, cioè l'elemento che sommato a C dà "zero" come risultato dobbiamo adesso attribuire a qualcuno il ruolo dello "zero".

Osserviamo 2 fatti:

1) una retta può intersecare la curva anche in solo due punti A e B (qui per intersecare intendo proprio "secare", non essere solo tangente in A o in B), e non necessariamente in 3 punti; come definire allora la somma tra questi due elementi, visto che la retta che li collega non passa per nessun altro punto della curva?

2) le uniche rette che passano solo per 2 punti distinti della curva (senza essere tangenti alla curva in nessuno dei due punti) sono le rette verticali (rette che collegano tra loro quindi 2 punti simmetrici rispetto all'asse x)

Unendo 1) e 2) otteniamo che nel caso di due punti A e B simmetrici rispetto all'asse x dobbiamo aggiungere per forza un terzo punto allineato a loro per definire la loro somma, e questo punto deve essere obbligatoriamente un nuovo punto, lo "zero" appunto (nuovo nel senso che non sta "naturalmente" sulla curva):

A+B+"zero" = "zero"  (quindi 2 punti sono opposti se e solo se sono simmetrici rispetto all'asse x)

dove qui "zero" indica quindi la direzione della retta verticale che passa per A e B e poi si "perde" verso infinito, si attribuisce perciò lo status di punto a una direzione come si è soliti fare in geometria proiettiva

NB: ribadisco che il punto zero non ha coordinate (anche se viene rappresentato nei software con le coordinate fittizie (0,0), coordinate che non soddisfano certo l'equazione di Weierstrass).
Le curve ellittiche vengono perciò definite come l'insieme dei punti che soddisfano Weierstrass + il punto all'infinito (a volte c'è ambiguità nel termine "curva", ma dobbiamo ricordarci che va sempre aggiunto alle soluzioni dell'equazione anche il punto all'infinito!). Questo punto è necessario per dare all'insieme nella sua totalità una configurazione di gruppo. Il punto zero è chiamato in questo modo semplicemente perchè è, per definizione, l'elemento neutro rispetto all'addizione.

Torniamo per un momento alla formula iniziale:

A+B+C=zero   cioè A+B=-C

adesso dovrebbe risultare più chiaro perchè, per sommare A e B, non basta solo tracciare una secante che da A e B raggiunga il punto C, ma dobbiamo passare poi anche al suo opposto (e simmetrico) C'=-C.

Quindi si tratta sì di una regola "strampalata" ma anche ragionata  

Poi il perchè questa regola per definire l'addizione valga anche se prendiamo i coefficienti in un sottocampo finito di R, questo proprio non lo so (ma è proprio questo che rende interessanti le curve ellittiche per le applicazioni pratiche, il fatto che ereditano proprietà normalmente valide solo sul continuo di R come quella dei 3 punti di intersezione tra retta e curva anche in un campo di lavoro finito per le coordinate, fatto veramente notevole per il quale queste curve vengono utilizzate in teoria dei numeri; le curve ellittiche gettano un ponte tra il mondo del continuo e il mondo del discreto e per quanto riguarda quest'ultimo anche tra l'infinito e il finito).



2) non lo so, a occhio direi proprio di no, tra un gruppo e un anello c'è una bella differenza, il prodotto dei punti della curva per gli scalari non è in realtà una vera moltiplicazione, ma semplicemente un modo sintetico di indicare un'addizione ripetuta.

Dal mio punto di vista in questo forum già si sparla molto/troppo del mondo delle banche, aggiungiamoci pure il mondo dell'informazione (in un semplice post di benvenuto sul bitcoin poi!) e avremo così completato il quadro di presentazione di un mezzo di pagamento elitario e anarchico scelto soprattutto come bandiera ideologica da chi si ritiene più intelligente degli altri (la massa) che invece non hanno capito che il sistema attuale non funziona.

Il bitcoin dovrebbe essere proposto innanzitutto perchè permette di avere una consapevolezza diversa di che cosa significa "denaro", di che cosa significa "possedere il denaro" e permette di rendere espliciti quali sono i meccanismi di attribuzione di fiducia sottesi anche nelle operazioni con valuta fiat che effettuiamo tutti i giorni.

Tutto ciò mi sembra un'operazione culturale non da poco.

Dopodichè ci sono un sacco di altri aspetti molto interessanti (aspetti tecnici-implementativi, matematici, economici, psicologici-filosofici, ...) con i quali chi entra in questo mondo potrà confrontarsi; direi che uno dei valori aggiunti di questo sistema è proprio quello di costringere ad aprire la mente, richiedendo da una parte una certa trasversalità nell'uso di competenze afferenti a discipline diverse, dall'altra una forte apertura mentale e disponibilità nel rivedere certi paradigmi (da qui si vede la mia deformazione professionale di "formatore").

Con tutte queste carte positive che possiamo mettere sul tavolo perchè mai dovremmo intristirci invece (in un post di benvenuto!) nel sottolineare che i giornali/la TV non dicono la "verità"? L'informazione ormai è libera, se uno ha testa sa scegliere e selezionare i canali informativi migliori e lasciar perdere quelli che meno lo soddisfano.

Dimostriamo con i fatti che diamo informazioni interessanti (perchè abbiamo cose interessanti da proporre), non diamo l'inutile informazione che da qualche parte c'è un'informazione poco utile, sembra solo un modo di definirsi migliori degli altri.

Abbiamo un prodotto che si "vende da sè", non abbiamo bisogno di parlare male delle banche per sottolineare i pregi di questo sistema di pagamento, ma solo di fare chiarezza sul come funziona (perchè proprio semplice non è, e questo sí che non è un problema da poco).

Consideriamo il funzionamento del pruning attuale:


Una funzionalità che si perde con il pruning è quindi la possibilità di importare delle chiavi private nel nostro wallet.

Osservazione:

in un wallet odierno non compare solo il bilancio (che può - o è già così? - essere ricavato immagino anche direttamente dal database degli UTXO) ma in esso compare anche la storia di tutte le transazioni in entrata e in uscita che hanno interessato i suoi indirizzi. Nel momento in cui si importa una chiave privata, il wallet deve rifare la scansione di tutti i blocchi per ricostruire la storia delle transazioni riguardanti il nuovo indirizzo importato, e chiaramente in caso di pruning questa operazione non è più possibile.

Qualora si operasse un pruning definitivo come quello di cui si sta discutendo in questo thread, perderemmo quindi la storia delle nostre transazioni, almeno di tutte quelle avvenute prima del taglio, pur conservando in maniera corretta il bilancio.
Sarebbe un po' come succede adesso con gli estratti conto, dopo un certo lasso di tempo non è più possibile conoscere lo storico dei movimenti effettuati sul conto, ma almeno siamo sicuri che il bilancio attuale tiene conto di tutte le entrate e le uscite passate, anche quelle ormai dimenticate.

E(F11) ha 12 elementi (bisogna contare anche lo zero!)

Il numero n di cui parli tu nel caso della secp256k1 non dipende dal punto iniziale scelto ed è esattamente uguale al numero di punti della curva. Questo vuol dire che E è un gruppo è ciclico, vuol dire che puoi ottenere tutti i suoi elementi a partire da uno solo.

EDIT: anche E(F11) è un gruppo ciclico ma non ha un numero primo di elementi, quindi alcuni suoi elementi hanno un ordine minore di 12. Se riguardi il post lo avevo scritto, se invece un gruppo ha un numero primo di elementi (come nel caso della secp256k1, n è un numero primo in quel caso) allora ogni suo elemento escluso lo 0 genera tutto il gruppo, questo fatto discende dal teorema di Lagrange che ho inserito nel post sulla matematica.

EDIT2: cosa dice il teorema di Lagrange? In soldoni dice che il numero di elementi che puoi generare a partire da un elemento di un gruppo deve essere sempre un divisore del numero degli elementi di tutto il gruppo.

Pensiamo a Z/12Z, che ha 12 elementi, e che può essere visto come un orologio con le 12 ore: ci sono elementi come 4 che hanno ordine 3 (poichè <4>={4, 4+4, 4+4+4} ={4,8,0} cioè ha ordine 3, che è un divisore di 12), elementi come 2 che hanno ordine 6, elementi come 1 che generano tutto il gruppo (che per questo si dice ciclico).
Nell'esempio di E(F11), poichè anch'esso è un gruppo finito di 12 elementi, è normale che tu possa trovare alcuni elementi che non generano tutti gli altri elementi del gruppo ma che al contrario generino solo un sottogruppo di 2 o 3 o 4 o 6 elementi del gruppo di partenza.

Tecnicamente si dice che l'ordine del sottogruppo deve dividere l'ordine del gruppo, e il risultato del rapporto ordine del gruppo / ordine del sottogruppo è un numero intero detto "cofattore". Se vai qui (https://en.bitcoin.it/wiki/Secp256k1 guarda nell'ultima riga il parametro h) vedrai che nella secp256k1 il cofattore di G è 1, cioè l'ordine di G è esattamente uguale all'ordine di E(Fp), entrambi sono n.

Domanda: è un caso fortunato che G generi tutto il gruppo? Oppure è stato trovato dopo un lungo lavoro di ricerca in E(Fp)? Direi proprio di no!

Infatti se un gruppo finito ha un numero primo di elementi, poichè per Lagrange l'ordine di ogni elemento deve dividere l'ordine del gruppo (ordine vuol dire numero di elementi) allora ogni elemento (diverso dallo zero) deve per forza avere ordine "massimo" (non può certo avere ordine 1, visto che almeno se stesso e lo 0 devono sempre esserci in ogni sottogruppo).

Questo è proprio il caso della secp256k1, che avendo un numero primo n di elementi risulta essere quindi non solo un gruppo ciclico ma in più ha anche la caratteristica che ogni suo elemento, a parte lo 0, è in grado di generare tutti gli altri.

Per riassumere: l'esempio che stai implementando non si comporta proprio come la secp256k1, poichè non stai utilizzando un gruppo con un numero primo di elementi.

EDIT3: penso che il termine "ordine di un elemento G" derivi dal fatto che scegliere un punto G di partenza (un generatore) equivalga di fatto a imporre un ordine con cui descrivere tutti gli altri elementi del gruppo: 2G, 3G, ... ordine che dipende quindi dal punto di vista di G)