So, trusting centralised data providers.

> You could for instance have 5 independent oracles responsible for validating whether the concert happened or not.

Ah yes. Because the ticket is validated after the concert has happened, and not, you know, at the entrance to the venue.

And also so many "coulda/woulda"s in your description of something that has already been solved and doesn't require mountains of compleiy on top of it. I mean, you can't reliably show how having a single ticket to a single concert would work better than the existing system. And that's the simplest thing that can happen to a ticket.

Can we just stop this and act like engineers and actually _try_ to understand each other?

> So, trusting centralised data providers

Where did you understood that? Did you even read the comment you're replying to?

Chainlink (being just one example of an oracle protocol to illustrate the discussion), allows you to choose how many oracles you want, with whatever reputation constraint you want, strictly named or open ended, with or without whistleblowing/conflict mitigation algorithm, etc.

How does that deserves a snarky "So, trusting centralised data providers"?!

> Ah yes. Because the ticket is validated after the concert has happened, and not, you know, at the entrance to the venue.

There are multiple ways to handle this, a lot of future crypto contract implement something very similar to:

- The venue issues tickets that can be purchased through posting money to a smart contract.

- The smart contract locks in the money until, say, 5 oracles validate that the concert did happen.

- The venue can prove the locked in ticket sale amount as collateral to borrow money in preparation of the concert.

- The oracles validate that the concert happened, unlocking the sale money to the venue.

or

- The concert was a scam, oracles do not validate that it happened, thus ticket sales are refunded.

> something that has already been solved and doesn't require mountains of compleiy

My comment is not about the rationale or utility of the concert ticket example. It's about how that could be implemented with a smart contract.

> And also so many "coulda/woulda"s in your description

Chainlink is already used since multiple years to secure billions of dollars of pegged tokens, sport bet results, election results, insurance, etc.

This would be a great thing for blockchain proponents to start doing, yes. HN is littered with threads where people have spent hundreds of comments trying to get someone to explain how a blockchain is better than the status quo, and it always devolves to “I need to sell my random hashes”, usually with a side of “I have done no research into the domain I’m trying to sell into”.

Concert tickets are a great example. There are no widespread problems with tickets being sold for concerts which don’t happen and refunds being denied in violation of the terms of sale. Similarly, people don’t have any trouble paying for tickets since the existing options are cheap and safe. Those problems certainly aren’t large enough to warrant the additional cost and risk of using a blockchain.

The actual problem with concert tickets in the U.S. is that one company has exclusive contracts with most of the venues, their agents handle bookings for most popular bands, and they have a comfortable relationship with the company which controls radio play in much of the country. If you want to do anything in this space you need to understand that it’s not a technical problem, and explain what you’re doing differently which will succeed unlike the various failed attempts since the beginning of the web.

Let's do that. I only wish these blind crypto absolutists would actually look at real world from time to time.

> Where did you understood that?

From your statement: "You can have hybrid smart contracts, that rely on oracles inserting real world data on chain"

Oracles are always cenralised data providers that you trust. And for may, many, many applications there will be only a handful of them.

> There are multiple ways to handle this, a lot of future crypto contract implement something very similar to:

Again. None of these are much of an issue for existing systems. Have you been to a real concert in the real world lately? You buy a ticket, you go to a concert, done.

No need for "five oracles to validate that a concert happened". There are hundreds of thousands of concerts happening all around the world without this inanity. What exactly does blockchain bring into this equation? Or "smart" "contracts" (which are neither smart nor contracts)?

> It's about how that could be implemented with a smart contract.

Indeed. That's what I was addressing. You wanted to talk like real engineers trying to understand each other? So try to understand this: you are proposing a mountain of complexity to solve what is largely a non-issue.

Your entire description on how ticket sales happen have literally no basis in the real world. And that's on top of the fact that you completely ignore what the original comment (and then I) said: your ticket is issued by a trusted central authority, and then is validated at the entrance by a central trusted authority. What does blockchain bring into this euation except lots of "coulda shoulda oracles"?

Edit:

Even in the cryptoutopia world the "contract" for the ticket will of course be released by the central authority running the concerts, and you'll have to trust that they didn't screw up the programming. And no, "you can always check the contract" doesn't work since there are now multiple cases of these "smart" "contracts" passing multiple security audits and still having glaring holes in them. A human-readable cotract you have with the concert organizer can actually be audited by regular people, and is enforceable.

> Chainlink is already used since multiple years to secure billions of dollars of pegged tokens, sport bet results, election results, insurance, etc.

Of course it did none of that.