Show Posts
We can look at the Bitcoin blockchain as the innovative technology that widely-introduced the concept of “verifiable assuredness,” in that each maintainer of the various crypto blockchains becomes, in essence, an “archivist of assuredness.” The mechanisms inherent in proof-of-<hmm> block verification ensure that all previous transactions are valid and universally accepted by the participants in that blockchain. A phrase I heard recently that describes this concept is that each blockchain and its native currency can be considered “Sovereign Chains” or “Sovereign Coins.”
Using this philosophy, the entity addresses that hold the currency of each blockchain can be leveraged as independent, sovereign entities that provide portability of Mastercoin transactions, which allows Mastercoins to be the “carrier” of aggregate value that can be moved between blockchains.
Certain blockchain implementations can even utilize their unique inherent properties to make them better suited for certain types of information storage, and in the case of Mastercoin, wealth portability, universal exchange and used as a means to benefit all holders of both Mastercoin and sovereign coin currencies, as explained further below.
For starters, this would allow an entity’s Mastercoins to be transferred such that they will exist solely on whichever blockchain the holder prefers.
Further down the path, however, it may provide a new methodology for establishing and extending the relationships between various blockchains, establishing fixed-point linkages between them, for reference purposes. Similar to the way hyperlinking technology enabled the concept of the world-wide-web, where disparate information sources were linked together using a universally accepted addressing mechanism, this proposal may allow for future extensions of the Mastercoin protocol to leverage any new blockchain storage and exchange technologies and incorporate them into the total sovereign blockchain ecosystem.
This sample example implementation is designed in a manner such that import/exports between blockchains provide the holder of a certain number of addresses the means to collect, in essence, tariffs that can be distributed back to all Mastercoin holders or for other purposes.
Those familiar with merged-mining may see this as cheating. However, it is a means of binding blockchains together without the need for individual blockchain maintainers to modify their codebases to allow such linkages.
In this example proposed below, we will bind the Bitcoin and Litecoin blockchains at the point of export. An entity address on the Bitcoin blockchain is represented as the origin of the Mastercoins to be exported (the “originating blockchain”), and an entity address on the Litecoin blockchain is represented as the recipient of the Mastercoins being imported (the “recipient blockchain”). We establish the recipient transaction id as the common point of reference between these two blockchains, and simply reversing the technique would provide for the return of the Mastercoins to the originating blockchain.
In a Mastercoin Simple Send transaction, we send a number of related transactions that establish the actual transfer of Mastercoins between entities on a single blockchain.
One of these sub-transactions includes the Cleartext Mastercoin Packet. We will use this particular type of sub-transaction to encode a similar transfer, but instead of transferring the Mastercoin values between two entities on the same blockchain, we will instead use “helper addresses” to facilitate the transfer to another blockchain. While this can be accomplished without helper addresses (by using the Base160 hash of the recipient blockchain addresses in the originating blockchain), this example provides some additional benefits using this method, which will be explained further below.
The current Mastercoin implementation has several “classes” of transaction types, and this technique can feasibly use any of them. For this example, we extend it by adding an extra dimension to the transactions.
To begin the export of Mastercoins from the Bitcoin blockchain to the Litecoin blockchain, we will first make a transaction on the recipient blockchain using, in essence, a Simple Send, but we will consider instead it a “Simple Import.” This establishes the recipient entity address as prepared to import the Mastercoin value.
This puts a certain amount of Mastercoin into a “pending import” state on the Litecoin blockchain. No Mastercoin value is represented on the Litecoin blockchain in this state, since no Mastercoin value was previously represented for this entity address on the recipient blockchain, but the amount of Mastercoin is staged on the recipient blockchain pending a proper “Simple Export” on the originating blockchain (in this case, the Bitcoin blockchain). The protocol can allow for an expiration of this import transaction on the recipient blockchain in the event a matching accompanying “Export” event does not occur on the originating blockchain.
Once a sufficient number of confirmations are received on the recipient blockchain (subject to the commonly accepted practice on that particular blockchain), we accept the transaction ID that will act as the marker for import/export on the originating blockchain.
We encode the first 40 characters of this TXID on the recipient blockchain using the Hash160 -> base58 used on the originating blockchain, which for this example would be MDVAKVHERCX9aSRYTA5wBKweuot5ByXoX, which *almost* resembles an entity address on the originating blockchain. (In the event the first 40 characters of the TXID are considered insufficient for identification purposes, it could be encoded in two base58 address columns instead of just one, but would require the generation of many many more addresses.)
At this point, the import transactions necessary on the recipient blockchain are complete, and are simply waiting on the accompanying “Simple Export” from the originating blockchain.
Here’s where the helper addresses come into play. In order to encode the correct export transfer, we send multiple sub-transactions in a manner resembling a Simple Send on the originating blockchain, but include the helper addresses to identify the entity on the recipient blockchain that will be receiving the Mastercoins.
In this example, it would look like this:
The first column is all 1’s when using the Bitcoin blockchain as the originating blockchain. The second column is the recipient entity address on the recipient blockchain. The third column contain the base58-encoded transaction ID from the recipient blockchain’s import transaction used as the marker.
At this point, once a sufficient number of confirmations have been received accepting these transactions as valid on the originating blockchain, the import/export is complete. The MSC that were in the “pending import” state on the recipient blockchain are now in a “ valid import” state and can be moved around as usual, and the MSC on the originating blockchain are put into an “valid export” state, and cannot be further exchanged on the originating blockchain. In this example, the MSC conceptually no longer exist on the Bitcoin blockchain, and those MSC now exist on the Litecoin blockchain.
The value of the Mastercoins are now represented as being owned by the recipient address on the recipient blockchain, and can be exchanged using the recipient blockchain exactly as specified in the existing Mastercoin protocol.
The purpose of using the helper addresses during Export in this example is to allow for the collection of something similar to “export tariffs.” The creation of a certain number of addresses (private/public key pairs) on the originating blockchain are necessary using this method. By default, in this example, these addresses’ public keys are built into the reference implementation under the control of the Mastercoin Foundation, but can be replaced by a different set of addresses in subsequent implementations for other purposes, or can be eliminated entirely if necessary (or generated dynamically by using the multi-sig method wherein no one owns the addresses).
The first three (or four) characters of each address become the identifiers of the
- the originating blockchain
- the recipient entity address on the recipient blockchain,
- the associated transaction on the recipient blockchain, encoded using the accepted method on the originating blockchain.
The local currency values sent to these addresses represent the tariff amount, and the small satoshi values are used for ordering, so we can be certain that the correct recipient entity address is interpreted correctly to establish the actual transaction.
Once these transactions are considered valid on both blockchains, not only has the MSC been successfully transferred to the recipient blockchain, the holder of the originating blockchain helper addresses can sweep the local currency amounts collected by those helper addresses, and at that point the local currency amounts can be distributed to all holders of MSC on that originating blockchain.
In this example, 0.00340560 XBT have been collected to be equally distributed to all MSC holders on the Bitcoin blockchain.
Using this process, all holders of MSC receive a payment in the local currency of that blockchain whenever an export occurs. The higher frequency of import/exports on the originating blockchain provides larger payments to all MSC holders that keep their MSC on that blockchain where these tariffs are collected.
The purpose of this proposal is to enable three important functions:
- Allow for cross-blockchain portability of Mastercoins, allowing them to
- retain value equivalent to some exchange rate of MSC in the local currency of the blockchain where they exist.
- enable Mastercoin protocol features on other blockchains
- Provide a linkage mechanism between sovereign blockchains for future information relationships between information stored on disparate sovereign blockchains, and
- Provide for payments in local currency to holders of MSC on the blockchain where MSC are exported to other blockchains.
All three of these functions provide additional value to Mastercoin, the Mastercoin protocol, the holders of Mastercoin, and hopefully, the blockchain ecosystem.
Please provide feedback, as this is only a loose draft mechanism that can easily be improved.
