Don't kill me if I'm about to ask something stupid. But I'm very noobish in this whole crypto world, and I'm terribly fascinated about its technology.
So just for education purposes I've decided to build my own blockchain following more or less the bitcoin principles (ECC keypair generation using the secpbk1 curve, SHA256 as hashing algo, dynamic diff based on the timestamp of the previous block, p2p connectivity etc..). But I've came to a point where I'm pretty confused about the blockchain's wallet itself.
For what I've learned so far, each transaction has to be signed by a wallet. So my transactions has basically three fields: input, outputs and id. Since the user's wallet signs the outputs field of the transaction, this can't be changed anymore without being signed again by the same private key that belongs to the public key contained in the input field, how can I reward the miners?
If I got it right, the miner creates a transaction signed somehow by the chain using the fee in the outputs field, or by asking the chain itself to generate and sign a special reward transaction for that miner.
The guide that I was following was using the second approach, and was generating a blockchain wallet each time the program was executed on a client. This approach left me perplexed:
wouldn't a client generate a new wallet for "his" blockchain each time it goes back online? If so, wouldn't this create a mess on the transactions signed on the chain? Since each miner (therefore peer) signing its own reward would use a different blockchain wallet than the other peers? Wouldn't this lead to any problems?
The first one that I might think of, is that if we generate a new blockchain wallet that signs rewards for miners, each peer would create a different wallet, so wouldn't this lead to many "ghosts" wallets in the chain, that spits out rewards tokens from nowhere? Is this supposed to happen?
For what I think is definitively more straightforward to use the fee amount to reward the miner, but this doesn't solve my doubts at all. Since the outputs of the transactions are signed upon creation, how could the peer initiating the transaction know upfront the possible miner who finds the block? And if he can't know it, how could possibly the miner "extract" its reward without tampering the transaction itself? Of course it could create a new transaction, and add that to the block. But who would sign that transaction? From where those reward tokens come?
And if the answer is not to generate a new wallet each time, where could you possibly store that very first private key of the chain's wallet where no one can see it, but still be able to use it, without having to put a server in the middle?
Which in my opinion breaks the whole decentralized concept and would add a single point of failure.
I've also implemented a transactions pool, that automatically filters out invalid (tampered) transactions, whenever a miner requests a sub set of them to stamp in a block. But does this mean that the miner for that only exception can tamper the transaction since it'll be "forged" in the block? So who gives a *** if it was tampered once it got in the chain? MEEEEEH that doesn't sound nice at all.
I'm terribly confused, and I'm dreaming key pairs at night. Please help me.
wouldn't a client generate a new wallet for "his" blockchain each time it goes back online? If so, wouldn't this create a mess on the transactions signed on the chain? Since each miner (therefore peer) signing its own reward would use a different blockchain wallet than the other peers? Wouldn't this lead to any problems?
You don't say what problems you think this will lead to. I can't think of any.
For what I think is definitively more straightforward to use the fee amount to reward the miner, but this doesn't solve my doubts at all. Since the outputs of the transactions are signed upon creation, how could the peer initiating the transaction know upfront the possible miner who finds the block? And if he can't know it, how could possibly the miner "extract" its reward without tampering the transaction itself?
The simplest solution to this is for the transaction itself to just contain its inputs and outputs. The fee is the difference between the total inputs and the total outputs.
The miner just includes the transaction in the block of transactions they mine. They also add one additional transaction into the block, sending themselves the reward. Obviously, they know their own destination address. Every participant who receives the newly-mined block checks to make sure this transaction is valid (just as they check every other one) and doesn't claim a larger reward than is allowed.
And if the answer is not to generate a new wallet each time, where could you possibly store that very first private key of the chain's wallet where no one can see it, but still be able to use it, without having to put a server in the middle?
Typically in a file on the local disk. The private key isn't really needed anyway -- you only need it to send. You don't need it to mine or report. So it can be prompted for or decrypted only when actually needed.
Of course it could create a new transaction, and add that to the block. But who would sign that transaction? From where those reward tokens come?
The usual rule is that the reward transaction has no inputs, one output, and no signature. The tokens come from the pool of unclaimed miner reward tokens which can be finite or infinite depending on the blockchain's design. (For bitcoin, this pool is finite.)
I have a form on my website and my customers send message to me with this form. Sometimes they write their credit card number on the message. So this is really critical. I want to mask these credit card numbers. But of course card numbers don't come on a regular basis.
Example 1: 1111222233334444
Example 2: 4444 3333 2222 1111
Example 3: 4444-3333-2222-1111
Example 4: 4444 - 3333 - 2222 - 1111
Example 5: 4444--3333--2222--1111
So I can mask for example 1, 2 and 3. But if there are more than one space or dash between numbers I can't.
And this is my last regex:
preg_replace("/(?:\b| )([3456]\d{3})([ -]+){0,1}\d{4}([ -]+){0,1}\d{4}([ -]+){0,1}(\d{0})/", "$1********$2", $a1);
And results for this regex:
Result 1: 4444********1111
Result 2: 4444******** 1111
Result 3: 4444********-1111
Result 4: 4444******** - 1111
Result 5: 4444********--1111
So what should I do in regex? Thanks.
May I suggest that you separate validation of your credit card number from the presentation of that number to your users via the UI? Assuming you have only stored valid credit card numbers, then it is probably safe to assume that every number has at least 8 digits. If so, then you can just use a blanket regex to only display the first 4 and last 8 digits:
$cc = "4444--3333--2222--1111";
echo preg_replace("/(\d{4}).*(\d{4})/", "$1********$2", $cc);
4444********1111
Demo
You might point out that this puts the same number of stars in between every card number. But, then again, this is a good thing, because it makes it even harder for a snooper to fish out what the real unmasked number actually is.
Edit:
Here is a smarter regex which will star out the middle portion of any number, leaving only the first and last 4 characters visible:
$cc = "4444--3333--2222--1111";
echo preg_replace("/(?<=.{4}).(?=.{4})/", "*", $cc);
4444**************1111
Note that this solution would not remove anything from 11114444 as a theoretical input.
How to mask credit card number mask in a text [with regex]?
Don't.
Sometimes they write their credit card number on the message.
They really shouldn't. Don't encourage this behavior. It is not PCI compliant:
What is PCI Compliance?
The Payment Card Industry Data Security Standard (PCI DSS) applies to companies of any size that accept credit card payments. If your company intends to accept card payment, and store, process and transmit cardholder data, you need to host your data securely with a PCI compliant hosting provider.
When you accept credit card data via a website, do so using an approved service provider like Stripe, PayPal, BlueSnap, SecurionPay, etc. These services are immensely popular not because it's hard to make payment systems, but because they're hard to make right (and legal). They all have PHP API's, so you can have people enter credit card data that you never see, and still charge them for amounts that you agree upon.
For example, if you were using Stripe and you wish to inform your customer what credit card they signed up with, their card object has a last4 property that gives the last four digits of the card: At this point you never knew the full credit card number, and you didn't even have to consider whether giving the first four and the last four was a security violation.
Further guidelines:
Never store electronic track data or the card security number in any form
While you may have a business reason for storing credit card information, processing regulations specifically forbid the storage of a card’s security code or any “track data” contained in the magnetic strip on the back of a credit card.
The card security number, called by many acronyms including CVV2, CID, and CSC, is the three digit number on the back of Visa/MasterCard/Discover cards or the 4 digit number on the front of American Express cards. It is designed to provide a way for merchants to know whether a customer authorizing a transaction over the phone or via the Internet actually has the card in their possession. This approach only works if the security code is never stored with the card number. Electronic storage makes this easy. You simply do not create a field for the security code. For paper storage, you need to redact (cross out with a dark pen to make unreadable) the security code after you successfully process the transaction and before you store a paper authorization form. [...]
Clearly you should store neither security codes nor track data purposely. But, you need to make sure you don’t store it inadvertently as well. To do this, be certain to use only approved hardware and software. [...]
Make sure all electronic storage of credit card account numbers is encrypted and all paper storage is secured
[...] Electronic storage of credit card numbers is also common if, for example, you process recurring or repeat transactions. If you do this, you need to make certain that you never store these files unencrypted. You need to make certain that any electronic storage is encrypted using a robust encryption algorithm. That way, if your computer is stolen or if someone in your office gains unauthorized access, you have some level of protection for the credit card numbers.
There are many service providers that offer secure storage—either as a standalone service or as part of a payment processing package. These services typically provide you with a “Token” for a card number they store. You can store the token in any unsecured file. When you’re ready to process a payment, you simply send the service provider the token and it retrieves the full card number for the sole purpose of processing the payment. (It’s technically more complicated than that, but you get the idea.) Just be certain to use a PCI DSS Verified provider [...]
Check the next regex \b([3-6]\d{3})(?: *-* *\d{4}){2} *-* *(\d{4})\b.
I have been tasked to "verify" the length of a U.S. Banking Institution ACCOUNT NUMBER for a web app I'm developing. I cannot find anything through SOF, Google, Fed reserve etc that outlines an account number standard length that we have in the United States. For the record I believe this is futile.
If someone could point me to any official documentation on the web, or has an example regular expression, or knows if there is a standard that exists, I would appreciate it greatly.
ADDED:
What would interest me even more since the response is overwhelming that their is no standard....has anyone ever run into a bank account number that is not completely "numeric"\
ADDED:
Thanks to everyone and their responses. Due to having no standard in the US, we are not going to enforce a length check, and we are going to store the number as a varchar due to the fact that it may be possible that a bank may assign alpha characters in their account numbers. Seems 99.999999% unrealistic in our view, but no standard means we will accept alpha characters and run the check on the account number to verify if it works or not. Thanks again all!
There is no standard for US banks' account numbers.
IBAN is not used in the US.
There is a limit for ACH transactions (4-17 digits), but not all transactions have to be ACH.
And yes, the US banking system is antiquated.
I'm looking at a DW (Data Warehouse) of 38 different systems at a bank and the length of account varies widely depending on the product. Several of the systems have alphabetic characters in the account numbers. This is probably irrelevant since they are special types of customer accounts like brokerage accounts and other things which aren't accessible through ACH - you need to specify what kind of account you're interested in. If you restrict yourself to accounts which you can get to through ACH, you can simply restrict to numeric digits.
You can get a lot more information about ACH at: http://www.nacha.org/
Good luck with that, because you can't.
Banks are free to use just about anything as an account number. I think the only validation you can do is whether or not they're numeric (as they all are).
The most common length for bank account numbers is 9, 12, or 10 digits. Although they range from 4 to 17 digits long. I have a large database of valid numbers and there's no pattern that I can see to the "account number".
A "routing number" defines the bank (pretty much) but even within a particular routing number, the account numbers can be of different lengths.
This is why payroll services often require an extra day (or two) before initiating Direct Deposit in order to "prenote" the account (validate it by performing a no-op ACH transaction) because you really can't verify it otherwise.
You can validate the routing number (or ABA) by downloading the DB (fixed field width text format) from the federal reserve bank. The data is here:
https://www.frbservices.org/EPaymentsDirectory/fpddir.txt and the layout describing the data is here:
https://www.frbservices.org/EPaymentsDirectory/fedwireFormat.html
There are companies (lyonslive.com) that offer a webservice to validate account numbers but they charge per validation (volume based pricing starting # 60 cents per check - if volume is high enough it can be as low as 24 cents).
Don't you mean International Bank Account Number? If yes, this is a regex for IBAN (all IBANs):
[a-zA-Z]{2}[0-9]{2}[a-zA-Z0-9]{4}[0-9]{7}([a-zA-Z0-9]?){0,16}
UPDATE: Actually, according to Wikipedia: Banks in the United States do not provide IBAN format account numbers. Any adoption of the IBAN standard by U.S. banks would likely be initiated by ANSI ASC X9, the U.S. financial services standards development organization but to date it has not done so. Hence payments to U.S. bank accounts from outside the U.S. are prone to errors of routing.
In Addition to the other great answers here, i think its helpful to know that routing numbers in the United States include a checksum digit which can be helpful for quick validation that the user typed it in correctly
http://www.brainjar.com/js/validation/
basically all US routing numbers should pass the following test:
3 * (digits[0] + digits[3] + digits[6]) +
7 * (digits[1] + digits[4] + digits[7]) +
(digits[2] + digits[5] + digits[8]) % 10 === 0
Very interesting. It seems like all routing/transit numbers are 9 digits.
I just checked American Express's online bill pay, for bank accounts they limit their field to 15 numerics. Chase limits theirs to 17. I would probably continue checking and maybe start to call a few banks to find out what their specifications are. It doesn't seem like there is a standard.
Another potential way to determine the length would be to ask the company that performs the transaction. Where does the account number get used? They should have specifications on what they will accept.
I don't think there is a standard - different institutions seem to use different lengths of account number. There probably is an upper limit - it is unlikely to be less than 20.
There is no standard for a bank account number in the US. There is a standard for the routing number, because that's shared between banks; the account number, however, is only of use internally by the bank itself.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Recently, I found myself having to write up some concerns I have about race conditions in an application that is in development (not by me). This will likely be brought to the attention of stakeholders who are non-technical and with whom I do not have a direct line of communication, so my explanation needs to be in written form.
I have already made an attempt at this write-up. I gloss over the technical specifics as best I can, give an example of how a race condition would occur in the application, and describe its impact. I feel I did pretty well, but it's far from perfect.
The problem is, as much as I try to shield the reader from computer science, I have still found it difficult to eliminate phrases like "threads of execution" and "mutual exclusion" without losing correctness and substance. The risk is that, with too much hand-waving, these concerns could be dismissed as a made-up boogeyman.
Anyway, my question to you is this: How would you explain race conditions to a non-technical audience? Would you dare to explain CPU scheduling? Would you invoke the dining philosophers?
You don't have to work within the constraints of my situation (but it would be awesomely helpful if you did).
Company X has $1,000 in the bank. X pays a rent of $2,000 and received a payment of $10,000 for services rendered to company Y. However, due to a race condition, X is in deficit of $1,000 and is now applying for bankruptcy. =(
You might want to explain how the bank handles company X's account in this way: Bank staff A takes the current value of $1,000 and adds $10,000 to it. Bank staff B takes the current value of $1,000 and subtracts $2,000 from it. Bank staff A updates the value to $11,000. Bank staff B updates the value to -$1,000.
I think bank transactions might be a good example, both because it's easy to see that an incorrect result is bad and because race conditions are easy to create in such an environment.
I have $500 on my account.
Someone transfers $200 to me at the same time that I withdraw $50.
Now, if the bank doesn't handle race conditions properly, they will do the following (assuming the transactions are handled manually, of course)
Clerk A will see the request to add $200 to my balance, and note that my balance is currently $500.
Clerk B will see the request to subtract $50 from my balance, and note that my balance is currently $500 (clerk A hasn't yet transferred the money).
Clerk A finishes the paperwork and sets my account balance to $700 (500 + the 200 he was supposed to add).
And then, a minute later (because clerk B just had to grab a cup of coffee), clerk B finishes up the other transaction and sets my balance to $450 (the 500 I had when he checked, minus the 50 he was meant to subtract).
My balance is now $450, when it should have been $650, because of a race condition. The outcome depended on the order in which different parts of the two transactions were performed.
That's the general description of how race conditions are bad. Now say that instead of clerks, we have our application processing two separate tasks at the same time (that's your 'threads of execution'), and just like above, they both read a value, modify the value that they read, and then write it back. One of the modifications may then be lost if this happens in the order shown above.
That should relate it to the specific problems in your app.
I would go for a Dining Philosopher's-esque approach, but depending on my audience, I would try to analogize it to the context of my audience. Are you speaking to business executives? Then analogize it to something like allocate a meeting room or a corporate car or booking a hotel room or whatever. Are you talking to average people? Then the dining philosopher's example is fine, or you can think up a similar situation involving caring for farm animals or sitting in chairs or whatever.
Whether you hijack the dining philosopher's example, or make up your own, definitely use a metaphor.
If you are writing to a non technical audience, you'll want to simplify your explanations and relate it to something they can understand. One explanation taken from the paper Analogies for teaching parallel computing to inexperienced programmers (http://portal.acm.org/citation.cfm?doid=1189136.1189172) explains it in terms of a pen game:
We’re going to play a game called the
Pen Game. The rules are simple: I’m
going to hold a pen in my hand, and
then I’ll say “One, two, three, go.”
When I say “go,” take the pen from my
hand. Whoever gets the pen wins.
Ready? One, two, three, go.
You then ask if the outcome of this game can be predicted in advance. If it can't be predicted, can we guarantee a correct outcome? This should lead to the realization that it's possible to get incorrect results for simultaneous writes to the same piece of memory.
I was going to recommend the dining philosophers, but I see you have already found that one. So, as an alternative, how about using gridlock as an analogy?
Imagine normal traffic driving along the four streets next to a single city block (North ave, South ave, East street and West street). When there are only one or two cars on the road, everything moves smoothly. When there is steady traffic, some cars will have to stop and wait for other cars to move past, but this is a manageable problem. One car stops to wait for another car to go by, and then continues on its merry way.
Now, picture rush-hour traffic at the same location. Let's say that one car driving South on West street can't make it all the way through the intersection at the NorthWest corner of our city block. That car now blocks all of the Westbound cross traffic on North ave. It doesn't take long before a Westbound car tries to make it through the NorthEast corner intersection and gets stuck, blocking all of the Northbound traffic on East street. When this situation makes it all the way around the four intersections, no cars can move! Each one is waiting for the cars in front of it to move ahead, but there is no way for the gridlock to be releived without pulling cars out backwards.
The comparison to computing should be straightforward. Cars are threads or processes, streets and avenues are processors, buffers, or cores. The concept of blocking can be described using traffic lights or stop signs, and the whole thing starts to make intuitive sense, even to non-programmers.
Write a program:
Wait for salary.
Go to shop.
Buy food.
Turn on the plate.
Put food on the plate.
Keep plate for 20 minutes.
Eat.
Go to bed.
Now try to have two threads (you, wife) execute it without syncronization.
You: Wait for salary.
Wife: Go to the shop without money, crash
You: Turn on the plate.
You: Keep plate for 20 minutes.
You: Go to bed.
Wife: Eat at someone else's place.
Wife: Go to bed.
Peter wants to pull out of his driveway. He checks that nothing is in the way of his car, then gets in. His son Frank then hides behind the car. Peter cannot see him and runs him over.
The important thing here is that for a computer, "inspect" and "modify" tend to be two separate actions, so an example where you can't check something when you modify it is a good one.
How about the plain obvious?
A race condition is literally a race between two people.
A company is bidding on a project. Two employees working independently on bids submit them to the customer, but one of the employees has outdated information. Neither employee know that the other is in the process of submitting a bid, therefore depending on who is faster, the first bid may be replaced with the slower employee. This will cause confusion as the bid may have changed over time.
There needs to be communication between the two employees to either work together or stop one of them.
One difficulty in explaining the general concept is that race conditions manifest themselves in a wide variety of situations. If your goal is give your non-technical audience the sense that this is a generic problem type, you should try to offer more than one example.
A picture is worth a 1000 words. Its true. If you draw a timeline and put some entity on it, and show its state changes as time progresses you can demonstrate a race-condition pretty easily in one diagram. It may take a few redos to get the picture just right, but I've always found that drawing it out gets my point across must faster than describing it.
I think it's hard to explain this in a simple way, because thinking about concurrency is inherently hard. The basic idea of a financial transaction might be a good place to start, since people will have some familiarity with them from real life.
In any kind of transaction, you need to make simultaneous entries in two places - debits and credits. If the transaction gets interrupted in the middle by someone else trying to perform another transaction, they will see the wrong balance in one or the other of the accounts.
There's a great example in Structured Concurrent Programming With Operating Systems Applications (as I recall)
In the impoverished country of Bezerkistan, two lines merge onto a single track in a tunnel. There have been collisions and the ruling junta needs a solution.
The issue is that it's mountainous and the engineers are blind. There's very little advance warning of two trains about to collide in the tunnel.
Here's the plan.
Put a big bowl at the juncture.
Give each engineer a little brass monkey.
When you're about to enter the tunnel, you stop your train. You pat around in the bowl to see if a brass monkey is in the bowl.
If there's a monkey, someone else is using the tunnel, so you have to wait until their train is entirely in the tunnel, at which time the conductor gets out of the caboose and grabs the monkey from the bowl.
If there's no monkey, no one else is using the tunnel. So, you can grab your monkey from the engine compartment, put it in the bowl and drive through the tunnel, knowing you have acquired exclusive access to the track. Of course, you stop briefly to allow the conductor to retrieve the brass monkey.
Guess what?
They still had collisions!
Why? What's the situation or sequence of actions that causes this to fail?
That's a race condition.
In a written document, you can explain how the race condition leads to an accident.
In a presentation, you can coach the audience through reasoning about concurrency and locking.
i would use a shared memory bank account example of a data race condition.
explain that the computer does something like: load balance; add 1; store balance;. consider two threads that are modifying your bank account balance (you and your wife are both depositing one dollar at the same time).
if both threads get interuupted after the: load balance; and then resume, you can lose one dollar.
see: http://wasp.cs.washington.edu/atomeclipse/handouts.pdf
As you mentioned, you often need to introduce other concepts (mutual exclusion, threads of execution) to accurately describe race conditions, even in a metaphor. So try defining these terms (or at least getting the idea across) first, using metaphor.
As a simple example, let's use a 4-way intersection (set in a country where you drive on the right). Divide the intersection into 4 quadrants: North-West, North-East, South-East, and South-West. Now call each quadrant a resource, and call each car a thread of execution. These cars only respect traffic systems, and since there are no stop signs or traffic lights at this intersection, the cars barrel right on through without slowing or considering traffic.
You can easily show that simultaneous use of one of these quadrants by more than one car is bad, and results in a car crash. One obvious solution is to install a traffic system. The system ensures that no more than one car is passing through a quadrant at the same time. It can do this intricately, without tying up all the resources. For example, letting cars coming from the South make a left turn to head West (using south-east and north-west quadrants), while letting cars coming from the West make a right turn to head South (using the south-west quadrant). The traffic system is providing mutual exclusion, or preventing simultaneous use (by multiple cars) of a common resource (the quadrant of road in the intersection).
This at least provides the ideas behind these definitions, the idea that simultaneously accessing shared resources can be bad, and that mutual exclusion can solve this problem. After this is established, you'll need to map these to a more appropriate metaphor to show what a race condition is and how it's one of those bad things that results from lack of mutual exclusion for a common resource.
It takes a bit longer, but it grants some familiarity with terms and the big picture before drilling down into a more complex metaphor.
Talking about money to your stakeholders might send them into panic mode especially if they assume they are losing actual money because of this, which is not exactly ideal if the problem does not specifically result in a net loss of profits, so here's a less financially oriented story on how you can explain a race condition to anyone.
This story does not address the concept of deadlock, but the more traditional race condition scenario and consequences.
STORY STARTS HERE:
The Setting: There are 3 cities connected by a railway network. The trains do not have any signs on them indicating which city they are coming from and which city they are going to because they are being used between all 3 cities and the railway network didn't want to deal with the hassle of changing signs all the time. Since the network is small there is no concrete schedule on when trains arrive and leave. The station overseers just get a call from the other city station overseers when a train departs, the overseer takes a note of the time when it has left and since all trains are the same models they drive at the same speed, so when the overseer receives a call from the other cities they announce to the people in the station that: "The next train will be heading to city C". So the people who wish to travel to city C await the train, hop on and merrily ride to city C.
The Problem: But one day, as a train was planning its route from A to B to C, it broke down half-way between A and B. Luckily the technicians are very skilled and would be able to repair the train in a short while. However that same day another train was also planning a different route from C to B to A. The overseer at station B received a call from A that a train is coming, and shortly after received another call from C that another train was also coming. The station overseer then announced to the passengers awaiting in the station: "The first train arriving will be heading to station C, and shortly after the train after that will be heading to station A." As the passengers gathered their luggage and went to their respective platforms. The overseer saw a train coming and redirected the rails to the platform where people were planning to head to city C. Little did they know that the train was actually going to city A instead. The other train, after having fixed its' mechanical problems also arrived at the station and the overseer happily directed it to the platform containing passengers wishing to go to city A. Needless to say none of the passengers arrived where they planned to, all because the overseer assumed that they would arrive in order as usual.
The problem with race conditions and many many computer science constructs is that people are not computers. Every time I explain an algorithm to my students they say "but it doesn't make sense to do it that way", to which I reply "computers don't have common sense, all they have are instructions". That aside, you should explain a race condition as a race, and it makes most sense to let people actually try the race, if they can. That way they can see how things go wrong. But... they are not allowed to use common sense.
So let's assume we have a game where 2 persons fill up stacks of colored blocks in order Red, Orange, Yellow. They have many red, orange and yellow blocks. All stacks need to be exactly three blocks high.
In the first game both try to do this as fast as possible, but they only work on their own stacks.
In the second game they try to work together by allowing themselves to also stack blocks on each other's stacks. However they are not allowed to change the block they have in their hand, and they have to place a planned block.
You can imagine a situation like this occurs in stack 1:
player 1 grabs a red block
player 1 places red block - player 2 grabs an orange block
player 1 grabs an orange block - player 2 places an orange block
player 1 places an orange block
So now we have a stack with two orange blocks. It's obvious that with a human game this would never happen, because people have common sense: they see that the orange block is already placed, and revert their decision to also place an orange block.
Also you can show them this video: https://www.youtube.com/watch?v=TcGwNdbsAbc
Let's use a whiteboard to do a trivial accounting task. We've got $100 on hand - write it on the whiteboard.
Alice has dozens of invoices that add up to $100, so she's going to note that $100, go and add up her list and come back in 5 minutes and write $200 on the board.
Bob's been shopping. He's going to take that number from the whiteboard and go and subtract $50 worth of purchases, and then he's going to write $50 on the board.
If Bob gets back first, we'll see $200 after Alice writes her result. If Alice gets back first we'll see $50, also wrong. What we want to see is $150, and we need to add some precautions somewhere to make that happen.
That should be enough to scaffold a discussion of technical solutions with reasonable intuitions.
For example, a mutex means you lock the door to the room with the whiteboard in it, and make them do their work in there. An optimistic solution means you get them both to check and start over if the number changed while they were away. If you want to talk about deadlocks, you can laugh about Bob calling Alice from inside the locked room to ask her to hurry up.
Send them to Race Condition on Wikipedia.
The first part will make some sense, and the rest (not shown below) will make you look smart since they will assume you understand it.
"A race condition or race hazard is a flaw in a system or process whereby the output and/or result of the process is unexpectedly and critically dependent on the sequence or timing of other events. The term originates with the idea of two signals racing each other to influence the output first."
I think the key point to get across is that its most frequently a timing issue that can be unpredictable because the timing something takes differs from time to time.