[exdsq]

The ticket is authenticated as yours by using the private key of the wallet that holds the ticket.

The company creating the tickets will say if it’s resellable etc, these are purely properties of an object.

Verifiers may well exist but how do you know someone hasn’t sold a ticket to two people? How do you know the ticket you receive is the one you see?

Also there may be some language context issues here. With NFT tickets I’m saying it’s possible to essentially use an API provided by an organization to verify a ticket. You can trust O2 Arena will know if a ticket to their own venue is authentic or not. They could provide an API that takes a ticket and returns a Boolean. A monetary transaction can be written that will only complete if the O2 Arena API confirms the ticket being traded is an authentic resellable ticket, otherwise it’d fail. That’s the thing here - we’re talking about programmable money and digital items can be seen as extensions of money with NFTs.

Another example - resellable digital games. You could have a game license that is resellable - any user account can play any game that they own the license for, and NFTs allow you to model this (it allows for trusted trading, it avoids double spend issues, with here cannot not be one instance of an NFT on a chain, etc…)

[dmitriid]

So, as luck would have it, today I had to fly from outside the Schengen zone into the Schengen zone with a layover.

So, passport checks, covid certificate checks, ticket checks. The ticket is non-resellable, non-refundable, non-transferrable to another person.

Guess how many of those steps required a blockchain. Also guess how many of those steps simply worked, and didn't need a blockchain.

Edit: Also worth noting: I bought the ticket through what is essentially a reseller (an aggregator site), and I could verify the ticket's authenticity with the organizer (the air company). Guess how many of these steps needed a blockchain to work.

[dmitriid]

# Problem statement

See, the problem with all you're describing (and the problem with any attempt to apply blockchains to anything) is that:

- it barely manages to cover the simplest of cases that already exist without any blockchain

- it makes a great many other cases needlessly complicated and complex

- for anything beyond the simplest cases (and often for the simplest case itself) it reverts back to approaches that already exist without a blockchain. And if those approaches don't exist, no idea why they would suddenly appear if you throw blockchain into the mix

So, back to your ticketing examples.

# The absolute simplest case: The organiser sells the ticket to a person.

1. Organisers generally don't care whether the person holding the ticket is the person who bought the ticket

You show up with a QR code, the QR code passes, you're through. That's it. For the rather rare cases where a person's authenticity needs to be verified, checking a person's id is more than sufficient.

In the case of blockchain, what is the exact process at the point of entry to the venue to both check that the ticket is valid and that the person is the one who bought it? The moment you say "yeah, the organiser will provide some external validator to check something", you lost: it can be done and is being done already, and you don't need blockchain for this.

2. To verify ticket authenticity the organiser or the ticket "it's possible to use an API", "O2 Arena could provide an API" etc.

"Possible", "could". They could do that already. Do they provide that API now? If not, why? And if not, why will they suddenly decide to provide the API when the tickets are on the blockchain?

So, blockchain brings literally nothing into this: to verify that a ticket is authentic you still have to rely on some third party external to the blockchain to provide some means of verification entirely external to the blockchain. Why do you need blockchain in this case? You can verify a QR code just as easily, and yet O2 Arena doesn't provide an API to do that, go figure.

3. They could provide an API that takes a ticket and returns a Boolean. A monetary transaction can be written that will only complete if the O2 Arena API confirms the ticket being traded is an authentic resellable ticket

So, a party external to the blockchain has to provide an API external to the blockchain that relies on non-standard object metadata recognisable only by that API external to the blockchain to ... write some transaction onto blockchain.

Why is blockchain needed at all in this case? To "make sure that if an object is marked as non-resellable we have a transaction log"? Well, maybe there's value in that, but it relies exclusively on non-existent APIs outside the blockchain that will maybe possibly perhaps appear.

And this "it's non-resellable, so no transactions can be written beyond the original one" preclude or make harder other very simple but very common cases:

# Other very simple but very common cases that are not taken into consideration because crypto-proponents have no idea how the real world works

- tickets are bought as gifts

- tickets are just given away because the person who bought them can't go

- tickets are bought in bulk for a group of people (so as gifts or given away)

- tickets are offered in bulk to orgs or bought in bulk by orgs to distribute between members of the org (corporate events, fan clubs etc.)

- tickets are re-sold by a chain of authorised resellers (chain being the key word here: a shop selling tickets in lower Manhattan could be on step 5 of the reseller ladder)

In the absolute vast majority of cases these cases are immediate and painless now. You buy a ticket and you hand it to another person.

In case of blockchain? Oh. "It's not resellable by the object metadata, so it will be invalid at the point of entry"? Or will you add more and more fields to the object metadata such as "gift, non-monetary transfer, corporate, reseller max steps 3" etc.? All of those fields non-standard, and relying on some external party to come up with an API that successfully deals with all these situations?

Why? And what exactly does it give anyone involved: both the organisers and the people who go to an event?

And, more importantly: how does it improve the current existing situation? Not in the simplest case that you came up with, but in all cases?

> Another example

No. Let's figure out one example first