W02.03 – CONSENSO SENZA IDENTITA’: LA BLOCK CHAIN


WEEK 2
Come Bitcoin realizza la Decentralizzazione

Learn Bitcoin’s consensus mechanism and reason about its security. Appreciate how security comes from a combination of technical methods and clever incentive engineering. Imparare il meccanismo di consenso di Bitcoin e la ragione sulla sua sicurezza. Apprezzare il modo in cui la sicurezza deriva da una combinazione di metodi tecnici e ingegnosità intelligente.

Arvind Narayanan
Assistant Professor of Computer science – Princeton

Sezione 02.03 – Consenso senza Identità: la Block Chain
02.03.01
So let’s now dig into the technical details of Bitcoin’s consensus algorithm. And while we’re looking at that, we should keep in mind that Bitcoin does all of this without nodes having any persistent long term identities. This is, yet again, a difference from how traditional distributive consensus algorithms operated and if nodes did have identities, it would make things a lot easier for a couple of reasons.

One is a pragmatic reason. It would allow you to put into your protocol things like, now the node with the lowest numerical ID should take some step or something like that. So that’s a simple pragmatic reason which, already if nodes are completely anonymous, becomes harder to do. But a much more serious reason for nodes to have identities, is for security, because if nodes were identified, and they weren’t attribual to create new node identities, then we could make assumptions like, let’s say that less than 50% of the nodes are malicious. And we could derive security properties out of that. So for both of those reasons, the consensus protocol in Bitcoin is a bit harder.
Quindi analizziamo ora i dettagli tecnici dell’algoritmo di consenso di Bitcoin. E mentre lo stiamo osservando, dovremmo tenere a mente che Bitcoin fa tutto questo senza che i nodi abbiano identità persistenti a lungo termine. Questa è, ancora una volta, una differenza rispetto al modo in cui gli algoritmi di consenso distributivo tradizionali hanno funzionato e se i nodi avevano identità, renderebbe le cose molto più semplici per un paio di motivi.

Uno è una ragione pragmatica. Ti permetterebbe di inserire nel tuo protocollo cose come, ora il nodo con l’ID numerico più basso dovrebbe fare qualche passo o qualcosa del genere. Quindi questa è una semplice ragione pragmatica che, già se i nodi sono completamente anonimi, diventa più difficile da fare. Ma una ragione molto più seria per i nodi di avere identità, è per la sicurezza, perché se i nodi sono stati identificati, e non erano attribuibili alla creazione di nuove identità di nodo, allora potremmo fare ipotesi come, diciamo che meno del 50% dei nodi sono dannosi E potremmo ricavarne proprietà di sicurezza. Quindi per entrambe le ragioni, il protocollo di consenso in Bitcoin è un pò più difficile.
02.03.02
But why is it exactly that Bitcoin nodes don’t have identities? Well, it’s for a couple of reasons. One is that if you’re in a decentralized model in a peer-to-peer system, there is no central authority to give identities to nodes and verify that they’re not creating new nodes at will. And, in fact, the technical term for this is a Sybil attack. Sybils are just copies of nodes that a malicious adversary can create to look like there are a lot of different participants, when in fact, all those pseudo participants are really controlled by the same adversary.

The other reason is that pseudonymity is inherently a goal of Bitcoin. Even if it were possible or easy to establish identities for all nodes or all participants, we wouldn’t necessarily want to do that.

So, Bitcoin doesn’t give you strong anonymity guarantees out of the box, in that the different transactions that you make can probably be linked together, but at the same time nobody is forcing you to put your real life identity, like your name or IP address or anything like that, in order to participate in the peer-to-peer network and in the block chain, and that’s an important property.
Ma perché è esattamente che i nodi Bitcoin non hanno identità? Bene, è per un paio di ragioni. Uno è che se sei in un modello decentralizzato in un sistema peer-to-peer, non v’è alcuna autorità centrale per dare identità ai nodi e verificare che non stanno creando nuovi nodi a volontà. E, in effetti, il termine tecnico per questo è un attacco Sybil [Sibilla]. Le Sybils sono solo copie di nodi che un avversario malizioso può creare per vedere come ci sono molti partecipanti diversi, quando in realtà tutti questi pseudo partecipanti sono controllati dallo stesso avversario.

L’altra ragione è che la pseudonimia è intrinsecamente un obiettivo di Bitcoin. Anche se fosse possibile o facile stabilire identità per tutti i nodi o tutti i partecipanti, non vorremmo necessariamente farlo.

Quindi, Bitcoin non ti dà forti garanzie di anonimato, in quanto le diverse transazioni che fai possono probabilmente essere collegate insieme, ma allo stesso tempo nessuno ti obbliga a mettere la tua vera identità di vita, come il tuo nome o Indirizzo IP o qualcosa del genere, per poter partecipare alla rete peer-to-peer e alla catena dei blocchi, e questa è una proprietà importante.
02.03.03
So, what we can do instead is we can make a weaker assumption. And I kind of wanted you to take a leap of faith with me here that this weaker assumption is something that is going to be feasible. And I’m gonna make this assumption here, and later show you how this is actually accomplished. And what this weaker assumption is, is that we’re gonna assume that there is some ability, somehow, to pick a random node in the system. And a good motivating analogy for this, is a lottery or a raffle, where any number of real life systems, we’re tracking and verifying people and giving them identities. And verifying those identities is pretty hard and so what we do in those contexts is we might give them tokens or tickets or something of that sort and that then enables us to later pick a random token ID and call upon that person.

So we’re gonna do something similar with respect to these Bitcoin nodes, and further assume, for the moment, that this token generation and distribution algorithm has enough smarts so that, if the adversary is going to try to create a lot of civil nodes, together, all of those civils just get one token, so the adversary is not able to multiply his power that way.
Quindi, quello che possiamo fare invece è che possiamo assumere un’ipotesi più debole. E in qualche modo volevo che tu facessi un salto di fiducia con me, qui che questa debole ipotesi è qualcosa che sarà fattibile. E farò questa ipotesi qui, e più tardi ti mostrerò come questo viene effettivamente realizzato. E ciò che questa assunzione più debole è, che assumeremo che ci sia qualche possibilità, in qualche modo, di scegliere un nodo casuale nel sistema. E una buona analogia motivante per questo, è una lotteria o una riffa, dove qualsiasi numero di sistemi di vita reale, stiamo monitorando e verificando le persone e dando loro identità. E il controllo di dette identità è piuttosto difficile e così quello che facciamo in quei contesti è che potremmo dare loro gettoni o biglietti o qualcosa del genere, e che quindi ci permette di scegliere successivamente un ID del token casuale e invitare quella persona.

Quindi faremo qualcosa di simile rispetto a questi nodi Bitcoin, e supponiamo ulteriormente, per il momento, che questo algoritmo di generazione e distribuzione di token abbia abbastanza intelligenza in modo che, se l’avversario sta per cercare di creare molti nodi civili insieme, tutti questi civilizzati ottengono solo un segno, quindi l’avversario non è in grado di moltiplicare il suo potere in quel modo.
02.03.04
So let’s make this assumption for now, and let’s see what becomes possible if we make this assumption.

Here’s the key idea. What becomes possible under this assumption of random node selection and something called implicit consensus. So what is implicit consensus?

In each round, and there are gonna be multiple rounds, each round corresponding to a different block in the block chain, in each round a random node is somehow selected, magically for the moment. And this node gets to propose the next block in the chain. There is no consensus algorithm. There is no voting. This node simply unilaterally proposes what the next block in the block chain is going to be.

But what if that node is malicious? Well, there is a process for this, but it is an implicit one. Other nodes will implicitly accept or reject that block. And how will they do that? If they accept that block, they will signal that acceptance by extending the block chain starting from that block, or if they reject that block, they will extend the chain by ignoring that block and starting from whatever was the previous, latest block in the block chain.

And technically, how is that implemented? Recall that each block contains a hash of the block that it extends and this is the technical mechanism that allows nodes to signal which block it is that they are extending.
Facciamo ora questa ipotesi, e vediamo cosa diventa possibile se facciamo questa ipotesi.

Ecco l’idea chiave. Ciò che diventa possibile sotto questa assunzione di selezione casuale del nodo e qualcosa chiamato consenso implicito. Quindi, qual è il consenso implicito?

In ogni round, e ci saranno più round, ogni round corrispondente ad un blocco diverso nella catena di blocchi, in ogni round un nodo casuale è in qualche modo selezionato, magicamente per il momento. E questo nodo arriva a proporre il prossimo blocco della catena. Non esiste un algoritmo di consenso. Non c’è il voto. Questo nodo propone semplicemente unilateralmente quale sarà il prossimo blocco nella catena dei blocchi.

Ma cosa succede se quel nodo è dannoso? Bene, c’è un processo per questo, ma è implicito. Altri nodi accettano o rifiutano implicitamente quel blocco. E come lo faranno? Se accettano tale blocco, si segnala che l’accettazione estendendo la catena di blocco a partire da quel blocco, o se rifiutano quel blocco, saranno estendere la catena ignorando quel blocco e partendo da ciò che era il precedente, l’ultimo blocco nel blocco catena.

E tecnicamente, come viene implementato? Ricordiamo che ogni blocco contiene un hash del blocco che estende e questo è il meccanismo tecnico che consente ai nodi di segnalare il blocco che stanno estendendo.
02.03.05
So, given this, this is what the overall consensus algorithm in Bitcoin is going to look like. Now this is a little bit simplified and the reason it’s simplified is again that I’m assuming sort of this magic random node selection process. But except for that simplification, this is pretty close to how Bitcoin actually works. So whenever Alice wants to pay Bob, she will create a transaction, and she will broadcast it to all of the nodes. And any one of these nodes is constantly listening to the network and collecting a list of outstanding transactions that have not yet made it into the block chain.

At some point, one of these nodes is going to be randomly called upon to propose the next block. It’s going to round up all of the outstanding transactions that it’s heard about and propose that block.

Now presumably, that node was honest, but it could also be a malicious node or a faulty node and propose a block that contains some invalid transactions. Invalid transactions are those that don’t have the right crypto signature or where the transaction is already spent, in other words, an attempt to double spend. So if that happens, other nodes are going to signal their acceptance or rejection of the block, as we saw in the last slide, by either including the hash of this latest block in their next block or ignoring this block and including the hash of whatever was the previous block that they considered to be valid. Right, so now let’s try to understand why this consensus algorithm works. And the way I like to understand this is instead of asking why this works, let’s try to ask how can a malicious adversary try to subvert this process.

So let’s look at that for a second. So here we have a couple of blocks in the block chain.
Quindi, dato questo, questo è l’aspetto dell’algoritmo di consenso generale in Bitcoin. Ora questo è un po ‘semplificato e il motivo per cui è semplificato è di nuovo che sto assumendo una sorta di questa magico processo di selezione casuale dei nodi. Ma a parte questa semplificazione, questo è abbastanza vicino a come funziona effettivamente Bitcoin. Quindi, ogni volta che Alice vuole pagare Bob, lei crea una transazione e lei la trasmetterà a tutti i nodi. E ognuno di questi nodi ascolta costantemente la rete e raccoglie un elenco di transazioni in sospeso che non sono ancora state inserite nella catena di blocco.

A un certo punto, uno di questi nodi sarà chiamato a caso per proporre il blocco successivo . Arrotolerà tutte le transazioni in sospeso di cui si è sentito parlare e proporrà quel blocco.

Ora presumibilmente, quel nodo era onesto, ma potrebbe anche essere un nodo malevolo o un nodo difettoso e proporre un blocco che contiene alcune transazioni non valide. Le transazioni non valide sono quelle che non hanno la firma crittografica corretta o dove la transazione è già spesa, in altre parole, un tentativo di raddoppiare la spesa. Quindi, se ciò accade, altri nodi segnaleranno la loro accettazione o rifiuto del blocco, come abbiamo visto nell’ultima diapositiva, includendo l’hash di quest’ultimo blocco nel blocco successivo o ignorando questo blocco e includendo l’hash di qualunque cosa era il blocco precedente che consideravano valido. Giusto, quindi ora proviamo a capire perché questo algoritmo di consenso funziona. E il modo in cui mi piace capire questo è invece di chiedere perché questo funziona, proviamo a chiedere come può un avversario malintenzionato cercare di sovvertire questo processo.

Diamo un’occhiata per un secondo. Quindi qui abbiamo un paio di blocchi nella catena dei blocchi.
02.03.06
Assume that this extends to the left a long way back, all the way to what is called the genesis block. But here, I’m only showing you a couple of blocks in the block chain. And that pointer that you see over there is a block referring to what is the previous block that it extends, by including a hash of that previous block within it’s own contents.

So, a malicious attacker, let’s call her Alice. What might she try to do?

Can she simply steal Bitcoins belonging to another user at a different address that she doesn’t control?

Now, even if it is now Alice’s turn to propose the next block in this chain, she cannot steal other user’s Bitcoins. Why? Because she cannot forge their signatures, so as long as the underlying crypto is solid, she’s not able to simply steal Bitcoins.

Another thing she might try to do, is if she really, really hates some other user, Bob, then she can look at Bob’s address and she can decide that any transactions originating from Bob’s address, she will simply not include them in any block that she proposes to get onto the block chain.

In other words, she’s denying service to Bob. So this is a valid attack that she can try to mount. But luckily, it’s nothing more than a little annoyance, because if Bob’s block doesn’t make it into the next block that Alice proposes, he will just wait another block until an honest node gets the chance to propose a block and then his transaction will get into that block.

So that’s not really a good attack, either. So the only one that we’re really left with, for what a malicious node can try to do here, is called a double spending attack. So how might a double spending attack work? To understand that, let’s assume that Alice is a customer of some online merchant or website run by Bob, who provides some online service, in exchange for payment in Bitcoins. Let’s say he allows the download of some software. So here’s how a double spending attack might work. Alice goes to Bob’s website and decides to buy this item, pays for it with Bitcoins, and what that means, in technical terms, is that she’s going to create a Bitcoin transaction from her address to Bob’s address. She broadcasts it to the network. And let’s say that some honest node creates the next block, listens to this transaction, and includes it in that block.
Supponiamo che questo si estenda a sinistra molto indietro, fino a quello che viene chiamato il blocco genesi. Ma qui, ti sto solo mostrando un paio di blocchi nella catena dei blocchi. E quel puntatore che vedi lì è un blocco che si riferisce a quello che è il blocco precedente che estende, includendo un hash di quel blocco precedente all’interno del suo contenuto.

Quindi, un malintenzionato, chiamiamola Alice. Cosa potrebbe provare a fare?

Può semplicemente rubare Bitcoin appartenenti a un altro utente a un indirizzo diverso da quello che non controlla?

Ora, anche se è ora il turno di Alice di proporre il prossimo blocco di questa catena, non può rubare gli altri utenti bitcoin. Perché? Perché non può falsificare le loro firme, quindi finché la crypto sottostante è solida, non è in grado di rubare semplicemente Bitcoin.

Un’altra cosa che potrebbe provare a fare è se lei odia davvero un altro utente, Bob, quindi può guardare all’indirizzo di Bob e lei può decidere che qualsiasi transazione proveniente dall’indirizzo di Bob, lei semplicemente non li includerà in nessun blocco che lei propone di ottenere sulla catena di blocco.

In altre parole, lei sta negando il servizio a Bob. Quindi questo è un attacco valido che lei può provare a montare. Ma per fortuna, non è altro che un pò di fastidio, perché se il blocco di Bob non arriva al prossimo blocco che Alice propone, attenderà un altro blocco fino a quando un nodo onesto avrà la possibilità di proporre un blocco e quindi la sua transazione entrerà in quel blocco.

Quindi non è davvero un buon attacco, per niente. Quindi l’unico con cui ci siamo davvero lasciati, per quello che un nodo dannoso può provare a fare qui, è chiamato un attacco a doppia spesa. Quindi, come potrebbe funzionare un attacco a doppia spesa? Per capirlo, supponiamo che Alice sia cliente di qualche commerciante o sito web online gestito da Bob, che fornisce alcuni servizi online, in cambio del pagamento in Bitcoin. Diciamo che permette il download di alcuni software. Ecco come può funzionare un attacco a doppia spesa. Alice si reca sul sito web di Bob e decide di acquistare questo articolo, paga con Bitcoin e ciò significa, in termini tecnici, che sta per creare una transazione Bitcoin dal suo indirizzo all’indirizzo di Bob. Lei lo trasmette alla rete. Diciamo che alcuni nodi onesti creano il blocco successivo, ascoltano questa transazione e la includono in quel blocco.
02.03.07
So, what is going on here? So, there is this block that was created by an honest node that contains a transaction that represents a payment from Alice to the merchant, Bob. By C subscript A, I mean, a coin belonging to Alice, and that is now being sent to Bob’s address.
Let’s zoom into this in a little bit more technical detail.
Quindi, cosa sta succedendo qui? Quindi, questo blocco è stato creato da un nodo onesto che contiene una transazione che rappresenta un pagamento da parte di Alice al commerciante, Bob. Con l’indice CA, voglio dire, una moneta appartenente ad Alice, e che ora viene inviata all’indirizzo di Bob.

Focalizziamoci su questo dettaglio un pò più tecnico.
02.03.08
A transaction, as we saw earlier, is a data structure that contains Alice’s signature here, and an instruction to pay to Bob’s public key, and also a hash. What is this hash? This hash represents a pointer to the transaction where Alice, in fact, received that coin from somebody else. And that must be a pointer to a transaction that was included in some previous block in the consensus chain. So visually, it’s going to look something like this. Una transazione, come abbiamo visto prima, è una struttura dati che contiene la firma di Alice qui, un’istruzione da pagare alla chiave pubblica di Bob e anche un hash. Cos’è questo hash? Questo hash rappresenta un puntatore alla transazione in cui Alice, in effetti, ha ricevuto quella moneta da qualcun altro. E quello deve essere un puntatore a una transazione che è stata inclusa in qualche blocco precedente nella catena di consenso. Così visivamente, assomiglierà a qualcosa del genere.
02.03.09
Let’s pause for a second here, because there’s something subtle going on. There are at least two different types of pointers in this diagram that I’ve showed you. There is, in fact, a third one corresponding to Merkle trace, but we’re not gonna look at that, at the present moment. But this two types of pointers that I refer to, are blocks that include a hash of the previous block that they’re extending, and transactions that include a pointer to whatever the previous transaction that where the coin came from. Right, so this is the situation, and this block was now generated by an honest node, and now let’s assume that the next time a random node is called, that node is a malicious node controlled by Alice. Right, so this is the block chain as it stands right now. Bob has already looked at this block chain, decided that Alice has paid him, and has allowed Alice to download the software or whatever it is that she was buying on his website.

Right, so as far as Bob is concerned, he is satisfied, the transaction is completed, Alice has now received her goods in exchange for the payment.
Ci fermiamo un secondo qui, perché c’è qualcosa di sottile in corso. Ci sono almeno due diversi tipi di puntatori in questo diagramma che ti ho mostrato. Esiste, in effetti, un terzo che corrisponde alla traccia di Merkle, ma al momento non lo vedremo. Ma questi due tipi di puntatori a cui mi riferisco sono blocchi che includono un hash del blocco precedente che essi si stanno estendendo e transazioni che includono un puntatore a qualsiasi transazione precedente da cui proviene la moneta. Bene, quindi questa è la situazione, e questo blocco ora è stato generato da un nodo onesto, e ora supponiamo che la prossima volta che viene chiamato un nodo casuale, quel nodo sia un nodo malevolo controllato da Alice. Giusto, quindi questa è la catena dei blocchi così com’è adesso. Bob ha già esaminato questa catena di blocco, ha deciso che Alice lo ha pagato e ha permesso ad Alice di scaricare il software o qualsiasi altra cosa che stava acquistando sul suo sito Web.

Bene, per quanto riguarda Bob, è soddisfatto, la transazione è completata, Alice ha ora ricevuto i suoi beni in cambio del pagamento.
02.03.10
Now what might happen, is if Alice now gets to propose the next block, she could propose a block that looks like this. Ignores altogether this valid block over here, and instead, contains a pointer to the previous block. And furthermore, it’s going to contain a transaction that contains a transfer of coins, of Alice’s coins to another address, A prime, that’s also controlled by Alice.

So this is a classic double-spend pattern.
Ora, cosa potrebbe accadere, è che se Alice adesso dovesse proporre il blocco successivo, potrebbe proporre un blocco simile a questo. Ignora del tutto questo blocco valido qui e invece contiene un puntatore al blocco precedente. Inoltre, conterrà una transazione che contiene un trasferimento di monete, di monete di Alice ad un altro indirizzo, un primo, anch’esso controllato da Alice.

Questo è un classico schema a doppia spesa.
02.03.11
What is going on here, is Alice now creates a new transaction that transfers that coin, instead of to Bob’s address, to another address owned by her. And visually it’s gonna look like this. This is a completely different transaction, also with the hash pointer going back to same transaction referred to earlier.

Right, so this is what an attempt at a double-spend look like. And how do we know if this double-spend attempt is going to succeed or not? Well, that depends on whether this green transaction here or this red transaction is going to ultimately end up in the long term consensus chain. So what determines that? That is determined by the facts that honest nodes are always following the policy of extending the longest valid branch. So now, which of these is the longest valid branch?
Quello che sta succedendo qui è che Alice ora crea una nuova transazione che trasferisce quella moneta, anziché all’indirizzo di Bob, a un altro indirizzo di sua proprietà. E visivamente sembrerà questo. Questa è una transazione completamente diversa, anche con il puntatore hash che torna alla stessa transazione a cui si fa riferimento in precedenza.

Bene, quindi questo è l’aspetto di un tentativo di doppia spesa. E come facciamo a sapere se questo tentativo di doppia spesa avrà successo o no? Bene, questo dipende dal fatto che questa transazione verde qui o questa transazione rossa finirà per finire nella catena di consenso a lungo termine. Quindi cosa lo determina? Ciò è determinato dal fatto che i nodi onesti seguono sempre la politica di estensione del ramo valido più lungo. Quindi, quale di questi è il ramo valido più lungo?
02.03.12
You might look at this and say, a-ha, the first one is the longest valid branch, not the second one, because it’s a double-spend attempt. But here’s a very subtle point that I want you to appreciate, from sort of a moral point of view, this transaction in green and the transaction in red might look very different, because based on the explanation that I’ve given you, the first one is an attempt by Alice to pay Bob, whereas the second one is an attempt by Alice to defraud Bob and pay coins back to herself. But from a technological point of view, these two transactions are completely identical. The nodes that are looking at this, really have no way to tell which one is the legitimate transaction. I’m putting legitimate in air quotes, because it’s a moral judgment that we apply to it, it’s not a technical distinction, versus which one is the attempted double-spend. It could easily be the other way around.

Now, nodes often follow a heuristic of extending the block that they first heard about on the peer-to-peer network, but it’s not a solid rule. And in any case, because of network latency, that could easily be the other way around.

So now there is at least some chance that the next node that gets to propose a block will extend this block instead of this one. Or it could be that even if it’s an honest node, Alice could try to bribe that node or try to subvert the process in a variety of ways. So for whatever reason, without going too much into the details, let’s say that the next node extends the block with the red transaction instead of the green one.

What this means is that at this point, the next honest node is much more likely to extend this block instead of this one because now this has become the longest valid chain.
Potresti guardare questo e dire, a-ha, il primo è il ramo più lungo valido, non il secondo, perché è un tentativo di doppia spesa. Ma qui c’è un punto molto sottile che voglio che tu apprezzi, dal punto di vista morale, questa transazione in verde e la transazione in rosso potrebbe sembrare molto diversa, perché basata sulla spiegazione che ti ho dato, la prima uno è un tentativo da parte di Alice di pagare Bob, mentre il secondo è un tentativo di Alice di frodare Bob e pagare le monete a se stessa. Ma da un punto di vista tecnologico, queste due transazioni sono completamente identiche. I nodi che stanno guardando questo, in realtà non hanno modo di dire quale sia la transazione legittima. Sto mettendo “legittimo” tra virgolette, perché è un giudizio morale che applichiamo ad esso, non è una distinzione tecnica, contro quale è il tentativo di doppia spendere. Potrebbe facilmente essere il contrario.

Ora, i nodi spesso seguono un’euristica per estendere il blocco di cui hanno sentito parlare per la prima volta sulla rete peer-to-peer, ma non è una regola solida. E in ogni caso, a causa della latenza della rete, questo potrebbe facilmente essere il contrario.

Così ora ci sono almeno alcune possibilità che il prossimo nodo che arriva a proporre un blocco estenderà questo blocco invece di questo. Oppure potrebbe essere che, anche se fosse un nodo onesto, Alice potrebbe provare a corrompere quel nodo o cercare di sovvertire il processo in vari modi. Quindi, per qualsiasi ragione, senza entrare troppo nei dettagli, diciamo che il prossimo nodo estende il blocco con la transazione rossa anziché quella verde.

Ciò significa che a questo punto, il prossimo nodo onesto ha molte più probabilità di estendi questo blocco invece di questo perché ora questa è diventata la più lunga catena valida.
02.03.13
So let’s say that after one more block, the situation looks like this. Now it’s starting to look pretty likely that this double-spend has succeeded, in fact, what might happen is that this ends up the long term consensus chain and that this block gets completely ignored by the network, and this is now called an orphan block, and this is an example of a successful double-spend. So now let’s look at this whole situation from Bob, the merchant’s point of view, and understanding how Bob can protect himself from this double-spending attack, it’s really gonna be a key part of understanding Bitcoin security. Quindi diciamo che dopo un altro blocco, la situazione appare così. Ora sta iniziando a sembrare abbastanza probabile che questa doppia spesa abbia avuto successo, in effetti, ciò che potrebbe accadere è che questo finisce con la catena del consenso a lungo termine e che questo blocco viene completamente ignorato dalla rete, e questo ora è chiamato blocco orfano e questo è un esempio di successo della doppia spesa. Quindi ora esaminiamo tutta questa situazione da Bob, il punto di vista del commerciante e comprendendo come Bob può proteggersi da questo attacco a doppia spesa, sarà davvero una parte fondamentale della comprensione della sicurezza di Bitcoin.
02.03.14
So let’s look at what happened here again. We have a couple of blocks in the block chain. And at this point, Alice broadcasts a transaction that represents her payment to Bob.

And so Bob is going to hear about it on the peer-to-peer network right here, even before the next block gets created. And so, Bob can do something even more foolhardy than what he did in the previous light which is, that as soon as he hears about the transaction on the peer-to- peer network, he can complete the transaction on the website and allow Alice to download whatever she’s downloading. That’s called a zero confirmation transaction.

Or, he could wait until the transaction gets one confirmation in the block chain, which means that at least some node has created a block and has proposed this transaction and that has gone into the block chain, but as we saw earlier,
Diamo un’occhiata a cosa è successo di nuovo qui. Abbiamo un paio di blocchi nella catena di blocchi. E a questo punto, Alice trasmette una transazione che rappresenta il suo pagamento a Bob.

E così Bob ne sentirà parlare sulla rete peer-to-peer proprio qui, anche prima che venga creato il blocco successivo. E così, Bob può fare qualcosa di ancora più temerario di quello che ha fatto nella luce precedente che è, che non appena sente parlare della transazione sulla rete peer-to-peer, può completare la transazione sul sito web e consentire ad Alice per scaricare qualsiasi cosa stia scaricando. Si chiama transazione di conferma zero.

Oppure, potrebbe aspettare fino a quando la transazione ottiene una conferma nella catena dei blocchi, il che significa che almeno un nodo ha creato un blocco e ha proposto questa transazione e che è entrata nella catena dei blocchi, ma come abbiamo visto prima,
02.03.15
even after one confirmation, there could be an attempt at a double-spend. So let’s say that this actually happens. If, as in the previous slide, the double-spend attempt succeeds, what Bob should do is to realize that the block that he though represented Alice paying him has now been orphaned, and so he should abandon the transaction. Instead, if it so happens that despite this double-spend attempt, anche dopo una conferma, potrebbe esserci un tentativo di una doppia spesa. Quindi diciamo che questo succede davvero. Se, come nella diapositiva precedente, il tentativo di doppia spesa riesce, quello che Bob dovrebbe fare è rendersi conto che il blocco che rappresentava se Alice lo stava pagando ora è rimasto orfano e quindi dovrebbe abbandonare la transazione. Invece, se succede che nonostante questo tentativo di doppia spesa,
02.03.16
the next block that’s generated turns out to extend the block that he’s interested in, now he sees that his transaction has two confirmations in the block chain.

Now he gets a little more confidence that his transaction is going to end up on the long term consensus chain.
il blocco successivo che viene generato si estenda per il blocco a cui è interessato, ora vede che la sua transazione ha due conferme nella catena a blocchi.

Ora ottiene un po ‘di più Confidiamo che la sua transazione finisca nella catena di consenso a lungo termine.
02.03.17
So let’s say there’s one more, and now there are three confirmations, in general, the more confirmations your transaction gets, the higher the probability that it is going to end up on the long term consensus chain. Because if you recall, the honest node’s behavior, that they will always extend the longest valid branch that they see, the chance that this one is going to catch up to this longer branch is now very minuscule, especially if only a minority of the nodes are malicious. Right, because, typically, the only reason that this double-spend attempt block would be extended at this point, is if the next node to be picked randomly was a malicious node, and then you’d need another malicious node and then another for this shorter branch to then become the longer branch. Supponiamo che ce ne sia un’altra, e ora ci sono tre conferme, in generale, più conferme ottiene la transazione, maggiore è la probabilità che finisca sulla catena del consenso a lungo termine. Perché se ricordi, il comportamento del nodo onesto, che estenderanno sempre il ramo più lungo che vedono, la possibilità che questo raggiunga questo ramo più lungo è ora molto minuscola, specialmente se solo una minoranza dei nodi sono dannosi. Giusto, perché, in genere, l’unica ragione per cui questo blocco di tentativo a doppia spesa verrà esteso a questo punto, è se il nodo successivo da selezionare casualmente fosse un nodo dannoso, e quindi sarebbe necessario un altro nodo dannoso e quindi un altro per questo ramo più corto diventa quindi il ramo più lungo.
02.03.18
In general, the double-spend probability decreases exponentially with the number of confirmations. So, if the transaction you’re interested in has received k confirmations, then the probability that this other transaction is going to end up on the long term consensus chain, goes down exponentially as a function of k. And the most common heuristic, that’s used in the Bitcoin ecosystem, is that you wait for six confirmations. There is nothing really special about the number six. It’s just a good trade-off between the amount of time you have to wait and your guarantee that the transaction you’re interested in ends up on the consensus block chain. In generale, la probabilità di doppia spesa diminuisce in modo esponenziale con il numero di conferme. Quindi, se la transazione a cui sei interessato ha ricevuto k conferme, allora la probabilità che questa altra transazione finisca nella catena del consenso a lungo termine, scende esponenzialmente in funzione di k. E l’euristica più comune, usata nell’ecosistema Bitcoin, è che aspetti sei conferme. Non c’è nulla di veramente speciale nel numero sei. È solo un buon compromesso tra la quantità di tempo che devi aspettare e la tua garanzia che la transazione a cui sei interessato finisca nella catena di blocco del consenso.
02.03.19
So let’s recap what we saw here.

Protection against invalid transactions, that is protection against a malicious node, simply making up a transaction to steal someone’s Bitcoins, is entirely cryptographic. But it is enforced by consensus, which means that if a node does attempt that, then the only reason that that transaction won’t end up in the launch group consensus chain is because a majority of the nodes are honest and will treat that transaction as invalid.

On the other hand, protection against double-spending is purely by consensus. Cryptography has nothing to say about this and true transactions that represent a double-spending attempt, kind of look identical from the prospective of signatures, and so on, but it’s the consensus that determines which one will end up on the long term consensus chain.

And finally, you’re never 100% sure that a transaction you’re interested in is on the consensus branch, but this exponential probability guarantee is pretty good. After about six transactions, there’s virtually no chance that you’re gonna go wrong.
Ricapitoliamo ciò che abbiamo visto qui.

Protezione contro transazioni non valide, cioè la protezione contro un nodo malevolo, semplicemente creando una transazione per rubare i Bitcoin di qualcuno, è interamente crittografica. Ma viene applicato per consenso, il che significa che se un nodo lo fa, allora l’unica ragione per cui quella transazione non finirà nella catena di consenso del gruppo di lancio è perché la maggioranza dei nodi è onesta e tratterà tale transazione come invalida.

D’altra parte, la protezione contro la doppia spesa è puramente per consenso. La crittografia non ha nulla da dire su questa e transazioni reali che rappresentano un tentativo di doppia spesa, un tipo di aspetto identico alla prospettiva delle firme e così via, ma è il consenso che determina quale si concluderà sulla catena di consenso a lungo termine.

E infine, non sei mai sicuro al 100% che una transazione a cui sei interessato si trovi sul ramo del consenso, ma questa garanzia di probabilità esponenziale è piuttosto buona. Dopo circa sei transazioni, non c’è praticamente nessuna possibilità che tu possa sbagliare.

[top]
© Arvind Narayanan – Assistant Professor of Computer science – Princeton University

W02.02
Consenso distribuito
W02.04
Incentivi e Prova del Lavoro