Double-Spent Attack

Any discussion of Blockchain is incomplete without discussing about double-spend attack mainly with cryptocurrencies. Double-spending happens when the same cryptocurrency coin is spent for two or more transaction at once. This type of attack requires a tremendous computational power and it is very likely to fail. However if successful, it may be profitable.


Assuming it is not a counterfeit paper note, in real world, same paper note can not be in two places at once. For example, Jimmy a rich millionaire visits his favorite local coffee shop to buy a $5 cup of coffee. In purchasing his coffee, Jimmy hands over the paper note to the shop owner. The owner, in accepting Jimmy’s $5 bill, can instantly confirm that Jimmy has paid the correct amount for the coffee. Jimmy therefore can not now spend that same $5 note elsewhere to make another purchase.




In case of digital transactions, they have to go through central authority (such as banks) to clear the electronic transfers. This is how in real world double-spend issue is easily addressed.




In digital currencies, however there is no actual physical relinquishing of a currency which creates the double-spending problem. Following is an example of double-spend attack in a digital currency called Richa Coin. The attack is split into four stages which are described below.

Stage 1 – Current

Assuming it is not a counterfeit paper note, in real world, same paper note can not be in two places at once. For example, Jimmy a rich millionaire visits his favorite local coffee shop to buy a $5 cup of coffee. In purchasing his coffee, Jimmy hands over the paper note to the shop owner. The owner, in accepting Jimmy’s $5 bill, can instantly confirm that Jimmy has paid the correct amount for the coffee. Jimmy therefore can not now spend that same $5 note elsewhere to make another purchase.



Stage 2 – Transfer

Jimmy agrees to sell the painting to Tom for 100 Richa Coins and Tom transfers 100 Richa Coins to Jimmy.


Meantime Tom creates an offspring of the Blockchain from Block 53 and transfers 100 Richa coins to a different account that he owns. This offspring does not broadcast the solution of his blocks to the rest of the Blockchain networks.





Stage 3 – Longest Chain

Jimmy on seeing transaction confirmation, ships the painting to Tom. While in the background, Tom on his private Blockchain succeeds in generating a longer Blockchain with reverse transaction back to him.



Stage 4 – Publish

Once Tom has the longest chain, he connects to the Blockchain network and publishes his blocks. All the nodes in the network agree on considering them as the valid ones because the offspring Blockchain is longer than the current valid Blockchain.


The offspring Blockchain now becomes the valid Blockchain and thereby reversing the transfer of 100 Richa Coins made to Jimmy. In the end Tom still has the 100 Richa Coins and the painting where as Jimmy has neither. This is an example of double-spend attack.





I hope this post now gives you an idea of how double-spent attack is executed and what is involved.

Types of Blockchain Consensus Algorithms

“A fundamental problem in distributed computing and multi-agent systems is to achieve overall system reliability in the presence of a number of faulty processes. This often requires processes to agree on some data value that is needed during computation”.


For safety reason and others, modern day cars come with various sensors, just look at Tesla which has 12 ultrasonic sensors providing it with 360 degree vision. Depending on the precision, there might be some variation in reading from these sensors and Auto pilot need to agree on when to apply brakes.


Similarly as a child, I used to play football (Soccer as they call in other countries) with my friends in a park. We didn’t have referee (centralized authority) to officiate our games or tell us what the score was. Each of us knew what the score was at any one time and we better have a very good reason to convince other players, if we wanted to change the score. Also we all knew the rules of the game to some extend but never the less we had some rules and all the players agreed to abide by them. If a foul was made, we would quickly make a decision to either act upon the foul or let the game continue and thereby constantly achieving a consensus between all of us. These two are example of a consensus problem being solved in our every day lives.


Blockchain is a new way of organizing data, it stores every change that has occurred and finally it arranges data in blocks. Blockchain only provides a very flexible and secure way of arranging data. Own it’s own it does not provide any sort of decentralization. Once you combine blockchain with a consensus algorithm, it then allows you for a successful operation of a fully or partially decentralized system. The Consensus algorithms address Byzantine Fault Tolerance (BFT), a solution to the Byzantine Generals’ problem for blockchains (I will explain BFT later on) in order to have a decentralized system.


The diagram below shows different consensus algorithms that have been implemented with blockchain. In this article I will only explain the most common consensus algorithms as it is a book on it’s own, if I have to explain all of them plus others not in the diagram.

Proof of Work (PoW)

Proof of Work (PoW) is currently the most common, one of the most robust consensus algorithm for blockchain technology and it is also the first blockchain consensus algorithm. It was devised by Satoshi Nakamoto for the use in the Bitcoin blockchain.


In PoW, Miners have to solve mathematically complex puzzles to produce block of transactions and get rewarded. After solving the puzzle, the result is then forwarded to other miners and verified by them before block is accepted on to the blockchain.


Mining requires highly specialized computer hardware to run the complicated algorithms. These specialized computers consume large amount of power. PoW runs on the concept of the “longest chain.” If most of the the miners are working on the same chain, that one will grow fastest and longest and therefore will be trustworth. The network is safe as long as more than 50% of the work being put in by the miners is honest. PoW addresses this by requiring a lot of computational power and lot of time to solve these puzzles, which in turn means high cost to run the infrastructure.


The 51% attack in a PoW blockchain is a situation whereby an organization is able to control majority of the network mining power. This will allow them to monopolize generation of new blocks and receiving rewards while preventing others from completing blocks. There is an app called, that tracks the cost of performing hourly 51 percent attacks on PoW based cryptocurrencies.

Proof of Stake (PoS)

Proof of Stake (PoS) is another category of consensus algorithm whereby a user can mine or validate block transactions depending on the user’s wealth, also defined as ‘stake’. Forgers is name given to the users who validate and create new blocks in the system. In PoW blocks are mined but in PoS, blocks are said to be ‘forged’ or ‘minted’.


From an algorithmic perspective, there are mainly two major types of PoS: chain-based PoS and BFT- style PoS. In chain-based PoS, the creator of a new block is chosen in a pseudo-random way where as in BFT-styple PoS validators are randomly assigned the right to propose block, however consensus is formed through a multi-round process where ever validator votes for a chain.


Some of the cryptocurrencies such as Ethereum are moving away from PoW to PoS because of the following reasons:

  1. Energy Efficiency – With PoS consensus you don’t need to use large amount of electricity in order to secure blockchain.
  2.  Security – Attackers must put their wealth on the line in order to attempt a 51% attack. If the attacker is the majority share holder on the network, then it will not be in his best interest to attach the network.
  3. Decentralization – In PoW network system, large mining-pools can work collectively to control over 51% of the network, leading to a very real threat of centralization. The reward in PoW system tends to go up exponentially compared to linear increase in reward for PoS based systems.


There is also a theoretical problem that may be encountered in PoS system called the “NOTHING AT STAKE” problem. This problem could happen if blockchain is forked. Basically validators don’t lose anything from behaving badly, you lose nothing by signing each and every fork, your incentive is to sign everywhere because it doesn’t cost you anything. Where as it will cost the validator a huge computational power (electricity cost), if they ever try to do that in PoW network.

Delegated Proof of stake (DPoS)

The Delegated Proof of Stake is the brain-child of Daniel Larimer, and is actually very different from PoS. DPoS, leverages the power of the stakeholders by voting for delegates who on their behalf validate transactions for the next block and in turn receive the reward. There are generally between 21–100 elected delegates in a DPoS system. If delegate does not behave or perform well, the stakeholders can vote them out and replace them with a better one. Therefore the major difference between PoS and DPoS is that PoS is a direct democratic and DPoS is representative democratic.

Proof of Authority (PoA)

In Proof of Authority consensus algorithm, it assigns a set of trusted nodes to process transactions and build new blocks. These new blocks need to be signed by the majority of the authorities. POA has a high throughput and is mainly optimized for private network.

Byzantine Fault Tolerance (BFT)

In distributed computing there is a classic problem of a system that must tolerate failure of one or more of its components and is usually explained with Byzantine generals. Famously described in 1982 by Lamport, Shostak and Pease, a city is surrounded by Byzantine army which is split into groups and each group is commanded by a general. Generals must decide in unison whether to attack or not. There is an added complexity that there might be one or more generals who are traitors and might try to prevent loyal generals from reaching an agreement of whether to attack or not. Generals are separated by distance and can only communicate via a messenger. Therefore generals need to have an algorithm that guarantees:

  1. All loyal generals decide upon the same plan of action.
  2. A small number of traitors can not cause the loyal generals to adopt a bad plan.

The generals are equivalent of nodes in a decentralized blockchain network, communicating and receiving information to the others via the blockchain network but unable to always trust it at a face value as they don’t know if any of those nodes have been compromised.

  1. Practical Byzantine Fault Tolerance (PBFT): The nodes collecting transactions, select a leader for their next block. Leader orders the transactions and broadcasts the list. Each node validates the transactions and broadcasts the calculated hash of the new block and. Once 2/3 of the nodes have the same hash, the new block is published. Currently in use by Zilliqa and HyperLedger.
  2. Federated Byzantine Agreement (FBA):FBA is another class of solutions to the Byzantine generals problem used by currencies like Stellar and Ripple. In FBA systems, each node does not have to be known and verified ahead of time, membership is open and control is decentralized. Nodes can choose whom they thrust and system wide quorums emerge from decisions made by individual nodes

Beginner’s Guide to Blockchain Technology – Part II

This is part II of the series and it will focus on concept called hashing.  I will use same metaphor as previous article to explain hashing. If we go back to our example of train, coupler is a mechanism used to connect carriages and engine of the train, as shown in the image below.


The coupler come in different shapes and sizes.Buffer & chain, Link & pin and Bell-and-hook are few example of couplers. Just like coupler for train, similar concept is used in Blockchain to connect blocks. The Blocks in Blockchain are linked to its immediate predecessor using hash. The first block in the Blockchain is called “Genesis” block or Block 0 and its link lies out in the system. The below diagram is a simplified version of how Bitcoin Blockchain looks like and generally Blockchains follow same pattern.


At this point you might be wondering, what is hashing and how is it useful in the whole Blockchain ecosystem. Worry not, I will try to explain it.


Hashing is a simply process of taking a variable length input and creating a fixed size output, which is sometimes also called as Digest. Just like different types of couplers for train, there are also different types of hash functions. Example are Murmur hash, CityHash, SHA256, xxHash and SHA-3.


Blockchain mainly uses cryptographic hash functions such as SHA256 and Keccak-256. Example of Blockchains using these functions are Bitcoin and Ethereum, respectively.



The main reasons for using cryptographic hash functions for Blockchain lies in its properties, which are:

  • Deterministic – each time you parse same input through the hash function, you will get same hash value.
  • Efficiency – for any given input, the hash function should be capable of returning the hash value quickly else the system is simply not efficient.
  • Pre-image resistance – given a hash value, it should be difficult to find its input value. It is not impossible to determine the original input from its hash function.
  • Collision resistance – two different inputs to a hash function cannot have same hash value.
  • Slight change to input – making a small change to the input will change the hash value completely. For example, just changing the first letter of the Iron Maiden song “The Trooper” to “the Trooper” using SHA256 hash function changes the hash value completely.


Input Digest
The Trooper DB934DFF3B19B23DD77EA52DDE8A0DBB8654F1902827CA8D6633D939B8B7C29A
the Trooper E414332ED44FB59942899C6AF443CC89CF392BD112964BAFA7E5C3E2CB4A3D39


Just to cap this article off, let’s say a malicious attacker changes a data in block 1 of the Blockchain. Because of the properties of cryptographic hash functions, any slight change made in block 1 will change the hash value stored in block 2 and this will result in changes in block 3 and so on and so forth. Therefore it will become very hard for the malicious attacker to compute an alternate chain from Block 1 which will catch-up with and overtake the one true chain.


More to follow.

Don’t ignore response codes, they do tell a story about your system

On a dark, gloomy day in Melbourne with rain pouring down our office windows, the team and I were debating whether we should test AWS S3 or not for our new architecture. After a bit of healthy debating, we agreed to run a performance test against the new architecture that leverages AWS Cloudfront and S3 functionality. The objective of the test was to check if we configured Cloudfront and S3 correctly, and also to see if they can handle anticipated static content load.  At this point, you might say, “Well, Cloudfront can handle 100,000 requests/sec per distribution and S3 can handle 5500 GET requests/sec, why the need?” Well, so did we, until we discovered an issue none of us anticipated, and if left unfixed, would have impacted end user experience (and potentially sales).


To test this scenario, we copied all the static content from our existing production infrastructure to the new infrastructure and used the current CDN to work out the load profile we needed to generate the right load. Once this activity was done, I quickly created a JMeter script and generated the load using Octoperf.


Following is the HTTP response code pie chart Octoperf generated after the test run. Nothing too exciting, except I have 7.6% HTTP 404 responses and remaining 92.4% HTTP 200 responses.



At this point, I started thinking, “I don’t see ~7.5% 404’s for static content in production, and since the data was copied from production and I am using static content URLs from production, something doesn’t feel right.” I raised my observation with the rest of the team, and within an hour of our investigation, we found out the real issue.


The real issue was related to how Windows and Linux interpret the file path. The existing architecture runs on Windows OS, and Windows, by default, is not case-sensitive for the file paths, whereas Linux (S3 bucked mounted) is, by default. What this means, from a customer point of view, is that they will receive a 404 for product images (just as an example) as Linux OS will try to resolve the image path to a location in the S3 bucket, but, because of the case-sensitive issue, the path won’t exist and will therefore return a 404 to the customer, and that won’t be a good experience. For example, the following is the response I got for one of the static requests from Cloudfront. Notice the “N” in the file path — the real folder in the S3 bucket ends with “n” and NOT “N.” Therefore, I get a 404, whereas Windows is not case-sensitive and treats them the same, and I get the right response.



During your performance testing, make sure you are also looking at the response codes, as they can tell you a lot about your system. Also, AWS S3 and Cloudfront were able to handle the anticipated load.

Beginner’s Guide to Blockchain Technology – Part I

I find people use the term ‘Blockchain technology’ to mean different things (i.e Bitcoin/altcoin blockchain, smart contracts etc) which can sometimes be confusing. However most of the time what they are talking about is distributed ledger. Considering Blockchain technology is disrupting industries from voting to banking, having a basic knowledge of it will be useful. Therefore this post is first in the series of posts explaining what is Blockchain technology.


The Blockchain is a digital ledger for storing data and the most famous implementation of this technology is the cryptocurrency called Bitcoin. This post will focus on two basic terms used in Blockchain technology, namely transactions and blocks.


Before we talk about the terms, let’s take a detour and talk about carriage trains. At this point you might be wondering, what has carriage train got to do with Blockchain. Well it has got nothing to do with Blockchain but it is a metaphor for explaining what transactions and blocks are to Blockchain technology.


At its core the passenger train has two components, namely locomotive (engine) and carriage/coach.  All the components are connected via a coupler and there are different types of couples such as Buffer & chain, Link & pin and Bell-and-hook coupler.  In part II, I will explain how coupler fits into the picture and what concept in Blockchain is similar to coupler.


The carriage is normally of fixed size and has a limit of how many passengers it can accommodate. To get on the carriage, the passengers have to buy a ticket and ticket will generally have information regarding what time the train departs, platform number and carriage number. If there are any seats available then they will get a confirmation and they can board the train else they have to go on a waiting list/wait for next train.


This same principle applies to Transactions and Blocks. So if we go back to Blockchain, transaction is similar to passenger. However transaction can also be something else, just like different types of trains such as freight train and passenger train. Similarly transaction can be a payment or medical record. Therefore you can define Blockchain transaction as a small unit of task that is stored in records. Generally there are two types of transactions, confirmed and unconfirmed. Confirmed transactions go into the blocks where as unconfirmed don’t. This is similar to getting a confirmed ticket to board the train else you have to be on waiting list.


The block in Blockchain technology is similar to carriage in train. Basically block is a record of confirmed transactions and different type of Blockchain implementations will have a maximum size for a block. For example, Bitcoin block has a maximum size of 1MB. Each new block will have a reference to the previous block in the blockchain except for the first block. Like in the train we have engine, the first block in Blockchain is called Genesis block.


The following picture depicts transactions & blocks in the Blockchain. The block data is where the transactions reside. In Part II, I will explain how hashing is used to connect blocks.


The Crypto Mistakes Newcomers Make

I got into cryptocurrency just over an year or so ago and during that period, I made a few mistakes. As I learnt more about crypo world and talked to other cryptonians (new & old), I found that those mistakes are quite common among newcomers. Therefore this blog post is my take on the most common mistakes newcomers makes when they get into the world of cryptocurrency.


Expecting big profit by mining

Those days are gone when you could mine a coin and make a big profit. Unless you can get ultra cheap electricity (even free), mining is simply not worth it.


Leaving coins on an exchange

Lots of newcomers make a mistake of buying and leaving coins on an exchange. For few years now, a few exchanges have gone busted/crashed or been hacked (i.e. Mt. Gox, Bitfinix). So if you don’t want to loose your crypto then move it somewhere safe (i.e cold storage, paper wallet, hardware wallet). If I plan on trading the coin in short term then I am happy to keep in an exchange else I will move it to a wallet.


Not holding your private keys

Going by point two above, if you are leaving your coin on an exchange then you don’t hold the private keys to your wallet. It is someone else who hold it and you are trusting them with your coin.


Not doing your own research

You are spending your well earned money purchasing crypotcurrency, so make sure you are doing your own research and not relying on someone else. If you do have someone, get their view but still do your own research on cryptocurrency that you would like to buy.


Transferring to wrong crypo-wallet

Make sure you are double checking the wallet address you are sending the fund to and also matches the right crypocurrency. Don’t send TIPS to Doge. Once transaction is made, it is irreversible so SLOW DOWN and make sure it is the right wallet you are sending to.


Use 2 Factor authentication

2FA is an extra layer of security that help reduce digital crime and internet fraud.   Therefore there is no excuse to not enable, whenever appropriate. Make sure you take a backup/save the restoration code incase you forget your 2FA.


Keep hardcopy of everything

Make sure you keep a hardcopy of everything which may include your password, restoration code, private key and save them somewhere secure. Should your computer crash or get compromised, you have backup copy to restore it.


Challenges of Relaunching Community Cryptocurrency


This posted is based on my experience of the challenges encountered when we tried to relaunching a dormant cryptocurrency. So if you are planning on reviving one, you are going to deal with these challenges to some extend. Most of these challenges you would have encountered in one situation or the other, even if you have never been involved in cryptocurrency.

  1. Security:
    • Lot of existing altcoin wallets have not been updated with right security patches for a very long time. Therefore, one of the main challenge will be to make sure the existing code base/libraries is updated with right security patches. In our case, last time the code/external libraries was updated was in 2015.
  1. Team communication, structure & collaboration:
    • If team members are co-located and solely working on coin, it is easy to build rapport and trust among the members. However this becomes challenging when you have team members scattered around the world and most of them have families and day job. Since you do not meet each other when performing the task, relying on each other to progress tasks a stronger level of trust is needed. In our case, we are using applications such as Slack, Trello, Github & Discord for communication and collaboration. Also we have a vetting process for recruiting new team members to make sure they fit in the team.
    • Another challenge you might face is around team structure and decision making. What kind of team structure will you be following? Hierarchy, flat or some other. If you are working on a community based cryptocurrency, should you be engaging rest of the community for any kind of decision making or should only handful of members make decision about the coin?
    • Currently we are a small team so communication, collaboration and decision making is easy to manage. However, I am looking forward to seeing what challenges lie ahead as the core team grows.
  1. Marketing strategy:
    • You might encounter challenge around marketing strategy which will include social media, exchanges, community engagement, roadmap and so forth. If you can liaise with the old team and get access to existing market strategy (if there is one) then it will make your life a lot more easy. Otherwise you might face same challenges as we did, such as:
        1. Social media channels & website: We didn’t have much luck getting right access to the existing social media channels/forums from the old team. This meant we had to start all over again by setting up new social media channels and website. It also meant publishing posts/ articles on different social channels/forums to let existing community know about us, what we are doing with the coin, where we are heading (roadmap), where they could get more information about the coin and how they can come onboard with this new project.
        2. Exchanges: Like social media, we had to reach out to existing exchanges to let them know about the relaunch so they could update appropriate links. Same time to increase our coin exposer, we reached out to new exchanges. Some of these exchanges required us to pay certain amount of fiat/cryptocurrency inorder to be listed and others it was online voting. Incase for voting, we had to reach out to the wider community via social medium to get their help.
        3. Community engagement: While you work on getting new community members (i.e. via using airdrops, twitter etc) on board you will also need to make sure you are engaging with existing members to get their buy in into what new team is trying to achieve. Which means actively engaging in answering their questions, comments and concerns. It could be anything from “How to” guide, hard fork, roadmap, exchanges, old vs new channels, mining and even trolls. All of this requires time and commitment from the team. There is a lot to the community engagement and I am still learning.
  1. Testing:
    • Cryptocurrency has varying challenges when it comes to testing. You have the functional and non functional side of it. The following are some of the challenges you will have to deal with when involved in testing. Depending on your situation, you might focus on specific type of tests for the relaunch while other ones later down the track.
        • Security
        • Performance/Scalability/Volume
        • Wallet functionality on different OS & devices
        • Wallet synching testing
        • Wallet backup functionality
        • Wallet upgrade/new installation etc
        • Miner testing (ASIC, GPU/CPU mining with different # of core/memory setting/disk iops)
        • and so forth
    • I normally use “FEW HICCUPPS” heuristics when I don’t have requirement and I need to do exploratory testing.  Testing all these areas can be time consuming, if done manually so you want to leverage automation. I are in the process of moving towards automation testing so it free us with exploratory testing and other things. Where possible try leverage cloud/virtualization option for testing. For example we use VMWare/Virtualbox/AWS for new wallet installation/upgrade and other functionality testing.


I hope this post gives you enough insight into potential challenges you might be dealing with when relaunching a community cryptocurrency.

Is Endurance Testing Dead?


Recently I posted a question on linkedin “Performance Specialists” group regarding soak(/endurance) test and whether it is required, if team wants to achieve daily deployment into production. I have to say it was an interesting discussion with different views. That discussion lead me to write this post about my own thought on the topic. Before we get to that, let’s first define what Endurance test is and its objectives.


What is Endurance testing?

Endurance or Soak testing is a type of load test that normally runs for extended period of time (few hours to days) while the system under test is subjected to a production like load(or anticipated load) to understand/validate its performance characteristics.


Why conduct Endurance test?

Endurance test is conducted to answer different kinds of questions such as:


  • Does my application performance remain consistence or degrade over time? For example, your application might have a resource leak such as memory or connection leak which manifests slowly over time and impacts your system.
  • Is there any interference that was not accounted for and could potentially impact system performance? Example application backups/VM backups/batch jobs/third party jobs running at different time of day that might not have been accounted for in other tests but do impact system performance.
  • Are there any slow manifesting problems that have not been detected by other types of test? Other then the resource leaks, you could also detect problems which are due to sheer volume of data. Example of such an issue is full table scan on the database. As the data grows, the database queries start to slow down because they are doing full table scan. Similarly, running out disk space because too much data is being written to log file which in turn causes the application to crash.


Now let’s get back to the question of whether endurance testing is required or not, if you want to achieve daily deployment.


My personal view is that there is no simple answer to conducting endurance test and for how long to achieve daily deployments. Would you want to conduct an endurance test that lasts for 12 hours, if you are making a text change? Probably, NOT. What about if there is a rewrite of a function that makes call to database and third party api? Probably, YES.


In the end it will all come down to the level of risk that team/stakeholders are willing to take to deploy code into production, standby their decision and how quickly they can mitigate performance issues in production without impacting brand image, sales, user experience and so forth.


However, I don’t believe Endurance testing is dead. There is a place for it in the continuous deployment world. It just needs a little bit more thinking and planning (different approach may be), if you want to achieve daily deployments. You can run soak test overnight, analyze and share results in the morning with rest of the team or conduct it over the weekend. Another approach could be that the team reviews which changes they believe are of low risk and therefore best candidate for deployment during the week without requiring an endurance test. While high risk changes undergo endurance testing over the weekend before deploying into production, the following week.


Finally there needs to be right monitoring and alerting tools in place to identity performance related issues (be it in production or non prod). Any issue identified in production also need to be fed back to performance engineering team. This will help them improve their performance testing process.



Reflecting on WOPR26



Over the years, I have attended a few testing conferences and Workshop on Performance and Reliability (WOPR) conference stands out for me due to its unique format.


The WOPR conference is generally limited to 20-25 seats and lasts for three days. This year the 26th WOPR was held in Melbourne (Australia) and the theme of the conference was “Cognitive Biases in Performance Testing”. We had 16 participants from around the world attending it.


A few things about WOPR that stood out for me when compared to other conferences are:

  • Real life experience report
    • Based on the theme, participants present real life experience report to the rest of the group. If you want to learn more about experience report then refer to this link.
    • After my first day, I ended up updating my report. It was written more like a “How To” presentation rather than an experience report. However because of the unique format, I had time to hear others experience report, reflect and update my report before presenting.
    • Some of the biases we discussed and presented at WOPR26 were:
      • Anchoring bias
      • Expectation bias
      • Attentional bias
      • Dunning-Kruger effect
      • Automation bias
      • Confirmation bias
      • Pro-Innovation bias


  • Open season and Q&A
    • The experience report is used as a vehicle to stimulate conversation between participants. You get to hear their own real life experiences and also get feedback on your own experience. This tends to lead to more questions, comments and new threads on the topic.
    • There is no end time for Q&A and open season sessions. The session will continue as long as there are questions, new threads and comments.
    • To facilitate Q&A and open season, facilitator uses K-cards. They are Green, Yellow and Pink. This helps the group stay focus on the topics related to the theme of the conference.
      • Green card is for new thread
      • Yellow card is for question/comment (used in same thread)
      • Pink card is for important question (put me on the top of the stack)


  • WOPR dinner night
    • It is the highlight of the conference. This is where you get to chill out with rest of the group after long day at the conference. You get to learn something, build new relationships and above all, you get to chill out with like minded people and enjoy wonderful dinner.


  • Conference atmosphere & corridor talks
    • During breaks you might have different groups discussion various things, revisit what was discussed during session, catch up with old friends and also introduce yourself. This helps with conference atmosphere because everyone gets comfortable with one other.
    • The conference atmosphere also helped me overcome my public speaking jitters as it was my first time presenting in a peer conference.


The attendees at WOPR26 were Paul Holland, Eric Proegler, John Gallagher, Tim Koopmans, Harinder Seera, Andy Lee, Aravind Sridharan, Diane Omuoyo, Scott Stevens, Sean Stolberg, Srivalli Aparna, Derek Mead, Joel Deutscher, Ben Rowan, Stuart Moncrieff and Stephen Townshend.


Also would like to thank Stuart Moncrieff for taking pictures and sharing it with us.

Bitcoin Crypto Throughput


You might have heard in news, websites, word of mouth or any other communication channel that the bitcoin transaction rate is somewhere between 3 to 7 transactions/sec.


If you are like me, you want to understand where this number come from or how it is calculated. So here it is. Before I get to the calculation, we need to define few terms and they are:


Transaction — is a transfer of bitcoin from one address to another. Example, Harinder transferring bitcoin to Jimmy inorder to buy bitcoin ebook.


Block — a group of transactions, marked with a timestamp and fingerprint of the previous block.


Block chain — is a list of validated blocks, each linked to its predecessor all the way to the genesis block.


If you want to remember them easily, just think of them as train, carriage & passengers.

Transactions is your passengers, carriage contain passengers (in this case it is block) and train consists of series of connected carriages (in this case it is blockchain). As shown below.



From the above graph we can see that the block size is getting towards 1MB and average transaction size is hovering around 505bytes. So…


How many transactions/block?

Formula: Transactions/block = Block size/average transaction size.

Average transactions/block = 1000000 Bytes/505 Bytes => 1980


What is the bitcoin throughput?

Formula: Transactions/sec = Transactions per block/ block time (in seconds)

Note: A new bitcoin block is on average discovered every 10 minutes. Therefore,

Transactions/sec = 1980/(10*60) = 1980/600 = 3.3


There you have it, now you know how bitcoin cryptocurrency throughput is calculated.

Probability Distribution Code in JMeter


“In probability theory and statistics, skewness is a measure of the asymmetry of the probability distribution of a real-valued random variable about its mean. The skewness value can be positive or negative, or undefined.”  (source wikipedia)



“In probability theory and statistics, the exponential distribution (also known as negative exponential distribution) is the probability distribution that describes the time between events in a Poisson point process, i.e. a process in which events occur continuously and independently at a constant average rate.” (source wikipedia)


When designing application simulation model for performance testing you will come across scenarios that will require you to use different probability distribution to emulate correct production behavior. For example, average # of items per order or think time between pages.


The code below is an example of how you can create a skewed or exponential distribution in JMeter.


Skewed distribution code

min = VALUE; //update this value to minimum value expected in the distribution
max = VALUE; //update this value to maximum value expected in the distribution
bias = VALUE; //update this to a value against which  the distribution should be biased toward
influence = 1; //[0.0, 1.0] – 1 means 100% influence
rnd = Math.random()*(max-min)+min;
mix = Math.random()*influence;
result = rnd *(1 – mix) + bias * mix;


NOTE: The above code is from stackoverflow and I don’t remember the link to it. If you do, please let me know you I can refer to it.


Exponential distribution code

Avg = VALUE; //update this value to reflect mean value for the distribution

MIN = VALUE; //update this value to minimum value expected in the distribution

result = (long)(-(double)Avg*Math.log(Math.random()))+MIN;


Example (Exponential distribution):
MIN = 1;
Avg = 2.5;
result = (long)(-(double)Avg*Math.log(Math.random()))+MIN;
If the above code is executed for 200 iterations/thread, it will generate the values depicted in the histogram below. More iterations executed, better the distribution will be. For testing, two threads were used.

NOTE: If you want to have a hard max boundary, add an if condition in the code to check against the MAX value.


Example (Skewed distribution):

min = 1;

max = 10;
bias = 3;
influence = 1;
rnd = Math.random()*(max-min)+min;
mix = Math.random()*influence;
result = rnd *(1 – mix) + bias * mix;

If above code is executed for 200 iterations/thread, it will generate values depicted in the histogram below. More iterations executed, better the distribution will look be. For testing, two threads were used.



Use beanshell sampler to generate the value and save it in a variable. Pass variable into the loop controller to control it. Below is the code in beanshell sampler.






1: Make sure you run a few tests to get the distribution right to reflect what is happening in production.

2: If you have a better code to generate probability distribution be it exponential or any other kind, I would love to  know.

3: Use JSR223 sampler than beanshell sampler. I have noticed that beanshell sampler throughput is less compared to JSR223 sampler.