Re: Branching

[somnicule]

Does anyone have thoughts on fixed ballot sizes vs. fixed ballot intervals?

So in a fixed ballot size, a ballot is created whenever, say, 30 decisions mature.

Off the top of my head, some benefits would be:

• Always a sufficient number of decisions in a ballot to limit perverse incentives
• Never an unmanageably large number of decisions in a ballot

And potential downsides:

• Uncertainty regarding ballot dates
• Problems with appropriate weighting of coin redistribution
• Exploitation via. creating decisions to make collusion for 51% attacks easier

I'm not sure if those benefits outweigh the downsides.

[psztorc]

Interesting idea. I hadn't thought of that.

I think I was tied to a time-based ballot so that the the information required would be most easily accessible, since info-accessibility drives which Decisions are possible. Everyone knows that Mitt Romney lost, but how many remember Bob Dole?

I'll think about it some more.

[psztorc]

Firstly, I hope everyone enjoyed the holiday weekend as much as I did. 

New Problem (?): Branch Spam
I've actually been thinking about Branching obsessively, as Branching has now changed to a colored coin. This change may introduce new problems, such as the spamming of branches.

Old Problem: Dying Branches
However, this change may give us the opportunity to solve both this new problem and an older an unresolved problem - a "dying" branch.

The original whitepaper did implicitly assume that there would always be something "at stake" during Voting: the future ListingFees and TradingFees (which would be paid to future Votecoin holders). This would lead people to want to own those Votecoins.

The whitepaper didn't explicitly mention this assumption (that the Decisions would keep rolling in), which I am correcting in a newer version. (I don't know of any other assumptions I've accidentally left out, although that whole section could be clearer).

Basically, if Decisions stop being made on a Branch (say, the Politics branch becomes unpopular because no one makes any political contracts), there will come a time when the Voters are forced into Early Retirement.

Solution: Only Healthy Branches Work
I think the solution is clear from somnicule's comments: not only should the ballot have a minimum size (not necessarily fixed), but it's branch should also have a minimum quantity of future ballots. If the requirements aren't met, the Decisions (and their Markets) can just stall until they requirements ARE met (they would "call in sick").

Then we still have a (small) problem of stalled (but not dying) branches. We could reuse the audit solution, and/or we could allow Authors of stalled Decisions to sign a statement transferring them to another Branch.

To be conservative, we could require 1] that the existing Branch be stalled, 2] the Decision-Author's signature, and 3] the Market-Author's signature.

Solution: Only Healthy Branches Split
What did this have to do with Branch Spam? Well, in nature, a tree only branches when it can "afford" to do so, ie it has enough nutrients and sunlight. We might purposefully sacrifice a some flexibility, and require that Branches already be super-healthy (have many many future Decisions already created), before any split can be triggered. The split itself could purposefully partition these future-decisions (based on tag, for example), and it could all happen more-automatically.

Finally, we could simply ignore the problem. Even with only 1 main branch, we can still potentially do hundreds of PMs a month, which is a big improvement and likely enough for a few years. Other collaborators may think of their own smart ideas during this time.

[zack]

Why do we want to get rid of stalled branches? Someone could create millions of branches as a denial of service attack?

A branch is 2 lists. a list of everyone who owns money in that branch, and a list of decisions that this branch is voting on.

Each branch takes very little memory, and it costs truthcoin to create it. A person trying to attack us by purchasing truthcoin and constructing tons of branches would be pushing the price of truthcoin upward. Such an attack would be counter-productive, because it makes the current holders of truthcoin more wealthy.

Instead of transferring decisions to a different branch, I think it is better to re-ask the same question to a different branch, if only to save lines of code.

[psztorc]

Someone could create millions of branches as a denial of service attack?

A branch is 2 lists. a list of everyone who owns money in that branch, and a list of decisions that this branch is voting on.

Each branch takes very little memory, and it costs truthcoin to create it. A person trying to attack us by purchasing truthcoin and constructing tons of branches would be pushing the price of truthcoin upward. Such an attack would be counter-productive, because it makes the current holders of truthcoin more wealthy.

You are right, the problem isn't the most important. However, each branch must construct a Vote Matrix and run SVD. Smart people today are already worried about Bitcoin scaling. My feeling is that anything that is not fee-regulated will cause the miners / full-nodes to suffer. And for what? I only introduced Branching as a scalability solution. If someone wanted a custom jury, they could create a private contract (as many firms do today), or start an Intrade-like PM business. This is to preserve public access to the institution.

Instead of transferring decisions to a different branch, I think it is better to re-ask the same question to a different branch, if only to save lines of code.

I'm all for minimizing the KLOC. The crucial thing is that people may have money tied up in a Market using a stalled Decision. Then, repeating that Decision somewhere else wouldn't help the Traders with money in that stalled-Market.

Why do we want to get rid of stalled branches?

Imagine someone gives you a train ticket, for a train which takes you a number of cool places. However, the final destination of the train is a horrible fire pit where you will die horribly. You cannot leave the train once you board. Of course, if you learned or suspected this about the train, you wouldn't board it at all.

Our challenge in calibrating this mechanism is similar. People will look forward, and think, "if I put my money into this (board the train), can I guarantee that things will work out for me (won't die)?". If they decide that there is a bad outcome, then that failure-expectation will travel backwards in time to the present, and people will refuse to use the system at all.

Stalled branches are bad, because we don't know in advance which branches (if any) will stall. Neither does anyone else. It is bad for Voters, who don't know if/when the truth-incentives collapse (as a result of early retirement), it is bad for Traders, who do not know if the markets in which they participate will be on healthy branches when the voting-period for their decisions comes around, and finally it is bad for Authors, who can't credibly guarantee that their decisions/markets will be useful to Traders.

It is not completely required, that Voters have future-$$ at stake when they vote (because the non-uniqueness of liar-ballots is substantially dis-coordinating), but it helps a lot. Guaranteeing that the markets resolve correctly is the heartbeat of this project.

[zack]

It is fairly easy to tell which branches are safe from stalling. The really popular one wont stall.
A good wallet could refuse to let you bet on markets that use unpopular branches

What is to stop someone from purchasing an alt-coin that loses value?
A lot of markets in the cryptocurrency world are buyer-beware.

People who are dumb enough to invest in a stalled market lose their money, to everyone else's benefit.

[psztorc]

It is fairly easy to tell which branches are safe from stalling. The really popular one wont stall.

I don't see why it would be that simple. If there is one major branch, then, yes, someone could (wisely) refuse to leave it ever. But what if there are 3 or 4 large branches? Is #2 guaranteed to stay popular forever, just because it is popular today?

If a branch has many Decisions, then Decisions expiring sooner are safer, but what about the latest Decision? It is the most unsafe. Perhaps no one will build Decisions after that one.

How can you tell "which branches are safe from stalling", "fairly easily"? Can you phrase your method using mathematics, to be completely unambiguous?

[zack]

The most recently created decision is not necessarily threatened by a stall.
Instead, the 4 decisions which have the expiration dates furthest in the future are the ones in danger from stall.

Buying 4 decisions that wont expire for a year is the startup cost for making a branch that people will use.

Users who worry about a stall can just make sure to ask decisions which expire nearer in the future than the 4 decisions which expire the furthest in the future.

[psztorc]

Users who worry about a stall can just make sure to ask decisions which expire nearer in the future than the 4 decisions which expire the furthest in the future.

If everyone follows this logic, the branch will stall after a year, meaning that Decisions/Markets will be retirement-attacked at some unknown time before the year is out. In other words, it means the project has failed.

Buying 4 decisions that wont expire for a year is the startup cost for making a branch that people will use.

Not the startup cost, they'd have to do this every year. If they stop, the branch dies, and if people (irrationally or otherwise) think that they'll stop, the branch dies anyway. What credible guarantee can they issue, and what are the costs? Very high, I think.

How can you tell "which branches are safe from stalling", "fairly easily"? Can you phrase your method using mathematics, to be completely unambiguous?

[zack]

"retirement attack" aha!!
Now I think I am understanding you.

How about the creation of a branch costs a big truthcoin deposit, and when the branch stalls, all the votecoins turn back into truthcoin.