Sorry I have little questions here.. following up this examples you gave. What if the two prediction isn't correct or doesn't match their bet as you said who then received the payment among the two.
Like I have never covered this range of knowledge so far so would want to know more about this, though the link you shared I will take time to study them to know more about this mechanism.

@Hatchy has already explained that in this example all cases are covered by the contract.

There may however be examples for contracts where ambiguities could occur. For example, in a "contract for difference", the outcome of the contract depend on the exact price at a certain date. However it is inefficient to sign a transaction for every possible outcome. Let's say you sign transactions for all possible outcomes from $1000 to $1000000, with a step of 1000. You still have to sign 1000 transactions then, which is still doable (those transactions will take approximately 300-400 bytes each I think, so you'll have to share 400 kB).

Two things in theory could occur though in this case:

- $1000000 is surpassed.
- The price reaches exactly $50500 for example. Is it already $51000 or still $50000?

It's actually the Oracle who has to decide in these cases which transaction to sign. One of the core ideas of DLCs is that the Oracle doesn't know which party has taken a certain position, to be immune against bribery. So the Oracle shouldn't know exactly what the parties agreed. Thus, it's the contract participants who have to know and follow the Oracle's rules.

Something that also can go wrong is that an Oracle fails or is unresponsive. To prevent these cases, afaik several Oracles could be used.

Thanks for sharing it with us, I am sure many of us were not aware of this so called DLCs. The only DLCs I am aware of is Downloadable Content for Games.
And with the example you shared, I am sure if it's easy to integrate with a website, you can make a betting platform using these Discreet Log Contracts.

Just like how many web3 applications are using Ethereum based contracts, which I feel like are far superior.

A lot of things can be made "internal". For example: if you want to trade between BTC and ALT, then it is all about signing a proper message, and then, if you count only "in the system trades", then you can write conditions about it.

Also, if you want to make for example swaps, then only one chain needs new opcodes. Then, you can have OP_CHECKSIG on BTC, and OP_CHECKSIGFROMSTACK on ALT, and then, just a regular multisig can be used, to move both coins, with the same signature.

Another thing is that for all external data, it is also possible, if you can write some software, executing a given contract, then you can make a SCIP version of that, and then, it works on any data: https://bt.irlbtc.com/view/277389.0

For example, some time ago, people moved some coins, for providing a solution for sudoku puzzle: https://github.com/zcash-hackworks/pay-to-sudoku

So: on Bitcoin, you can just use some hash, or some signature. However, if it will unlock some external proof, then it can be as complex, as you want. And you don't need to push everything on-chain: you can only put the hashed password, or a OP_CHECKSIG-compatible signature.

To control the congestion, transaction joining is needed. And note, that batching N transactions into one can be achieved through full-RBF. And if you combine it with SCIP, then the password can for example unlock a batched transaction. Also, because of homomorphic encryption, people can externally join their payments in a trustless way, and then, the last recipient can just use decryption key, and submit the final version on-chain.

This is incorrect. The BTC/USD price I mentioned in my example is not an on-chain element, but would be extracted from the data of an exchange.

Basically the "bets" can involve any data two parties agree on 1) the data source (in our example, it may be Binance or Kraken for example) and 2) the Oracle. So it can also be sports, election results and any other data. The Oracle of course must support the type of data and the source the parties use. So the challenge is to find a suitable and trustable Oracle.

Regarding usefulness, the DLCFD (Discreet Log Contract-for-difference) is useful, for example, if you have:

1) one party that needs to ensure the value of an amount of BTC doesn't go lower than a certain price - they want their Bitcoin investment to stay stable at least. This can be a person who wants to ensure that at least a part of their Bitcoins holds their value. The use case is similar to a put option.
2) one party wanting to leverage a long position, i.e. profit in a higher proportion from a price increase.

The DLCFD allows the parties (let's again go with Alice and Bob) to agree on a contract where each party  contribute 1 BTC when the value is at $60000, and Alice (it could be called a "conservative short" position) always receives the value of $60000, in Bitcoin, while Bob (the "leveraged long" position) receives the rest. The outcome is then as following:

1) If the price goes above $60000 at the deadline of the contract, then Alice receives less than 1 BTC but always the value of $60000, while Bob receives more than 1 BTC (and thus more than 60000), which means he's making profit.
2) If the price goes below $60000 at the deadline, then Alice receives more than 1 BTC but still always the value of $60000, while Bob receives less than 1 BTC, and thus is at loss.
3) If the price goes to $30000, Alice receives the whole value of the contract (because 2 BTC are now worth 60000), and Bob doesn't get nothing.
4) If the price goes below $30000, Alice receives the whole value of the contract, but it's now worth less than 60000. This is an additional risk for the short position in DLCFDs, in comparison to "normal" CFDs, where Bob would have to provide always $60000 for Alice. However, normally this outcome is unlikely, at least for contracts over short timeframes.

DLCFDs of course could also be done involving stablecoins, although there seem to be currently few stablecoins on the Bitcoin blockchain, and on Ethereum other contracts are more useful for this use case.

As DLCFDs are more risky for the long position (Bob), who can lose everything (cases 3/4 above) Bob could probably in most market situations demand the payment of a premium as it occurs with put options.

DLCs can also be entered and settled via Lightning Network, so the fees are not necessarily an issue.

Here's the original whitepaper of DLCs: https://adiabat.github.io/dlc.pdf