- Hotels want to have their information on as many sites as possible

- When travel site A blocks / books a room, travel site B and C need to update their databases quickly

- The money is not in the database, as those are effectively just data caches of the information that the hotels will happily provide free of charge

- The data is already shared between hotel sites, just that every site has their own data silo.

- Money is made through individual contracts, upsell, services or better UI to access the shared data

Another example of this is, of course flight information.

So why would a company move this data onto a blockchain. We can take Ethereum as an example. Note that some of the things I describe here are presently not possible with Ethereum but will be possible within the next couple of software updates (I imagine within the next 1-2 years). Ethereum offers an existing, working, generalized blockchain with existing miners. Sure, a company could try to roll its own blockchain, but, as you observed, who would want to mine that. Also, there's little to gain by taking a private database and making it a semi-private blockchain.

Ethereum incentives the miners with Ether to continue to secure the data and keep the consensus.

The Hotelbeds database could become a database on top of Ethereum and the access would be regulated via a smart contract. That smart contract could be used to mark an individual room as booked (or reserved) for a certain time range. This means that each booking would cost a small amount of gas to pay for the transaction. Ethereum strives for a sub-second block time, which means that the database transaction could be almost instantaneous (compared to, say, Bitcoin, where currently transactions sometimes need to wait 3-4 hours). In comparison to the booking cost of the room, this small transaction / gas fee would be negligible (I hope). Since all Hotelbed sites would use this same contract / blockchain, there'd be no syncing required, as all changes would be available to all clients the second they happen. Even better, the smart contract could contain basic logic to defend invalid requests without ever alerting the clients (booking invalid dates, etc). A different, but related dataset (say car bookings) could also be hosted on the blockchain and could be queried at the same time to provide additional services ("there's one free car to rent for your hotel in that timeframe").

Alternatively, of course, all hotel sites could just get their data from one database company that sells access to the data and takes care of an internal database of all hotel bookings (i.e. Google). However, then, you're dependent on a different vendor. He may change his prices, he may limit the data, he may start giving certain hotels only to premium clients (see net neutrality). Even worse, at some point he may stop serving the data because it is not economically feasible (see Google Reader, or Facebook Parse). With Ethereum, there's nobody who officially owns the database. It can also never be taken offline again (at least until the last miner stops running his Ethereum node).

This doesn't work for data sets where the value lies in the data itself, but for data which is already replicated across multiple databases anyway, this is a great alternative solution to have a truly global, synced, database that is owned by nobody, where nobody gatekeeper, and where the entrance barrier is low.

I.e. it wouldn't make sense for Facebook (obviously) or Gmail, but for a truly decentralised Twitter (nee Diaspora) or Weather Information, etc.

I mean, hotels are a great example of a system where there is a gatekeeper (the hotel), that gatekeeper wants to do stuff that blockchains aren't optimised for (rolling back transactions, keeping most of the data non-public and limiting who can access the shared bits at what rate) and doesn't want to do any of the stuff which blockchains are optimised for (trustless transactions, immutable permanent records). With hundreds of thousands of travel agencies already using distribution platforms that interface with existing reservations system and none writing smart contracts, I can't see any incentive for a hotel to insist on accepting bookings in the latter form. Making a purely internal blockchain database like TUI have done is an even weirder move.

(English version of the TUI interview http://www.tuigroup.com/en-en/homepage-news-specials/2017-05...)

Some questions:

How is user access organised?

How to remove an organisation?

How to remove old booking for hotels?

How to prevent me from exploiting an bug in the database? I.e. incuring storage or computation costs -> DDoS?

How to revoke access when a private key / access token is compromised?

If I'm having a lot of Etherum due to hacking or stuff like that - what prevents to me extort the Hotels to break their system? Blow up the database? if I have enough gas.

Bug in the database?

I'm honestly interested how this is solved / will be solved. If you have links - at best with some math / hard concepts please share!

Thanks!

When someone creates a booking, he has the right to remove his own booking. Each booking might also have an expiration date, so it's removed automatically when expired. When a key is stolen, a key with a higher privilege level can disable access of the stolen key.

If it's implemented correctly (which will take time and maybe several failed attempts), hacking, bugs and DDOS should not be an issue.

Distributed consensus transactions are MUCH MUCH more expensive than transactions to centralized databases. Is that extra cost worth eliminating the disadvantages of centralization that you cite? Maybe. But that's not at all obvious to me.

Keep in mind that a transaction on the block chain currently costs about $11:

144blocks/day * 12.5btc/block * $2100/btc / 335000transactions/day