Theatre tickets are not so expensive, except for prime events. There are substantial advantages to use back-step blockchain technology to create a ticket buying application. The process is simpler, compared to existing systems. The tickets can be resold and there is transparency for the Users and the Theatre. At the end, less operational cost.
This use case shows how multiple back-step blockchains will work together, it is a Blockchain to Blockchain application. For that we assumed that each user has his or her own blockchain in his or her smartphone. It can also be a desktop or a notebook.
In this example we have 2 users, Alice and Bob (famous crypto example users), a credit card company and a Theatre. It is also possible to use any Cryptocurrency as long as it is accepted by the Theatre. I gave the steps in the diagram numbers for easy reference to the text. First, the 2 Users and the Theatre involved has blockchain that stores their own identity at the beginning block, block number 0. Because we need privacy, the Theatre should not know any transactions not related to the ticket. Users and the Theatre may have thousands of other blocks in their chain that must be kept private. Now let’s look at the flow in the diagram above.
Step (1) shows the beginning of the back-step blockchain. The first record contains the identity of the chain. There could be a certificate that other users or business partners can verify. If this certificate was created from a trustful organisation (government) you may trust the chain owner. The user may have multiple applications that use this back-step blockchain. Thousands of blocks may be between the first (Identity) block and the ticketing blocks discussed now. Each application may use it’s own encryption of the payload (block user contents). The content in the chain is then encrypted and only the correct application is able to see their own records. This is an implementation detail and doesn’t matter at the moment. For now let’s assume the ticket application sees their related records.
Ms. Alice saw on the website a concert that she wants to attend. She found the best seat and starts booking. The ticket application in her own computer places her request (2) into her own blockchain. Now this needs to be sent to the Theatre (3). Actually two blocks are sent to the Theatre, her identity block and the request block for the ticket just created in her computer. The Theatre’s server now verifies the identity of the request. The back-step value of the current reservation request to the back-step value of the identity block is a continuous one-way encrypted value. The verification can be done by performing one-way encryption on the reservation request back-step value and compare the result with the hash of the identity block. If everything matches the owner of the blockchain is verified. The one-way calculation can perform 5 million steps per second. For users/customers with a large chain that should not take long. Now, the Theatre’s server issues a ticket number and places the request as new block into its own blockchain (4).
From that point on the seat is reserved for a certain period. If the whole transaction is not completed within that period the reservation is lost and a timeout record is put into the Theatre’s server blockchain. The Theatre wants to see money before releasing the ticket. It issues a payment request, places it into its own blockchain (5) and sends that block together with its identity record to Alice (6). Alice with her application, can now check if the payment request is matching the Identity record of the Theatre. The same mechanism described above is applied. There is still a small chance of a so called “man in the middle” attack which we can eliminate. This is described in a separate article in the near future.
Alice places the payment request into her own blockchain (7) and forwards that block together with her identity block to her payment agent. In our case we use American Express. The response after a successful payment (8) is again placed into Alice’s blockchain as block (10). Amex sends an information to the Theatre telling that the ticket payment is credited to the Theatre’s account. This information is placed into the blockchain as block (11). Now after payment the Theatre will create a block (12) stating the ticket ownership transfer to Alice. This block is transferred to Alice (13). She places the block into her blockchain (14) to proof that she has the ticket now.
Now two scenarios are possible, Alice will attend the concert with the ticket she owns or Alice can chose to resell the ticket to Bob. Scenario 1, Alice uses the ticket for herself, this is covered in steps (35) to (40). These steps are identical for any ticket holder, independent how often the ticket has changed hands. Scenario 2, Alice chose to resell the tickets to Bob which are shown in steps (15) to (34). We will explain that in detail in a few moments.
Alice can have the ticket on her smartphone or printed out on paper. She presents the ticket ownership block (35). The block is on-line transferred to the Theatre’s server where it is match to the most recent ownership block (36) for that ticket number. A match occurs then a request (37) for a verification is generated. In on-line mode a new block is generated immediately and placed in Alice’s blockchain (38) and delivered to the Theatre (39). In paper mode such a block was pre-calculated. The Theatre uses the back-step value from the verification block and calculates backward using the one way function. After some steps the back-step value of the ticket ownership transfer block should be found. Now, please give Alice access to her seat and let her enjoy the beautiful music.
In the case when Alice transfer the ticket to Bob steps (15) to (34) are now performed.
Let’s assume Alice agrees to sell the ticket to Bob. He prepares a request ticket (15) block and sends it together with his identity block to the Theatre (16) and to Alice (18). Both place the request in their blockchain (17) for the Theatre and (19) for Alice. Both the Theatre and Alice can use the back-step value of the request to calculate backwards to the identity record and verify Bob’s identity. The Theatre also checks if the ticket still belongs to Alice. Then, the Theatre acknowledges the transfer request with block (20), which is sent to Bob (21) together with the identity block of the Theatre. Bob stores the acknowledgement in block (22). Bob is at that point able to verify that he is talking to the right Theatre. Now he knows that the ticket Alice offers him does really exist and is not transferred to somebody else. Alice cannot double sell a ticket.
Alice wants money for the ticket and places a payment request (23) as invoice into her blockchain. This block is then transferred to Bob (24). He places it into his blockchain (25) and forwards the block to the bank for payment. After the money is transferred, the bank informs Alice (30). She puts the received payment into her chain as block (31). This ends the procedure for Alice. The bank also informs Bob of the successful payment (26). He places the information from the bank into block (27) and transfers the block (28) to the Theatre. This proof of payment is placed into the blockchain of the Theatre as shown in (29). Now the Theatre creates a new ticket ownership transfer block (32) and transfers it to Bob (33). He stores it in his own blockchain (34) as proof that he owns the ticket now.
The procedure at the time of the event was already explained when we assumed that Alice uses the ticket for herself. The reader can try to modify the procedure if Alice wants to give the ticket to Bob as a gift, without payment involved.
This protocol has a few interesting advantages:
Firstly, the Theatre does not know the price Bob paid to Alice.
Secondly, the Theatre knows who is visiting the performance. This information can be used for marketing and security purpose.
Finding the right ticket owner is easy. The most recent ticket ownership transfer record shows the ticket holder.
The Theatre knows how often a ticket was resold.
Verifying blocks is easier compared to a traditional blockchain.
Neither party needs to verify the total chain of the others. The forward hash verification is only used by the chain owner to check if his chain is authentic. The other parties using this protocol use the back-step value to verify if a previous record belongs to that chain.
Between two blocks belonging to the same transaction any number of blocks from other transactions can be in the chain. This allows the chain to support parallel activities of different transactions at the same time.