W03.03 – APPLICAZIONE DI SCRIPT BITCOIN


WEEK 3
Mechanics of Bitcoin

Learn how the individual components of the Bitcoin protocol make the whole system tick: transactions, script, blocks, and the peer-to-peer network. Scopri in che modo i singoli componenti del protocollo Bitcoin fanno funzionare l’intero sistema: transazioni, script, blocchi e la rete peer-to-peer.

Joseph Bonneau
Postdoctoral Research Associate – Princeton University

Sezione 03.03 – Applicazione di Script Bitcoin
03.03.01
So we’ve just invested the effort to understand Bitcoin scripts a little bit, but I haven’t really shown you what’s so cool about Bitcoin scripts yet. It turns out, you can do quite a lot of neat things that will justify the complexity of having the scripting language instead of just specifying public keys.

So one of them is to do an escrow transaction.

So this is a classic situation online. Alice and Bob wanna do business with each other, maybe Alice has just won some online auction and is ready to buy some things from Bob.

Now Alice wants to pay Bob in Bitcoin for Bob to send some physical goods back to Alice. But we get into this problem where Alice doesn’t want to pay until after she has received the goods but Bob doesn’t want to send the goods until after Bob has been paid.

So what can we do about that? There is quite a nice solution in Bitcoin that’s actually used quite heavily in practice. Which is to introduce a third party and do escrow transactions.
Quindi abbiamo appena investito gli sforzi per comprendere un po’ gli script Bitcoin, ma non ti ho ancora mostrato cosa c’è di così interessante negli script dei Bitcoin. Si scopre che puoi fare un sacco di cose che giustifichino la complessità di avere il linguaggio di scripting invece di specificare solo le chiavi pubbliche.

Una di queste è fare una transazione di deposito a garanzia.

Quindi questa è una classica situazione online. Alice e Bob vogliono fare affari tra di loro, forse Alice ha appena vinto alcune aste online ed è pronta a comprare alcune cose da Bob.

Ora Alice vuole pagare Bob in Bitcoin affinché Bob invii alcuni beni fisici ad Alice. Ma entriamo in questo problema in cui Alice non vuole pagare fino a quando non ha ricevuto la merce, ma Bob non vuole inviare la merce fino a dopo che Bob è stato pagato.

Quindi cosa possiamo fare a riguardo? C’è una bella soluzione in Bitcoin che è in realtà utilizzata in modo piuttosto spesso nella pratica. Che è quello di introdurre una terza parte e fare le operazioni di deposito a garanzia.
03.03.02
So how does this work?

Well, Alice is gonna send the money not directly to Bob, but create a MULTISIG transaction that requires two or three people to sign in order to redeem the coins.

And those three people are going to be Alice, Bob, and Judy, who is a judge, who is going to come into play in case if there’s any dispute. So, Alice will create this transaction for the desired amount. With that two out of three MULTISIG between Alice, Bob and Judy. Alice signs the transaction redeeming some coins that she owns and this will get published in the block chain. So at this point these coins are held in escrow between Alice, Bob, and Judy. And any two of them can specify where the coin should go.

So Bob will be satisfied after that happens that he’s safe sending the goods over to Alice. So he’ll mail them or deliver them physically.
Quindi come funziona?

Bene, Alice invierà i soldi non direttamente a Bob, ma creerà una transazione MULTISIG che richiede la firma di due o tre persone per riscattare le monete.

E quelle tre persone saranno Alice, Bob e Judy, che è un giudice, che entrerà in gioco in caso di controversie. Quindi, Alice creerà questa transazione per l’importo desiderato. Con quel due su tre MULTISIG tra Alice, Bob e Judy. Alice firma la transazione riscattando alcune monete che possiede e questo verrà pubblicato nella catena di blocco. Quindi a questo punto queste monete sono tenute in deposito tra Alice, Bob e Judy. E ognuno di loro può specificare dove deve andare la moneta.

Quindi Bob sarà soddisfatto dopo che ciò accadrà che è sicuro di inviare la merce ad Alice. Quindi li spedirà per posta o li consegnerà fisicamente.
03.03.03
Now what we hope happens in the normal case is that Alice and Bob are both honest.

In which case the goods arrive on time, they’re what Alice was expecting, and she wants to actually release the money from escrow so that Bob can spend it.

So if this happens, Alice and Bob can both sign a transaction redeeming the funds from escrow and sending them to Bob. And the great thing here is that Judy never had to get involved at all. There was no dispute. And so, Alice and Bob were able to sign, and that represents two out of the three people required by the MULTISIG transaction.
So in the normal case, this isn’t that much less efficient than Alice just sending Bob the money. It requires just one extra transaction on the block chain.

Now, what would have happened if Bob didn’t actually send the goods or if he tried to send them and they were lost in the mail, maybe he sent the wrong size?

Alice now doesn’t wanna pay Bob, cuz she thinks that she got cheated and she wants to get her money back.
So Alice and Bob are definitely not both going to sign a transaction that releases the money to Bob. But Bob’s also not going to sign a transaction that releases the money back to Alice because he may be denying Alice’s claim of fraud here.
Ora quello che speriamo accada nel caso normale è che Alice e Bob sono entrambi onesti.

Nel qual caso le merci arrivano in tempo, sono ciò che Alice si aspettava, e lei vuole effettivamente rilasciare il denaro dal deposito a garanzia in modo che Bob possa spenderlo.

Quindi, se questo accade, Alice e Bob possono entrambi firmare una transazione riscattando i fondi dal deposito a garanzia e inviandoli a Bob. E la cosa bella qui è che Judy non ha mai dovuto essere coinvolta. Non c’era nessuna disputa. E così, Alice e Bob sono stati in grado di firmare, e questo rappresenta due delle tre persone richieste dalla transazione MULTISIG.

Quindi, nel caso normale, questo non è molto meno efficiente di quello di Alice, ma solo di inviare a Bob i soldi. Richiede solo una transazione extra sulla catena di blocchi.

Ora, che cosa sarebbe successo se Bob non avesse effettivamente spedito la merce o se avesse tentato di spedirli e fossero stati persi nella posta, forse ha inviato la taglia sbagliata?

Alice ora non vuole pagare Bob, perché pensa di essere stata imbrogliata e vuole riavere i suoi soldi.
Quindi Alice e Bob non stanno sicuramente firmando una transazione che rilascia i soldi a Bob. Ma Bob non ha intenzione di firmare una transazione che restituisce i soldi ad Alice perché potrebbe negare la pretesa di frode da parte di Alice
03.03.04
So now we’re going to have to get Judy involved. Judy is going have to decide which of these two people was honest, which one doesn’t deserve the money.

And if Judy decides that Bob cheated, Judy will be willing to sign a transaction along with Alice sending the money from escrow back to Alice. So Alice and Judy can get together, that’s two of the three required signatures, and Alice can get her money back.

And of course Judy would have the opportunity to rule in the other direction.

If Judy thinks that Alice is at fault here and Alice is simply refusing to pay when she should, Judy can sign a transaction with Bob sending the money to Bob.

So Judy essentially has full control here, but the nice thing is that she won’t have to be involved unless there’s a dispute.
Quindi ora dovremo coinvolgere Judy. Judy sta andando a decidere quale di queste due persone è stata onesta, quale non merita i soldi.

E se Judy decide che Bob ha tradito, Judy sarà disponibile a firmare una transazione insieme ad Alice inviando il denaro dal deposito in garanzia a Alice. Quindi Alice e Judy possono stare insieme, sono due delle tre firme richieste e Alice può riavere i suoi soldi.

E ovviamente Judy avrebbe l’opportunità di decidere nella direzione opposta.

Se Judy pensa che Alice abbia colpa e Alice si rifiuta semplicemente di pagare quando dovrebbe, Judy può firmare una transazione con Bob che invia i soldi a Bob.

Quindi Judy ha essenzialmente il pieno controllo, ma la cosa bella è che non dovrà essere coinvolta a meno che non ci sia una disputa.
03.03.05
Another cool application is what are called green addresses.

So the problem here is that Alice wants to pay Bob and Bob’s offline. So Bob can’t go and look at the block chain to see if the transaction that Alice is sending is actually there. Maybe Bob simply doesn’t have time to go and look at the block chain and wait for the transaction to be confirmed.

Remember that normally we want a transaction to be in the block chain, and be confirmed by six blocks, which takes up to an hour before we trust that it’s really in the block chain.
Un’altra applicazione interessante è ciò che vengono chiamati indirizzi verdi.

Quindi il problema qui è che Alice vuole pagare Bob e Bob è offline. Quindi Bob non può andare a dare un’occhiata alla catena dei blocchi per vedere se la transazione che Alice sta inviando è effettivamente lì. Forse Bob semplicemente non ha tempo di andare a vedere la catena di blocchi e aspettare che la transazione venga confermata.

Ricorda che normalmente vogliamo che una transazione sia nella catena di blocchi e che sia confermata da sei blocchi, che richiede fino a un’ora prima che ci si possa fidare che sia davvero nella catena di blocchi.
03.03.06
Or maybe Bob is just in a Faraday cage and doesn’t have any connection to the Internet at all, so Bob is never gonna be able to check the block chain. This would be the case, say, if Bob is the person selling food on the street. So to solve this problem, of being able to send money using Bitcoin without the recipient being able to access the block chain, we have to introduce another third party, which is the bank.

So Alice is gonna talk to her bank, and say, hey, it’s me, Alice. I’m your loyal customer. Here’s my card or my identification. And I’d really like to pay Bob here, could you help me out?

And the bank will say, sure, I’m gonna deduct some money out of your account and draw up a transaction from one of my green addresses over to Bob.

So notice that this money is coming directly from the bank to Bob. Some of the money of course in a change address is going back to the bank maybe.

But essentially the bank is paying Bob here from a bank controlled address. That bank controlled address comes with a guarantee that that money will never be double spent. So as soon as Bob sees that this transaction is signed by the bank, if he trusts the bank, if he trusts the bank’s guarantee not to double spend the money, he can accept that, that money will eventually be his when it’s confirmed in the block chain. Now, notice that it is not a Bitcoin enforced guarantee, this is a real world guarantee, so Bob has to trust that the bank in the real world Is doing a business, and cares about their reputation, and won’t double spend for that reason.

And the bank will be able to say, you can look at my history, I’ve been using this green address for a long time, and I’ve never double spent. Therefore, I’m very unlikely to do so in the future.

Of course if the bank ever does double spend, trust in this whole system is gonna collapse pretty quickly.

And in fact, the two most prominent online services that implemented green addresses, which were Instawallet and Mount Gox, both ended up collapsing. So, for that reason, green addresses aren’t used as much in Bitcoin as when they were first proposed. People were really excited and thought this was a great idea and a way to do payments more quickly and without accessing the block chain. Now people are actually quite nervous about this idea and they’re worried that this puts too much trust in the bank. As a result, this isn’t used that much in practice even though it’s a cool protocol.
O forse Bob è solo in una gabbia di Faraday e non ha alcuna connessione a Internet, quindi Bob non sarà mai in grado di controllare la catena di blocchi. Questo sarebbe il caso, per esempio, se Bob è la persona che vende cibo per strada. Quindi per risolvere questo problema, di poter inviare denaro usando Bitcoin senza che il destinatario sia in grado di accedere alla catena di blocchi, dobbiamo introdurre un’altra terza parte, che è la banca.

Quindi Alice parlerà alla sua banca e dirà, hey, sono io, Alice. Sono il tuo cliente fedele. Ecco la mia carta o il mio identificativo. E mi piacerebbe davvero pagare Bob, potresti aiutarmi?

E la banca dirà, certo, che dedurrò del denaro dal tuo conto e redigerò una transazione da uno dei miei indirizzi verdi a Bob.

Quindi noti che questo denaro proviene direttamente dalla banca a Bob. Alcuni dei soldi, naturalmente, in caso di indirizzo di cambiamento tornano in banca forse.

Ma essenzialmente la banca sta pagando Bob qui da un indirizzo controllato dalla banca. Questo indirizzo controllato dalla banca viene fornito con la garanzia che quel denaro non sarà mai speso doppiamente. Quindi, non appena Bob vede che questa transazione è firmata dalla banca, se si fida della banca, se si fida della garanzia della banca di non spendere doppiamente i soldi, può accettare che, quel denaro sarà alla fine suo quando sarà confermato nella catena di blocchi. Ora, nota che non è una garanzia applicata a Bitcoin, questa è una garanzia del mondo reale, quindi Bob deve fidarsi che la banca nel mondo reale sta facendo affari, e si preoccupa della loro reputazione, e non raddoppierà la spesa per questo motivo.

E la banca sarà in grado di dire, puoi guardare la mia storia, sto usando questo indirizzo verde da molto tempo, e non ho mai raddoppiato. Pertanto, è molto improbabile che lo faccia in futuro.

Naturalmente se la banca dovesse raddoppiare la spesa, la fiducia in questo sistema crollerebbe molto rapidamente.

E infatti, i due servizi online più importanti che hanno implementato gli indirizzi verdi, che erano Instawallet e Mount Gox, entrambi finirono per crollare. Quindi, per questo motivo, gli indirizzi verdi non vengono utilizzati tanto in Bitcoin quanto quando furono proposti per la prima volta. Le persone erano davvero entusiaste e pensavano che questa fosse una grande idea e un modo per fare pagamenti più velocemente e senza accedere alla catena di blocchi. Ora le persone sono piuttosto nervose riguardo a questa idea e sono preoccupate che questo faccia troppa fiducia nella banca. Di conseguenza, questo non è usato molto nella pratica anche se è un protocollo interessante.
03.03.07
A third example I’d like to show you, is a way to do efficient micro-payments. So this set up here is that Alice is a customer who wants to pay Bob a low amount of money for some service that she’s gonna use.

So maybe in this case Bob is really Alice’s wireless service provider, and Alice wants to pay a small amount of money for every minute that she talks on her phone.

Now you can see why a solution that won’t work here is to simply create a Bitcoin transaction every minute that Alice speaks on the phone, that’s gonna create too many transactions. There will be too many transaction fees and nobody is happy about that. The simple solution here is to create a new, low value transaction every minute that Alice talks on the phone. So if she talks for two hours you might might need over a hundred transaction.

The problem that you’re gonna get into with that system is that those transactions might all be very low value and that transaction fees might really kill you. So if the value of each one of these transactions is on the order of what the transaction fees are, you’re going to be paying quite a high cost to do this.

So what we would like is if you can combine all these small payments into one big payment at the end. And there’s actually a neat way to do this with serial micro-payments. So how is this gonna work? So we start with a MULTISIG transaction that pays the maximum amount Alice would ever need to spend to a MULTISIG transaction requiring both Alice and Bob to sign to release the coins.

Now after the first minute that Alice has used the service or the first time Alice needs to make a micro-payment, she signs the transaction spending those coins that were sent to the MULTISIG address sending one coin to Bob and returning the rest to Alice.

After the next minute of using the service, Alice signs another transaction, and this time she’s paying two coins to Bob and sending the rest to herself.

And notice that these are just signed by Alice, they haven’t been signed by Bob yet.

Alice is gonna keep sending these transactions to Bob every minute that she uses the service.

Notice that these aren’t getting published in the block chain. They’re just getting sent from Alice to Bob. Eventually Alice is gonna finish using the service. In which case she’ll tell Bob, I’m done, you can cut off the service, I’m not gonna pay you anymore. And Bob is going to say, great I’ll disconnect your service. And I’m gonna take that last transaction that you sent me, and I’m also gonna sign that and publish that to the block chain.

So since each transaction was paying Bob a little bit more and Alice a little bit less, whatever the final one is is what Bob is gonna choose to actually redeem, paying him for the service that he was provided and giving the rest of the money back to Alice.

And the great thing is that all those transactions that Alice signed along the way, won’t make it to the block chain, Bob doesn’t have to sign them, they’ll just get discarded.

So technically all of these transactions are double spends. So unlike the case with green addresses, where we were specifically trying to avoid double spends with a strong guarantee. With this micro-payment protocol, we’re actually generating a huge amount of potential double-spends. Although in practice, if both parties are operating normally, Bob will never sign any transaction but the last one, in which case the block chain won’t actually see any attempt at a double-spend.
Un terzo esempio che vorrei mostrarti è un modo per effettuare micro-pagamenti efficienti. Quindi questo è che Alice è un cliente che vuole pagare a Bob una piccola somma di denaro per un servizio che lei userà.

Ipotizziamo in questo caso che Bob è il fornitore di servizi wireless di Alice, e Alice vuole pagare una piccola somma di soldi per ogni minuto che lei parla sul suo telefono.

Ora puoi capire perché una soluzione che non funziona è semplicemente creare una transazione Bitcoin ogni minuto che Alice parla al telefono, che creerà troppe transazioni. Ci saranno troppe commissioni di transazione e nessuno ne è felice. La soluzione semplice è creare una nuova transazione di basso valore ogni minuto che Alice parla al telefono. Quindi se parla per due ore potresti avere bisogno di più di cento transazioni.

Il problema con cui ti troverai in quel sistema è che queste transazioni potrebbero avere un valore molto basso e che le spese di transazione potrebbero davvero ucciderti. Quindi, se il valore di ognuna di queste transazioni è nell’ordine di ciò che sono le commissioni di transazione, pagherai un costo piuttosto elevato per fare alla fine.

Così quello che vorremmo fare è riuscire a combinare tutti questi piccoli pagamenti in un unico grosso pagamento alla fine. E in realtà c’è un modo pulito per farlo con micro-pagamenti seriali. Allora, come funziona? Quindi iniziamo con una transazione MULTISIG che paga l’importo massimo che Alice avrebbe mai dovuto spendere per una transazione MULTISIG che richiede sia ad Alice che a Bob di firmare per rilasciare le monete.

Ora dopo il primo minuto che Alice ha usato il servizio o la prima volta Alice ha bisogno di effettuare un micro-pagamento, firma la transazione spendendo quelle monete che sono state inviate all’indirizzo MULTISIG inviando una moneta a Bob e restituendo il resto ad Alice.

Dopo il minuto successivo di utilizzo del servizio, Alice firma un’altra transazione, e questo volta che sta pagando due monete a Bob e invia il resto a se stessa.

E nota che questi sono appena firmati da Alice, non sono ancora stati firmati da Bob.

Alice continuerà a inviare queste transazioni a Bob ogni minuto che usa il servizio .

Notare che questi non vengono pubblicati nella catena di blocchi. Sono appena stati inviati da Alice a Bob.
Finalmente Alice finirà di usare il servizio. Nel qual caso lei lo dirà a Bob, ho finito, puoi interrompere il servizio, non ti pagherò più. E Bob sta per dire, fantastico disconnetterò il tuo servizio. E prenderò l’ultima transazione che mi hai mandato, e lo firmerò anch’io e lo pubblicherò nella catena dei blocchi.

Siccome ogni transazione stava pagando Bob un po ‘di più e Alice un po’ meno, qualunque sia il l’ultimo è quello che Bob sceglierà per riscattarlo, pagandolo per il servizio che gli è stato fornito e restituendo il resto dei soldi ad Alice.

E la cosa bella è che tutte quelle transazioni che Alice ha firmato lungo la strada, non sono andate a finire nella catena dei blocchi e Bob non deve firmarli, verranno semplicemente scartati.

Tecnicamente tutte queste transazioni sono doppie. Quindi, a differenza del caso degli indirizzi verdi, in cui cercavamo specificamente di evitare le doppie spese con una forte garanzia. Con questo protocollo di micro-pagamento, stiamo generando una quantità enorme di potenziali doppie spese. Anche se in pratica, se entrambe le parti funzionano normalmente, Bob non firmerà mai alcuna transazione, ma l’ultima, nel qual caso la catena di blocchi non vedrà alcun tentativo di una doppia spesa.
03.03.08
Now there’s one more detail here, if you stop and think for a second. Which is somewhat tricky to deal with, what if Bob never signs the last transaction? He may just say I’m happy to let the coin sit there in escrow forever. In which case maybe the coins won’t move but Alice will be out the full value that she paid at the beginning. So there’s a very clever way to avoid this problem using a feature that I described earlier but haven’t explained yet, which I’ll need to introduce now. And that feature is called Lock Time. So to avoid this problem before the micro-payment protocol can even start, Alice and Bob will both sign a transaction which refunds all of Alice’s money back to her, but is locked until some time in the future.

So before Alice signs the first transaction paying for the first minute of service, she’s gonna wanna get this refund transaction from Bob and be able to hold that in her hand. And know that if she makes it to time t and Bob hasn’t signed any of the small transactions that Alice has sent, Alice can publish this transaction which refunds all of the money directly to her.

So what does it mean when I said it’s locked until time t, how do we do that?
Ora c’è un altro dettaglio qui, se tu fermati e pensa per un secondo. Il che è alquanto complicato da gestire, e se Bob non firmasse mai l’ultima transazione? Potrebbe solo dire che sono felice di lasciare che la moneta resti lì per sempre nell’impegno. In tal caso, forse le monete non si muoveranno, ma Alice sarà fuori dal valore completo che ha pagato all’inizio. Quindi c’è un modo molto intelligente per evitare questo problema utilizzando una funzionalità che ho descritto in precedenza ma che non ho ancora spiegato, che dovrò presentare ora. E questa caratteristica si chiama Lock Time. Per evitare questo problema prima che il protocollo di micro-pagamento possa anche iniziare, Alice e Bob firmeranno entrambi una transazione che rimborsa tutti i soldi di Alice a lei, ma è bloccata fino a qualche tempo nel futuro.

Prima che Alice firmi la prima transazione che paga il primo minuto di servizio, vorrebbe ottenere questa transazione di rimborso da Bob e riuscire a tenerla in mano. E sappi che se lei arriva al momento t e Bob non ha firmato nessuna delle piccole transazioni che Alice ha inviato, Alice può pubblicare questa transazione che rimborsa tutto il denaro direttamente a lei.

Quindi cosa significa quando ho detto che è bloccato fino al tempo t, come lo facciamo?
03.03.09
Well you’ll remember when we looked at the metadata in Bitcoin transactions that there was this lock_time parameter which I had left unexplained.

It’s quite simple actually, if you specify any value other than zero for the lock time, that tells miners don’t publish this transaction until this point in time. The transaction is invalid and can’t be published, until either a specific block number, or a specific point in time based on the timestamps that are being put into blocks.

So this is a way of preparing a transaction that can only be spent in the future if something else doesn’t happen. And it works quite nicely. And that micro-payments protocol as a safety valve for Alice to know that if Bob never signs, eventually she’ll be able to get her money back.

So hopefully those examples have shown you that you can do some pretty neat stuff with Bitcoin scripts. Those are just three examples that are the most practical and simple to explain but there are a lot of other things that people have looked in to doing. One of them is multi-player lotteries, which is a very complicated, multi-step protocol, with a lot of transactions, a lot of transactions with different lock times. There are escrows in case people cheat. But you can actually run a fair multi-party lottery over Bitcoin using just the scripting language, which is really neat.
Beh, ricorderete quando abbiamo visto i metadati nelle transazioni Bitcoin che c’era questo parametro lock_time che non avevo ancora spiegato.

In realtà è piuttosto semplice, se specificate un valore diverso da zero per il tempo di blocco, che dice ai minatori di non pubblicare questa transazione fino a questo momento. La transazione non è valida e non può essere pubblicata fino a un numero di blocco specifico o a un punto temporale specifico in base ai timestamp che vengono inseriti nei blocchi.

Si tratta di un modo di preparare una transazione che può essere speso solo in futuro se qualcos’altro non accade. E funziona abbastanza bene. E quel protocollo sui micro-pagamenti è una valvola di sicurezza per Alice per sapere che se Bob non firmerà mai, alla fine sarà in grado di riavere i suoi soldi.

Spero che quegli esempi ti abbiano mostrato che puoi fare qualcosa di carino con gli script di Bitcoin. Questi sono solo tre esempi che sono i più pratici e semplici da spiegare, ma ci sono molte altre cose che le persone hanno cercato di fare. Una di queste è la lotteria multi-player, che è un protocollo multi-step molto complicato, con molte transazioni, molte transazioni con tempi di lock diversi. Ci sono degli averi nel caso in cui la gente imbroglia. Ma in realtà puoi gestire una lotteria multipartitica su Bitcoin usando solo il linguaggio di scripting, che è davvero pulito.
03.03.10
There are other things. Like you pay some one if they know the pre-image of a hash, so you can try to pay somebody to do some brute force work for you. And there are a couple of neat protocols for different people to get their coins together and mix them so that it’s harder to trace who owns which coin. And we’ll talk about that a lot more in our lecture on anonymity.

So the general term for contracts like this is smart contracts, which means that the contracts actually have some technical enforcement of something that used to be enforced through things like laws or courts of arbitration.

So it’s a really cool feature of Bitcoin that we can use scripts, and we can use the miners, and we use transaction validation to enforce things like escrow or the micro-payment protocol. And you don’t have to rely on any centralized authority to actually enforce these contracts.

Now the whole field of smart contracts goes quite deep. There’s a lot more smart contracts people would like to apply, a lot of which you unfortunately can’t build with the Bitcoin script today. So the Bitcoin script is fairly limited in the types of things that you can address. There’s a lot of smart contracts people wish they could build that either are impossible or nobody has come up with the way to do it yet. But you can do quite a few interesting smart contracts with the Bitcoin script.
Ci sono altre cose. Come se pagassi qualcuno se conoscono la pre-immagine di un hash, quindi puoi provare a pagare qualcuno per fare del lavoro di forza bruta per te. E ci sono un paio di ottimi protocolli per persone diverse per mettere insieme le loro monete e mescolarle in modo che sia più difficile rintracciare chi possiede quale moneta. E ne parleremo molto di più nella nostra lezione sull’anonimato.

Quindi il termine generico per contratti come questo è un contratto intelligente, il che significa che i contratti hanno effettivamente una qualche applicazione tecnica di qualcosa che era stata applicata attraverso cose come leggi o tribunali arbitrali.

È una caratteristica davvero interessante di Bitcoin che possiamo usare gli script, e possiamo usare i minatori, e usiamo la convalida delle transazioni per far rispettare cose come l’impegno o il protocollo di micro-pagamento. E non è necessario affidarsi ad alcuna autorità centralizzata per applicare effettivamente questi contratti.

Ora l’intero campo dei contratti intelligenti è piuttosto profondo. Ci sono molti più contratti intelligenti che la gente vorrebbe applicare, molti dei quali sfortunatamente non riesci a costruire con lo script Bitcoin oggi. Quindi lo script Bitcoin è abbastanza limitato nei tipi di cose che puoi affrontare. C’è un sacco di contratti intelligenti che le persone vorrebbero poter costruire o che sono impossibili o che nessuno ha ancora trovato il modo di farlo. Ma puoi fare alcuni interessanti contratti intelligenti con lo script Bitcoin.

[top]
© Joseph Bonneau – Postdoctoral Research Associate – Princeton University

W03.02
Script Bitcoin
W03.04
Blocchi Bitcoin