Should the Master Protocol do Scripting?

dacoinminster

Vitalik Buterin, whom I now consider the father of Turing-complete financial scripts, has no less than two features in our spec which were his suggestions. He suggested both the Contract-for-Difference (CFD) bet and the rate-limited wallet.

When we asked Vitalik to look at my proposed implementation of his CFD idea, he came back a few days later with a proposal for a general purpose scripting engine, which he was very excited about, as it would allow Master Protocol users to implement features we haven’t even dreamed up.

Of course, bitcoin itself originally had a number of general purpose scripting capabilities, which have been disabled by the developers. The obvious problem with Turing-complete financial scripts is that hackers will find endless ways to exploit them.

It is instructive to look at the history of HTML and JavaScript. The Master Protocol is currently a lot like HTML. It has powerful functions which are heavily desired by a lot of people. We’re engineering the protocol for the most common use cases. JavaScript is an insanely powerful addition to HTML with endless uses, but it comes with a heavy price – JavaScript engine developers are engaged in a perpetual game of cat-and-mouse with hackers looking for JavaScript exploits.

Imagine how much more intense that battle will be when the prize is not control of a browser, but control of money worth millions or billions of dollars. Financial scripting engines allow lots of interesting niche use cases, but they present a mammoth attack surface to malicious actors.

Still, some very smart people (including Vitalik) are tackling these problems, and I think it is quite possible that the end result will be something useful. Once the painful lessons have been learned, and a battle-hardened scripting engine emerges, that would be a great time to add a similar scripting engine to the Master Protocol.

When Vitalik brought us his scripting engine, I told him that the Master Protocol may very well add scripting someday (citing my logic above), but we needed to get our basic functions in place before we took on something that ambitious. He decided to wade in right away, starting his own initiative on a new block chain.

I have no doubt that his initiative (and many others) who are tackling these huge problems will raise vast quantities of money. Developers are fascinated (for good reason) and investors are salivating. Once they’ve got the kinks worked out, you can bet that the best of their work will show up in the Master Protocol, built right on top of the bitcoin block-chain, which I expect to be the back-bone of the future of finance.

script_warning

Should the Master Protocol do Scripting?

14 thoughts on “Should the Master Protocol do Scripting?”

  1. Luckybit says:

    My opinion is to avoid a turing complete scripting language. It’s a high risk experimental feature. Instead let Ethereum implement that feature and if it does not blow up in their face then implement it.

    When you’re running an experiment you want to try it out first and then if its successful you’ll see it reproduced everywhere else. What reason we we have to use Ethereum if the most innovative and experimental feature is on Mastercoin?

    I think for Mastercoin it’s most innovative feature is escrow backed currencies. Counterparty still has not implemented that but without collateral or escrow backing there is no way for us to trust the issuer will redeem whatever they promise to redeem. Contract for difference is good for issuing derivatives and speculation backed assets but when you want to issue a redeemable token of credit what can you use except for the escrow backed currency feature?

    I agree with the idea of letting Ethereum be the experimental testing field for the cutting edge features. If it is shown that scripting is worth it (and in the long term it probably will be) then it will be implemented eventually but this is money not web pages so the risk is high.

  2. Dan Lafever says:

    I concur with Luckybit as well. At least the way I think about it, deliver a good MSC protocol without scripting to achieve widespread adoption. Adding the scripting engine at the outset could slow things down and add unnecessary complexity to development. I have no doubt that clever fellows like JR and Vitalik will work out scripting challenges over time. If you have ever heard of TRIZ, this would seem to call for a segmentation solution-separating the base MSC protocol from the scripting language. So, segmenting experimental testing of scripting in Ethereum is a direct application of that concept.

    BTW, the level of transparency of MSC development is amazing. Thanks for opening up to the community.

Comments are closed.