Messages

more on hierarchical clustering:

The worry is that an attacker will put tiny votes in just the right places to cascade and give himself control of the outcome even though he has a minority of the reputation.
The reason the attacker can do this is because he knows the deterministic rule for how the votes are clustered.
So I think we should salt the clustering rule. Using a random number that the voters didn't know when they were voting.

It would still possible to take control with a minority, but it is probabilistically improbable.

Another easy way to solve this is to just do something like:

``` # detect how far the "truths" are away from actual outcomes
    # then choose closer mode as final truth cluster
    if(L2dist(mode.meanVec, outcomes)<bestDist):
        bestDist = L2dist(mode.meanVec, outcomes)
        best = mode
        bestClusters = clusters
    if(L2dist(mode.meanVec,outcomes)>1.07 and times==1):
        possAltCluster = cluster(features,rep,2,threshold*3)
        return(possAltCluster)```

It's basically a second pass.

This seems to work well in all the test cases I've been able to come up with to throw at it as well as the one Vitalik posted.  If anyone has any ideas for a matrix that could get past this redundancy check, let me know and I'll test it. 

Edit: nvm on last edit, just had a typo in sims!

Yeah, branching is already implemented it's just not in the UI yet.  Will add it in beta. 

"So your saying augur will accept any type of coin created on the ethereum network?"
Yep

"So will fees be determined by a base currency-- but this base currency can be anything?"
Also yes

"Will people be vulnerable to FX risk depending on the base currency used?"
No, it'd be relative to w/e currency you're using (unless you make CFD markets)

"Wouldn't this affect a votecoins payouts, (this screws up Truthcoins Game Theory) if their fees earned are depreciating/appreciating against other rewarded currencies"

I imagine branches would be able to choose what currencies they want to accept (e.g. sidechained bitcoin, stablecoin, ether).  I'd rather let the market segregate based on currency into diff. branches instead of forcing all branches to accept all currencies (which would make your questions above become serious problems)

Keeping secrets stopped developers who were interested in helping Augur for free.

I don't think so; every developer who asked to help was given access to the repo back when it was closed. 

Fair point on Serpent code

Anyway, it's open now

That's interesting, I thought it was always open source.

I'm not sure, but my guess is that other people will be similarly confused. Instead the announcement will be read: "Augur was closed source once for some reason".

You guys were the only ones who reacted this way haha, everyone else understood why it was prev. closed which we had stated multiple places many times (it was really messy & we didn't want feedback yet until some issues were worked out).

I don't like having codebases that don't run or don't run as expected open for public feedback, now that everything runs (at least on a basic level), feedback is great!

I stopped working for Augur largely because of them not being open source.

I thought it was b/c you got more $ working on tendermint

Re Todd: Convo went as follows:
Todd: "I wouldn't recommend building using Bitcoin"
Jeremy: "But you wouldn't recommend ethereum either, correct?"
Todd: "If Ethereum works, you guys will have made the right decision."
I think eth will work, Paul doesn't, not much more to discuss here.

Re oracle leeching:
Although they're a few years off, you could use zero knowledge proofs to achieve this.

Re ethereum changes:
Sure, they can make changes; they've also made many changes to accomodate us (including raising the block gas limit).

Re C++/forking Bitcoin:  Fair point on my C++ skills (I'm the first one to admit that until I built sidecoin w/ Jack I didn't have much C++ experience).  However, there's no reason we couldn't have simply forked BitcoinJ and built using that (it supports full nodes now), except all my other issues w/ forking Bitcoin still apply to BitcoinJ.

Re proof of stake: The Eth team isn't going to implement it if it doesn't work (e.g. they won't be using slasher, that's an out of date blog post by now). 

Secondly regarding Ethereum there are a couple things many in the community seem to forget.  Ethereum can be forked just as Bitcoin can (if they raise gas prices by 100x, there's no reason there couldn't be a chain that does only prediction markets).  Sidechains and Ethereum aren't mutually exclusive.  E.g. there will likely be a version of Augur on Ethermint (because it's hopefully cheaper & faster).

However, building on Bitcoin does destroy one of the *key* amazing things that this technology allows us to do, which is create a distributed oracle system.  If all we can use it for is prediction markets, well, that's cool, but it's nowhere near what could be done if other contracts could ask our oracles questions. 

I think doing a naive implementation of Truthcoin using a fork of Bitcoin would be relatively easy; doing a full true to the paper implementation would be at least one or two orders of magnitude more time intensive than say a simple binary outcome w/ reporting that doesn't have the full feature set.  My experience developing this again confirms the adage, at least for me, (can't remember who said this) that 90% of development time is spent on the last 10% of features.

Finally, our work wouldn't be for naught if Ethereum failed.  We now have a great codified (nearly full) implementation of truthcoin that's easy to read.  Some say you don't really understand something until you implement it, and to some degree, I think that's true.  In fact, if Ethereum failed tomorrow I'd be very disappointed and upset, but I'd have a nice blueprint to move forward with a different implementation, and I'm confident we could build it. 

People love the romantic idea of building on Bitcoin (I did) until they actually build on Bitcoin. With this project we're adding enough functionality that the idea that Bitcoin's security is worth anything is slightly humorous.

It's like taking DOS, building windows vista on top, and saying "but we built on top of a nice secure modular system so it's all good!"  Bitcoin is anything but modular, it's one of the most tightly coupled pieces of open source software (it isn't like gnu/Linux in this sense). Change one thing and 10 other things break, little is well abstracted, almost everything depends on main.cpp and its dependencies.

Completely agree with Martin and Armstrong. Was talking to Peter Todd the other day and he too says it would be a terrible idea to build on Bitcoin (the same reason his proof chains are taking so long).

Oracles can be leeched on *any* implementation of this btw, not a concern unique to eth (I asked Paul's thoughts on this a couple months back and he said he wasn't concerned). I'm somewhat concerned about this

1. It's pretty slow (1999 smartphone as Vitalik always says haha). Since block times are 12 seconds you could only do high frequency trading using something like lightning network, but vanilla eth no. Ethermint will have even faster block times iirc. So it's hard to do TPS estimates a la Bitcoin with ethereum because it's based on gas limits. But if you filled one block with only augur transactions (buying selling shares, etc.) you could fit about 300 tx in. Which gives you 25 transactions per second (this is without Zack's work and without any scalability measures for either eth or augur).

So already better than Bitcoin TPS, and we'll be improving as we implement more scalability measures.

2. Fees for transactions should be pennies (doing the math based off genesis sale that's how much they cost when testing).  I would checkout blog.augur.net (there's a qualitative post I made there why we went with ethereum) and some posts by Jack on improvements to the consensus algo.

So you can use ether to pay for contract execution (but you don't hace to), you can pay with subcurrencies. You can make a market in a subcurrency, so you can use a stablecoin, sidechained Bitcoin, ether, whatever. Speaking of sidechains, I have an interesting idea on how to implement them without the mining concerns expressed on the community, will do a blog post on this soon!


3. So the main thing is scalability additions. There's also the aspect of I want this to be tested really really well. There were going to be some additional features between beta and release, but we're actually a bit ahead on backend work, so they'll probably be mostly all in place by the beta.

I think the key problem with this post was, although it does mention "This idea is the foundation of Augur's event resolution mechanism (as well as that of Truthcoin, Augur's theoretical inspiration)." along with a link, the blog post itself didn't mention a key aspect of Truthcoin. Which is it didn't really go into the reputation system and how you can have varying amounts of it, but the total amount is fixed. 

Sure, the blog post mentions weighting reputation, but if I had never read about this project before I think it's pretty reasonable to assume I wouldn't have made the connection. 

In my interactions with the community I find myself talking about what you've already written the most (I never talk for only a Truthcoin audience). 

I didn't write that post, and it was mostly well received minus that slight confusion above.  What seems to work best is explaining enough of Truthcoin so that the audience can understand what you're talking about, still mention the Truthcoin proposal (whilst not assuming they're familiar with it, at ~40 pages or so it's a lot to assume people have read through), and then lightly touching on value-added.  It is difficult to navigate

I think this is right.  Although the reason most of us use Slack is because things are in so much flux that it's easier to just have a chat rather than a forum thread about something.  Although the Augur slack is open (our IRC currently says "send joey@augur.net or jack@augur.net an email to join our slack where most of our conversations take place"). 

After our alpha's out I think more talk will move to the forums as you said above.  Right now most of the changes just aren't really controversial things, so they happen over a few messages on Slack (e.g. "are we implementing x correctly?" "no, per pg. x of the whitepaper it should be done this way."  "does that make sense?" "yes, because x, y, and z").  More substantial conversations, e.g. "How exactly should the proof of work be done to mitigate front-running?" will be had on the forums once we get to making those sorts of decisions (should be in a few weeks, although UI work for the alpha may push it back a bit). 

More babble.

I could explain why your MSR comments are wrong, but I'm forecasting another derailed thread of me repeating myself endlessly only to be ultimately ignored. I'm not sure I can handle another dose of boredom.

The implication that my great respect for Dr. Hanson would lead me to mis-favor certain mathematical formulas that he published personally (over slight-modifications to those formulas) in the hopes of not offending him is ridiculous.

I ran that LMSR test using your excel file, can post you a link of my test where the cost is 9.999999 with vanilla lmsr vs ls-lmsr if you don't believe it.  Of course, if you think the price is justified when in a traditional parimutuel wager that would be absurd, then my point about ls-lmsr being better in this case is rendered invalid

Edit: Sorry, let me correct that, it's 9.999997

I never claimed to have discovered the flaw, just pointing out that it was the only thing that really concerned me and that since it's easily fixable I wasn't actually concerned.  And that you have not mentioned hashing the votes with a salt in your whitepaper as an alternative to using unconventional crypto practices (which is an improvement for usability & simplicity). 

The problems with LS-LMSR and trading are significantly less than LMSR's (considering you can have a setup of 1000 vs 1100 and buy 10 shares for 1000 vs 1110 and end up paying 9.999999 with LMSR).  Even Hanson agrees with the idea of using some sort of liquidity sensitive market maker; it doesn't offend him if we don't use lmsr   Of course, being an advisor to our project I'd hope you would bring up any further issues with LS-LMSR you know about, but if you want to keep them secret that's fine, LS-LMSR runs better in sims in the vast majority of scenarios compared to LMSR so it'd take a lot of convincing to get us to go with vanilla lmsr.

This flaw isn't critical, the only one to claim that is you, as it's quite easily solvable I don't really care how "critical" it may or may not have been (although without a bond mechanism it does make collusion easy unless one goes with the convoluted reporting technique described in the whitepaper, so perhaps you're right about it being critical)! 

The problem with linear PCA algos is the results vary when run even on the same machine when you rerun the program, that's what this algo solves (which is a major problem if you rely on nodes to get the same result, although you could just implement rounding into the protocol).  It's also much faster.

ECDSA private keys are not designed to be used for encryption, using crypto in unintended ways tends to result in massive failures...  Hash functions are superior to encryption in this use case, that's how I've been implementing it.  "Public key cryptosystems are extremely fragile. Do not use them differently than they were designed." ~ Stack Overflow

The hash function idea has a flaw... I can publish my salt and not-hashed ballot and you can prove I voted a certain way.  Hash functions are pretty simple, so I'm not sure where you got the idea that I'm switching to something I don't understand.  I'm "concerned about" the solution re hashing, which doesn't work due to the reason in this paragraph.

Again, the way to fix this is to use rep. as a bond itself and if I prove someone revealed their vote early I get their rep (which is nowhere to be found in the whitepaper nor any whitepaper talk on hashing votes).  Another improvement people have come up with (Martin I believe) is using a liquidity sensitive MSR and linear time deterministic pca .  Truthcoin isn't perfect, heck, it even has errors in the SVD description in the whitepaper.

The odd ECDSA private key encryption is again expensive, hash functions + collusion checking are a cheap and more intuitive solution, I see no reason why we shouldn't continue to implement it that way (if there is I'd still like to see one, although I haven't yet in these past few messages).

"d. Voters encrypt, sign, and broadcast a
Ballot which contains their Votes and a new public key (for which they have the
corresponding private key)." 

"Voters
reveal the private key used to encrypt their votes in (5), allowing these votes to be
decrypted and read into the consensus algorithm. "

This suggests you're using standard public-private key cryptography, so it's really unclear from the combinations of your examples whether you suggest using symmetric keys (which have the problems I posted above) or pub-private key crypto.  If you are talking about pub-private crypto, you encrypt using your public key, making it so I can share my vote with anyone... which is solvable with Zack's solution.  You do not encrypt using your private key...

Moving on to your FAQ:
"Ballots are encrypted, and contain a new destination (public key), for this reason. Votes are cast in one period, and unsealed in a later period (during which no new votes are cast). Because private keys are required to decrypt, it is always impossible to prove that you've voted a certain way"

Here's an easy way to prove you voted a certain way, allowing one to collude very easily (unless you use zack's soln.):
1) I publish my encrypted ballot using my public key
2) I publish the unencrypted ballot, my public key, and any random person can take the ballot, encrypt it with my pubKey and see that I voted a certain way.  They don't need to take the encrypted ballot and use my private key to decrypt it to discover my vote.

A solution from twelve months ago that fails to take into account the basics of public-private key crypto is also slightly disturbing

If you do have a solution, and can explain it in a step by step manner that's consistent and doesn't mix asymmetric + symmetric crypto and doesn't involve encrypting with a private key, please explain it as I'd like to read it.