killerstorm

If our interest is an append-only database, then each operation can be described as adding entry

E = F(U, Q)

to the database, where U is user data, Q is result of query on the current state of the database, and F is a function which transforms U and Q into what we want to add.

In this case commitment to E can be replaced to commitment to pair (U, Q). So a commitment to database state can be replaced with a commitment to a transaction log, where client creates transactions in the following way:

killerstorm

In the previous message I've described how colored coins can represent prediction market contracts.
It works when we have only two outcomes like YES or NO, but what if want something more flexible, like making a bet on price moves?

Say, we want something like CFD: http://en.wikipedia.org/wiki/Contract_for_difference

In finance, a contract for difference (or CFD) is a contract between two parties, typically described as "buyer" and "seller", stipulating that the seller will pay to the buyer the difference between the current value of an asset and its value at contract time. (If the difference is negative, then the buyer pays instead to the seller.) In effect CFDs are financial derivatives that allow traders to take advantage of prices moving up (long positions) or prices moving down (short positions) on underlying financial instruments and are often used to speculate on those markets.

(Note that what I'm describing here might not work exactly like traditional CFDs, but is probably close enough.
Although it'

killerstorm

RELEASE NOTES 0.10.0 (2019-11-04)


Upgrade instructions: http://rell.chromia.com/en/0.10.0/languageguide/migration-0.10.html


1. Language: Module system

Docs: http://rell.chromia.com/en/0.10.0/languageguide/modules.html

killerstorm

RELEASE NOTES 0.10.0 (2019-11-04)

Upgrade instructions: http://rell.chromia.com/en/0.10.0/languageguide/migration-0.10.html

1. Language: Module system

Docs: http://rell.chromia.com/en/0.10.0/languageguide/modules.html

killerstorm

class user { key pubkey; }

class channel {
  key name;
  admin: user;
}

class channel_member { key channel, member: user; }

class message {

killerstorm

alex=# begin transaction;
BEGIN
alex=# select 20000000000::integer + 1000000000::integer;
ERROR:  integer out of range
alex=# select 1;
ERROR:  current transaction is aborted, commands ignored until end of transaction block

killerstorm

Interest tokens

Token sales are associated with a number of problems, such as high risk, lack of fairness, network disruptions, etc. A good overview of problems as well as possible mitigating strategies are described in V. Buterin's Analyzing Token Sale Models.

In this article I'm going to describe a very simple mechanism which can potentially mitigate some of ICO problems. It has following properties:

1. Incentive to invest early (without it it is usually better to wait until the last minute)
2. No network disruptions
3. Almost no risk for investors
4. Can be used at very early stages

killerstorm

pragma solidity ^0.4.8;

contract PredictionClub {

  struct OutcomeState {
    uint nOutcomeTokens;
    uint nBetTokens;
    uint cumBetTokens;
    uint withdrawQueueBetTokens;
    mapping (address => uint) balances;

killerstorm

Bancor vs Growth Tokens

About a year ago I described a concept which I called Growth Tokens (hereinafter GT). As I recently found out, Bancor is very similar to GT. In fact GT can be seen as a generalization of Bancor as it gives you more parameters to play with. Also Bancor and GT assign different interpretation to virtually the same mathematical formula, so it might be interesting to compare that.

Let's start with going through Bancor model. First, recall the basic formulat for price:

Price = Cost / Quantity

This can be used to calculate price within one transaction, but the formula also works when you aggregate results of multiple transactions:

killerstorm

contract EthGrowthToken {

    uint256 ethBalance = 0;
    
    uint constant depositFeePc = 1;
    uint constant withdrawFeePc = 1;

    // Following function implement growth logic:
    // ether can be converted to and from tokens according to a current price which 
    // is calculated as (ethBalance / totalTokens), however we charge deposit