Skip to content

Latest commit

 

History

History
89 lines (62 loc) · 4.07 KB

OR_RETURNs_proposal.md

File metadata and controls

89 lines (62 loc) · 4.07 KB
Raw
  BIP:
  Layer:
  Title:
  Author:
  Comments-Summary: No comments yet.
  Comments-URI:
  Status: Draft
  Type:
  Created: 2020-10-12
  License:

Abstract

The purpose of this proposal is getting a commitment to eliminate the restriction that enforces having only a single OP_RETURN output within a transaction. It's a policy change not concensus change. 4 line in node code change e.g. /BitcoinUnlimited/src/policy/policy.cpp.

// only one OP_RETURN txout is permitted
// if (nDataOut > 1)
// {
//     reason = "multi-op-return";
//     return false;
// }

This restriction has to be replaced with one enforces the total maximum size across multiple OP_RETURN outputs within a transaction.

Motivation

The primary motivation for this proposal comes from a desire to combine multiple OP_RETURN based protocols (such as SLP) and to add additional data to token transactions that utilize these protocols. Currently it is not possible to construct a transaction using SLP and append additional data to said transaction. Allowing for such additional data could open up new use case opportunities.

Problem example

One example of such a use case is the current inability to associate SLP fungible and non-fungible tokens with each other.

Every type of SLP transaction (GENESIS, MINT, SEND) for both tokens types (Token Type 1 and NFT1) use OP_RETURN to store their token information. SLP transactions are rendered invalid if any extraneous data are added to their OP_RETURN information. This makes it impossible to combine other metadata or to mix multiple token protocols within a single Bitcoin Cash transaction. Moreover, there is not any other implied way to store arbitrary data on bitcoin cash blockchain within SLP transactions.

Problem actors: Account1, Account2

Steps to reproduce the problem:

  • Create an SLP defined Token Type 1 (Fungible) token (Token Type 1 GENESIS transaction) - TokenFund (N amount owned by Account1)
  • Create an SLP defined NFT "Group" token (NFT Group GENESIS Transaction)
  • Instantiate X number of SLP defined NFT child tokens to X number of transaction outputs (one per output) (NFT Group SEND Transaction)
  • Create an SLP defined NFT "Child" token (NFT Child GENESIS Transaction) - TokenNFTChild1 (owned by Account2)
  • Send N of TokenFund from Account1 to Account2 and associate the amount N of TokenFund to the specific TokenNFTChild1

Single OP_RETURN is already being used by SLP defined TokenFund token. This leaves no way to add metadata that creates an association between the SLP defined NTF1 and SLP defined Token Type 1.

Proposed solution: Add an additional OP_RETURN output that points to the TokenNFTChild1 token ID, which is its GENESIS transaction hash.

Specification

This BIP proposes allowing multiple OP_RETURN outputs in a transaction, but maintaining the same size limit across all OP_RETURN outputs.

Risks

Increase mem pool?

Compatibility

This proposal is backward compatible.

Reference implementation

This reference implementation is trying to exemplify the use case of having a multiple op_return in a single transaction output. By remove the check single op_return from the node policy. That's mean the node have no consensus change and

node code change

https://github.com/BitcoinUnlimited/BitcoinUnlimited/compare/release...ActorForth:feature/regtest-multi-op-return

node

slp serve

http://128.199.203.157:12300/explorer

bch-api

http://128.199.203.157:3000/v3/blockchain/getBlockchainInfo

Copyright

References

  1. BUIP140: Multiple OP_RETURN with shared size limit by Jonathan Silverblood
  2. BUIP149: Delimited OP_RETURNs by Jonathan Silverblood