Author Topic: Smart Contract without Turing Completeness  (Read 1685 times)

0 Members and 1 Guest are viewing this topic.

clout

  • Guest
Bitshares music isn't handling royalties. I don't intend on using their buy back mechanism and I don't intend on using my own block chain as I would like to ultimately use BitUSD that is used among multiple services.

In general I don't really like BitShares Music's business model and wouldn't want to wait for them to develop the features I want. I highly doubt that they move to the current Bitshares blockchain. As toast explains:

Nobody has decided to make it on BTS yet. That will only be done if NOTE's can *definitely* capture income from music-related transactions, which we have no reason to believe right now.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I personally want to use royalty smart contracts to manage music artist royalties from digital sales and allow for fans to invest in an artist earnings.

Hmm... isn't that exactly what BitShares Music is doing? So, you're in luck, that is being (will be?) developed. I have no idea what the status of that is though (paging @cob). You would have to wait until BitShares 1.0 (or whatever we are calling the stable release) is released before the BitShares Music chain comes out.

Anyway, once it is implemented, I see no reason why that smart contract can't easily be copy and pasted into BitShares blockchain as well. In fact, it may turn out that the Music blockchain features end up just being implemented on the BTS chain.
« Last Edit: February 05, 2015, 02:31:47 am by arhag »

clout

  • Guest

Certainly any features we want to add should first go to DevShares until they are ready to be released in an infrequent bulk upgrade on BitShares. But you still need to coordinate all the dev effort to build it into the development branch of BitShares, then DevShares, and then finally BitShares. The nice thing about Turing complete scripts is that you don't need to coordinate with the core devs to get your pet feature into the codebase and then wait several months until it makes its way to the real BitShares blockchain. You don't need to ask for permission, you can just develop and test the script in isolation and then release it into the wild.


I get that the process does not scale for all variations of smart contracts but I think that there are a select number of smart contracts, royalties being one of them, that are important enough to not be delayed by the development of turing complete scripting environment. I personally want to use royalty smart contracts to manage music artist royalties from digital sales and allow for fans to invest in an artist earnings. I can do it without using a smart contract if the markets are in a USD credit (UIA) that I issue. I'd rather have the market be in BitUSD but I would have to incur the risk that the computer managing the contract might get hacked.

This is a simple contract that can be used for any web based company that accepts BitAssets. For example Crypotfresh.com could have royalties account and anyone could buy and sell cryptofresh assets knowing exactly what they were redeemable for. Such a smart contract would make UIA almost as "trustless" at BitAssets.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
To be honest I just don't anticipate seeing turing completeness anytime within the year.

Yeah. I agree.  :(

Also if upgrading is a problem these features can exclusively be released on Devshares.

I don't get how that really solves anything. If you want the masses to use it, you can't expect them to use it on DevShares.

Certainly any features we want to add should first go to DevShares until they are ready to be released in an infrequent bulk upgrade on BitShares. But you still need to coordinate all the dev effort to build it into the development branch of BitShares, then DevShares, and then finally BitShares. The nice thing about Turing complete scripts is that you don't need to coordinate with the core devs to get your pet feature into the codebase and then wait several months until it makes its way to the real BitShares blockchain. You don't need to ask for permission, you can just develop and test the script in isolation and then release it into the wild.

In theory the upgrades wouldn't matter to a typical user because they would be a light wallet.

A lot of people would want to still run full clients even when light wallets become feature complete for the sake of security. Plus exchanges will likely be using full clients and they aren't going to be happy with us if we keep forcing them to upgrade very frequently.

clout

  • Guest
To be honest I just don't anticipate seeing turing completeness anytime within the year. I think that encoding simple contracts and enhancing their functionality over time could be a faster route to bringing more financial products to market that can compete with whatever Ethereum provides through scripting. Also if upgrading is a problem these features can exclusively be released on Devshares. In theory the upgrades wouldn't matter to a typical user because they would be a light wallet.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I think there are incredibly large number of variations of what you proposed that people can come up with which would also be useful to many people. Which is why Turing completeness is nice because it should allow you to implement this specific smart contract for your needs without needing to force a mandatory upgrade of everyone's clients so that the blockchain can support it natively.

Also what is the advantage of having smart contracts like BitUSD encoded into the block chain as opposed to be created through scripting on the block chain?

It is a trade-off between flexibility and performance. Your example seems simple enough that a Turing complete smart contract could likely be implemented efficiently (not too many instructions that need to run to implement it and thus not too high of a fee to run the script). Implementing a full exchange with order book matching with Turing complete scripting and no native acceleration would probably be a lot slower and expensive to operate than a native feature that it wouldn't be worth the flexibility it provides to change the mechanics without hard forks (plus in the case of BitAssets, holders would probably prefer stability and predictability of its rules and mechanics rather than constant changes).

clout

  • Guest
How trivial would it be to implement a contract feature in which an account holds a specified asset and releases that asset upon receiving a specified UIA?

Lets say there is smart contract account that holds 50,000 BitUSD. I have 500 of the 100,000 the UIA that is linked to the smart contract account. If I send my 500 UIA to the account, the delegate processing the next block would see the account is on a registry of smart contracts and execute the contract instructions by sending me back 250 BitUSD.

This would be a really simple way to encode royalty contracts into the block chain, but I'm not sure if its feasible. I want to use the block chain to distribute royalty payments but I don't want to hold the private keys to the royalty accounts. Any thoughts?

Also what is the advantage of having smart contracts like BitUSD encoded into the block chain as opposed to be created through scripting on the block chain?