Topic: Mastercoin as a portable reserve currency between blockchains (Read 3558 times)

Ouch.  I now understand your tone a little bit better.  I hope you realize that this “quick botched work” you’re analogizing is being refined every day.  No one’s done this before, sir.  We want it to be as pure as it can be as well.  The 81 year old thought she’d done a pretty good job (eek).  Using your comparison: we don’t think it’s done yet, we’re looking at just the initial low-res render.  Detail and beauty come with subsequent passes.


This was conjecture on my part with regards to how the BTC client handles the partial BTC blockchain in this scenario.  A matter of saying “I know the current BTC balances.”  Mastercoins do have a conceptual equivalent, however, but are obviously unrelated to those on the underlying blockchain.  I got my comparison muddled with my explanation, my apologies for being unclear.


Agreed, that MSC transactions are not validated by miners, but the RPC transactions on the RPC blockchain are.  MSC@RPC would have “arrived” at some RPC block X when they were imported, and moved around until some other RPC block X+N when they were exported.  If we are certain that every RPC transaction between X and X+N are valid (because this is what the RPC miners are confirming), and the MSC@RPC only lived between those blocks, why would we need the rest of the RPC blockchain?

(edited for clarity)

It is possible only if you can create a compact cryptographic proof that transfers on secondary chain were valid. That is, you need something like this: http://www.scipr-lab.org/

But even a compact proof size is well beyond what Bitcoin blockchain allows you to include into transactions, so, unless you want to split this data over multiple transactions, you need an additional blockchain for these proofs.

Bitcoin clients do not require entire Bitcoin blockchain because Bitcoin was designed with SPV (Simplified Payment Verification) in mind. Clients like Electrum and Multibit already work that way, and it is secure. Then only need to download block headers and Merkle tree branches which confirm transactions they have.

SPV is possible because Bitcoin miners verify transactions and do not allow inclusion of invalid transactions into blocks. If rogue miners includes and invalid transaction into a block, other miners will reject that block, so it is a very expensive thing to do.

Thus we can say that miners are paid in order to make it safe for everyone.

Mastercoin is designed in a different way... J.R. Willett mentioned that the only consideration was simplicity. It is possible to send mastercoins using an ordinary Bitcoin client which isn't mastercoin-aware. All you need is 10-line Python script which creates addresses.

But, well, Mastercoin is completely incompatible with SPV, it isn't possible to verify validity of payments without downloading the whole Bitcoin blockchain.

Comparing Bitcoin and Mastercoin is like comparing left and right paintings here: http://static.guim.co.uk/sys-images/Guardian/Pix/online/2012/8/22/1345647849262/Ecce-Homo-by-Elias-Garcia-006.jpg

One is a work of a genius which shows tremendous attention to detail, another is a quick botched work. (Backstory: 81 year old woman tried restoring painting in church, not recognizing that she is ruining it, probably due to bad eyesight.)



How is it relevant to Mastercoin? It isn't tied to unspent transactions in any way.


You absolutely need to track all transactions on RPC blockchain to check validity of transfers. Mastercoin transactions are not validated by miners, so their validity shouldn't be taken for granted.

Ok it’s 2:15am.  Here’s a crazy idea.

Don’t (almost) all of the current altcurrencies still use secp256k1 as the elliptical-curve algo for the raw public/private key pairs?  If so….

Could all that we need to know about the alt chain is which hashing method is used to encode it’s addresses, such that by using the same *raw* ECDSA private key to sign both sides of the transaction on both blockchains… we therefore have an absolute reference, once they’re matched?

Sure, the addresses would look different, but they’re just that alt chain’s way of encoding the secp256k1 key pair.

I can’t tell if that would just validate that both sides were done by the same entity better, or if this can be carried along until eventual export...

The import problem.  I’ve been noodling on that one myself.  Not sure if there’s an easy answer yet.

However.

Everyone seems to agree that eventually, the end-user client will not need the entire BTC blockchain.  By that time, I assume there will be a mechanism to keep perhaps the most recent unspent transactions (some subset of the blockchain), and be able to query the surrounding network for missing information or validation, if needed (perhaps reach “consensus” on missing info?).  If this will (eventually) be the case, or something like it, then the necessary “following of the second chain” will be as straightforward (simple?) as following the necessary info on the primary chain.

But maybe it’s not that difficult.  We’re already talking about the race-condition concerns on the distributed exchange (a lot can happen in 10 minutes), so there may be talk of “sniffing” the unconfirmed transactions before they are locked in a block.

In the first scenario above, the difficulty is validating the “import” on the receiving blockchain.  For simplicity, let’s say some amount of MSC have been exported off the BTC blockchain previously (to wheverer, doesn’t matter, which we can deal with, they’re exported, they can’t move on the BTC blockchain context anymore), and some MSC suddenly re-appear in a new “import” transaction on the BTC blockchain.  Since we’ve got some number of exported MSC that we know about (since we do follow the BTC blockchain), we know this isn’t impossible.

That new “import” on the BTC blockchain, let’s say, will be coming from the RonPaulCoin blockchain.   But we’re not listening to that blockchain, so we can’t verify that some crazy person didn’t just invent MSC@RonPaulCoin without having received it from some other blockchain at some point prior.  (they came from MSC@BTC originally, obvioiusly, but maybe hopped around on some other blockchain inbetween)

So we see the “import.”  Luckily, the “export” of MSC@RPC occurs in the future (from the BTC blockchain’s import context, remember, the export comes *after* the import), if we began listening to the RPC blockchain at that point in time when we first see the import on our primary BTC blockchain (either right when we sniff the import tx or see it in its first block in the BTC context), we could begin listening for the next several valid blocks to come in from the RPC blockchain, and we wait to see the export.  Once we have it, it includes the address that was meant to receive the MSC@BTC, which “confirms” that at least a correctly formatted “export” of MSC@RPC was performed (yes, assuming many many things, and it sounds like merge-mined blockchains might make this less squiggly), and that at least on the surface, the BTC address used in newly seen “export” tx @RPC matches the RPC address encoded in the import @BTC.

The problem is this: those MSC@RPC could’ve been moving around for quite a while on the RonPaulCoin blockchain, and/or they’ve been sitting in an RPC address for weeks.  Finding the last transaction which would verify the MSC balance of that address, or tracking down their movement between addresses across who knows how many RonPaulCoin transactions would be difficult without having the whole RPC blockchain.  

(Wouldn’t it be nice if there were an easy way to blockstamp “imported” MSC that always hung around with it through all transactions, to provide a reference block to check against for validation purposes?  Then you’d just need what happened between that import block and the export block you’re hoping to validate, and not the whole blockchain)

Also discussed has been an entirely separate “tiny” blockchain whose sole purpose it is would be to track these import/exports… but that seems unnecessary…?  



I agree that in a one-way-only situation, the MSC price may become detached, with a second assumption that it’s either an inefficient market, or if the MSC have lost some of their utility on the new blockchain.  Or, in anticipation of it eventually becoming two-way, the recipient blockchain MSC might trade at a premium ;-)

However, in a two-way situation, an efficient market should make sure that MSC always retain a consistent(ish) value, regardless of the blockchain it’s on, and be related such that MSC/BTC = RPC/BTC * MSC/RPC

Actually, it’s not one-way from the recipient blockchain’s context at this point.  We can’t verify imports ;-)  It’s simple freeze of some MSC@BTC at this point.
...

Trying to vizualize metadata hopping around a bunch of partial graphs on two timescales with only limited context is a fun exercise at 2am.

It seems to me there are obvious answers right in front of us, but which continue to elude us.  But for some reason, I’m convinced they're there.

Related: https://trello.com/c/2PiTRxy7/22-300-document-a-rough-plan-to-migrating-off-the-bitcoin-blockchain-into-a-new-altchain-possibly-merged-mined

My intuition is that there is a way to do this, although I don't have the time to seriously think about this a.t.m.

If mastercoin can be brought back from a secondary chain to main chain, how is it possible to check the validity of such transaction without following the secondary chain? I'm fairly certain that it isn't possible.

If it is one way only, it can work, but price of mastercoins in a secondary chain might be fully detached from price of mastercoin on the main chain.

Very interesting idea, thanks udecker for suggesting it!

If I understand correctly, you always pick two participating blockchains: The Bitcoin Blockchain (or whatever your authoritative source is), and a Secondary Blockchain. Any client that supports this type of operation needs to parse that secondary chain. A Mastercoin client that doesn't wish to parse the secondary chain can still operate normally in side the Main/Bitcoin blockchain.

I think this can work without too much headache (for some definition of "too much").

One good use case would be high(er) frequency trading. You can have an alt chain with a block every 10 second (or even 1 or less second in some cases), and have people interested in doing HFT move MSC to that chain. (Yes, I know that HFT is usually in the sub-millisecond range... I did write higher)

Yes Github would be helpful in this effort. You may want to propose it as part of the Master Protocol spec, if not in the main spec in the appendix.

https://github.com/mastercoin-MSC/spec

As this is meant to be a rudimentary example of a theoretical implementation, it needs additional improvement. 

Would it be beneficial to establish a github repo for this proposal so that others can modify and assist in its refinement? 

Excellent commentary, sir!


A reasonable assumption.  However, the end-result information stored in any blockchain not only is the most accessible to Mastercoin developers (not requiring modification to the underlying blockchain codebase, so long as it conforms to the requirements of the primary blockchain protocol) but also, the OP proposal was created to provide a simple example that anyone without in-depth knowledge of the “innter workings of cryptocurrencies” can understand and provide useful contributions on the general concept of cross-blockchain value portability.  Having more understanding of the inner workings would only enhance the elegance of this proposal’s resultant implementation.


The original Mastercoin protocol proposal used a simlar end-result information mangling method to accomplish its ends.  Since consensus has already been established within the original blockchain's protocol, the Mastercoin protocol leverages that accepted consensus to extend the type of information that has been agreed upon.  Such an abstraction may diverge from the consensus, but the proposed protocol would not be widely accepted (nor should it) without taking advantage of the most important thing about the underlying cryptocurrency.  Responsibility is required!  Breaking consensus is not an option.


This proposal was meant to demonstrate a theoretical possibility with a simple implementation example that could be generally understood.

In the above proposal, one blockchain should be definitive - the one where the “import” is performed (and where consensus is needed so that they can be exchanged on that blockchain with confidence).  If the underlying consensus on previous transactions are respected on the recipient blockchain, the “export” transaction simply accepts that consensus as definitive, and provides it as a reference.  In essence, the recipient (where the MSC ends up) provides the definitive reference used by the originating blockchain.  If you meant that one blockchain needed to be definitive for all transactions, I’m not certain that is necessary, with the below consideration:


Each client used by an MSC holder that wishes to transact on a secondary blockchain does require it to follow that secondary blockchain.  Otherwise, so long as the client understands “exported” MSC, it wouldn’t accept transactions attempted on that originating blockchain when the MSC was in that state, since no consensus can be established beyond “these MSC are somewhere else.  Any attempt to move them around in this state on this blockchain should be rejected."

You’ve made an excellent point, which is: how does one accept consensus from an alternate blockchain without knowing everything about that alternate blockchain?  Is there a common “state” that can be attributed to MSC (such as the “exported” state in the proposal) where knowing about the events on the alternate blockchain are not required for confidence and further consensus once they are intended to be returned to the originating blockchain? 


Since we’re working to decentralize these exchange mechanisms, and working with the fundamental assumption that trust-less exchange is the premise of verifyable transactions, what would be a good example of additional needed information to be included on that blockchain for this to conform and be successful?  If the consensus is required on the recipient blockchain to begin transacting on that blockchain, how can one establish a credible reference?  What additional information is available to be stored on the recipient blockchain to facilitate that assuredness?

Need was only a minor consideration in this proposal, because most are hypothetical.  In the event Bitcoin (or any other) currency/blockchain falls out of favor (or runs into a technical issue of some unforeseen sort), a mechanism such as this would allow for portability of assets to a more robust blockchain and not keep those assets irrevecably bound to a single blockchain.  In the event a liquid market did not exist to exchange MSC between itself and another cryptocurrency, a method of this sort would allow for MSC to exist on that currency’s blockchain for immediate exchange between the two (trading MSC for Feathercoins would be immediate if those MSC lived on the Feathercoin blockchain, for example).

For a "why" that lead to this proposal, for example, could a method be devised that allowed for “dividend” payments to Mastercoin holders that did not require further issuance of currency, and if so, from where would the value necessary derive?  In this case, the import/export method has value (assuming the needs such as presented above are true), and providing such a value in the Mastercoin protocol could feasibly increase the inherent value of Mastercoins for the holders.

The OP implemenation example is just a simple example to show that the underlying idea can be roughly implemented, but that refinement would be necessary to make the solution a proper elegant one.

The main problem with this proposal is that you learned about inner workings of cryptocurrencies via block explorer sites... These sites show information in the convenient way, and certainly you can learn from them, but they don't show you the whole picture.

The most important thing about cryptocurrency is consensus, and your proposal completely sidesteps that... You really need to think in terms of information available to client software, not in terms of what is available on block explorer web sites.

That said, something like this is theoretically possible... But you need one blockchain to be authoritative. Also, there is a problem with amount of information you need to include into that blockchain.

EDIT: Within the Mastercoin model it is possible only if each client follows all blockchains, and even then it's kinda problematic.

following

Interesting proposal, almost any bitcoin-like blockchain could potentially host a mastercoin-like protocol layer, but why do they need to be integrated at all?
 
Cool idea—but might need to outline specific use cases, benefits, and vulnerabilities.

Updated with additional examples and formatting

Proposed below is a loose draft specification wherein the Mastercoin protocol can be extended to allow for cross-blockchain interactions.

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- 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.