 So this work, which is joint work with Juan Garay and Ángel Oscarllas, we study properties of the Bitcoin protocol in a setting where the hardness of proof of work changes over time to accommodate for changes on the number of parties. It is based on previous work where we study the protocol in a static setting where the number of parties was fixed. And the core of the Bitcoin protocol was abstracted and for the first time we provided a proof and formal analysis on its properties. We also showed how to build applications on top of the Bitcoin backbone protocol like on sensors and of course a robust transaction ledger as in Bitcoin. There were follow-up works with model variants and extensions where additional properties of the blockchain were studied or different network models like the partial sensors model and also on the next talk we'll see simulation based security. Now all the above works assume a fixed target which means a fixed hardness in the proof of work puzzle and this is not how Bitcoin works. So in reality Bitcoin employs a target calculation mechanism and every now and then it adjusts the hardness of the proof of work to accommodate for changes on the number of participants. And in this work we provide a formal analysis in this dynamic setting. We also show how properties we proved in the static setting carry over to the dynamic setting and there is also a new analysis methodology which simplifies all the proofs in the static case. So the model we work on is the fully synchronized model so time is divided in rounds. All parties that participate in the protocol are equivalent and the power of the adversary is expressed by the number of parties it controls. The honest parties act independently but the parties controlled by the adversary can collaborate. Communication is done by broadcast and the adversary can send a message only to a subset of the parties and it can also reorder a party's messages which as we see later it gives him certain powers. And also the setting is anonymous so you cannot even decide if two messages come from the same party. So we are going to study a distributed algorithm and the main object is the blockchain so this is the data structure that each party has in its private memory and we're going to focus on two ingredients of the blockchain. The first is that it's hard to generate a block so the hash value of a block has to be less than some target value t. Note here that by calibrating, by adjusting the target value t you can adjust the hardness of the proof of word, the hardness of generating a block. Another ingredient is that for a block to extend the previous one it has to contain its state, it has to contain its hash value. So both of these properties make the blockchain tamper resistant so what we should keep from these properties is that the adversary cannot really manipulate existing blockchains to change the data on some blocks he should change all subsequent blocks and so it takes a lot of work or discover a collision of the hash function and we model the hash function as a random oracle. Also recall that you can adjust the hardness of the puzzle by adjusting the target t and so without loss of generality we're going to think of the inverse of the target as the difficulty of reducing a block. So this is the algorithm so every party participating on this has in its memory a blockchain and what it does when the round starts is the following. First it listens to the network for blockchains that were broadcast by other parties in the previous round. From the collection of these chains it's going to pick the longest one or the heaviest one so actually the first longest one and this is where order matters because the adversary has a longest chain and it's longer than the parties then it can force the party to adopt the adversarial chain. After choosing the longest chain the party now is trying to extend it and this is really modeled by a Bernoulli trial where the probability of success depends on the target t or that the block should have. And finally if the party is successful in this Bernoulli trial or if it just got a longer chain from the network in the end this new chain is broadcast to all the users. So let's visualize this with an example. So initially everybody starts with an empty chain but later on the non-sparking might compute a block so a white block is a block computed by the non-sparking. Later on maybe on a single round both the non-sparking end the adversary compute a block so in this case a fork is created so the asterisk is supposed to mean that you have non-sparkings on both of these chains the upper one and the lower one. Another thing that can happen is that the adversary can compute a block and not announce it to anybody so he can keep it to himself and then say later on when an honest party extends the upper chain he can broadcast it at the same round and maintain the fork similarly here or the honest parties, two honest parties may compute a block on the same round and this way they just fork by themselves. So this can continue this like so, so in the end you can have a picture like this so what I want to take from this picture is that this is not a good picture so we have three chains of longest length in the end with honest parties on all of them and the two upper ones have a very large fork so this would keep parties from having an agreement on what the block chain is they have completely different views and it makes it hard to build a cryptocurrency on top of this so such a picture will be much better so we still have a fork but it's very small so this is a property we want from Bitcoin and in particular if we are building a transaction ledger what we want is that if at any point some transaction is confirmed by an honest party then from that point onwards every honest party will find this transaction at the same position in the ledger so this property we call persistence another property is that well you want the transactions eventually to get into the ledger you don't want the adversary to have the power to stop the transaction from appearing but we will be proving properties of the block chain so we want to express these properties as properties of the block chain so the sister property of persistence is common prefix property which basically says that any two parties the block chains of any two parties share a large common prefix or otherwise if two parties prune a few blocks from the end then they end up with the same chain another property is the chain quality property so this means that if you look at a large enough sequence of blocks in the block chain then you will find among them enough blocks that come from honest parties they're not going to be all adversarial and finally the chain growth property so in Bitcoin this basically says that if the honest parties compute 100 blocks then their chains will have grown by 100 blocks the adversary cannot stop that so now let me review the proof of a common prefix property in the static case where you have a static fixed number of parties so as we've seen what we don't want we don't want large forks so here is a large fork and let's see what bad things this fork implies what bad events so the key observation is that if you have if some block is complete is computed at a uniquely successful round so at every round the parties engage those Bernoulli triads if at a round exactly one honest party computes a block then we call this round uniquely successful so the observation is that if say the fifth block is computed at such a round a uniquely successful round then any other fifth block in any other chain should have been computed by the adversary so after this observation the proof is almost done because what you can do is you can pair up honest blocks with adversarial ones so for each block that is computed by an honest party at a uniquely successful round you can find a corresponding adversarial block and after setting up some rounds appropriately you end up with the fact that a large fork implies that in a certain set of rounds the adversary got as many solutions as the uniquely successful solutions of the honest parties so the moral of this is that if the proof of work is really hard so in every round you have a small probability of success then your successful rounds is almost as many as your uniquely successful rounds and so if the adversary has less than half the power then this is a low probability you're just comparing two binomials so the chain of bounds as exponentially as more probability and you're done so however in the dynamic execution if you just keep the target fixed and the number of parties starts increasing then your block production rate is going to get closer to 1 the probability of a successful round is going to get closer to 1 and the persistence breaks and the comma prefix breaks well the proof breaks but also if you have a lot of honest parties you think singularity solutions on any round they're going to fork by themselves and also the problem is block production rate drops to 0 because then well liveness is here and no new blocks get generated and in reality Bitcoin strives to maintain a constant block production rate about 1 block per 10 minutes and the way it does that is exactly by adjusting the target T and if you think about it you'll realize that you want to do this in a distributed manner so what can you do so a natural thing that comes in mind is to set the target of the next block by looking at your previous how fast your previous blocks were computed so we'll see details about that later for the moment note that in this setting now with each block we associate a weight, a difficulty which is 1 over T so the harder to compute the block the higher the difficulty it is so the higher its weight in the chain and now parties follow the heaviest chain instead of just the longest one and so let's see the comma prefix how much of the comma prefix prove carry over to this setting so again let's see a long fork but this time let's think of the chains as a continuous accumulation of difficulty and let's see the same observation hold so imagine some difficulty at some point 8.3 on a chain so let's say the difficulty on point 8.3 on a chain was computed at a uniquely successful round it belongs to a block that it was computed at a uniquely successful round then difficulty 8.3 at any other chain has to be provided by the adversary it has to be in a block that was computed by the adversary so as before this allows you to show that a large fork implies an inequality between the difficulty accumulated in uniquely successful rounds by the honest parties and difficulty accumulated by the adversary but then how do you show that this is a low probability event so in the static case this was easy we were just comparing two binomials so chain of bound would give you the low probability of this event in the dynamic case now you really have two martingale sequences so if you condition if you stop at any time execution you still have those Bernoulli triads but the probability of success depends on the actions of the adversary it depends on the targets you have and those depend on the actions of the strategy of the adversary so it's not clear how to proceed you have to prove the target calculation works and keeps the probability of success about constant okay so let's see now how Bitcoin actually does achieves that so what it does is that at every some constant number of blocks that's AM blocks you have to recalculate the target so if you have a chain with a multiple of M number of blocks then you have to calculate the target for the next block and informally what it does is that it looks at the last time blocks so this period is called an epoch it looks at how fast the epoch was computed and if it was computed faster than you want you just make the proof of work harder if it was computed slower you make it easier and if you think about it there is a very reasonable thing to do so you say okay I look at M blocks and I want my block production rate to be F so every block should be computed in about one over F rounds so M blocks I should get them in about M over F rounds but say my epoch was finishing delta rounds then because when block production rate is small the F and T are linearly related approximately it makes sense to set a new target to increase it by a factor of delta over M over F so if it was finished 1.1 times faster you're going to increase the target by decrease the target by 1.1 now interestingly if this is just you do there is an attack so Bajak I think in 2013 posted a paper on E-print with an attack in this case in which basically the adversary ignores what the honest guys do and he just builds an epoch by himself finishes an epoch by himself with fake timestamps so the timestamps show that it's like the epoch has finished very quickly which would mean that the next target should be really small so the next proof of work should be really difficult with a very high difficulty and then if the adversary is very lucky and he succeeds in computing a single block very quickly he can create a very large fork so if you do some calculations this can be shown to work with constant probability but Nakamoto knew this so this is not what Bitcoin does so Bitcoin uses the same formula exactly with the only difference that if this formula says that you should increase your target by a multiple larger than 4 then it says you should stop there so you shouldn't do more than 4 or you shouldn't decrease your target by more than 4 that's it so this stops Bajak's attack because you can't, you should wait longer until the hardness has increased by as much as you would like the problem now is, that arises is that if the parties increase very quickly in say a period of an epoch then target calculation won't catch up so you increase by a large factor and you are adjusting the target like they're increased by 4 in the end you're going to fall behind and the question then is what kind of security can you prove in this situation and it seems that you need to assume some bounds on the fluctuation of the number of parties and the theorem we prove is like the following so we say that if in a certain number of rounds the number of parties do not fluctuate too much by factor of lambda then all the properties you want from Bitcoin still hold under of course assumption that the adversary still has a minority of the hash power and that your initial parameters will set properly so how does the proof go in a very high level so we show that if you start with good parameters then every chain ever adopted by an honest party enjoys the following properties one it was never abandoned by honest parties for too long so every now and then an honest party was trying to extend it from these then you can show that the time stamps are about accurate so the adversary has not produced has not managed to make you adopt a block which has a very which has a time stamp that is way off of the recreation time of the block and then using the above you can show that actually the calculation points are very good so they give you a target which is close to the ideal one which in turn gives you that all the blocks in the chain you adopted have good targets good targets meaning that the block production rate for this target is where you want it to be so to sum up you can show that any block in a chain adopted by honest parties has accurate time stamps and good targets and from these then the old proof in the static case can carry over to the dynamic case so now how do you implement how do you follow this proof roadmap so the problem here is that these statements are kind of interleaved together in a proof so one uses the other and if you try to do a probabilistic analysis it seems that you condition you create conditional probability probability space is that you don't understand the structure very well and the way out of this was to define the notion of a typical execution so we define a set of typical executions which basically contains all executions where our random variables are concentrated around their expectation and having defined the typical set of execution and proved that it contains almost all executions under the probability measure then we can do proofs in a combinatorial manner without considering probabilities at all so for example for the static case where you know the probability of a success of the block production rate is constant is f you can just use the chain of bound to say that any sequence that has a number of successes concentrated around the expectation is typical but how do you do this in the dynamic case so to appreciate the difficulty let us consider the following game so suppose you are playing a game with an opponent and at each round the opponent is choosing a probability p and then you flip a coin you engage in a Bernoulli trial which has a success probability p and if there is a success you gain 1 over p so this corresponds to the difficulty that you compute when you are successful or if you lose with probability 1 minus p you lose 1 over 1 minus p so this defines a Martin game but note that the adversary is deterministic you can think of it as deterministic but it's also adaptive so at every round the adversary can look at the past and decide what's the new probability in your Bernoulli trial so how do you define the typical set for this one so the problem is that so how large a set of rounds should you look into the probabilities could be very small and maybe you should look at the largest set of rounds and the solution gives the following result which you can find in a survey by MacDarmin called Concentration which we, well we shouldn't we shouldn't pass all of this right now but let's look at the final statement what this says is that if you have a Martin game like in the stochastic process before the game we just saw then what you can say is that the event that you don't have concentration and you have small variance small sum of conditional variances is very small in other words either you have large variance or you have concentration so using this you can define the typical set and then the proof at a very high level goes as follows so you show that if you start with a good execution but somewhere in the way your block production rate is not where you want it to be then concentration was violated why the variance was small which is a small probability event by this year so finally just some pointers for future work is that so our bounds we get are not good for the real-world parameterization of Bitcoin so it would be interesting to improve the analysis and get some tight analysis another thing which is interesting is to study it in the case where in the partial synchronous model where there is a delay on the messages and another question is to study the target recalculation mechanism one could think other things he could do to recalculate the target so is the best one so that's all thank you thank you for being here