New BIP Would Enable Better Privacy, CrossBlockchain Exchange, TrustFree Betting, and More for Bitcoin

A new Bitcoin Improvement Proposal (BIP) authored by Bitcoin Core contributor Johnson Lau would bring enhanced functionality to the Bitcoin blockchain. The new BIP is dependent on BIP 114, which was also authored by Lau.

CoinJournal reached out to Lau to get the details on these improvement proposals.

The basic idea behind Lau’s recently-published BIP is to enable some new (and re-enable some old) opcodes in Bitcoin’s scripting language. Opcodes are essentially the rules that determine how and when some bitcoin will be spent. As Lau explained to CoinJournal, “The most commonly used rules (i.e. address starting with 1) is ‘In order to spend the bitcoin, you have to give a valid signature for this public key.’”

Many opcodes were disabled by Satoshi Nakamoto in the early days of Bitcoin for security reasons, but Lau says, “Satoshi disabled those opcodes as an emergency response. Most of these opcodes could be reimplemented safely.”

Lau would like to allow for much more complex Bitcoin transactions. Through newly-enabled opcodes, new features, such as better privacy and trust-fee betting, would be possible.

According to Lau, the ideas behind BIP 114, also known as MAST (Merkalized Abstract Syntax Tree), originated from work by Russell O’Connor and Bitcoin Core contributors Pieter Wuille and Peter Todd. Many others have discussed re-enabling various opcodes for years.

More Efficient and Private Transactions

BIP 114 is an improvement to Bitcoin’s scripting system that would increase efficiency and privacy of conditional transactions. Under the current scripting system, the conditions by which a bitcoin output can be spent are public. Lau explained how this is a problem for privacy:

“It’s bad for privacy. The more conditions you reveal on the blockchain, the more clues are given to a blockchain analyst to identify the purpose of the transaction or the identities behind.”

According to Lau, MAST would improve upon this setup by only requiring users to reveal one condition for the spending of a bitcoin. Because less data needs to be public, transactions can also take up much less block space. Lau added, “Conditional scripts are not common today. But payment channels, like Lightning Network, will use conditional scripts extensively, and MAST could be very useful.”

Atomic Cross-Blockchain Exchange

New opcodes can also enable trust-fee exchanges of tokens between different blockchains. Although CHECKPRIVATEKEYVERIFY designer Tier Nolan has proposed a new opcode for this purpose, Lau told CoinJournal, “I just show that the same effect could be achieved by re-enabling OP_CAT (or OP_SUBSTR).”

The trust-free nature of these exchanges is enabled by Peter Todd’s BIP 65, also known as CHECKLOCKTIMEVERIFY.

The way this process works is, essentially, a bitcoin user pays a user on an alternative blockchain for the private key associated with the address on the other chain. In addition to trustless altcoin exchange, this functionality may also enable trustless exchange between Bitcoin sidechains.

Trust-Free Betting

Provably-fair betting is a concept that has been associated with bitcoin casinos since the early days of Satoshi Dice. Lau explained how this feature is applied in practice:

“Many bitcoin casinos improve on traditional online casinos by pre-announcing the hash of the random number before the customer places a wager. If the casino wins, it could show that the random number was generated before the wager is placed and not modified.”

“However,” Lau added, “theoretically, the casino may still run with the money if it loses too much in a single bet. So this is not really trust free.”

Lau went on to describe how re-enabling XOR and RSHIFT (or a few different opcodes) would allow two anonymous individuals to wager against each other in a trust-free manner. He explained:

“We could allow two people to both be the dealers at the same time. They will both generate a random number individually, reveal them, combine them, and use the result to determine the winner.”

Lau added that the two players would both need to provide collateral in order to avoid third-party arbitration. This is similar to a concept that has been applied in some Bitcoin markets, such as BitMarkets, to enable low-trust online commerce. As a way to explain the goal of these sorts of 2-of-2 multisig escrow systems, Lau stated, “Being uncooperative is more expensive than losing the bet. No one should be uncooperative.”

According to Lau, an unlimited number of bets could also take place via payment channels with only the final balances being settled on the blockchain.

What Else is Possible?

When asked about other features enabled by MAST, Lau mentioned larger multi-signature constructs and the commitment of non-consensus enforced data. Both of these features are outlined in BIP 114.

Although Bitcoin’s current multisig architecture supports up to 20 public keys, the construction of these multisig addresses is not efficient. MAST would enable multi-signature schemes that allow for up to 2000 addresses to be used with smaller data requirements than what’s currently available with a 20-address multisignature construction.

MAST also enables more private and efficient “message-only keys,” which allow Bitcoin users to sign a message with a key associated with a Bitcoin address that cannot also be used to spend the bitcoin held by the address. Lau noted, “People may keep the message-only key in a hot wallet, and keep the funding key in a cold wallet.”

This sort of functionality may be useful for Bitcoin voting schemes.

It’s unclear when these opcodes could be enabled in Bitcoin, but Lau noted that Segregated Witness and BIP 9 (Version Bits) can make the process much easier. He also mentioned that the re-enabled opcodes included in his new BIP were also mostly enabled in Blockstream’s Elements Alpha project, and he sees sidechains as “a good way for experimenting with new features.”

Lau concluded, “The implementation is not the difficult part. The difficult part is to make sure the opcodes are really safe, which requires extensive review and testing.”