Messages

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".

It was closed-source, but we always planned to open-source it as soon as it was live.  Now it's live, so we open-sourced it, as promised!

We just made this announcement and I wanted to share it here:

The Augur team has now gotten all the Augur contracts on the live Ethereum testnet.  All function calls have been tested (albeit naively, with more testing ongoing) and confirmed to be working.  Our code is now open source, and lots of documentation + a graphical UI will be coming very soon!

https://github.com/AugurProject/Augur-core

My claim was specifically that the C++ problems are less-troublesome than the Ethereum problems.

Yep, this is the crux of our disagreement, but you misunderstand a key point: I'm not saying that C++/Bitcoin problems are less troublesome than Ethereum's.  Rather, my point is that both sets of problems are unbounded and extremely hard to quantify.  Therefore, I do not think the assertion that Augur-on-Bitcoin would be more secure than Augur-on-Ethereum is correct.  (In Truthcoin parlance, the question of which would be more secure deserves a 0.5.)

Since I do not have a clear idea of which implementation would ultimately be more secure, to me, the logical default is to choose the version that allows us to build, iterate, and launch faster.  There may, as you say, be many Bitcoin-users who can personally afford to drop tens of millions of dollars; however, my experience fundraising for this project suggests that actually getting those dollars is much easier said than done.  And, a faster build means less up-front funding needed.

While that information is certainly very new and interesting to me, I don't think it is very relevant...open source software of this particular nature is likely to see dozens of people look at it who actually are C++ experts, so the issues you raise with C++ specifically strike me as innocuous. By contrast, it is entirely possible that problems with Ethereum could be fundamentally unsolvable.

In my experience, it's pretty rare for people to do thorough code-reviews of projects simply because they're open-source.  (Particularly if the code bases are large.)  Don't get me wrong: I'm sure, given sufficient time/traction/money-in-the-network, some knowledgeable C++ developers would eventually review the code.  The question is, would these code-reviewers be trying to fix the code?  Or, would they be trying to find bugs so they could use one to crack the network open and suck out all the money?

Maybe they'd start out being helpful volunteers.  Maybe we'd even put up a bug bounty program, to help keep them honest.  But our resources aren't unlimited, and the network gathers more and more money.  "Opportunity makes the thief" -- someone who's honest when seated by an unguarded $50,000 might not be when seated by $500,000.

I think we're treading in very dangerous territory when we start relying on third-party volunteers to secure the codebase.  The codebase needs to be as secure as possible when it's released, and to me that means it must have a reasonable baseline level of security that does not depend on random C++ experts stumbling upon the code and fixing it up for us.

[CryptoSystem]

My position is not that Bitcoin's codebase adds some positive amount of security, it is that each change from Bitcoin represents a loss of security. Truthcoin-on-Bitcoin (ToB) might lose a huge amount...over 50%, over 75%, of the "established stuff" (bug-catching, dos-protection, cryptoecon stability experience), possibly even 99%, as I've repeatedly stated. However, compare this to Truthcoin-on-(py)Ethereum (ToE)...firstly, everything is lost and must be rebuilt, but -and this is the crucial point- more than 100% is lost because there are all kinds of new, potentially unsolvable problems, that may lurk for years before anyone cares enough to call them to anyone's attention.

So we could say:

CryptoSystem	Bitcoin-Security Ratio
Bitcoin:	+1.00
ToB:	+0.01
ToE:	- 9.00

I think what's missing here is that each change to a C++ code base represents a greater average loss in security, compared to a change in a code base that is not C/C++.  Quite a few attacks exist against C/C++ programs -- buffer overflows, formatstring attacks, double-free attacks, etc. -- that simply don't work against programs written in higher-level languages.

How much worse the "starting point" for security would be in C++ vs. a higher-level language obviously depends somewhat on the programmer -- but there's definitely a penalty for using C++, even if you're a C++ expert.  So, I think it would be very easy for ToB's Bitcoin-Security Ratio in your table to drop below ToE's:

CryptoSystem	Bitcoin-Security Ratio
Bitcoin:	+1.00
ToB:	1 - cN
ToE:	- 9.00

...where N is the number of changes made to Bitcoin, and c is the extra amount of vulnerability that inherently comes with having made those changes in a C++ codebase.

Most of the people I've talked to (including you) lack the technical ability to build on Bitcoin. This is nothing against anyone's character or value, but you have (for example) admitted to me that you cannot program effectively in C++. In fact no one on your team, except Jack, seemed even willing to claim to be technically able enough to try to modify Bitcoin's source code. Everyone is the hero of their own story, so it is easy to write off "things that I am not particularly skilled as doing" as "bad ideas".

I have several years' experience with C++.  I don't mind programming in it at all: it's slower to code in than a scripting language, but you get the satisfaction of working close to the metal.  Joey's right about Bitcoin Core being non-modular, undocumented, and difficult to extend.  But, after a couple weeks tinkering with it, it wasn't hard to get inside the code and see my way around.  I thought it was as ugly as just about anything, but the ugly parts felt like armor, which made them alright.  It's neat rummaging through code that's taken such a beating and survived.

Also, Joey and I actually did modify Bitcoin's source code.  We built Sidecoin (http://sidecoin.net).

I mention all this, because I want to make the point as emphatically as possible that I absolutely would not re-architect a project simply because I dislike C++ and/or Bitcoin Core.

So, why did we switch to Ethereum?  A better question might be, why build on Bitcoin?  Augur-on-Bitcoin would take longer to build than Augur-on-Ethereum; there's just more low-level stuff you have to do.  So, absent a compelling reason to build on Bitcoin, Ethereum seems like the obvious default choice.  The main reason you and others have cited for building on Bitcoin Core is security: Bitcoin's source code has been thoroughly fireproofed.  Everyone agrees on this.  Less obvious is what benefits would be conferred on Truthcoin by that fireproofing.

Until you really get into the guts of the implementation, it's easy to think that the changes required to turn Bitcoin into Truthcoin aren't that extensive.  (As late as September, I remember the two of us talking about how Joe Dolinak's cpplib consensus code had already taken care of the hard stuff; around the same time, I confidently told Joe Costello that I thought Truthcoin would take "about 3-4 months to build".)  Really, it was not until I sat down and wrote the Augur whitepaper (http://augur.link/augur.pdf) that it dawned on me the sheer volume of stuff we'd have to change.

The reason this matters is not because it's difficult.  It's because all that stuff would be our code -- meaning, in way too many cases, our implementation would present our lovingly home-made attack surface to the world, rather than Bitcoin's superhardened surface.  And, if it's not helping our security, what is the point of extending Bitcoin Core?

That's why we ultimately went with Ethereum.  It's true that Augur-on-Ethereum will not initially have Bitcoin's security, and that's unfortunate.  But neither would Augur-on-Bitcoin.  What Augur-on-Ethereum does have, however, is a team of very smart people at Ethereum who really want to fireproof Ethereum, and really want Augur to succeed -- and they're willing to spend endless hours working with us to make sure our efforts are in sync.

As for Bitcoin, well...what happened to that genesis block hashing code, anyway?  Try asking in #bitcoin on irc.freenode.net -- I'm sure the natives will be friendly.  They just love altcoins there!

I'm honestly still waiting for people to tell me what they'd use it for.

Truthcoin 

To preface all writing with ( "This article assumes the reader is already familiar with the Truthcoin proposal here" ), seems more reasonable.

That's a good idea.  I thought of the "lie detector" post as being in the Science/Nature style of "friendly, readable intro -- followed by a deep technical discussion that assumes you're well-acquainted with this field already".  I do need to make it clearer what the "field" is here, though!  The post references the Truthcoin whitepaper, but not that front-and-center.

Edited: just updated the post to include a short discussion of Reputation, as well as what sorts of events this method can reasonably address.  Hopefully this -- in combination with links to the Truthcoin and Augur whitepapers -- adds enough context to the rest of the post.