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?
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