Kind Of a Roadmap, Twice. Pt. 2

This blog post is a continuation of part one, which can be found here.

I understand that by '24, most people who are in the cryptocurrency/blockchain scene are very much used to the on-chain smart contract way of thinking and what I am proposing may sound strange and unusual. Some may ask why not simply implement on-chain contracts on Peercoin. My answer to that is that Peercoin was designed to be a coin, not a smart contract platform. Smart contracts belong on platforms specifically designed to run them. To run smart contracts and dapps, the architecture of the system must be adapted to serve such a task. In my opinion, complex smart contracts do not belong on a coin. I am saying complex here because Peercoin does have a scripting system and limited capability for smart contracts - most famously used for multi-signature addresses, atomic swaps and the lightning network.

There is a market for smart contract platforms, and evidently demand too, but again, this does not belong on a coin. It belongs on specialized platforms. With the technologies proposed in this post, moving information to and from any number of platforms becomes rather easy - without forcing design decisions that conflict with the coin.

To summarize, by moving the execution of smart contracts off-chain, the following favorable traits are achieved:

• Increased Privacy; to the outside world, the entire contract seems like a regular taproot transaction.
• Lower Fees; due to drastically reduced script size and cheap signature validation.
• Scalability; as most computationally intensive work is done elsewhere and only settled on the main chain.

The ability to operate contracts with a minimal on-chain footprint while ensuring integrity and confidentiality is a pivotal development in the quest for a more accessible and efficient blockchain ecosystem.

Now, let's imagine what kind of services can be built.

Binary Options

With the presented technologies, implementing binary option platforms is the easily accessible, low-hanging fruit. It's probably also the easiest case to imagine for most readers, so I am starting with it. Due to the nature of DLCs and how they work, everything has to be expressed as true or false, so binary options are a natural fit.

Binary options are a type of financial derivative where individuals can place all-or-nothing bets on the outcome of specific events or changes in asset prices. The essence of these options lies in a simple "yes or no" proposition, which is why they are called "binary."

If a trader's prediction is correct, and the option expires in their favor (in the money), they receive a payout. Conversely, if the prediction is incorrect, and the option does not end as anticipated (out of the money), the trader incurs a loss.

Let me illustrate further with two simple examples.

Example 1: Nvidia Stock Binary Options.

Stock binary options, with both sides trying to outsmart each other based on what they think will happen with Nvidia's stock.

In every binary option scenario, we have two parties, two roles. The maker and taker.

The Maker: In the world of binary options, the maker is the party that creates the binary option contract. They decide the conditions of the option, like which stock it's about, whether the bet is on the price going up or down, and the time frame (like by the end of the day, or the end of the quarter). The maker is offering a challenge and is essentially saying, "I bet you a tenner that Nvidia's stock will (not) reach a certain price by a certain time."

The Taker: In this scenario, you're the taker if you decide to take on the bet. By accepting the bet, you agree to the terms set by the maker.

Perhaps it is confusing to define the roles abstractly like this, but imagine every Alice being able to be a maker and every Bob can take the bet. Any peer could come around and post a bet, and any other peer could come around and take that bet offer.

How it all Plays Out:

• Setting the Stage: The maker sets up the option by deciding on the terms (Nvidia stock, price direction, timeframe, and bet amount). Maker posts a bet offer which claims that the price of Nvidia stock will trade under $1000 by Jan. 1st 2025.
• Accepting the Challenge: The taker, intrigued by the maker's bet, decides to take the challenge. If the taker agrees with the maker's offer, they're essentially betting against the maker. In other words, in order for the taker to win, the maker must lose.
• Waiting for the Outcome: Both parties wait until the future event to see what happens with Nvidia's stock price.
• Winning or Losing:
  • If the stock's price is over $1000 on Jan. 1st, 2025, the taker wins the bet and collects both his deposit and the deposit of the taker.
  • If the stock's price is under $1000, the taker loses the money they bet and the maker can withdraw the full sum.

In this scenario, the maker is taking on a bit of risk by offering the bet, but they might also be using their knowledge or intuition about the stock to try to win money from the taker. The taker, on the other hand, is directly accepting the challenge, using their own knowledge or gut feeling to try to win.

See in the next example exactly how these binary options would be settled and what the role of the oracle is.

Example 2: Betting on the Outcome of an Event, the USA Presidential Elections

The Maker: This party sets up a new bet related to the upcoming presidential election in the USA. They propose a bet saying, "I bet that Donald Trump will defeat Joe Biden in the upcoming presidential election." The maker decides on the terms of the bet, such as how much money is at stake.

The Taker: Another party who decides to engage with the maker's bet. The taker bets against the maker, i.e. betting that Biden will win the election. It always comes down to boolean true/false.

The Oracle: This is a crucial character in our setup. The oracle is an independent party that doesn't bet but plays an essential role. They are responsible for determining the outcome of the event and declaring the result of the bet based on that outcome.

How it all Plays Out:

1. The Bet is Made: The maker puts forward the bet on the election outcome. They might say, "I bet Ᵽ100 that Trump will win the election."
2. The Bet is Accepted: The taker reviews the bet and decides to take it. By definition, the taker disagrees with the maker, and they're betting their money on Biden winning.
3. The Election Happens: People vote, and the votes are counted, and official results are published.
4. The Oracle Steps In: Once the election results are official, the oracle announces the outcome to the players. This ensures that there's no dispute about who won or lost the bet. The oracle says, "The result is in, and [Trump/Biden] has won the election."
5. The Outcome of the Bet: If Biden wins, the taker wins the money.

In this scenario, the oracle plays a crucial role in maintaining the integrity of the bet. By having an independent party declare the result, both the maker and the taker can trust that the outcome is fair and that the bet will be resolved honestly. This setup mirrors real-life mechanisms where third parties often mediate outcomes in betting and financial contracts.

I am trying to shorten this blog post, so I will just mention that sports betting can be done in the very same way, given that there is an oracle swarm that specializes in this. Alice makes the bet that the Doggers will win against the Blazers by 5 points or more. Bob accepts the bet as a counterparty and everything continues just like in the example above.

Bridges of all Kind

Bridges to sidechains, bridges to foreign chains, all kind of bridges.

Cross-chain Bridges

A cross-chain bridge enables the transfer of token assets, smart contract instructions or data between blockchains.

Most of the cross-chain bridges out there are simple multi-signature setups. A number of trustees band together to form an address from which spending is only possible if a certain number of signers provide a valid signature. The most common multi-signature setup is 2-of-3, which means that there is a total of three signers, and a minimum of two is required to produce a valid spending condition.

Wrapped Bitcoin, the tokenization of Bitcoin on Ethereum, is a contract with 13 signers. On the other side of the blockchain scene, most, if not all, Ethereum "layer twos" are still on "training wheels" secured with similar multisig contracts on Ethereum L1. For example, the Ethereum ↔ Polygon bridge used to be a 5/8 multisig, and maybe it still is. Besides the obvious security risks of having so few signers, there is also the privacy risk, since the addresses of all parties in a multisig contract are easily visible. I am also fairly certain that such setups carry high regulatory risk, given the amount of money they handle, as they would be classified as VASPs in OECD member states and should be registered as such. This is precisely why users have to go through KYC procedures if they want their wBTC unwrapped or BTC wrapped. Why don't these rules apply to Ethereum layer two networks, I don't know?

By utilizing threshold signature and signature aggregation, such multisigs can be scaled up to dozens or even hundreds of signers. Moreover, due to the nature of Schnorr threshold signatures, the identity of participants remains obscured. From the outside, it looks like a single address and a single signer. Hiding the signers makes the system far more robust, as nobody can be singled out, threatened, blackmailed or prosecuted.

Let's imagine a hypothetical wrapping protocol that would be using a threshold signature schema such as FROST or ROAST.

Bridging from a UTXO-based blockchain to a smart contract platform, where DeFi usually happens, is actually quite tricky since the two systems work very different. Due to this, reliance on some sort of custodian address for deposits is required. The custodian is usually a multisig address in these kinds of setups. But let's try to imagine something different. In this scenario, the counterparty for custodianship of the UTXOs is an entire network of signers.

• To deposit, you ask the network for the new deposit address. It is always a fresh address and is generated on demand by the network of signers by some sort of distributed key generation.
• Upon the confirmation of the deposit, the network gives you a signature, which you use to mint new wrapped tokens on the foreign chain by interacting with the wrapped coin contract.
• To withdraw, you submit a request to withdraw and present a proof of burn on the foreign blockchain. You also submit your desired withdrawal address.
• The network deducts a fee and proceeds to assemble the transaction by randomly selecting UTXOs it controls. It then signs and transmits the transaction.

The user treats this network of signers as a black box, which does its job without exposing its internal processes. However, these internal processes can be quite complicated. Internally, the network can be coordinated by a blockchain, it can have punishment mechanisms for dishonest signers, mechanisms to replace unresponsive signers, reputation tracking and much more.

If a bridging service like this can demonstrate that its internal consensus is a consequence of a peer-to-peer protocol with clear and pre-defined rules - I believe such a network would not be considered a VASP, in the same way a block producer on Peercoin network is not a VASP, and could provide its services without AML/KYC procedures on its customers.

Bridging to Sidechain(s)

In another example of bridging to somewhere, the destination chain can be a sidechain, a layer two. Using the same, or similar, bridging service, users can send their peercoins to a specialized sidechain that offers EVM compatibility or any other popular Turing-complete virtual machine. Such a blockchain can be both private or public, it can have a native token, but it can also natively use wrapped peercoins. It can be secured by PoS, dPoS, PoA or anything else. There can be a myriad of such chains, too, each with a different set of features and catering to a different audience. If you want to have a private sidechain where you and your friends play poker, it probably makes sense to simply use an existing professional service like this bridge to get your peercoins over to the sidechain.

There is another way to bridge to sidechains, without using a custodian bridge service. It can be done directly using DLCs.

• The user moves their coins into a DLC contract on the Peercoin chain, a contract where the counterparty is a specialized service providing exactly this sort of bridging.
• Both the user and the service select a suitable oracle (network of oracles) which will deliver proof of burn on the sidechain.
• Since the coins are effectively locked now, the proof of lock can be issued to the user (a signature), and the user can mint the same amount of wrapped coins on the other side.
• The user can use the wrapped version of peercoin for any service offered by this sidechain.
• When a user wants to withdraw from the sidechain and move back to Peercoin, they destroy (burn) the wrapped coin.
• The oracle continuously monitors the sidechain for burn events. Once the event has occurred, the oracle releases the private key (discrete log) for their public key, allowing the signature to become valid and - unlocking the DLC.

Let me try to imagine a less degenerate scenario that is not related to cryptocurrency, or gambling.

Insurance

In this scenario, UK-based Company "C" trades with a regime at risk of being sanctioned by Western countries due to human rights violations. The business is lucrative, but the risks are high. To protect against potential losses from such sanctions, the Company enters into a Discrete Log Contract (DLC) with an insurance company. This contract will pay out to Company C if a network of oracles confirms that the regime has been sanctioned.

The oracles, chosen for their reliability and access to geopolitical data, independently verify and report on the sanction event. If the predetermined conditions are met—specifically, if the oracles confirm that sanctions have been imposed, the company is eligible for payout. This process mitigates the risk of political sanctions affecting Company C's business activities, providing a secure, private, and efficient insurance mechanism without the need for traditional financial institutions.

The use of multiple oracles reduces the risk of manipulation, ensuring the contract's integrity. If the regime is not sanctioned by the time the contract expires, Company C does not receive a payout, and the insurance premium stays with the insurance company.

All these technologies like threshold signatures and massive multisigs, distributed oracles and smart contracts that work off-chain won't really become meaningful unless they're easy for everyone to use. For these technologies to truly make a difference, they need to be made user-friendly. This means hiding all the complicated tech stuff under the hood and presenting it in a simple and clear interface to users. Only by making these technologies approachable and straightforward can we hope to see them become a part of everyday life. And that's precisely what we're working on by integrating all these new technologies into the Peercoin Flutter wallet.

It's all about making sure that these advancements are for people, not just for tech experts.

Human meaningful and human centric.