Transaction

j"19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAutNà#
# SuperAsset **A Fungible-Token (FT) standard for assets and smart contracts powered by Bitcoin Script and enforced by miners via the normal UTXO consensus rules at the base layer. A novel approach provides the same SPV-guarantees and peer-to-peer distribution for any asset or computation, and practically identical to the native Satoshi tokens.** >Copyright 2020. MatterPool Inc. Released under GNU GENERAL PUBLIC LICENSE v3. See LICENSE below. Attila Aros - Chief Technology Officer, MatterPool Inc. [email protected] Contributors: Dean Little, Daniel Krawisz. Document version 1.0 ## Abstract This paper introduces a novel Fungible-Token (FT) smart contract called "SuperAsset" that has the same properties as the native Bitcoin Satoshi token unit of account. It is backed by the same proof-of-work and consensus mechanism that are enforced by Bitcoin miners. Specifically, we emulate the _conservation of Satoshi quantity_ balancing requirement in _Script_ when spending _colored_ outputs andd we therefore inherit all the capabilities afforded such as SPV, trustless verification and double-spend protection. This is a breakthrough design and the world's first smart contract specification for a truly scalable token asset protocol that has the same "cash-like" peer-to-peer properties that users are accustomed to when transacting in native "non-colored" or "plain" Satoshis. The transaction size and history always grows linearly just like the plain Satoshi UTXOs. SPV works exactly as expected with the identical security guarantees. There is no way to corrupt state, man-in-the-middle, or pull of a replay-attack and furthermore users cannot accidentally destroy ("burn") coins nor spend coins that do not belong to them (Same guarantees as plain Satoshi UTXOs themselves). Building on the concept of a [Bitcoin Agent](https://bitcoinfiles.org/t/77a2928ada60ee24f012a5309f221c52a1b9e15a900a9bb63993340e596b0c15), we introduce a _distributed verification network_ and also introduce a novel and _completely optional_ "asset block committment hash" technique for being able to quickly _check_ if the other Agent operators are claiming to be in consensus or not. The key strength of this technique is that when a problem is detected, the resolution of the corruption is always in the most recent blocks and the UTXO sets can be trivially compared to identify the problem. This design allows anyone to build a fungible (or non-fungible) smart contract asset that are truly distributed and backed by the full power of the Bitcoin proof-of-work system. It works exactly as many have desired for years. Various [colored coins](https://en.bitcoin.it/wiki/Colored_Coins) implementations have been created and none have been able to achieve the _pure Colored Satoshi ideal_, until now. Note: Throughout this paper "Bitcoin" refers to the original protocol "Bitcoin (BSV)". * [Abstract](#abstract) * [Background Theory](#background-theory) * [Essential Requirements of the Ideal "Colored Coins" Solution](#essential-requirements-of-the-ideal--colored-coins--solution) * [Smart Contract Technical Specification](#smart-contract-technical-specification) - [Contract Fields](#contract-fields) * [Contract Methods](#contract-methods) + [Initial Deployment](#initial-deployment) + [Issue](#issue) + [Transfer](#transfer) + [Split](#split) + [Merge](#merge) + [Melt](#melt) * [Consensus and Verification](#consensus-and-verification) * [Economic Disincentive for Attackers](#economic-disincentive-for-attackers) * [Transaction History and Size Calculations](#transaction-history-and-size-calculations) * [Additions and Variations](#additions-and-variations) * [Composability Considerations](#composability-considerations) * [Applications in Various Fields](#applications-in-various-fields) * [Conclusion](#conclusion) * [License](#license) ## Background Theory > This builds upon the concepts described in the paper introducing [Bitcoin Agent](https://bitcoinfiles.org/t/77a2928ada60ee24f012a5309f221c52a1b9e15a900a9bb63993340e596b0c15). The reader may find it helpful to understanding the operaitons of this smart contract design. We want our digital asset protocol to be as efficient as possible and maximally capable like the native Bitcoin system itself - but running inside Bitcoin executed scripts. Specifically we want _all_ of the same benefits and guarantees as the _native satoshi itself is afforded to it by the Bitcoin node_. We want Byzantine consensus at scale, Simplified Payment Verification (SPV), tamper-resistance, trustless verification, and efficient zero-indexing overhead, and the other benefits afforded to the UTXO set and native satoshi value system. This is a system capable of scaling to millions of transactions per second, ultra-low fees and full Byzantine fault tolerance and permissionless smart contracting capabilities that will put Ethereum, EOS, Chainlink out of business. We develop a smart contract that allows _fungible_ types that have an initial quantity supply that can be sent around like regular satoshis themselves (ie: transferred, merged, split, etc). Each satoshi represents an indivisible unit of a token. This means that a satoshi could be worth more or less than the value of the token itself. If the token is worth less, then the owner can _melt out_ the satoshis from the token and thereby destroying the token itself "un-coloring". The key insight is that Bitcoin nodes themselves are pattern matching the coinbase tx coin emissions and their downstream transactions only in a data-structure called _UTXO Set_, which is built up block by block from the chain of valid state transformations (ie: spends). > **Statement 1.0** We define our own "minting events" for colored coins in a matter similar to how any Bitcoin node detects the coinbase tx pattern for coin emission. Any Bitcoin Agent interested in tracking a specific colored coin types can trivially parse outputs for each transaction in a block and pattern match against the (static) smart contract that comprises the logic of the colored coin. Any _efficient_ token indexer will only store transaction histories of interest pertaining only to the tokens it is indexing. Specifically each UTXO should have the entire relevantt parent history so that any independent user or auditor can trustlessly validate the entire parent chain of spends back to a minting event. In other words, we modify the Bitcoin node or agent service to _ignore_ regular coinbases (by not adding the outpoint into the UTXO set) and instead perform a prefix match for the static part of the token minting event outputs it encounters (Blind fast rawhex pattern match against a whitelist of contracts/tokens of interest to the agent).  By making this one modification, it means that when reading raw blocks from the blockchain, in sequence at some starting height, then we can effectively build a _zero-overhead_ UTXO data store that keeps precisely the relevant transactions from the minting transaction and their downstream children only. This forms a coherent UTXO-_shard_. Since this shard is a subset of the total transactions, topologically related amongst themselves in inside and between blocks. There is "zero-overhead" (ie: no extra indexes are required) when compared to a regular Bitcoin 'global' node since the upper bound is identical - in the limit (ie: tracking your colored tokens _and_ coinbase tx emission events) then it simply recovers the full blockchain UTXO set. > **Statement 1.1** A Bitcoin node enforces the proof-of-work and validity of transactions. In particular it conserves the satoshi _quantity_ between the inputs and outputs (and any deficiency is taken as fees by the miner who included that transaction a block they mined).  We will show that we can build a Bitcoin script that is executed and enforced by Bitcoin nodes in the Bitcoin Virtual Machine (BVM) such that we can conserve quantities of arbitrarily "colored" satoshis in a manner similiar to how the Bitcoin node itself enforces the quantity of inputs and outputs. Our strategy for building a token requires the power bestowed to _plain uncolored_ satoshis, but for our colored versions.  > **Statement 1.2:** The _entire_ chain of parent-child spend raw transaction history is required by _some user or service_ to be able to verify authenticity with **zero** trust. Any wallet, user, or service can either proactively pre-index these spends (just like a Bitcoin node pre-indexes satasho spends building up block by block) OR they can retro-actively ask for the _entire_ history from a "coin title history" from the seller of the coins or a blockchain history lookup service. [See: Bitcoin Agent](https://bitcoinfiles.org/t/77a2928ada60ee24f012a5309f221c52a1b9e15a900a9bb63993340e596b0c15) This is not controversional as this is exactly what MatterCloud, ElectrumSV, Whatsonchain, Bitcoin-sv Node, Xoken Nexa, and all other mining and listening nodes perform. That's what a node needs to do to build the UTXO set. They merely proactively index the entire chain of spends of coin emission events (coinbase transactions) and started doing so from block height h=0. We generalize this concept in this paper to apply to indexing arbitrary minting "coin emission" events (ie: any smart contract or asset of interest) starting at some arbitrary block height h. The Bitcoin Whitepaper points out that the chain of digital signatures _is_ the coin. A single UTXO is not a coin. Neither is just the transaction id history. Nor is an SPV proof a coin, and neither is an API response from a blockchain service provider. If you do not have the chain of digital signatures, then you do not _know_ 100% if the coins in hand are authentic. That's the trustless nature of Bitcoin in that everyone can get the complete hisory and _check for themselves proactively or reactively as appropriate_. Every Bitcoin node is proactively indexing this chain of signatures and saving the raw transaction histories for later recall or re-organization. That's how the user or services _knows_ it is authentic. Because they verified the chain or paid someone to do it on their behalf. Such as ElectrumSV with ElectrumX and other "SPV light node" solutions or Bitcoin wallets. > **Statement 1.3:** At some point, a user or service must necessarily process through the history from minting event to subsequent latest spends at least once. Bitcoin nodes enforce consensus rules, however it is up to users and businesses to decide what minting events (and therefore their downstream transactions) are interesting _amongst themselves_. The Bitcoin mining nodes have no concept of "colored" UTXO's, they are just blindly executing the script transition rules.  > **Statement 1.4:** It is desirable to maintain all the guarantees that the native Bitcoin satoshi value itself is afforded. In particular, consensus at scale, SPV, distributed fault-tolerance, tamper-resistance, trustless verification, efficient zero-indexing overhead, immediate spend state corruption detection are a few of the benefits. We need two basic ingredients to make a colored coin smart contract that itself is enforced on the same UTXO layer, contains a 100% self verifiable chain of signatures (following parent UTXO chain), and has the same benefits and guarantees for all satoshis (such as SPV, unforgeability, etc). ## Essential Requirements of the Ideal "Colored Coins" Solution 1. **(Easy)** Mint (and trivially recognize) arbitrary colored smart contract outputs containing satoshis as the 'supply' itself. Example: a supply of a hypothetical DOGEBSV in-game rewards points is decided to be capped at total supply of 100,000,000 units. Therefore exactly 1 BSV (1 million satoshis) needs to be deposited into the smart contract. The individual satoshis themselves represent units of the token. A "DOGEBSV" token could be worth more or less than 1 satoshi. The Bitcoin Node or Agent merely indexes this unspent outpoint as any other transaction, but merely tags it with the color `DOGEBSV` along with the assetId in the case of duplicate symbols. 2. **(Hard)** We need some kind of clever rules in the Bitcoin script spending constraints to preserve colored input and output balancing quantity. Effectively maintaining identity and conservation of value, while avoiding all possible forgery, man-in-the-middle, replay and inflation attacks. This requirement to maintain the correct balance of colored input value to output value has never been solved until now. This is the most important requirement for the case of `merge` function because it prevents a coin from accidentally or maliciously spent in such a way as to inflate supply (awarding the attacker with new "colored" coins that they did not have) and it also prevents accidental burning of the coins. A wallet that doesn't understand the rules will be unable to spend the coins no matter what even accidentally. In other words the solution to this "conservation of value" or "balancing" of colored _satoshis_ enforced at the Bitcoin native scripting is the key to unlocking enormous potential. The bulk of the specification deals with handling the `merge` function as the `split` and `transfer` functions are relatively simple. 3. (**Easy, trivial**) If a corrupt Agent or indexer serves up false state, then we want the full guarantees of the Bitcoin system: a) User cannot accidentally destroy or "burn" their coins. b) User cannot be tricked into spending coins that do not belong to them. c) Service provider or website cannot steal funds from the user. d) User can self-evidently verify the authenticity when provided with the _raw history_ from any service that provides the history (or from the peer user). e) The corrupt Agent can be detected trivially and data replayed quickly to pinpoint exact outpoint that is mismatched in the block update. f) In the case of corrupt state being served, we wish to _know immediately of the problem_ (ie: within the current/last block) so that re-org and corruption damage is bounded (to at most the last 1 block in ~10 minutes). Requirement 1. is easy to satisfy because the token contract code will be constant (static) and can be easily pattern matched and indentified by a Bitcoin Node or Agent via a white list. > "Hello, which smart assets and tokens can I index and show you today? Check the following options...." - Hypothetical Smart Contract Browser Website Requirement 2. Is much more difficult because we need a way to create constraints on the _total input quantity_ compared to the _total output quantity_. The main problem we run into is that _each unlocking input does not have access to each other output directly nor it's value directly when under the BVM execution context_. We will show in the rest of the paper how we can achieve this knowledge and create such constraints. Observe that Requirement 3. is actually a _consequence_ of requirements 1. and 2. because they make the colored coins operation isomorphic to the UTXO satoshi transfers themselves (they piggyback "on top, fused" to the satoshi itself) and we then inherent all the properties and benefits that the Bitcoin system affords. A note about the last point of Requirement 3f), it would be extremely undesirable to detect corruption that happened 1,000+ blocks ago. The recovery effort will be challenging and many systems would have ingested the corrupt data (ie: not-determinstic or fault tolerant), leading to a small mutiny on your hands from your information technology teams and loss of trust with your customers and partners. This problem is fully solved in this specification below and introduces a novel _proof of indexing_ that can be used to quickly detect corrupt service providers or mistakes almost immediately. In the sections below we invent and describe the world's first fully _permission-less fungible asset protocol for Bitcoin_ with identical security guarantees as the Bitcoin system itself. It operates at the speed and efficiency of the UTXO model, it's inherent parallelizability, and extreme low-cost fees with the same (and better) capabilities than Ethereum, EOS, Chainlink, or any other blockchain system provides. The potenial of this technique and algorithm has applications far beyond simple fungible "colored coins" and will form a powerful substrate to carry any incentivized (valued) workload or computation across autonomous agents. The applications of this technology will completely transform the fields of commerce and finance, distributed systems, crowd-sourced intelligence, gaming, reputation systems, automated arbitration and insurance, logistics, amongst many others. We use the following sections to detail the smart contract layout and algorithm for making this a reality. ## Smart Contract Technical Specification The smart contract's output is laid out in the following manner. The fields `[ isMerge prevOuts input1PrevTx input2PrevTx ...]` are present only in the case of the `merge` function and can be omitted for `transfer`, `issue`, and `split`. Transaction Output Layout: ``` ========================================================================================== | | | CODE | OP_RETURN assetID ownerPubKey [ isMerge prevOuts input1PrevTx input2PrevTx ...] | | ========================================================================================== ``` The hardest case is `merge`, so we explore it first. Specifically we are going to discuss an `n-way input` merge that results in combining up to `n` colored input satoshis into a single colored output. The bulk of the complexity for `merge` is dealing with Requirement 2. above for _conserving the satoshi quantity_. This smart contract invention is the world's first solution to solve the `n-way` colored UTXO merge with actually only `O(N)` growth rate in the number of inputs. The challenging part is that each input does not know the other inputs' outpoint or satoshi value. The novel technique we introduce is to place the prevOut bytes and the respective parent input raw transaction bytes into the _one and only colored output_. In this way both inputs **must** necessarily validate that their view of hash(prevOuts) obtained from their preimage matches the prevOuts hash in the output. We must also include each and every rawtx for each colored input, to the end of the output script because that's how we can know the correct satoshi value being spent after we parse the transaction). Here is the information available from the pre-image:  We can see that if we provide the _prevOuts_ in the _single output_ and then we enforce each unlocked input to also have the same hash(prevOuts) (via it's own Preimage) then we can effectively bind the balance to be conserved and validating all inputs and outputs are known in each execution context. Forgeries, attacks, man-in-the-middle, are all not possible. The colored coins can only be spent if they conform to the rules _exactly). #### Contract Fields **CODE** (required): Unchanging static smart contract code. This part remains constant in all transactions for the lifetime of the asset and cannot be changed. Everything after the OP_RETURN is the state data for the instance and must confirm to the rules in `CODE` at each step of the way. **assetID** (required): Set to `000000000000000000000000000000000000000000000000000000000000000000000000` (36 bytes) upon initial deployment to the blockchain. After issuing/minting the asset, then the smart contract enforces setting the `assetID` to the `prevOutpoint` (36B) of the issuing transaction to prevent replay attacks. Tokens cannot be forged without getting a different globally unique identifier making replays and forgeries trivial to detect. **ownerPubKey** (required): Set to public key of initial owner (33B) on minting to initialize. Subsequent transfers can set any new owner. Only the current ownerPubKey can spend the output because the contract enforces a signature to be provided by the current owner to authorize the transaction. **isMerge** _(optional - required to be true only for 'Merge')_ To prevent the UTXO history chain from growing too fast, we enforce that a recently merged UTXO cannot be then again merged immediately. Instead the wallet must do a regular spend or split of the UTXO first before the merge operation can be performed again. This means the entire UTXO history (ancestor outputs) will grow only linearly `O(n)` in the size of the chain of digital signatures going back to the minting event from the particular UTXO's being merged. In other words, the spending transaction cannot include any inputs where `isMerge=true` until it was split or transferred again (when it is then set to `isMerge=false` after a regular transfer or split). This is an inconvenience that can be invisible to the user with a wallet that is aware of the `isMerge` status and can automatically spend them behind the scenes, so that all the user's tokens are always in a "mergeable" state if desired. Without this requirement, then token histories would grow exponentially. We call this technique of "mergeability" a _forward constraint on spends of the parents_. Other token examples that "look backwards" and therefore cannot avoid the super linear factor in storage requirements that renders them useless after a few dozen or hundred transfers. (ie: 42TB in size after +32 transfers) **prevOuts** _(optional - required only for 'Transfer', 'Split' and 'Merge' function)_ Raw bytes of the prevOuts of the current transaction. This gives us the information to know the structure of the sibling prevOuts. It makes the other inputs "knowable" (via hash(prevOuts)) to all inputs in the unlocking execution context. We write this to the single merged output, and each input is enforced to match it's own view of the hash(prevOuts) via the Sigpreimage. This means no other fake or corrupt inputs can be used to spend the transaction. The outpoint (txid+index) array is included in the prevOuts and we therefore can look at the fields `input1PrevTx`, `input2PrevTx`, ... to get the satoshi value of the respective unlocked outpoints. The raw transaction bytes for each of the input parent's are needed because the prevOuts do not contain the satoshi value being redeemed. We must always get that from the complete parent transaction which contains the outpoint and the satoshi value being locked. Observe that the size _prevouts itself_ grows with `O(N)` space and time complexity where `N` in this case is the number of inputs to the current transaction. **input1PrevTx, input2PrevTx, input3PrevTx, ...** _(optional - required only for 'Merge')_ In the case of a merge operation, there must be at least 2 rawtx's of the respective parent previous transactions for each of the colored token inputs. This is required because we must hash the rawtx to arrive at the txid (trustlessly) and then constrain the unlocking prevOut txid+index to it's associated rawtx. Effectively binding severally and jointly each input to the merged output. `SIGHASH_ALL` signature is required on all colored inputs except the 1 funding input UTXO. The number of rawtx's to include is linear in the number of inputs to the current transaction. ## Contract Methods ### Initial Deployment Upon initial deployment, the user locks up a number of satoshis. For example, if the user intends to issue 100,000,000 colored asset tokens, then they lock up that number of satoshis in the "genesis" transaction.  ### Issue The `issue` function gives a unique identity to the asset by enforcing that `assetID` must be equal to the minting txid+index (prevOut) of the `issue` transaction. This can never be changed for the lifetime of the asset in subsequent UTXO's. Any agent can trivially check a UTXO and locate the initial deployment of the smart contract and trustlessly build up the history if necessary. Note: that `SIGHASH_NONE` is used on a funding input (not pictured) that is used to pay the mining fee in non-colored satoshis as normal. Therefor an non-colored change output is also needed.  ### Transfer A simple `transfer` function that allows spending a single input to another output. This is useful for making recently merged outputs to create a "gap" so that there is never 2 consecutive merges in a row. This can also be used to transfer ownership to any other owner. Note: that `SIGHASH_NONE` is used on a funding input (not pictured) that is used to pay the mining fee in non-colored satoshis as normal. Therefor an non-colored change output is also needed.  ### Split A colored asset UTXO can be split to `n-outputs` (2 outputs are pictured), conserving the satotshi quantity so that coins cannot be created or destroyed. Note: that `SIGHASH_NONE` is used on a funding input (not pictured) that is used to pay the mining fee in non-colored satoshis as normal. Therefor an non-colored change output is also needed.  ### Merge Any number of colored inputs can be safely merged with the transaction only growing linear `O(n)` in the number of inputs. After a merge is completed, then the flag `isMerge=true(01)` is set so that the wallet or user cannot accidentally merge an already recently merged UTXO thereby avoiding the exponential doubling in transaction size. The wallet can trivially check the user has unspent coins with `isMerge=true` and then automatically spend them to the same `ownerPublicKey`. This can be invisible to the user, and imposes no cognitive overhead or manual action because it can be fully automated with ease. The only reason `n-input` merging works successfully is because each unlocking input context has it's own preimage and therefore we can impose a mutually binding constraint on every input by _projecting forward the prevOuts and the raw transactions of the immediate prev parents_. Recall that we can obtain `hash(prevOuts)` from the raw prevOuts *and* also from the outputs in the respective parent prev transactions that are also embedded in the output. Note: that `SIGHASH_NONE` is used on a funding input (not pictured) that is used to pay the mining fee in non-colored satoshis as normal. Therefor an non-colored change output is also needed.  ### Melt A user can "melt" (ie: destroy) their asset tokens and redeem the underlying satotshi conttent back to non-colored "plain" native satoshis. A user may opt to do this if the underlying asset becomes worth less than the value of the satoshi. Future versions of this _SuperAsset_ standard could include an immutable _issuerPubKey_ in the initial deployment to allow only the original issuer to "melt" or redeem the colored outputs.  ## Consensus and Verification  Similiar to how the blockhash is a commitment to the transactions in the block, we introduce an optional "asset block committment hashes" that gives independent agents a way to know they have arrived at the same consensus state. This also serves the purpose for informing partners, customers, and even adversaries that consensus state is achieved (or lost, so that the correction can be made quickly and efficiently). The commitment hash is simply the: - hash(blockhash + txids_of_colored_inputs_in_current_block) We can even distribute this "colored token block" in serialized form and merklize the transactions so we could serve mini-SPV-like committments. It is not necessary for agents to use this committment scheme and no additional guarantees are provided except for the convenience notion that a large operator with many Bitcoin Agents can trivially see when a computer or hard drive has become corrupted. Consider the following three Agents and a token type `DOGEBSV` being ttracked by all three. **Agent 1:** ``` DOGEBSV: 650,003: f7a8211a... 650,002: 5de1d2d... 650,001: bf3994a4... 650,000: e4bc9513... ``` **Agent 2:** ``` DOGEBSV: 650,003: ab1802e... (DIFFERENT!) 650,002: 5de1d2d... 650,001: bf3994a4... 650,000: e4bc9513... ``` **Agent 3:** ``` DOGEBSV: 650,003: f7a8211a... 650,002: 5de1d2d... 650,001: bf3994a4... 650,000: e4bc9513... ``` In the example above we can see that Agent 2 arrived at a different committment hash, perhaps because their disk or RAM got corrupted and a bit was flipped. By comparing to at least one other agent, it can be quickly determined what the problem is and recover gracefully. ## Economic Disincentive for Attackers Even though a forgery is trivially detected by inspecting the history or proactively indexing assets of interest, there will still be attackers who attempt to pass off a fake asset, just like they may attempt with fake native satoshi UTXOs. As long as the user makes a request to a blockchain provider to fetch the entire parent history (or demands that a seller of an asset provide their complete copy of the history) then the user cannot be tricked into accepting a fake asset. Notice the disincentive for an attacker: since the supply is one and the same as the Satoshi unit of account it then means they must _give away free fake colored satoshis_. Upon discovering this forgery, the new owner of these fake assest (which themselves are real valuable satoshis) can be melted back for a small tiny profit. ## Transaction History and Size Calculations The size of _output itself_ grows with `O(N)` space and time complexity where `N` in this case is the number of inputs to the current transaction. Even though we embed the _entire prev raw transactions_ it is **still linear** and this will be scalable for n-inputs and not just a 2-input merge scenario. Also let's recognize that the size of the history of the UTXO token state grows linearly for sufficiently large constant `C=2 kilobytes`. Because we do not allow merging immediately after a merge, then the history will grow `O(C*N) = O(N)` which is still linear space and time complexity. If we allowed a merge to immediately follow a merge, then the transaction size would grow double in size with each subsequent merge. That is why it is disallowed. Example: a 4KB output smart contract will grow in size with 3 inputs like so: - Base Input Size: 4kb * 3 inputs = 12 kb - Base Output Size: 4kb * 3 inputs = 12 kb - Parent Input's Rawtx embedded in outputs: 4kb * 3 = 12kb - **Sum: 12kb + 12kb + 12kb = 3*12kb = 36kb** An example with 4-way mergeable inputs: - Base Input Size: 4kb * 4 inputs = 16 kb - Base Output Size: 4kb * 4 inputs = 16 kb - Parent Input's Rawtx embedded in outputs: 4kb * 4 = 16kb - **Sum: 16kb + 16kb + 16kb = 4*12kb = 48kb** ## Additions and Variations Extending the base contract can be done easily, and a number of important vareties can be created. ### Issuer / Redeemer If the issuer enforces that it's issuerPubKey is minted into the deployment, and carried forward in all subsequent UTXOs, then the `melt` function could be changed to allow only spending _to_ the `issuerPubKey` is possible (ie: issuer needs to authorize the redemption or melting) ### Continuous Supply Increases When the contract is deployed, we can create two outputs: 1 for `issue` and another for a `supplyIncrease` output. This second output represents a "supply increase output baton" that can be spent by the issuer to increase supply of the token quantity. This can be a useful technique for also 'recycling' coins to reduce the history for the users of the token asset. And of course it is inherently useful for coins which naturally get lost or decay and must be replenished. ### Non-Fungible Token Variation We can create a Non-Fungible Token (NFT) where the satoshi value is equal to 1 (then by definition it is non-fungible). However we wish to make a modification that does not allow `merge`, nor `split` but instead allows a single quantity of Satoshis (say 100,000) to be _fused_ into the NFT which in essence acts as a kind of "bitcoin reserve value" on the price floor of the asset. ## Composability Considerations The specification and examples above use an Address (Ripemd160) for change address output. However this need not be the case and we can allow _any_ other valid output to receive the change. The only restriction we must enforce is that this change output does *not* contain the constant static part tof the `CODE`. We must ensure the change is not-colored and that is how we can enforce it easily. Furthermore, by allowing any funding inputs to be added, other smart contracts can interact with this contract and be used to trigger various events. More work needs to be done to explore this area. ## Applications in Various Fields **Voting**: By issuing 'voting tokens', then each UTXO holder can update a `payload` via a potential `updateState` method that can express a voting preference. Resolving the current voting result status is siimply enumerating all UTXO's and then aggregating their responses, weighted by total voting token quanitty. **Distributed Computation**: A recursive computation can be incentivized and a value assigned so that independent workers can process the work in parallel and receiving the 'reward' for their work by 'melting' down the token upon submission of a successful solution to unlock the native satoshis underneath. **Games**: The ability to create non-divisible (in the case of a token supply of 1 satoshi) and divisible assets means users can _own unique property that they control directly_. Games can create an in-game currency that has inherent value because they are backed by satoshis themselves. Items can be "infused with Bitcoin" to give them value. Imagine a powerful sword item with 0.25 Bitcoins that gets passed along to the future owners (hopefully after turning a tidy profit and healthy margin on this one-of-a-kind in game item.) **Logistics and Tracking**: A shipping company can track each vehicle with a unique colored UTXO. When a new stage or delivery checkpoint is met, then the truck driver can update the UTXO state with it's coordinates and status. Real-time analysis is possible and history can be analyzed for patterns. **Trade and commerce**: Businesses and users can easily issue and loyalty points, coupons, and other rewards to increase business and customer options. The nature of the token makes it easy to integrate with any point-of-sale system, reporting requirements, and mobile kiosks in exactly the same way as sending regular Bitcoin cryptocurrency. ## Conclusion This paper introduced a novel Fungible-Token (FT) smart contract called "SuperAsset" that has the same properties as the native Bitcoin Satoshi token unit of account. It is backed by the same proof-of-work and consensus mechanism that are enforced by Bitcoin miners. As a result we inherit all the capabilities afforded such as SPV, trustless verification and double-spend protection. This breakthrough design for a token smart contract specification enables a truly scalable token asset protocol that has the same "cash-like" peer-to-peer properties that users are accustomed to when transacting in native "non-colored" or "plain" Satoshis. The transaction size and history always grows linearly just like the plain Satoshi UTXOs. SPV works exactly as expected with the identical security guarantees. There is no way to corrupt state, man-in-the-middle, or pull of a replay-attack and furthermore users cannot accidentally burn coins nor spend coins that do not belong to them (Same guarantees as plain Satoshi UTXOs themselves). We introduced a _distributed verification network_ upon the conceptual framework of the [Bitcoin Agent](https://bitcoinfiles.org/t/77a2928ada60ee24f012a5309f221c52a1b9e15a900a9bb63993340e596b0c15), w and also introduce a novel and _completely optional_ "asset block committment hash" technique for quickly checking consensus state with other peers. The key strength of this technique is that when a problem is detected, the resolution of the corruption is always in the most recent blocks and the UTXO sets can be trivially compared to identify the problem. This design allows anyone to build a fungible (or non-fungible) smart contract asset that are truly distributed and backed by the full power of the Bitcoin proof-of-work system. ## License GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007 Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/> Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Preamble The GNU General Public License is a free, copyleft license for software and other kinds of works. The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too. When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things. To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others. For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights. Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it. For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions. Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users' freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users. Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free. The precise terms and conditions for copying, distribution and modification follow. TERMS AND CONDITIONS 0. Definitions. "This License" refers to version 3 of the GNU General Public License. "Copyright" also means copyright-like laws that apply to other kinds of works, such as semiconductor masks. "The Program" refers to any copyrightable work licensed under this License. Each licensee is addressed as "you". "Licensees" and "recipients" may be individuals or organizations. To "modify" a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a "modified version" of the earlier work or a work "based on" the earlier work. A "covered work" means either the unmodified Program or a work based on the Program. To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well. To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying. An interactive user interface displays "Appropriate Legal Notices" to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion. 1. Source Code. The "source code" for a work means the preferred form of the work for making modifications to it. "Object code" means any non-source form of a work. A "Standard Interface" means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language. The "System Libraries" of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A "Major Component", in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it. The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work. The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source. The Corresponding Source for a work in source code form is that same work. 2. Basic Permissions. All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law. You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you. Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary. 3. Protecting Users' Legal Rights From Anti-Circumvention Law. No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures. When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures. 4. Conveying Verbatim Copies. You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program. You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee. 5. Conveying Modified Source Versions. You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions: a) The work must carry prominent notices stating that you modified it, and giving a relevant date.