Branching

[psztorc]

Side chains appear to be taking too long. I, for one, would prefer not to wait.

However, this design change (to abandon side-chains) alters my concept of 'branching', which solved a number of scalability problems. Instead, it seems that all the branches will have to be contained within one software/blockchain.

This raises some technical questions:
Will this cause blockchain bloat? (Probably not, would be a problem with Bitcoin way before this).
Will people spam the creation of branches? (Probably not, if branch-creation has no strategic impact on blockchain size)
How exactly should branches be created? (One basic idea is to use a colored coins concept, and split a small amount to individuals as desired. This is nice because colored coin technology has already been invented. Absolute care must be taken to make sure that fees are never paid with a share [a colored coin] and always with the basic coin layer).

It does hurt to have to change the design, even this slightly, from my initial January publication, but the original branching proposal would now (in the world of non-side-chains) double the coins with the shares, which is obviously unacceptable.

Normally, I think a lot about problems before I post about them, but since I'm starting a forum with a lot of smart people, I'm just going to throw these half-baked ideas out there and see if a discussion comes back.

[toast]

If you have full control over your chains then there is no reason to go with sidechains. IMO the sidechain proposal is a power grab by large BTC holders and double-sha256 miners. Once you get over the idea that a higher hashrate is always worth the "extra security" it provides, you'll see there is no benefit over just making your own chain.

How exactly should branches be created? (One basic idea is to use a colored coins concept, and split a small amount to individuals as desired. This is nice because colored coin technology has already been invented. Absolute care must be taken to make sure that fees are never paid with a share [a colored coin] and always with the basic coin layer).

The bts toolkit will let you have user-issuable assets that are tradeable on an embedded exchange and that pay fees in the underlying asset right from the get go, a la coloredcoin/MSC/XCP.

[psztorc]

If you have full control over your chains then there is no reason to go with sidechains. IMO the sidechain proposal is a power grab by large BTC holders and double-sha256 miners. Once you get over the idea that a higher hashrate is always worth the "extra security" it provides, you'll see there is no benefit over just making your own chain.

IMHO the primary benefit is not the hashrate, but the money-supply-stability.

[psztorc]

I was thinking it over today, and I like the colored coin idea a little more. It makes creating branches similar to normal transactions. As "normal transactions" already work, this is something I like. Again the crucial thing will be awareness of the colored coins. They can't accidentally be mixed, and people must be able to assess which colors are the 'right' ones to a] make contracts on, and b] own.

A system of tags for the prediction markets (Politics, Sports, etc), coupled with a field tracking the Cumulative Trading Fees of each "color", would be a relatively simple way, I think.

I had always imagined that the PMs would have tags, to be searchable.

[axismoto]

I was thinking it over today, and I like the colored coin idea a little more. It makes creating branches similar to normal transactions. As "normal transactions" already work, this is something I like. Again the crucial thing will be awareness of the colored coins. They can't accidentally be mixed, and people must be able to assess which colors are the 'right' ones to a] make contracts on, and b] own.

A system of tags for the prediction markets (Politics, Sports, etc), coupled with a field tracking the Cumulative Trading Fees of each "color", would be a relatively simple way, I think.

I had always imagined that the PMs would have tags, to be searchable.

How would this work? 
Let's say Bob has one Truthshare with three separate colors: Original Genesis Truthshares (colored red).  FinanceTruthshares (colored blue).  And PoliticsTruthshares (colored white).  Because his Truthshares are colored these three colors, he can vote on all three markets.  However for one week Bob votes on Genesis and Finance Market, but forgets to vote on Politics Market.  Now he faces losing his Truthshares, even though he missed out on one market.  Instead of getting punished for one market, its like he's getting punished by all three. 

Moreover, who will this three-toned coin go to?  Will it go to someone with 5 colors?  Or some lucky fellow who only has one red color?

[axismoto]

Maybe some developer could answer this.  Could a semi-fork be possible, where the votecoin will be forked into two seperate branches, but still use the same truthcoin pool.  like an embedded exchange.

[Bitcoinfan]

Maybe some developer could answer this.  Could a semi-fork be possible, where the votecoin will be forked into two seperate branches, but still use the same truthcoin pool.  like an embedded exchange.

This is an interesting proposition.  This branching issue seems solvable with the Bitshares toolkit. Since the Bitshares Toolkit is moving to a relational database,  its possible to have a function that splits off in a branch. (Although I think it should have to satisfy certain parameters first; not just anybody can split off into another fork.)  When a branch happens, it writes a whole new table and copies all the previous information.  This will allow for the branching effect.  The two tables will have same public key identifier, except now the new table will have distinct table identifier for say TruthFinance shares.  (Or just a new column in voteshares table would be enough.)  This creates a subnetwork, but can still can still share the Truthcoin monetary supply. 

Maybe the delegated proof of stake can help with the logistical problems like who and how to branch.  The requirements for branching could be something on the lines:

1)  At least a 51% agreement by all voteshares in that branch (this can be proposed at any bi-weekly ballet).  The voteshares would also have to cast a representative vote to a delegate
2) The top ten delegates votes on whether to branch or not.
 
Once both Voteshares and Delegates agree on branching for it to happen it can then be executed by the program.   

I suppose once your in a small subnetwork like TruthSports.Basketball.College-- the requirements for branching into TruthSports.Basketball.College.Big East are not as large as the Truthcoin Politics, since you are dealing with a smaller niche network. 

[zack]

I didn't like the old branching idea. It is no good to copy everyone's coins.

I think it is best if juries have a fee for creation. Maybe 10,000 votecoins are created when you make a jury, and 1,000 truthcoins are destroyed.
Each jury has distinguishable votecoins, which are spendable like normal.

Example of somone's account in database: {'address':982378h9yf92f3, 'truthcoins:1000, 'shares':[[8093jf8304jf443fj849, 1, 100], [984320ue383294832, 0, [7823u9jd8328, 1, 1000]]], votecoins:[9824y89324r8932, 10000]]}

they have 1000 truthcoins, and they can win 100 coins in market 8093jf8304jf443fj849 on yes.
They bet 1000 into a market, and it also had a sub-market for that coin. so if you are correct on both bets, you will win 1000 coins.
You bet no in 984320ue383294832 and yes in 7823u9jd8328.

Finally, you own 1000 vote coins in jury 9824y89324r8932

[zack]

Another reason I don't like branching...
I think that a prediction market should be able to use decisions from multiple juries. (from multiple branches.)

If one jury handles who is president, and a different jury handles predicting the future tax rate, a market should be able to combine decisions from those two juries.

[toast]

Since the Bitshares Toolkit is moving to a relational database

Have to add that every time I've said "relational" I really meant "transactional" - there's no relational algebra happening on the blockchain.
Of course the functionality you can implement is still the same - just a nitpick.

[psztorc]

How would this work? 
Let's say Bob has one Truthshare with three separate colors: Original Genesis Truthshares (colored red).  FinanceTruthshares (colored blue).  And PoliticsTruthshares (colored white).  Because his Truthshares are colored these three colors, he can vote on all three markets.  However for one week Bob votes on Genesis and Finance Market, but forgets to vote on Politics Market.  Now he faces losing his Truthshares, even though he missed out on one market.  Instead of getting punished for one market, its like he's getting punished by all three. 

Moreover, who will this three-toned coin go to?  Will it go to someone with 5 colors?  Or some lucky fellow who only has one red color?

No, no, that's not what I'm thinking. By the way I've attempted to rename your "Truthshares" as Votecoins..I realize that changing names is like the worst, but the current names aren't working. Bob would only get punched for his PoliticsTruthshares (PoliticsVotecoins), some of which would be redistributed to other PoliticsTruthshares accounts according to RBCR. Each color would do it's own svd-consensus.

This is an interesting proposition.  This branching issue seems solvable with the Bitshares toolkit. Since the Bitshares Toolkit is moving to a relational database,  its possible to have a function that splits off in a branch. (Although I think it should have to satisfy certain parameters first; not just anybody can split off into another fork.)

Why not? The only real issue is blockchain bloat. This hypothetical is getting a little abstract now, but perhaps the Votecoin-owners would have to 'pay rent', in some sense, in the blockchain. That's actually pretty simple, isn't it. Just some kind of tiny monthly fee. However, remember that version 1 will just have "one branch", so this is just food for thought.

Maybe the delegated proof of stake

Sorry, not going to happen. PoW until Something-Else runs for at least a few years (post about this to come).

I didn't like the old branching idea. It is no good to copy everyone's coins.

I think it is best if juries have a fee for creation. Maybe 10,000 votecoins are created when you make a jury, and 1,000 truthcoins are destroyed.
Each jury has distinguishable votecoins, which are spendable like normal.

Example of somone's account in database: {'address':982378h9yf92f3, 'truthcoins:1000, 'shares':[[8093jf8304jf443fj849, 1, 100], [984320ue383294832, 0, [7823u9jd8328, 1, 1000]]], votecoins:[9824y89324r8932, 10000]]}

they have 1000 truthcoins, and they can win 100 coins in market 8093jf8304jf443fj849 on yes.
They bet 1000 into a market, and it also had a sub-market for that coin. so if you are correct on both bets, you will win 1000 coins.
You bet no in 984320ue383294832 and yes in 7823u9jd8328.

Finally, you own 1000 vote coins in jury 9824y89324r8932

The "old branching idea" was to copy what-are-now-known-as Votecoins. For a number of reasons discussed in the whitepaper, it might sometimes be a good idea to transfer those to existing owners of certain branches, to "import" the reputation of those Voters. Whatever we choose should have the option to do this "importing"-copy in a way that is (a) easy and (b) and easily-understandable by far-away Traders.

Another reason I don't like branching...
I think that a prediction market should be able to use decisions from multiple juries. (from multiple branches.)

If one jury handles who is president, and a different jury handles predicting the future tax rate, a market should be able to combine decisions from those two juries.

It can, actually. Branches handle the Decisions, not the Markets themselves, which are coordinated by time (ie block number) so it will probably be possible.

Have to add that every time I've said "relational" I really meant "transactional" - there's no relational algebra happening on the blockchain.

Yes "relational databse" has a very specific meaning (to me), which is largely irrelevant to what we're talking about.

[psztorc]

Another reason I don't like branching...
I think that a prediction market should be able to use decisions from multiple juries. (from multiple branches.)
If one jury handles who is president, and a different jury handles predicting the future tax rate, a market should be able to combine decisions from those two juries.

It can, actually. Branches handle the Decisions, not the Markets themselves, which are coordinated by time (ie block number) so it will probably be possible.

By "it", I mean the new colored-coin-way. You're right in the old way it would have been impossible.

[asherp]

If the goal is to make it easier for voters to specialize when declaring an outcome, then shouldn't the PM Authors play some role in forming ballots? Don't know if this is technically feasible, but here's one idea for how this could work:

Let's say Author Carol creates a PM for the Dogecoin price. She declares that "those voting on this PM must simultaneously vote on Author Bob's PM specifying the Litcoin price". Similarly, Bob's PM would require voting on Alice's PM specifying the Bitcoin price, but those voting on Alice's PM could do so without voting on Bob's or Carol's. In other words, the ballot corresponding to Carol's PM is a superset of Alice and Bob's. The advantage would be that individually, gaming Alice's PM would be much harder than gaming Carol's, so Carol needs to include Alice's PM if she wants to maximize her trade volume.

This seems natural to me, since the Author is already responsible for making outcomes easy to evaluate and they should know what other PMs will be similar, though I'm not sure how this affects the strategy of the trader... authors would need to take that into account when choosing which set of ballots to include, and the market would penalize them for not doing so (Edit: in the same way that the market penalizes authors for forming ballots that require too much work for the voters, but rewards them for maximizing voter profits.) Also, voters could choose the amount of work they want to commit to, which would allow the pool of voters to scale nicely with demand. The combination of all of the above would make branching much more dynamic and market driven.

Btw, I'm looking forward to your interview on Let's Talk Bitcoin! 

[psztorc]

If the goal is to make it easier for voters to specialize when declaring an outcome, then shouldn't the PM Authors play some role in forming ballots?

They do in a way: they select the branch and maturation-time. Eg Decision: "DJIA close on Feb 18th, 2015", Branch: Votecoins_Finance, Date: March 2015, Then the Ballot that that Decision will in is the March 2015 Ballot on the Finance branch.

Read the whitepaper to learn how the Ballot is used (re: the rest of your post).

Btw, I'm looking forward to your interview on Let's Talk Bitcoin! 

I'm looking forward to being interviewed.

[asherp]

If the goal is to make it easier for voters to specialize when declaring an outcome, then shouldn't the PM Authors play some role in forming ballots?

They do in a way: they select the branch and maturation-time. Eg Decision: "DJIA close on Feb 18th, 2015", Branch: Votecoins_Finance, Date: March 2015, Then the Ballot that that Decision will in is the March 2015 Ballot on the Finance branch.

Right. I'm just trying to think of a way of adding more fine-grained branching than that. One should be able to author a decision that belongs to multiple categories without requiring those voting on it to vote on every category it belongs to. Another problem is that a flood of new decisions could be added to the March 2015 Ballot in the last minute (this could be malicious or it could just be a function of the demand for new decisions) - it seems unnecessary to hurt the reputation of those who have planned to vote for a decision that has been on the same ballot for the last year just because of a slew of new decisions they didn't know about. I'm attempting to solve both problems below.

Read the whitepaper to learn how the Ballot is used (re: the rest of your post).

I think you're referring to Appendix I of Truthcoin_1.1.pdf on missing votes: specifically the calculation of the participation for voter "i" is Sum(VotesCast_i) / sum(VotesExpected_i). I'm suggesting that 1) VotesExpected_i should be dependent on which other decisions i has cast votes for and that 2) this dependence should be set explicitly by the decision authors, so every voter knows which votes are required of them.

The following example illustrates what I mean. Assume all of the following decisions come due on March 2015, but were authored at different times. Decisions {A .. G} are related to general finance and were authored sequentially in time, but the author of G requires that those who vote on G are expected to vote on F, and F's author expects voters to vote on E and so on back to A. Then, a chain of new decisions {H1...K1} are added, which are roughly related to the sub category of assets; here, K1 requires voting on the union of {A .. G, H1 .. K1}. Then, another chain of decisions {H2...K2} are added, roughly related to the sub category of liabilities, such that those voting on K2 must vote on the union {A .. G}{H2 .. K2}. Crucially, those voting on {A .. G} need not vote on {H1 .. K1} or {H2 .. K2}, and those voting on {H2 .. K2} need not vote on {H1 .. K1} and vice versa.

This way everything happens on the same block chain and all categorization is done implicitly. Everyone knows what they're supposed to vote on and can plan ahead of time - they don't have to worry about late decisions harming their reputation. We could even scale to hundreds or thousands of decisions all coming due in the same time period.