Blog of a Consultant
Offering information about Blockchains and Consulting

What is Ticket Peer to Peer? ~New System to Prevent illegal resale~

What is Ticket Peer to Peer?

~New System to Prevent illegal resale~


The system of preventing resale  “Ticket Peer to Peer” developed by LCNEM.


What is 「Ticket Peet to Peer」?

“Ticket Peer to Peer” is a system that can prevent resale, and is planed to be made as a Software library with the public blockchains of the cryptocurrency NEM.

Details will be described later and will be briefly described below.

First, the “address” on the blockchains plays the role of a single ticket. A unique address is issued for each issued ticket.
By the function of the blockchains, it is possible to know whether transactions on the blockchains (corresponding to remittance processing) are received for each address. The ticket not received is “valid”, and the received ticket is “invalid”. For example, when ticketing a ticket by reading the QR code at the event site, a transaction is sent to the address of the ticket at that time and it becomes “invalid”.

Likewise, if someone finds the ticket being resold, by sending a transaction to the address of the ticket on the NEM blockchains (this is an operation that anyone with NEM wallet can do) , you can invalidate the ticket. In other words, you can simultaneously report and invalidate ticket resale.
Furthermore, “Who/where informed and invalidated” can also be recorded in a form that can not be tampered with on the blockchains, that is, without objection.

By remitting the reward on the blockchains to the first reporter of resale, it can be used as an incentive for reporting. Since it is possible to send a fee only to the first informant of each ticket, it is difficult for wrongdoing or objection concerning reporting to occur. How much incentive fee is sent to the informant is out of the scope of the service and it depends on event organizer’s discretion

I will describe the detailed commentary on “Ticket Peer to Peer” as follows.


On the premise that
・Ticket is address of blockchains themselves
・Valid if the address has never received a transaction
・Invalid if the address has received a transaction

2019/2/11 Postscript

We edited it ,
because corresponding to the description of the improved version applicable not only to the ticket but also to the prevention of resale of account for charge game.

This system is patent pending.

The Improved system is as follows:

On the premise that:
In the ticket management system, ticket unique IDs are allocated.
The 256 bit cryptographic hash function is H 256 (x), and we get as follows;
Hash 1: = H 256 (ID)
Hash 2: = H 256 (Hash 1)
We consider those 256 bit hash values ​​as secret keys.

That is
PrivateKey 1: = Hash 1
PrivateKey 2: = Hash 2

Derive the public key and address from each private key.

That is
PublicKey 1 = PublicKey (PrivateKey 1)
Address 1 = Address (PublicKey 1)
PublicKey 2 = PublicKey (PrivateKey 2)
Address 2 = Address (PublicKey 2)

The private key used by the ticket system (game system) to issue transactions is PrivateKeyS, the public key is PublicKeyS, and the address is AddressS.
I will use the above information for explanation.


When selling ticket:
(In the charge game, it is “at the beginning of procedure of taking over account”.)

First of all, ticket seller or charge game operator will acquire the user’s phone number by using SMS authentication etc.

And then,

CommonKey = f (PrivateKeyS, PublicKey 1) = f (PublicKeyS, PrivateKey 1)

With Common key AES(Advanced Encryption Standard) encryption CBC mode(Cipher Block Chaining mode), the ticket (game) system encrypt the phone number. We define encrypted phone number as “Encrypt (Phone)”.

Then the ticket (game) system sends a transaction Tx1 containing “Encrypt (Phone)” as a message. The sender of Tx 1 is Address S, and the recipient is Address 1.

To put it clearly …
the ticket (game) system sends the phone number to the Address 1 as an encrypted message on the NEM blockchains.

When reselling:
Suppose there are two players as follows:

Ticket seller (charge game operator)
Secondary Purchaser

When resold, secondary purchaser can know the ticket (game account) ID.

Therefore, the secondary purchaser informs the ticket seller (accounting game operator) “ID purchased by reselling”.

When reporting:
When reported, the operator derives PrivateKey 1 from the ID, decrypts the encrypted message by using f (PublicKeyS, PrivateKey 1), and reads the phone number.

AddressS then sends a transaction of 0XEM transmission to Address 1.

In addition, you should take an appropriate action to the phone number.

If it’s simple, it is possible to make reseller not be able to purchase tickets or register the account again (BAN) with that phone number.

In addition, it is possible to set a fine for the contractor of that phone number under the terms of use.

When entering:
We will talk about entering with the ticket. In the charge game, it means “When you enter ID in taking over account”.

When entering, ID is read and Address 2 is derived.

AddressS then sends a transaction of 0XEM transmission to Address 2.

You declare in advance that the secondary purchasers who have reported will be given a reward.

If you declare this declaration, you think that you will be BAN if you do resell and then reseller will not occur. In other words, if you declare that, entering the phase in which reseller occurs is not a solution for subgame.

In Game Theory, it means a “commitment”.

1. Resale 2. Report
Do Not do
Not do

In the game tree, it will be as above.

We should calculate the equilibrium from behind.

First of all, whether to report or not(2), the secondary purchaser chooses ①. There is incentive by reward. It also means that a solution for subgame, whether to report or not, is ①.

Next, about whether or not to resell(1), since the solution of subgame in 2. is ①, we will compare ① and ③.

Here, when ①, appropriate response to phone number will be taken.

When purchasing a ticket or registering an account for charge game can not be done by that phone number again, it is thought that ③ is more beneficial than ① and ③ becomes a solution on individual level.

In the case of resale of organization-wide in premier tickets, we can make the gain of ① smaller than ③ by taking an appropriate action to the contractor of the phone number.

It may be possible to use personal information that is more accurate than a phone number for premier tickets.

So to sum it up,
subgame perfect equilibrium becomes ③, and resale is prevented.


The Meaning of using blockchains

The transaction history of Address 1 determines whether or not the report has been completed, and it is determined by the transaction of Address 2 whether or not it has been admitted to events etc..

Since it is possible to have evidence that the reported or admitted has been made on the blockchains in a condition that (almost) impossible to falsify, the incentive structure for reward will be clarified.

In other words, blockchains prevent the incentive structure from being inhibited by doubts about the operator. This is the biggest reason for using blockchains.

This is the explanation about the preventing resale system “Ticket peer-to-peer” using blockchains.