Certo che l'insieme è limitato a n!
Per l'esattezza è compreso tra 1 e n-1 (questo sono sicuro di averlo scritto!)

n è leggermente minore di p (cioè il numero di punti della curva secp256k1 è leggermente minore dei possibili valori che posso provare ad assegnare alla x per vedere se c'è una y corrispondente tale per cui la coppia (x,y) soddisfa l'equazione della curva).

p è a sua volta un po' minore di 2^256.

EDIT: Poichè E è ciclico nel caso della secp256k1 ed è formato da un numero primo di elementi, ogni suo elemento tranne lo 0, compreso G, genera tutto E

EDIT2: nel caso di E(F11), la curva del post 6, E è ciclico ma non ha un numero primo di elementi (ne ha 12), lì quindi bisogna trovare in effetti una G che generi tutto E.  

Se poi mi chiedi con quale criterio allora abbiano scelto G nella secp256k1, sinceramente non lo so  

Le curve ellittiche non c'entrano, il problema sta nella conversione delle coordinate di un punto della curva ellittica in un indirizzo bitcoin.
Tra chiavi private e chiavi pubbliche c'è una perfetta corrispondenza biunivoca (si tratta rispettivamente di scalari a 256 bit e di punti della curva ellittica P=(x,y) dove x e y sono numeri di 256 bit).

Per trasformare i 512 bit della chiave pubblica in una stringa di 160 bit che è l'indirizzo bitcoin, si deve fare l'hash256 delle due coordinate e poi ripmed160. Il problema nasce dal fatto che è possibile rappresentare un punto della curva ellittica usando anche solo la x e il segno di y (infatti se (x,y) è un punto della curva lo è anche (x,-y)), dal momento che il valore di y dipende solo dal valore di x --> y^2=x^3+7

Quindi poichè l'algoritmo hash produce 2 diversi risultati se gli diamo in input (x,y) o (x,+/-), si determina il problema che la stessa chiave privata, la quale determina dal punto di vista matematico un solo punto P della curva ellittica, produce in realtà due chiavi pubbliche P diverse (dal punto di vista dell'hash sono effettivamente diverse, poco importa che siano solo rappresentazioni diverse dello stesso oggetto matematico).

Quando importiamo una chiave privata nel nostro wallet, a quale delle "due" chiavi pubbliche si riferisce la chiave privata? E quindi quale indirizzo deve monitorare il wallet?

Per distinguere i due diversi casi, per quanto riguarda la chiave pubblica si usa la seguente convenzione:

"02" + 128 caratteri in formato esadecimale per la chiave pubblica standard (x,y) (8 + 512 bit)

"03" + 64 caratteri in formato esadecimale per la chiave pubblica compressa (x,pari) (8 + 256 bit)
("04" + 64 caratteri in formato esadecimale per la chiave pubblica compressa (x,dispari)) (8 + 256 bit)

Ma ricordo che la chiave privata è unica, quindi bisogna aggiungere delle informazioni quando si presenta la chiave privata al wallet (che per questo è o in formato WIF o in formato WIF compresso). In questo formato, dove si passa dalla rappresentazione binaria o esadecimale a quella base58, viene aggiunta (come dice il nome) anche quell'informazione che consente al wallet di sapere che tipo di chiave pubblica e quindi di indirizzo deve ricavare da quella chiave.

A complicare ulteriormente le cose, l'informazione che si aggiunge alla chiave privata per dire che da essa si deve ricavare la chiave pubblica compressa rende la chiave privata in formato WIF compresso più lunga rispetto alla chiave privata in formato WIF, ciononostante si chiama ancora "chiave privata compressa" poichè da essa si deve ricavare la chiave pubblica nella sua rappresentazione compressa.

Dovevo specificare che:

Se A diverso da B, e xA = xB allora A+B = 0 (punto all'infinito), quindi in tal caso non si applica la formula della somma di due punti (semplicemente una retta verticale non ha coefficiente angolare, quindi è inutile tentare di dividere per 0)

Se A = B, e yA=0 allora A+B=2A = 0 (punto all'infinito), quindi in tal caso non si applica la formula di duplicazione

Nel caso specifico di D(5,0) siamo nel secondo caso (che è a sua volta un caso particolare del primo caso). Quel punto è anche l'opposto di se stesso - poichè 2 punti sono opposti se e solo se hanno stessa x e y opposta (se (x,y) soddisfa l'equazione di Weierstrass la soddisfa evidentemente anche (x,-y)); nel caso di ordinata nulla se (x,0) soddisfa l'equazione di Weierstrass, se mantengo la x e cambio "segno" alla y trovo ancora (x,0), quindi (x,0)+(x,0) = 0 sempre!

Purtroppo ho saltato diverse precisazioni...

Ma a questo punto tanto vale lasciare le cose come sono, se uno non vuole sprecare spazio utilizza l'opzione di pruning; con il tempo sai quanti superblocchi e quindi nuovi (e arbitrari) punti di partenza bisognerebbe introdurre; mi sembrano più gli svantaggi che i vantaggi.

Non era una gara, ho semplicemente dato una mia risposta a un newbie che chiedeva informazioni (penso sia meglio ricevere 2 risposte che una sola  )

Nella mia risposta non ho parlato di double spending. Io non penso che la troncatura della blockchain possa portare alla double spending (che di fatto è possibile sempre solo in casi particolari e su tempi brevissimi, di solito le double spending sono a 0 conferme, è impossibile ingannare la rete costruendo un ramo alternativo della chain a meno che non si abbia il 51% di capacità computazionale).

Altra considerazione, è possibile sicuramente operare un taglio "sensato" della chain; la domanda del nuovo utente sul senso di mantenere informazioni vecchie e obsolete era dal mio punto di vista molto ben posta, e in fondo aveva quasi ragione, almeno dal mio punto di vista: se si raccogliessero tutte le informazioni aggiornate al blocco 100000 per esempio (incluso il database degli UTXO) e si troncasse lì la chain, partendo da un unico nuovo grande genesis block come suggeriva l'utente picchio qualche post fa, non sarebbe affatto possibile la double spending; di fatto ci troveremmo all'incirca nella stessa situazione di adesso; questo però non si fa perchè bisognerebbe cambiare le regole, e abbiamo visto anche di recente com'è difficile introdurre delle modifiche in corsa in un meccanismo delicato che ormai è avviato (e meno si tocca meglio è).

Ovvio che se invece si operasse un taglio della chain senza contromisura alcuna, allora sorgerebbero molti problemi, ma non certo di double spending, al contrario molti bitcoin semplicemente sparirebbero e non potrebbero essere più spesi dai loro proprietari (non puoi spendere dei bitcoin - o meglio degli UTXO - di cui la rete ha perso traccia).

Cos'è che non va allora in generale nel taglio della chain?

Secondo me, e ripeto la mia risposta, in ogni tipologia di pruning definitivo (anche quello "sensato" temperato mediante l'introduzione ad esempio di un nuovo grande blocco di partenza che facesse la sintesi della storia passata), coloro che entreranno nel mondo bitcoin dopo il taglio dovrebbero dare per scontato una serie di informazioni, fidandosi di altri che hanno avuto invece la possibilità di verificare queste informazioni in prima persona. Si dovrebbero confrontare nel migliore dei casi solo con una sintesi, non avrebbero più la possibilità di verificare che quel nuovo (e per certi aspetti arbitrario) punto di partenza sia stato correttamente impostato secondo le regole di base del protocollo (e non mi pare poco). Quindi invece di avere un unico solidissimo genesis block su cui si fonda tutto l'impianto, ne avremmo al suo posto uno nuovo un po' più debole; dopo x blocchi probabilmente si provvederebbe a rimpiazzare un'altra volta il nuovo punto di partenza con uno più recente (la sintesi della sintesi), creando in questo modo una successione di punti di partenza sempre più deboli, dove il senso della storia originale rischia di andare perduto e con esso la fondatezza e l'autorevolezza delle certificazioni operate dalla blockchain (un notaio che certifica in base al sentito dire e non controlla in prima persona non fornisce una grande garanzia).

Anche adesso è possibile utilizzare un full node con pruning attivato, ma non si tratta di un pruning definitivo, un conto è scaricare e controllare tutta la blockchain e poi eliminarne una parte dal proprio hard disk (sapendo che in caso di necessità sarà sempre possibile riscaricarla dal primo blocco), un altro è non averla mai potuta scaricare e verificare.

Il mio consiglio è partire da una ottima sintesi sul mondo bitcoin : "Mastering Bitcoin"

http://chimera.labs.oreilly.com/books/1234000001802/index.html

Ci sono un sacco di dettagli e fornisce inoltre anche un quadro generale di come è strutturato questo sistema, poi uno semmai approfondisce ciò che gli interessa di più.

La definizione rigorosa di curva ellittica non è banale, si tratta di una curva proiettiva liscia i cui punti soddisfano una certa equazione detta equazione di Weierstrass generalizzata.

"proiettiva" ha a che fare con il fatto che dobbiamo aggiungere il punto all'infinito, "liscia" vuol dire non singolare, cioè deve essere derivabile in ogni punto, senza spigoli (altrimenti non sarebbe definita la tangente in ogni punto)

Si può dimostrare che quasi ogni curva ellittica può essere descritta da un tipo di equazione più semplice detta equazione di Weierstrass:


La condizione su a e su b è che il discriminante dell'equazione sia diverso da 0 (corrisponde al richiedere che la curva sia liscia). Nel caso della secp256k1 a=1, b=7, quindi 4*1^3 + 27 * 7^2  = 1327 e quindi si tratta in effetti di una curva liscia.

Queste informazioni e maggiori dettagli li trovi su questa tesi che si trova online (da pag. 47) http://www1.unipa.it/~giovanni.falcone/tesilenia.pdf


ECDSA come dice il nome stesso (Elliptic Curve Digital Signature Algorithm) è solo un algoritmo di firma, quindi serve solo a firmare e a verificare la firma.

Se vuoi però utilizzare le curve ellittiche anche per cifrare i messaggi esistono anche algoritmi di cifratura come ad esempio  l' ECIES (Elliptic Curve Integrated Encryption Scheme) che trovi a pag.99-100 sempre della tesi.

Per produrre una firma, oltre alla chiave privata e al messaggio da firmare, è necessario generare ogni volta un numero casuale. Se firmi due messaggi per mezzo della chiave privata utilizzando sempre lo stesso numero "casuale", è banale ricavare dalla firma la chiave privata.
Questo è il motivo per cui è necessario avere un buon generatore di numeri pseudo casuali, non solo per generare buone chiavi private, ma anche per poter firmare in sicurezza senza esporre la chiave privata (che è poi il senso generale della firma).

Al momento l'UTXO è sopra 1 GB  --> http://statoshi.info/dashboard/db/unspent-transaction-output-set

e a occhio dovrebbe contenere le informazioni minime necessarie per conoscere lo stato attuale della distribuzione dei saldi diversi da 0.
Ma non si diceva che uno degli aspetti più interessanti della blockchain era anche la possibilità di registrare "per sempre" delle informazioni?
Un conto è consentire il pruning, un altro è forzare tutti a tagliare.

 

La possibilità di tagliare i blocchi molto vecchi della blockchain c'è già dalla versione 0.11.0 di Bitcoin Core (opzione pruning).

Il problema di base però è:  quando un nuovo peer si collega alla rete, come fa a conoscere la distribuzione attuale dei bitcoin? (ovvero: quali sono gli indirizzi a saldo diverso da zero? dove sono allocati i bitcoin prodotti finora? esplicitamente questo non c'è scritto da nessuna parte!)

Il concetto che sta alla base di questo sistema è che ciascuno deve essere messo nella condizione di poter verificare di persona la validità dei pagamenti che riceve, e se io voglio verificare la validità di un pagamento che ricevo adesso devo sapere se l'indirizzo che mi ha inviato i btc possedeva effettivamente quei btc al momento dell'invio.  

Per fare questa verifica in modo sicuro ho un solo modo: almeno una volta nella vita devo scaricare tutta la blockchain, ricostruendo sin dal primo blocco la storia dei passaggi di proprietà di tutti i btc. In tal modo potrò ricostruire la distribuzione attuale dei saldi degli indirizzi (ho un po' semplificato); se invece non faccio la ricostruzione personalmente dovrò fidarmi della ricostruzione fatta da qualcun altro (e questo è un male, soprattutto se lo fanno tantissime persone).

Con l'opzione pruning, man mano che arrivano nuovi blocchi posso eliminare dal mio hard disk i blocchi più vecchi per risparmiare spazio; questo è possibile dal momento che mi tengo (oltre ai blocchi delle transazioni) sempre un database, che mi sono costruito e aggiorno dinamicamente, in cui registro la distribuzione dei saldi diversi da 0 degli indirizzi (tecnicamente si chiama UTXO, insieme degli output non spesi delle transazioni).

Quindi per rispondere alla tua domanda, è possibile eliminare i blocchi molto vecchi ma:

1) solo dopo aver almeno una volta scaricato tutti i blocchi, a partire dal numero 1, in modo da poter conoscere con sicurezza dove stanno tutti i saldi diversi da 0

2) se tutti attivassero l'opzione pruning, quando un nuovo nodo entra nella rete (oppure a un vecchio nodo si rompe l'hard disk) come fa questo a controllare tutta la blockchain? Da chi scarica i blocchi più vecchi se tutti li hanno eliminati dal loro pc? Ricorda che tutti devono essere messi nella condizione di poter verificare in maniera autonoma la validità dei pagamenti ricostruendo la distribuzione dei saldi (per conoscere la quale bisogna studiare tutta la storia passata delle transazioni).

Il sistema Bitcoin è un sistema "trustless", ovvero non c'è bisogno di fiducia (è affidabile proprio perchè ciascuno può non fidarsi degli altri e fare da sè il lavoro di controllo e verifica delle transazioni e dei blocchi). Quindi non è possibile tagliare i blocchi più vecchi in modo definitivo, sarebbe come dire che tutti quelli che non hanno avuto l'opportunità di controllare la blockchain in passato non ce l'avranno mai più e dovranno fidarsi almeno un po' di chi invece ha potuto effettuare questo controllo in prima persona.

Ho migliorato nel post 1 la presentazione di G, aggiungendo anche il controllo che effettivamente appartenga alla curva secp256k1.

Ho anche aggiunto una precisazione alla risposta alla tua domanda sulla corrispondenza biunivoca tra chiavi private e pubbliche nel post 14.

Io intendevo, in maniera ancora più radicale, si potrebbe evitare proprio (a livello teorico, ovviamente sarebbe scomodissimo) di utilizzare il concetto di firma e quindi i comandi tipo OP_CHECKSIG.  
Alla fin dei conti sarebbe sufficiente scrivere uno script con i comandi consentiti dalla sintassi del linguaggio SCRIPT e farne l'hash. Mi riferisco al concetto di P2SH (pay to script hash).


Ad esempio: scrivo uno script del tipo

"fornisci l'hash del blocco 1000 e confrontalo con 0000125...."

oppure

"x + 10 = 30, fornisci x"

poi ne faccio l'hash e ripemd160 e la stringa che ottengo diventa il mio "indirizzo", l'analogo della stringa da 160 bit che ottengo facendo sha256 e poi ripemd160 partendo dalle coordinate di un punto sulla curva ellittica.

Prima della versione 0.9.2 di Bitcoin Core, di fatto si utilizzava questa modalità solo per gli indirizzi multisig, ora è permessa tutta la flessibilità consentita dal linguaggio SCRIPT.

PS: ovviamente vincolare dei fondi a uno script come quello proposto da me sopra non avrebbe senso alcuno, poichè qualora volessi sbloccare quei fondi dovrei trasmettere alla rete una transazione con lo script in chiaro il cui hash256 corrisponde al mio indirizzo + il dato richiesto per lo sblocco, e quindi sarebbe facilissimo sostituire la mia transazione modificando al volo il destinatario prima che essa sia inclusa in un blocco.
Il concetto di firma è proprio quello di poter generare una stringa con la quale dimostrare di avere la chiave privata senza bisogno di renderla pubblica.
Il senso del mio discorso era che il sistema bitcoin fondamentalmente lavora con coppie di stringhe A e B, la stringa/indirizzo B con la funzione di vincolare i btc all'indirizzo/stringa B, la stringa A con la funzione di svincolare i btc dall'indirizzo B. Nel caso delle curve ellittiche, A è la chiave privata, B l'hash della chiave pubblica, ma non è strettamente necessario che sia così.
 

Per quanto riguarda l'algoritmo ECDSA, sto preparando la spiegazione!

Non avevo mai pensato al funzionamento del vanity gen, in effetti dovrebbe essere proprio come lo hai descritto!



Sì, una volta scelto il punto base G, detto per questo anche punto generatore di E(FP), c'è una corrispondenza biunivoca tra l'insieme dei naturali compresi tra 1 e n-1 e i punti della curva

Si fissa G (è stato scelto "Standards for Efficient Cryptography" (SEC), vedi http://www.secg.org/sec2-v2.pdf a pagina 9).
Fissato G, è univoco l'ordine con cui percorrere tutti i punti della curva:

1 --> G
2 --> 2*G
3 --> 3*G
..
..
n-1 --> (n-1)*G


la prima colonna è quella delle chiavi private (scalari)
la seconda colonna è quella delle chiavi pubbliche corrispondenti (punti di E(Fp)) (NB: lo scalare 0 non è considerato una chiave privata accettabile nel protocollo bitcoin, quindi 0*G ( o n*G, che è lo stesso) non lo ho inserito nelle possibilità.)

Per ogni chiave privata c'è un'unica chiave pubblica e viceversa.

Le 2 colonne hanno entrambe n-1 elementi (sono circa 2^256, un po' di meno di p = 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1 che è l'ordine del campo delle coordinate). La corrispondenza biunivoca tra i due insiemi è garantita dalla matematica che ho spiegato nei post precedenti (E(Fp) è un gruppo ciclico, l'elemento G è un generatore che permette di riottenere tutti gli altri punti)

La corrispondenza però non è più biunivoca se aggiungiamo una terza "colonna", quella degli indirizzi, che non c'entrano però con le curve ellittiche.

insieme scalari (fissato G)     <-->    insieme di punti di E(Fp)  -->   indirizzi


L'insieme degli indirizzi ha circa 2^160 elementi distinti possibili. Per passare dall'insieme E(Fp) all'insieme degli indirizzi ci sono 2 operazioni, un hash256 e un ripemd160 che traducono una stringa di 256 bit in una di 160 bit (la quale viene poi rappresentata in base 58, ma questo è solo un problema appunto di rappresentazione del risultato finale).

Quindi ci sono tantissime chiavi private (con relative chiave pubbliche) che producono lo stesso indirizzo.***

***EDIT2: in realtà c'è anche un altro problema quando traduciamo un punto della curva in un indirizzo. Poichè la funzione hash lavora in modo stupido solo sulla rappresentazione del punto, se scriviamo un punto di E(Fp) nella sua forma compressa (cioè con solo la coordinata x e il "segno" della y, aggiungendo come prefisso 02 se y è pari e 03 se y è dispari), avremo che lo stesso punto può essere tradotto in due indirizzi completamente diversi (ma controllati sempre dalla stessa chiave privata)

Riporto qui il passo dedicato alla questione in "Mastering Bitcoin"


EDIT: a voler essere pignoli, per ottenere un indirizzo è sufficiente sostituire nel meccanismo una qualsiasi stringa di 256 bit al posto dell'hash256 delle coordinate di un punto della curva ellittica. Non vorrei dire una stupidaggine ma penso che il sistema bitcoin - blockchain sia del tutto indipendente dalla teoria delle curve ellittiche e dall'algoritmo di firma digitale ECDSA.

Certo che il prezzo lo fa il mercato!

Ma i miner sono tra gli attori più esposti in questo tipo di mercato, poichè anticipano molti soldi, cioè investono a loro modo in questo settore scommettendo in una evoluzione futura (perlomeno futuro prossimo) positiva dell'andamento del valore dei btc.
Quindi il fatto che la crescita della difficoltà (la difficoltà complessiva è legata all'investimento complessivo dei miner, oltre che alla migliorata efficienza delle apparecchiature) stia aumentando nell'ultimo periodo è un indicatore di quale sia il "sentiment" odierno (o forse solo la speranza?) di questi attori.
In sostanza: c'è in giro molta gente che continua a credere (non solo a parole, scommettono soldi veri!) che il mining sarà redditizio, ergo:

- o il prezzo del btc è già attualmente così alto da permettere ai miner dei margini tali da guadagnarci anche in caso di diminuzione del prezzo

- o i miner sperano/credono in una evoluzione al rialzo dei prezzi

- o pensano che la migliorata efficienza del loro lavoro compenserà l'aumento di competizione e concorrenza nella gara per aggiudicarsi le ricompense dei blocchi

Naturalmente, anche se si trattasse della seconda motivazione, il fatto che i miner (e tanta altra gente oltre a loro) pensino che quest'anno il prezzo del bitcoin aumenterà non significa affatto che ciò accadrà realmente, ma è pur sempre un indicatore di cui tenere conto.

Mi sembra particolarmente interessante inoltre osservare questo fenomeno di iperinvestimento dei miner nel periodo di avvicinamento all'halving, quando è certo che le loro entrate (in btc) dimezzeranno.

Guardando questo grafico

https://blockchain.info/charts/miners-operating-profit-margin?timespan=2year&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

non capisco se i margini dei miner stanno aumentando o diminuendo (propenderei per la seconda)

Queste dovrebbero essere le assunzioni fatte nel costruire il grafico:


Sicuramente i margini diminuiranno in modo significativo con l'halving.
A un certo punto la difficoltà non potrà continuare ad aumentare con i ritmi attuali

https://blockchain.info/it/charts/difficulty?timespan=2year&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=

poichè l'aumento di efficienza delle macchine da sola non basterà più a sostenere un aumento del carico di lavoro; a quel punto o aumenterà il valore dei bitcoin, o diminuirà il lavoro effettuato per renderli sicuri.
Al momento, almeno guardando al tasso di aumento della difficoltà, sembrerebbe che molti miner stiano scommettendo sul fatto che il valore del bitcoin aumenterà.

Infine ho notato il seguente grafico

https://blockchain.info/it/charts/output-volume

dal quale sembra che ultimamente ci sia un aumento del volume di btc scambiati sulla blockchain.
Interpretazioni al riguardo?

Certo che sarebbero in sicurezza, due address (o meglio le due chiavi private che li hanno generati) di uno stesso wallet sono del tutto indipendenti, nel senso che se anche la chiave privata dell'indirizzo A fosse stata violata, non ci sarebbe modo da questa di ricavare anche la chiave privata di un altro indirizzo B dello stesso wallet.

Ho guardato un po' in giro, penso di aver capito il funzionamento del nodo con pruning attivato:

questo nodo deve inizialmente scaricare tutta la blockchain, in modo da costruirsi da sè il database degli UTXO corretto (+ l'indice di tutti i blocchi); a differenza dei full node, appena la catena dei blocchi scaricati e validati supera un certo spazio occupato, allora il nodo comincia a eliminare i blocchi più vecchi.

Comunque è in grado di valutare il bilancio del proprio wallet con lo stesso grado di attendibilità con cui lo fa un full node, nonchè di fornire il classico servizio di consulenza ai client SPV. Inoltre è in grado di verificare perfettamente la validità di tutte le transazioni che gli arrivano (e quindi è in grado anche di ritrasmetterle a sua volta agli altri peer).

L'unico vero suo limite dal punto di vista della rete è legato al fatto che non è in grado di fornire i blocchi troppo vecchi (che non ha più) ai nuovi peer che si collegano alla rete.

Per quanto riguarda invece il wallet installato nel nodo, alcune funzioni che implicano il rescan (tipo importaddress e importprivkey) non possono funzionare, poichè i raw data non ci sono più.

EDIT:
[da qui https://www.reddit.com/r/Bitcoin/comments/46f67s/bitcoin_v0120_has_been_tagged_for_release/d04ksz9
sembra che quelle funzioni siano possibili ma senza il rescan; bisognerà verificare se sarà proprio così e se il wallet indicherà almeno il bilancio corretto rispetto alle chiavi private importate.]

Ecco a cosa servono i raw data in un full node (oltre a creare i database degli UTXO e l'indice dei blocchi):


Queste sono quindi le uniche funzionalità perse dai nuovi nodi con pruning attivato.

Avevo copiato da Word e in effetti non si capiva molto. Guarda adesso se si capisce.

A queste due domande ho tentato di rispondere nei post 4 e 5 di questo thread.



Certo, si basa proprio su n*(a,b), si tratta in sostanza di dividere n in 2^m passi e applicare ricorsivamente la formula di duplicazione 2*(a,b) (però per essere più preciso devo andare a cercarlo)

Ho aperto un thread apposito https://bitcointalk.org/index.php?topic=1339031.msg13658587#msg13658587
per discutere di questo argomento.

La risposta breve è che:
quando l'insieme delle coordinate possibili per x e y (nel tuo caso: a,b,c,d) sono prese in un sottocampo dei numeri reali (sia per (a,b) che per (c,d))
quando (a,b) e (c,d) soddisfano entrambe la stessa equazione di una curva ellittica
quando hai definito una somma per cui (a,b) + (c,d) è sempre un punto della curva ellittica (nel piano cartesiano con coordinate reali)

allora per un teorema di Poincarè del 1900
la loro somma (a,b) + (c,d) è sempre un punto della curva ellittica con coordinate che stanno ancora nel sottocampo dei numeri reali da cui ha pescato a,b,c,d.

Quindi se a,b,c,d appartengono a F17, come nell'esempio di mastering bitcoin, allora sicuramente anche P = (a,b) + (c,d) (somma definita inizialmente su R) deve avere ancora coordinate in F17.

D'altronde se per la risoluzione dell'ultimo teorema di Fermat Andrew Wiles ha utilizzato proprio le curve ellittiche il motivo è proprio questo  

Per quanto riguarda come si fa a fare la somma, è semplice geometria analitica: applica il discorso della secante nel caso della somma di due punti distinti in R, troverai una formula che ottiene le 2 coordinate del punto finale per mezzo proprio di a,b,c,d; la stessa formula vale anche nel sottocampo K, cioè la teoria afferma che sicuramente le coordinate che otterrai saranno ancora nel sottocampo nel quale stai lavorando. Ovviamente devi fare però tutti i calcoli sulle coordinate modulo p!