In the race to build public blockchains empowered with self-executing code, at least two competing philosophies have emerged.

Ethereum has created a platform that makes it easy for developers to create nearly any type of smart contract that they want, while bitcoin has been added similar functionality at a much slower pace. But bitcoin developers like Lightning Network paper co-author Tadge Dryja argue there's a reason for adding smart contract functionality to bitcoin more cautiously.

During his work on the transaction-boosting technology Lightning Network, which he has been working on more recently at MIT, he came up with a method of adding some smart contract functionality to bitcoin in a way that he believes could preserve both privacy and scalability.

The idea behind Dryja's Discreet Log Contracts (DLC) is to try to keep the blockchain more decentralized.

Dryja told CoinDesk:

While onlookers often see the two cryptocurrencies as competitors, Dryja went on to argue that his idea may just be more practical as an engineering option in the long term.

"It has much lower impact on everyone else who uses the system, as the contracts take up very little [space] on the blockchain," he said.

Dryja's smart contract idea centers around a popular concept: oracles.

Some of the more complex and interesting smart contracts, as proposed, need the help of an outside data source. Oracles feed that data to smart contracts, which then execute based on the data that they receive.

Say that one user bets five ether that on Friday we will see over 80ºF weather. Two users set up a smart contract that specifies these conditions, and then select a data source that they both trust. (Maybe both users decide that theweather.com is the most trusted resource for timely temperature data.)

Next, the smart contract receives information from this source automatically on Friday. Whoever guesses the correct temperature range wins the five ether. Simple, right?

Ideas for how to do this in bitcoin already exist, but aren't widely used.

Dryja thinks that could be for a few reasons. One, these oracles need to be aware of users through the whole process, opening opportunities for the two to collude and game the system. Two, oracles will know which users are requesting data from them, which means that users that leverage the construction risk their privacy.

That's where Dryja's idea comes in. The interesting part is that the oracle operator can't see if anyone is using the data it sends out.

"That's the lonely life of an oracle," he said. "You can't even tell if there was even a contract even after it happens. So that's kind of fun."

How does DLC accomplish that? At a high level, the oracle beams out data. (Say it sends out the temperature at a certain time each day.) This key will be mixed with data from the user before it is added to the blockchain.

Since the oracle's key is mixed with data that the oracle doesn't know about, the oracle can't tell if it was ever used and added to the bitcoin blockchain.

"We're going to combine the oracle's data with our own secret data, so we can recognize it but the oracle won’t recognize it," Dryja said.

He argued that the rationale for this level of privacy is that, more likely than not, companies using blockchain technologies don't want to reveal their financial records or a trail of the data they're using to the rest of the world.

DLC, like the ethereum project Town Crier, proposes one way of shielding some of the data.

Besides privacy, oracles face some other tricky problems.

In general, oracles are trusted centralized services. Why does that matter? Remember, the smart contract is going to execute whether it's fed correct data or not. So, users need to "trust" that the service is sending reliable data.

Developers have proposed different ways of dealing with this point of centralization. Decentralized prediction market Augur, for example, plans to use a number of oracles at once to report an outcome.

Dryja doesn't think there's a way of eradicating the problem completely, though he has a couple of ideas for at least "mitigating" it. DLC aims to incentivize oracles to report the correct information. If an oracle dishonestly broadcasts different information to two smart contracts, for example, then the oracle's private key will automatically be revealed.

"Mathematically it works, but does it actually stop oracles from misreporting?" he said, adding that it will take more review to find out how well the idea stands up.

The idea is still a work in progress, but Dryja said that he's looking for more feedback from the community with the publication of a white paper on DLC.

For now, he hopes that his idea will help to inspire a new way of thinking about smart contracts; one that is more privacy and scalability focused. As far as next steps for the project, Dryja said that DLC will be his "next fun project" after he squares away some of the work he's doing on his version of the Lightning Network for MIT.

He noted that DLC does not require any changes to bitcoin, but it (like many others in the space) will work better when a coding optimization known as SegWit is activated on bitcoin – if it ever is.

He further said that it's possible to code up a version of DLC without SegWit, but it would be "annoying" to complete a version of the code that doesn't require SegWit's activation if SegWit is then activated soon after. So, he will likely wait for its activation to begin work on the project.

Tadge Dryja image via Shutterstock