Why does Bitshares/Graphene not have a gitter? It seems that it would benefit immensely from having a gitter room where people could openly ask technical questions in real time and be responded to with the help of the community rather than communicating via slow updating forum pages.

Here's a page: https://gitter.im/home

I hope you all consider it. I think it would be a great in addition to the mumble server.

Looks absolutely awesome.

Quote from: VoR0220 on August 04, 2015, 10:44:48 pm

Quote from: toast on August 04, 2015, 01:07:39 am

Graphene can be made programmable while retaining the features that make it fast. For most contracts the necessary language restrictions would not be a problem. For the few where it does, you just have to hard fork.

I think this is both a good thing and a bad thing. The dynamism is excellent. The lack of the trustlessness is what will keep Ethereum in competition.

I'd say the opposite is true. Non of the these systems are trustless. Industry professionals in the payment and exchange industry don't want "trustless" systems where transactions are processed by anonymous entities. In this way Ethereum is not really a competitor. I think that both Bitshares and Ethereum are catering to different markets.

would you mind elaborating?

Not necessarily just that. It can trade with anyone else who has the atomic cross chain code running in their chain. There's a whole bit on it on their website and in an article somewhere...

maaaaaaaaan, now he's not gonna see it  Now we'll never see the beard.

So, I had an idea for a bunch of T-shirts engraved with the faces of all the modern day cryptocurrency heroes slaving away to bring us to a decentralized world. And I started looking up Dan Larimer, and I found this picture:



Look at that manly face! It's so manly I think Chuck Norris is hiding in there somewhere. Dan, bring yo beard back! Chicks dig a beard! Executives dig a beard! Do it! For all of Bitshares!

Every single change set will be relatively small and self contained.

In this commit on a branch I implemented a new smart contract, a payment splitter.

https://github.com/cryptonomex/graphene/commit/c6b848ef18ed80607bfa4e0fde6fbcf38c0f6862

The payment splitter is an object that accumulates payments and once a threshold has been accumulated it divides the proceeds up among several different destinations:
1. another account
2. a market order
3. another splitter (future work)

The code is divided into `operations`, `evaluators`, `objects`, and `indexes`

1. an `evaluator` performs mutations on the blockchain state for a particular `operation`
2. the blockchain state consists of a set of `indexes` on `objects` which can be though of like "tables" and "rows"

So a typical "smart contract" can be thought of as a class

Abstract Example
```

Code: [Select]

class MySmartContract
{
     /// maps to the *_operation structs
     variant  some_operation(  op_field1, op_field2, ... )

     /// maps to the *_object data
     string persistant_data1
     int       persistant_data2
}

/// maps to the *_evaluator
variant MySmartContract::some_operation( op_field1, op_field2, ... )
{

}```

Operations are "decorated" with some meta data such as:
1. required fees
2. required authorities (must be derivable from data in the operation)
3. static validation (independent of chain state)
4. relevant accounts (any account that may have an interest in the operation)

Evaluator's are divided into TWO stages:
1. evaluate - performs invariant and pre-condition checks and ensures the operation is properly formed in light of current blockchain state
2. apply - performs the minimal work to transition the database state and assumes all preconditions are met.

This division between eval and apply allows the blockchain to SKIP evaluate while reindexing and simply apply the state transition.

When does the tutorial for how to go about using smart contracts drop?

IMO the only 2.0 crypto chains to be watching right now are Bitshares and Ethereum. One is overly complex but madly efficient and the other one is solving a previously thought unsolveable problem (that being the problem of ASIC resistance) while being incredibly fun to develop on top of. For the size of the team it has been working with, Bitshares has done INCREDIBLY. I'd say that they've worked way harder than the Ethereum team because the Ethereum team had the marketing to get more people to develop for them (developers love the idea of a turing complete blockchain...who knew?)