Ethereum

[Jack]

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!

[psztorc]

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.

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

[Jack]

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.

[psztorc]

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.

[Jack]

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.

[psztorc]

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

If you argue that you're worried about problems, but you don't argue that Ethereum is less problematic, then it seems that your statement endorses my position, not yours.

Perhaps you intended to introduce an argument that Ethereum would have a large, well-funded team of bug-catchers, whereas Bitcoin would not. I don't agree at all...there are many Bitcoin-users who can personally afford to drop tens of millions of dollars -more than Ethereum's entire operating budget- for a project they like, and that they think will increase the value of Bitcoin and increase their fame, legacy, and influence.

It is a straw man tautology to say you are worried about problems, or that fixing problems is expensive. Only the relative difference between Bitcoin-problems and Ethereum-problems would matter, as I've been trying to explain.

[Jack]

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.

[joeykrug]

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.