Truthcoin Talk 2.0

General Category => Development => Topic started by: psztorc on May 28, 2014, 10:07:29 PM

Title: Branching
Post by: psztorc on May 28, 2014, 10:07:29 PM
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.
Title: Re: Branching
Post by: toast on May 29, 2014, 01:59:58 AM
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.

QuoteHow 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.
Title: Re: Branching
Post by: psztorc on May 29, 2014, 11:40:16 PM
Quote from: toast on May 29, 2014, 01:59:58 AM
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.
Title: Re: Branching
Post by: psztorc on May 29, 2014, 11:44:08 PM
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.
Title: Re: Branching
Post by: axismoto on May 30, 2014, 12:46:06 AM
Quote from: psztorc on May 29, 2014, 11:44:08 PM
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?
Title: Re: Branching
Post by: axismoto on May 30, 2014, 01:00:36 AM


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.
Title: Re: Branching
Post by: Bitcoinfan on May 30, 2014, 12:55:04 PM
Quote from: axismoto on May 30, 2014, 01:00:36 AM


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. 
Title: Re: Branching
Post by: zack on May 30, 2014, 01:21:27 PM
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
Title: Re: Branching
Post by: zack on May 30, 2014, 03:14:08 PM
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.
Title: Re: Branching
Post by: toast on May 30, 2014, 07:14:58 PM
Quote from: Bitcoinfan on May 30, 2014, 12:55:04 PM
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.
Title: Re: Branching
Post by: psztorc on May 30, 2014, 09:49:46 PM
Quote from: axismoto on May 30, 2014, 12:46:06 AM
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.

Quote from: Bitcoinfan on May 30, 2014, 12:55:04 PM
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.

Quote from: Bitcoinfan on May 30, 2014, 12:55:04 PM
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).

Quote from: zack on May 30, 2014, 01:21:27 PM
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.

Quote from: zack on May 30, 2014, 03:14:08 PM
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.

Quote from: toast on May 30, 2014, 07:14:58 PM
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.
Title: Re: Branching
Post by: psztorc on May 30, 2014, 09:52:07 PM
Quote from: psztorc on May 30, 2014, 09:49:46 PM
Quote from: zack on May 30, 2014, 03:14:08 PM
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.
Title: Re: Branching
Post by: asherp on June 02, 2014, 05:50:17 PM
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!  :)
Title: Re: Branching
Post by: psztorc on June 02, 2014, 11:57:50 PM
Quote from: asherp on June 02, 2014, 05:50:17 PM
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).

Quote from: asherp on June 02, 2014, 05:50:17 PM
Btw, I'm looking forward to your interview on Let's Talk Bitcoin!  :)
I'm looking forward to being interviewed.
Title: Re: Branching
Post by: asherp on June 04, 2014, 08:28:46 PM
Quote from: psztorc on June 02, 2014, 11:57:50 PM
Quote from: asherp on June 02, 2014, 05:50:17 PM
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.

Quote from: psztorc on June 02, 2014, 11:57:50 PM
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.
Title: Re: Branching
Post by: psztorc on June 04, 2014, 09:49:56 PM
Firstly, two things you mention are actually good, not bad: It is good to prevent Authors from choosing Voters in any way, because this decreases their ability to collude. It is also good, up to a point, to have large Ballots, as security increases with Decisions / Ballot (more cross validation, and harder coordination).

I think I actually addressed your concern about crowding on page 25 "Intelligent Decision Fees". Its funny you use the example of March, maybe you subconsciously absorbed it from that section. Also, a Voter-wide-participation-decrease is handled in the calculation of Fee1 and in several Tests (specifically at the end of the "Missing Values" section, if Voters protest uneconomical Decision-creation.

You idea might seem fine at first glance, but that is nowhere near good enough. Game theory requires that we consider every single information set, ie every possible state of knowledge of the players. I encrypt Ballots, and produce a zero-sum Votecoin pool, for example, partially so that I don't have to think about how people's m!n! vote-combinations might influence each other (as all talk is equally non-credible). I'm apprehensive by how complicated your ideas are, and about how people would strategize to avoid/not-avoid entering the more powerful A..G group, how that would change with changes in transaction fees in that or other groups. I think the attack-logic would depend on these factors and potentially make the whole thing very confusing for a very small benefit.
Title: Re: Branching
Post by: asherp on June 04, 2014, 10:15:06 PM
Thanks, I appreciate the feedback. It sounds like I need to sit down and learn more game theory, then simulate/test the idea to see if there's any real benefit. In physics we tend to just throw shit at the wall and hope it sticks...
Title: Re: Branching
Post by: zack on June 04, 2014, 11:46:10 PM
The problem you describe: What if many decisions are added at the last minute, and voters are punished for not voting on them?
The solution you mention: Don't punish voters when they fall for this.
My alternative solution: Stop accepting new decisions towards the end to give voters ample time to vote.

I was studying physics until I dropped out of my undergrad last year.
Robin Hanson who invented LMSR had degrees in physics.

I have a basic understanding of "prisoner's dilemma".
What does a person read to learn game theory? What part of game theory matters for PMs?
Title: Re: Branching
Post by: asherp on June 05, 2014, 12:57:57 AM
Well my question is a bit more general: I feel like maximizing the number of people voting is just as important as encouraging them to vote for the truth, so it feels weird that someone who only votes on one thing should be penalized for it. Rather than vote for more things, they may just quit voting entirely.

William Spaniel's game theory channel is pretty accessible
https://www.youtube.com/channel/UCJDIGW0ywWw9Kh9_vtwqxXA
Title: Re: Branching
Post by: psztorc on June 05, 2014, 01:40:30 PM
Quote from: zack on June 04, 2014, 11:46:10 PM
The problem you describe: What if many decisions are added at the last minute, and voters are punished for not voting on them?
The solution you mention: Don't punish voters when they fall for this.
My alternative solution: Stop accepting new decisions towards the end to give voters ample time to vote.
Zack, the true problem I'll describe is that you don't read the whitepaper carefully, and jump to all of these incorrect conclusions as a result. Perhaps, this time, I should refuse to address your question, for fear of encouraging this type of behavior any further.

Adding/removing specifications just because someone somewhere thought of something this morning, and didn't bother to see how their thought related to all of the other moving parts, is not going to create a viable end-product.

It is extremely obvious, to me, why Authors would never create a lot of Decisions last minute, and, even if they did, why Voters would have plenty of time to address all of them, and why they would be happy to do so, and why, even if they didn't have enough time to get to all of them, that wouldn't be a problem for anyone but those who added the Decisions last minute.

Perhaps "proof is left as an exercise" to anyone who wants to guess at the answer(s).

Quote from: zack on June 04, 2014, 11:46:10 PM
What does a person read to learn game theory?
What does a person read to learn physics?

Quote from: zack on June 04, 2014, 11:46:10 PM
What part of game theory matters for PMs?
What we are doing here, designing a Truth-finding mechanism, is only incidentally related to PMs.
http://en.wikipedia.org/wiki/Reverse_game_theory
Title: Re: Branching
Post by: zack on June 05, 2014, 04:11:22 PM
It costs money to make a decision, and there is no time left to profit with. Each decision created can only increase the amount of money that voters earn. The smaller number of voters who do vote on these decisions will take all of the reward?

It is possible to make someone lose a little votecoins, but because the smoothing parameter alpha=0.1, they are bounded on how much they can lose in a single round.

probably there are still things I don't understand...
Title: Re: Branching
Post by: asherp on June 05, 2014, 07:34:41 PM
Quote from: psztorc on June 05, 2014, 01:40:30 PM
What we are doing here, designing a Truth-finding mechanism, is only incidentally related to PMs.
http://en.wikipedia.org/wiki/Reverse_game_theory

Thanks for pointing this out. I would even call this REQUIRED READING before tackling the TruthCoin paper. It explains the theory behind what TruthCoin is doing and why you might have formalized it this way. For example, it's easy to be skeptical of the assertion that TruthCoin incentivizes people to vote for the truth, but if you point them to the section on the Revelation Principle and "truthfully implementable mechanisms" then 90% of the work is done for you and the rest is "just code". I wonder to what extent Satoshi used reverse game theory when designing bitcoin..?
Title: Re: Branching
Post by: psztorc on June 05, 2014, 08:44:50 PM
Quote from: zack on June 05, 2014, 04:11:22 PM
It costs money to make a decision, and there is no time left to profit with. Each decision created can only increase the amount of money that voters earn. The smaller number of voters who do vote on these decisions will take all of the reward?

It is possible to make someone lose a little votecoins, but because the smoothing parameter alpha=0.1, they are bounded on how much they can lose in a single round.

probably there are still things I don't understand...

Very good. Also, Voters have two weeks to submit votes (in my example timeline), regardless of how many Decisions are added or mature in the previous period (Decisions can't mature before they are added).

So Voters probably would NOT lose any votecoins, and just answer all of these questions and take the extra fees. Most likely of all, it would never happen.

Voters would not collect Trading Fees for these Decisions, of course, but that really isn't relevant because the (attacking) Authors don't collect them either AND the attacking Authors had to pay Fee1, so the problem is worse for Authors while Fee1 > Value of the median Voter's Time. (Note that, although each Voter only gets a proportional fraction of Fee1, each Author loses all of Fee1, which is the true purpose of Fee1). As all Decisions must be easily-verifiable (or face the dreaded .5 contingency), this will likely be the case. Voters, as a committed group, have all the power, they can just .5 everything and screw the Authors (the only requirement is that they feel other Voters will act the same way). If someone really did something crazy like add 400 Decisions at the last minute, that weren't used to make Markets and that no one traded on, it would become possible for Voters to coordinate in this way.

Finally, even if they did NOT coordinate in this way, and answered as many Decisions as they could, but not all of them, the protocol would still resolve the Decisions as-correctly-as-possible and, what's more, (they way I designed it right now), Fee1 would automatically increase. I'm actually not crazy about that way of setting Fee1, however. Perhaps just allowing the Votecoins to vote, with a 75% majority or something required to change, would be the simplest and best. Branches should have a little text info idea going over the specialty / rules, and these might need to be changed, which implies a changing mechanism anyway.

I'm more than open to improvements, though. As I said in "Intelligent Decision Fees", Fee1 can probably take some smart improvements.
Title: Re: Branching
Post by: darkmatter7 on August 02, 2014, 05:35:57 PM
We should explore mini-blockchain schemes toward avoiding blockchain bloat:
http://cryptonite.info/wiki/index.php?title=Mini-blockchain_scheme

I believe that blockchain bloat MAY become a problem with the branching scheme without additional technology.  I will investigate this claim more.