PacMan Culture

Some (useful) "list pages" on Wikipedia

2014-10-29T12:16:00.001+01:00

List of single-board computers (Raspberry PI, Banana PI, etc.)
List of router's firmwares (DD-WRT, OpenWrt, Tomato, etc.)
List of pirated movies realese types (and in italian)
List of non-self-governing territories (Hong Kong, Macau, Gibiltrar, etc.)

The Art behind Umbrella Revolution in Hong Kong

2014-10-01T12:28:00.000+02:00

Not Mine (Pop Video)

2014-09-04T14:24:00.003+02:00

Il PDF di "Cent'anni di Solitudine"

2014-04-22T17:02:00.000+02:00

Cercando su google "cent'anni di solitudine pdf" si trova facilmente il pdf del libro di Gabriel Garcia Marquez.

Ecco qua il link.

Coca Cola Chinese Neolithic Vase by Ai Wei Wei

2014-03-27T10:27:00.003+01:00

Da "La Grande Bellezza"

2014-03-04T23:17:00.000+01:00

Ho trascorso tutte le estati della mia vita a fare propositi per Settembre. Ora non più. Ora trascorro l’estate a ricordare i propositi che facevo e che sono svaniti. Per pigrizia, per dimenticanza. Che cosa avete contro la nostalgia? È l’unico svago che resta per chi è diffidente verso il futuro. Senza pioggia, Agosto sta finendo. Settembre non comincia. E io sono così ordinario. Ma non c’è da preoccuparsi. Va bene così.

Bitcoin: come funziona il protocollo (Parte 3)

2014-02-20T12:59:00.000+01:00

Premessa

Questo post è la parte 3 della traduzione del post di Michael Nielsen sul funzionamento del protocollo alla base di Bitcoin. Le puntate precedenti le trovi a questi links: parte 1, parte 2.

Proof-of-work (1/2)

Supponiamo che Alice voglia attuare una truffa e spendere doppiamente il suo infocoin nel protocollo appena descritto. Potrebbe fare ciò "impossessandosi" della rete Infocoin. Ad esempio, supponiamo che Alice abbia messo in piedi un sistema automatizzato che le abbia consentito di creare un gran numero, diciamo un milione, di differenti identità nella rete Infocoin. Come prima, ella prova a spendere doppiamente il suo infocoin con Bob e Charlie. Ora, quando Bob e Charlie chiederanno alla rete di validare le loro transazioni con Alice, accadrà che la rete sarà composta da numerosissime false identità con a capo Alice. Queste, sotto il comando di Alice, risponderanno ovviamente sia a Bob che a Charlie che le loro transazioni sono valide e non fraudolente, ingannando così una o entrambe le vittime.

Fortunatamente esiste un modo ingegnoso di evitare questo problema. Tale metodo si basa su una tecnica conosciuta come proof-of-work. Quest'idea può sembrare controintuitiva e coinvolge una combinazione di altre due idee: (1) rendere (artificialmente) computazionalmente costoso per gli utenti della rete validare le transazioni; e (2) premiare gli utenti che aiutano il processo di validazione. Il premio è usato per incentivare gli utenti della rete allo svolgere l'attività di validazione delle transazioni, nonostante sia ora diventato un processo computazionalmente costoso. Il beneficio ottenuto nel rendere costoso il processo di validazione delle transazioni è che tale validazione non sarà più influenzata dal numero di identità nella rete che qualcuno controlla, bensì dal potere computazionale offerto. Come vedremo, usando un design ingegnoso, si può far si che un eventuale truffatore avrebbe bisogno di un enorme potere computazionale per mettere in pratica la sua truffa, rendendo il tutto impraticabile nella realtà.

Questa è l'essenza della tecnica del proof-of-work. Tuttavia, per meglio comprendere tale tecnica, abbiamo bisogno di esaminare qualche dettaglio.

Ipotizziamo che Alice trasmetta in broadcast all'intera rete il messaggio "Io, Alice, do a Bon un infocoin, con numero seriale 1234567".

Appena un utente della rete riceve questo messaggio, lo aggiunge ad una propria coda di transazioni pendenti, cioè transazioni di cui ha ricevuto notifica ma che non sono ancora state validate dalla rete. Ad esempio, un altro utente della rete chiamato David potrebbe avere la seguente lista/coda di transazioni pendenti:

"Io, Tom, do a Sue un infocoin, con numero seriale 1201174"

"Io, Sydney, do a Cynthia un infocoin, con numero seriale 1295618"

"Io, Alice, do a Bob un infocoin, con numero seriale 1234567"

David, usando la propria copia della block chain, può verificare che ogni transazione è valida. Quindi, egli trasmetterà in broadcast la notizia della validità di queste transazioni.

Tuttavia, prima di far ciò, come parte del protocollo di validazione, a David è richiesto di risolvere un difficile rompicapo/problema computazionale (la proof-of-work). Senza la soluzione a questo problema (che sarà quindi trasmessa insieme al messaggio di accettazione delle transazioni), il resto della rete non accetterà il suo messaggio di validazione.

Quale problema far risolvere David? Sia h una funzione hash fissa e conosciuta da tutta la rete (è parte del protocollo). Bitcoin usa la ben conosciuta SHA-256, ma ogni funzione hash crittograficamente sicura fa al caso. Assegniamo l'etichetta l alla lista delle transazioni pendenti di David (giusto per avere un nome a cui riferirci). Supponiamo che David appena in coda a l un numero x (chiamato nonce) e che valuti la funzione hash su tale combinazione. Ad esempio, se l="Hello, world!" (ovviamente questa non è una lista di transazioni, ma solamente una stringa usata a scopi illustrativi) e x=0, allora l'output esadecimale sarebbe:

h("Hello, world!0") = 1312af178c253f84028d480a6adc1e25e81caa44c749ec81976192e2ec934c64

Il problema che David deve risolvere (la proof-of-work) è quindi quello di trovare un numero/nonce x tale che quando si appende x ad l e si valuta la funzione hash di questa combinazione, l'hash ottenuto inizi con una lunga sequenza di zeri. Il problema può essere reso più o meno difficile variando il numero di zeri richiesti nella soluzione. Una proof-of-work relativamente semplice potrebbe richiedere giusto 3 o 4 zeri all'inizio dell'hash, mentre un problema più difficile potrebbe richiederne 15. In ogni caso, l'esempio precedente con x=0 non rappresenta una soluzione alla proof-of-work dato che l'hash ottenuto non inizia con nessun zero. Provando x=1 non funziona lo stesso, infatti:

h("Hello, world!1") = e9afc424b79e4f6ab42d99c81156d3a17228d6e1eef4139be78e948a9332a7d8

Possiamo provare vari valori di nonce, x=2,3,.... Alla fine, al valore x=4250 otteniamo:

h("Hello, world!4250") = 0000c3af42fc31103f1fdc0151fa747ff87349a4714df7cc52ea464e12dcd4e9

Quindi, tale nonce (4250), ci fornisce una stringa di 4 zeri all'inizio dell'hash. Questo è sufficiente per risolvere una semplice proof-of-work, ma non sufficiente a risolverne una difficile (con molti zeri iniziali richiesti).

Ciò che rende questo problema difficile da risolvere è il fatto che l'output di una funzione hash crittografica si comporta come un numero casuale: modificando l'input anche di pochissimo si ottiene un output completamente modificato, così da rendere (praticamente) impossibile ogni previsione. Così, se vogliamo un valore hash che inizi con 10 zeri, allora David avrà bisogno, in media, di provare 16^10 (circa 10^12, cioè circa mille miliardi!) differenti valori per x prima di trovarne uno adatto. E' per questo che tale problema richiede molta potenza computazionale.

Ovviamente, è possibile rendere questo problema più o meno difficile richiedendo più o meno zeri iniziali nell'output della funzione hash. In pratica, il protocollo Bitcoin possiede un livello di controllo sulla difficoltà del problema proof-of-work usando una leggera variante del metodo appena descritto. Invece di richiedere degli zeri iniziali, il proof-of-work usato da Bitcoin richiede che l'hash dell'header di un blocco (della block chain) sia minore o uguale ad un numero noto come target. Tale numero è automaticamente aggiustato per assicurare che un blocco Bitcoin richieda in media 10 minuti per essere validato (si deve aggiustare perché per la legge di Moore la potenza computazionale di un utente medio aumenta negli anni).

(Nella pratica c'è della variabilità/varianza del tempo richiesto per validare un blocco. A volte un nuovo blocco è validato in 1 o 2 minuti, altre volte potrebbero essere necessari 20 o più minuti. E' tuttavia semplice modificare il protocollo Bitcoin di modo da avere un tempo di validazione con meno varianza intorno ai 10 minuti. Invece di risolvere un singolo proof-of-work si potrebbe richiederne di risolverne di più (con difficoltà più piccola) e con un po' di attento design è possibile ridurre considerevolmente la varianza del tempo di validazione di un blocco di transazioni).

... continua in un post futuro ...

Bitcoin: come funziona il protocollo (Parte 2)

2014-02-13T11:32:00.001+01:00

Premessa

Come già descritto nella parte 1 di questo articolo, ciò che trovi di seguito è una traduzione (dall'inglese all'italiano) del post originale su Bitcoin di Michael Nielsen.

Monete univocamente identificabili tramite numeri seriali

Un problema con la precedente versione di Infocoin è che Alice potrebbe esser tentata ad inviare a Bob lo stesso messaggio più e più volte. Supponiamo ora che Bob riceva dieci copie del messaggio firmato digitalmente "Io, Alice, do a Bob un infocoin". Ciò significa che Alice ha inviato a Bob dieci differenti infocoin? O magari, il messaggio potrebbe esser stato accidentalmente duplicato? Forse Alice sta tentando di ingannare Bob cercando di indurlo a credere di avergli trasmesso dieci differenti infocoin. Il messaggio prova al mondo intero che Alice intende trasferire un solo (e non meglio identificato) infocoin.

Quello che vorremmo è un modo di rendere gli infocoin unici. Associarli ad una qualche etichetta, o meglio a un numero seriale. Così il messaggio precedente, firmato da Alice, diverrebbe qualcosa tipo "Io, Alice, do a Bob un infocoin, con numero seriale 8740348". Dopodiché, Alice trasmette a Bob un secondo infocoin firmando il messaggio "Io, Alice, do a Bob un infocoin, con numero seriale 8770431", cosicché Bob (e chiunque altro) capirebbe che il secondo infocoin trasferito differisce dal primo.

Per far funzionare questo schema abbiamo bisogno di una sorgente fidata di numeri seriali. Un modo di creare tale sorgente è di introdurre una banca. La banca fornirebbe numeri seriali per gli infocoin, tenendo traccia di chi possiede ogni singolo infocoin, e verificherebbe che le transazioni siano valide e legittime.

Più dettagliatamente, supponiamo che Alice va in banca e dice "Voglio prelevare un infocoin dal mio conto". La banca riduce di un infocoin il saldo del conto di Alice e le assegna un nuovo (e mai usato prima) numero seriale, diciamo 1234567. Ora, quando Alice vuole trasferire il suo infocoin a Bob, firma il messaggio "Io, Alice, do a Bob un infocoin, con numero seriale 1234567". Ma Bob non accetta immediatamente l'infocoin trasmessogli. Contatta la banca e verifica che: (a) l'infocoin con numero seriale 1234567 appartenga ad Alice, e (b) Alice non abbia già speso quell'infocoin. Se entrambe queste verifiche vanno a buon fine, allora Bob comunica alla banca che desidera accettare l'infocoin. La banca quindi aggiorna i suoi archivi di modo da memorizzare il fatto che l'infocoin 1234567 appartiene ora a Bob e non più ad Alice.

Sostituire la banca con la collettività (ovvero: Alice, Bob e il resto del mondo)

Quest'ultima soluzione sembra promettente. Tuttavia, proviamo a fare qualcosa di molto più ambizioso. Possiamo eliminare completamente la banca dal protocollo. Ciò cambierebbe considerevolmente la natura della valuta. Significherebbe che non c'è più una singola organizzazione responsabile della valuta. E se si pensa all'enorme potere che una banca centrale ha (controllo dell'offerta di moneta) ciò rappresenta un cambiamento piuttosto grande.

L'idea è di far si che tutti (collettivamente) siano la banca. In particolare, assumeremo che ogni utente che usa Infocoin mantenga un archivio completo che memorizza quali infocoin appartengano a quali persone. Puoi pensare a ciò come ad un libro mastro condiviso che tiene traccia di tutte le transazioni Infocoin. Chiameremo questo libro mastro block chain (catena di blocchi), dato che questo è anche il nome usato in Bitcoin.

Ora, supponiamo che Alice voglia trasferire un infocoin a Bob. Ella firma il messaggio "Io, Alice, do a Bob un infocoin, con numero seriale 1234567" e lo trasmette a Bob. Bob può ora usare la sua copia della block chain per verificare che quell'infocoin appartenga effettivamente ad Alice. Se la verifica va a buon fine, Bob trasmette in broadcast all'intera rete Infocoin sia il messaggio ricevuto da Alice che la sua accettazione della transazione. Quindi, tutti possono aggiornare la loro copia della block chain.

Ma abbiamo ancora un problema. Da dove vengono fuori i numeri seriali? Allo stato attuale, questo problema risulta piuttosto facile da risolvere, quindi, rimando la sua discussione alla sezione dove parlerò di Bitcoin. Un problema più stimolante è che questo protocollo permette ad Alice di truffare spendendo doppiamente (double spending) il suo infocoin. Alice potrebbe prima trasmettere a Bob il messaggio firmato "Io, Alice, do a Bob un infocoin, con numero seriale 1234567" e poi trasmettere lo stesso messaggio a Charlie. Sia Bob che Charlie usano la loro copia della block chain per verificare che Alice davvero possieda l'infocoin 1234567. Ipotizzando che entrambi svolgano la verifica grosso modo nello stesso momento (se questo non fosse il caso, il più lento avrebbe ricevuto il broadcast dell'altro), entrambi verificheranno che, sì, l'infocoin 1234567 appartiene ad Alice. Così, entrambi accettano la transazione e trasmettono in broadcast a tutta la rete la loro accettazione. Ora però sorge un problema. Come dovrebbero aggiornare la propria block chain gli altri utenti della rete? Potrebbe non esserci un modo facile per mantenere una condivisione consistente del libro mastro delle transazioni (block chain). E anche se tutti trovassero un accordo, rimarrebbe pur sempre il problema che uno fra Bob o Charlie è stato truffato da Alice.

A prima vista, per Alice il double spending (truffa) sembrerebbe difficile da realizzare. Dopotutto, se Alice trasmette il messaggio prima a Bob, Bob può verificarlo e comunicare a tutti gli altri nella rete (incluso Charlie) di aggiornare la loro block chain. Una volta fatto ciò, Charlie non potrebbe più essere truffato da Alice. Così, c'è solo un piccolo lasso di tempo nel quale Alice potrebbe fraudolentemente praticare il double spending. Tuttavia, è comunque indesiderabile anche avere un infinitesimo lasso di tempo. Infatti, ci sono tecniche "hacker" che Alice potrebbe usare per dilatare questo lasso di tempo. Ella potrebbe per esempio aver fatto un'analisi del traffico di rete di Bob e Charlie per capire quando è più verosimile che i due possano avere un'alta latenza nelle loro comunicazioni. O magari potrebbe praticare qualche hacking per rallentare deliberatamente le comunicazioni delle due vittime (in realtà uno solo dei due è vittima, ma chi dei due è piuttosto arbitrario da capire). Anche solo qualche secondo sarebbe sufficiente a permettergli di spendere doppiamente il suo solo infocoin.

Come possiamo quindi risolvere il problema del double spending? La soluzione ovvia è che quando Alice trasmette a Bob un infocoin, Bob non dovrebbe verificare la transazione da solo. Piuttosto, egli potrebbe trasmettere in broadcast all'intera rete la transazione candidata e chiedere quindi a tutti i singoli utenti Infocoin di aiutarlo a legittimare o meno il messaggio di Alice. Se la rete collettivamente decide che la transazione è ok, allora Bob può accettare l'infocoin e chiunque nella rete può aggiornare la propria block chain. Questo può aiutare a prevenire il problema del double spending, dato che, se Alice prova a spendere il suo infocoin sia con Bob che con Charlie, altre persone nella rete noteranno che c'è un problema nella transazione e comunicheranno ciò sia a Bob che a Charlie (e a tutti gli altri utenti in realtà) così da fermare il processo di accettazione della transazione.

Più dettagliatamente, supponiamo che Alice voglia dare a Bob un infocoin. Come prima, ella firma il messaggio "Io, Alice, do a Bob un infocoin, con numero seriale 1234567" e lo trasmette a Bob. Ancora come prima, Bob verifica che Alice possieda davvero quell'infocoin utilizzando la propria copia della block chain. Ma a questo punto il protocollo è modificato. Bob, invece di accettare direttamente la transazione come faceva prima, trasmette il messaggio di Alice all'intera rete. Altri membri della rete verificano il fatto che Alice possegga realmente l'infocoin 1234567. Se così è, ogni singolo "verificatore" trasmette in broadcast (quindi ancora una volta all'intera rete) il messaggio "Sì, Alice possiede l'infocoin 1234567, che può ora essere trasferito a Bob". Quando abbastanza persone avranno trasmesso il messaggio di conferma della verifica, ognuno aggiorna la propria block chain di modo che l'infocoin 1234567 appartenga ora a Bob. La transazione è completata.

Questo protocollo ha un po' di elementi di imprecisione al momento. Ad esempio, cosa significa dire "quando abbastanza persone avranno trasmesso il messaggio"? Cosa si intende per "abbastanza"? Non può significare chiunque nella rete, dato che a priori non conosciamo chi e quanti utenti fanno parte della rete Infocoin. Per la stessa ragione non può significare una qualche frazione fissa degli utenti della rete. Non tenterò di rendere questa definizione precisa ora. Invece, nella prossima sezione evidenzierò un problema più serio dell'approccio appena descritto. La soluzione a tale problema consentirà collateralmente di chiarire le idee precedenti.

... clicca qui per leggere il seguito ...

Efficiently swap matrix rows and columns synchronously

2014-02-11T15:19:00.001+01:00

It may happen (practical and usual examples?) that you have a matrix data structure and you need to (synchronously) swap rows i and j together with columns i and j.

The simple solution would require to iterate on the rows/columns entries, so it costs O(n) for an n x n matrix (similar considerations if the matrix is rectangular).

A more clever solution adopts an additional vector of size n and works in O(1). The idea is to keep the additional vector ind as a sort of array of pointers to the rows/columns of the matrix m. In the following, the three main aspects of the solution:

Vector ind has to be initialized to the "identity" vector (ind = <0, 1, ..., n-1>).
Access m entries no more directly but through ind, i.e. m[ind[i],ind[j]] instead of the classical m[i,j].
Now, the swap of both rows and columns i and j can be done by simply swapping ind[i] and ind[j].

A set data structure to insert, remove and get a random element in constant time

2014-02-10T01:00:00.000+01:00

If you are a coder, and you need to implement a set data structure that requires insert, remove and "get random element" operations all working in constant time, so here the solution!

Simply use a dynamic array (for example: vector in C++ or ArrayList in Java) and an hash table (for example: unordered_map in C++ 11 or HashMap in Java) together.

The key idea is to store the set elements consecutively in the array, and keep track of their indexes in the (inverted) hash table. Thus, the hash table keys are the array values (i.e. the set elements) and the hash table values are the array indexes.

Now the semantics of the operations.

INSERT(val): append the value at the end of the array, so at index array.size-1 (if the array is 0-based), and create a new entry in the hash table with val as key and array.size-1 as value. Obviously, you have also to check if val is already in the set. Anyway, the complexity is always O(1) (using amortized analysis).

REMOVE(val): use the hash table to get the array index of val, say it is ind. Get the last element in the array (the one in position array.size-1), say it is lastval. Swap the array elements at positions ind and array.size-1 (so you swap the values val and lastval). Decrease by 1 the array size (e.g. using pop_back in C++). Update the hash table entry for lastval with the value ind. Finally, remove the entry with key val from the hash table. Obviously, you have also to check that val is really contained in the set. Anyway, the complexity is always O(1) (using amortized analysis).

GET_RANDOM_ELEMENT(): this is now the easy part. Simply pick up a random integer r between 0 and vector.size-1 and return the r-th value from the vector. Complexity O(1).

Other operations like random access and value check are easy and O(1) as well!

Bitcoin: come funziona il protocollo (Parte 1)

2014-02-05T18:14:00.000+01:00

Premessa

Iniziamo qui una serie di post sul funzionamento di Bitcoin a livello tecnico/teorico. Credo possa interessare a molti (almeno a chi possiede un minimo di background).

Ci tengo a precisare che niente è farina del mio sacco. Questi post sono delle mere ~~ed imprecise~~ traduzioni del fantastico articolo su Bitcoin di Michael Nielsen (un ricercatore di fama mondiale nel campo dell'informatica). In quanto traduzioni, l'uso della prima persona singolare non è ovviamente volto ad identificare me, ma, appunto, il vero autore dell'articolo (che vi invito a leggere direttamente se avete familiarità con l'inglese). Via alle danze!

Introduzione

Svariati articoli sono stati scritti con l'obiettivo di descrivere il funzionamento di Bitcoin, la valuta peer-to-peer online. Molti di questi, però, forniscono delle considerazioni del tutto superficiali. Altri invece vanno più a fondo ma trascurano comunque taluni punti cruciali del protocollo. L'obiettivo di questo post è quindi quello di spiegare le idee principali che stanno dietro al protocollo di Bitcoin in modo chiaro, semplice e comprensibile. Partiremo da alcuni concetti iniziali di modo da costruire le basi teoriche su cui si basa il protocollo per poi far luce sui dettagli di questo ed arrivare quindi ad analizzare i dati grezzi (raw data) di una transazione Bitcoin.

Comprendere dettagliatamente il protocollo non è semplice. Forse è a causa di ciò che molti prendono il funzionamento di Bitcoin come un dogma e si perdono in riflessioni sul come diventare ricchi con Bitcoin, sul fatto che Bitcoin sia una bolla speculativa o meno, sulla fine delle commissioni bancarie e così via. Probabilmente tutte discussioni interessanti ma che limitano ed esulano dalla comprensione tecnico/teorica di Bitcoin. Capire i dettagli del protocollo permette invece di aprirsi verso nuove prospettive. In particolare, è la base per la comprensione del linguaggio di scripting built-in di Bitcoin, il quale rende possibile la creazione di nuovi strumenti finanziari, come ad esempio gli smart contracts. Tali nuovi strumenti possono a loro volta dar vita a nuovi mercati e quindi a nuove forme di interazione sociale. Ma passiamo ora alla spiegazione!

Descriverò gli script e le estensioni di Bitcoin in futuro. Invece, questo post si concentra nel descrivere gli ingranaggi del protocollo alla base di Bitcoin. Per la comprensione di questo post sono necessarie delle infarinature sui concetti di crittografia a chiave pubblica e firma digitale. Inoltre, assumerò una vostra familiarità con gli hash crittografici. Niente di particolarmente difficile, tutte cose abbordabili da uno studente al primo anno di un corso di matematica o informatica.

Può sembrare sorprendente che Bitcoin si basi sulla crittografia. Ma Bitcoin non dovrebbe essere una valuta? Oppure è un modo per spedire messaggi segreti? In effetti, i problemi che Bitcoin deve risolvere riguardano perlopiù la messa in sicurezza delle transazioni: fare sì che non ci siano furti, truffe, false identità, .... Nel mondo reale ricerchiamo la sicurezza tramite lucchetti, cassette di sicurezza, firme e caveau bancari. Nel mondo digitale, questo tipo di sicurezza è ottenuta tramite la crittografia. Questo è il motivo del cuore crittografico di Bitcoin.

La mia strategia in questo post è di "costruire" Bitcoin per fasi successive. Inizierò spiegando una semplice valuta digitale che chiamerò Infocoin, per distinguerla da Bitcoin. La nostra prima versione di Infocoin avrà molte carenze, quindi itereremo lo sviluppo di Infocoin introducendo una o due nuove (e semplici) idee ad ogni iterazione. Dopo un po' di iterazioni arriveremo al protocollo Bitcoin completo. Avremo reinventato Bitcoin!

Questa strategia può sembrare lenta e macchinosa rispetto ad altre, ma ha il grosso vantaggio di rendere chiaro il perché Bitcoin è stato progettato così com'è.

Passo 1: una dichiarazione di intenti firmata

Come possiamo progettare una valuta digitale?

A primo acchito un tale marchingegno potrebbe sembrare impossibile. Supponiamo che Alice possieda un po' di moneta digitale che vuole spendere in qualche modo. Se Alice può usare una sequenza di bit come moneta, come possiamo evitare che possa usare la stessa sequenza per uno, due, cento, mille acquisti? O ancora, se potessimo in un qualche modo risolvere questo problema, come potremmo evitare che qualcun altro possa contraffare, clonare o generare la stessa sequenza di bit così da rubare denaro ad Alice?

Questi sono solamente due dei molteplici problemi che sussistono nell'usare l'informazione come moneta.

Come prima versione di Infocoin, cerchiamo quindi di trovare un modo che permetta ad Alice di usare una sequenza di bit come forma di moneta (seppur molto primitiva ed incompleta per iniziare) che le dia almeno qualche protezione contro la contraffazione. Supponiamo che Alice voglia dare a Bob un infocoin. Per far ciò, Alice scrive un messaggio "Io, Alice, do a Bob un infocoin". Poi, firma digitalmente il messaggio usando la sua chiave (crittografica) privata, e divulga pubblicamente la sequenza di bit corrispondente al suo messaggio firmato digitalmente.

(Giusto un veloce appunto. Userò "Infocoin" per riferirmi al protocollo, e "infocoin" come denominazione specifica della moneta. Questo uso è comune, seppur non universalmente riconosciuto, anche nel mondo di Bitcoin.)

Questo prototipo di valuta digitale non impressiona per niente. Ma possiede comunque alcune virtù. Chiunque al mondo (incluso Bob) può usare la chiave pubblica di Alice per verificare che Alice è davvero la persona che ha firmato il messaggio "Io, Alice, do a Bob un infocoin". Nessun altro può aver creato quella sequenza di bit, nemmeno Alice stessa potrebbe più negarlo. Quindi, il protocollo stabilisce che Alice veramente intende dare a Bob un infocoin. Lo stesso argomento (nessun altro può aver creato quella sequenza di bit) fornisce ad Alice anche una limitata protezione dalla contraffazione. Certo, dopo che Alice ha pubblicato il suo messaggio è possibile che altre persone possano duplicarlo, ed in questo senso la contraffazione è possibile. Ma nessuno può farlo da zero (ovvero duplicare/predirre un messaggio non ancora divulgato). Queste due proprietà, la dichiarazione di intenti di Alice, e la limitata protezione dalla contraffazione, sono caratteristiche notevoli di questo protocollo.

Non ho ancora detto cos'è la moneta digitale. Per essere espliciti: è esattamente la sequenza di bit rappresentante il messaggio di dichiarazione di intenti (es: "Io, Alice, do a Bob un infocoin") firmato digitalmente. Similmente, le successive versioni di Infocoin, useranno questa rappresentazione della moneta come messaggi firmati digitalmente, seppur sempre più elaborati.

... clicca qui per leggere il seguito ...

George Best: dribbling e drinking da Belfast a Hong Kong via Johannesburg, Brisbane, Los Angeles, ...

2014-01-25T16:25:00.001+01:00

~~Maradona good~~

~~Pelè better~~

George Best, uomo di eccessi, eccesso di classe in campo, eccessivi eccessi fuori dal campo, è stato senza dubbio il più grande calciatore dell'Irlanda del Nord e probabilmente uno dei migliori quattro o cinque calciatori nella storia del calcio.

George nasce a Belfast il 22 maggio 1946 e inizia a dare i suoi primi calci nel Glentoran (squadra locale di Belfast). Nel 1961, Bob Bishop, talent scout del Manchester United, manda il seguente telegramma all'allora manager Matt Busby: "I think I've found you a genius".

Inizia la favola di George (the) Best. Numero 7. Ala destra. Difficile descriverlo meglio di così: "l'ala destra era un ribelle, un sognatore e un fuggitivo. Aveva la maglia numero sette sulle spalle fragili, portava i capelli lunghi o arruffati e i calzettoni abbassati, i suoi dribbling erano arte pura, elogio della malinconia, allegria e follia" (tratto da "Nostalgia dell'ala destra" di Darwin Pastorin).

Undici stagioni di Manchester United. Innumerevoli successi. Su tutti, una coppa dei campioni ed un pallone d'oro. Best diviene presto un campione, beniamino dei tifosi, leggenda sia dentro che fuori dal campo. E fuori dal campo, se possibile, riesce a distinguersi ancora più che dentro. In ordine sparso: belle donne, whisky, auto sportive, birra, bella vita, miss Canada, vizi, corse di cavalli, scommesse, notti brave, ecc.

George inizia la sua traiettoria discendente già negli ultimi anni di Manchester. Ma questo lo sanno ormai più o meno tutti. Ciò che è meno conosciuto sono gli anni calcistici immediatamente post Manchester di George Best.

Si narra di George Best bere tè in un locale di Hong Kong (forse in uno dei (pochi) tentativi di "dealcolizzazione"). Di George Best partecipare al terzo tempo della nazionale di rugby francese e risvegliarsi in un pub di Edinburgo a poche ore dalla partita del suo Hibernian. Di George Best aprire un locale in una spiaggia di San José (California). Di George Best in Sud Africa, Australia, Scozia e ancora Irlanda.

Ma ripercorriamo il suo vagabondare per il mondo in cerca di ingaggi, partite e contratti, spesso a gettone. Un globetrotter del calcio. Figura difficilmente immaginabile per quell'epoca.

Nel 1974 George lascia il Manchester United e si trasferisce in prestito al Jewish Guild, formazione sud-africana di Johannesburg. Sole cinque partite e qualche scorribanda notturna. George torna in Inghilterra, allo Stockport County. Tre partite, due goal e via di nuovo. Destinanazione: Los Angeles Aztecs, North American Soccer League. Qua, in America, George è la stella del campionato locale. Ma è difficile tenerlo fermo. Fra il 1975 ed il 1981, George alterna i suoi campionati americani ad alcune apparizioni in Gran Bretagna e Irlanda. Oltre agli Aztecs, milita nelle compagini americane dei Fort Launderdale Strikers e dei San José Earthquakes. Nei suoi ritorni "at home" calca invece i campi di Cork Celtic (Irlanda), Fulham (Londra, Inghilterra) e Hibernian (Edimburgo, Scozia). Nell'82-83 è il turno del Bournemouth (Inghilterra) oltre che di alcune apparizioni negli Hong Kong Rangers e nel Sea Bee, entrambe compagini del campionato di Hong Kong, l'allora colonia inglese in Cina. Ma non finisce qui, George Best vanta presenze anche in Australia, quattro partite ufficiali con i Brisbane Lions ed altre non ufficiali con gli Osborne Park Galaeb (South Australia). Per finire poi la sua carriera con qualche apparizione nelle serie minori inglesi fra le fila del Nuneaton Borough e del Tobermore United.

Irlanda del Nord - Inghilterra - Sud Africa - Irlanda - Stati Uniti - Scozia - Hong Kong - Australia. Anche questo era George Best.

Fonti:
The Guardian
Wikipedia

Lettura consigliata:
Noi che preghiamo George Be[lfa]st

Lorem Ipsum

2014-01-24T12:49:00.001+01:00

Dry hopping bottle conditioning, lauter tun; heat exchanger ester bunghole cask conditioned ale. keg shelf life bottom fermenting yeast, barrel scotch ale, gravity lager, fermentation-- mash tun. cask barley, bock mouthfeel lauter krausen.

Candy bonbon pastry jujubes lollipop wafer biscuit biscuit. Topping brownie sesame snaps sweet roll pie. Croissant danish biscuit soufflé caramels jujubes jelly. Dragée danish caramels lemon drops dragée. Gummi bears cupcake biscuit tiramisu sugar plum pastry. Dragée gummies applicake pudding liquorice. Donut jujubes oat cake jelly-o. Dessert bear claw chocolate cake gummies lollipop sugar plum ice cream gummies cheesecake.

The path of the righteous man is beset on all sides by the iniquities of the selfish and the tyranny of evil men. Blessed is he who, in the name of charity and good will, shepherds the weak through the valley of darkness, for he is truly his brother’s keeper and the finder of lost children. And I will strike down upon thee with great vengeance and furious anger those who would attempt to poison and destroy My brothers. And you will know My name is the Lord when I lay My vengeance upon thee.

Finalmente online!