So, I'm really an outside to coding, and I was wondering if anyone thought Ethereum could do away with the need for multiple coins?
https://www.youtube.com/watch?v=cahj4WJtp20
I couldn't find any mention of it in this forum.
Hello.
If by "multiple coins", you are referring to the two coin types of [1] CashCoin and [2] VoteCoin, then the answer is no.
Those coin types are not some technical quirk, they are logically required. In fact, the addition of a second coin-type to motivate an appropriate self-selection of laborers is one of the most important concepts in this design (and, my guess is, my dual-coin setup will be a requirement for all surviving "Distributed Autonomous Corporations"s that require labor).
For example control+f to " It is a common misconception " under section " [1] Reputational Capital " in the FAQ (http://www.truthcoin.info/faq/).
I'll check it out, thanks! Any thoughts on Ethereum btw?
I'm honestly still waiting for people to tell me what they'd use it for. I ask, every time Ethereum comes up in a discussion.
More details: http://www.truthcoin.info/blog/limits-of-blockchain/
To add to that, the idea of Ethereum is very tech-idealistic (always a bad sign), and allows ample opportunity for (high status) coders to stand out to each other (even worse). Ethereum also appeals to the fears of the Bitcoin community (replacement, obsolescence), which would lead it to get a disproportionate amount of discussion.
I also wonder, why the Ethereum contracts won't just "eat each other" in perfect competition (ie, copy each other while undercutting fees). Also I worry about software rot.
Quote from: psztorc on March 18, 2015, 01:34:39 AM
I'm honestly still waiting for people to tell me what they'd use it for.
Truthcoin :D
Quote from: Jack on March 20, 2015, 08:20:49 AM
Quote from: psztorc on March 18, 2015, 01:34:39 AM
I'm honestly still waiting for people to tell me what they'd use it for.
Truthcoin :D
Of course:
[1] http://forum.truthcoin.info/index.php/topic,90.0.html
[2] http://www.truthcoin.info/blog/limits-of-blockchain/
[3] https://twitter.com/Truthcoin/status/578687698744909824
But ability comes at great cost (review cycles, interactions in software)...why lug around equipment for all kinds of sports, taking up space in your car, when you only want to play basketball? And even Vitalik has expressed his concern that Ethereum contracts will leech each other to death (whereas specialized ones would not, as the miner-requirement actually works for you -not against you- in such a case).
Benefits of building truthcoin on a turing-complete blockchain:
*If we have an idea to make the oracle or market maker better, we could update them without making users download new software.
*We aren't making a gambling blockchain any more, it is a computer. Gambling is just one app. This gives us legal breathing-space to work in.
Benefits of building it onto a custom blockchain:
*It is simpler, so it will have less security issues.
*I estimate it would be 100x faster at doing prediction markets and financial derivatives.
I much prefer the idea of building a specialized chain rather than ethereum's turing-complete mess.
I have studied with Jae Kwon for a month, and learned a lot about proof of stake. I think I can make a really nice truthcoin now.
My employer has me building atomic swap stuff for ethereum https://github.com/zack-bitcoin/ethereum-atomic-swap .
Which is useful for truthcoin too, but I would rather be building truthcoin directly.
Suggesting that it'd be easier to build Truthcoin by making small modifications to bitcoin's codebase reminds me of a quote from this talk (https://youtu.be/lKXe3HUG2l4?t=12m41s) by Joe Armstrong: "Management thinks modifying legacy code is cheaper than a total rewrite." Granted, bitcoin is not as bad as legacy enterprise COBOL from the 1970s. But the Augur team's experience of modifying bitcoin to create "sidecoin" was what motivated the switch to ethereum script (even unstable as it is, it's still preferable).
The transition from "DApps as desktop apps" (ie. bitcoin-qt, electrum, openBazaar, namecoin, bitmessage, lighthouse, uTorrent, and so on) to "DApps in a browser" would be analogous to how the average internet user's software stack changed as web browsers became more powerful. Next to the Netscape 1.0 icon on windows 3.1, there was also a desktop app for newsgroups, another for e-mail, another for real-time chat, another for ftp, and so on. Nowadays, most people browse forums, send e-mail, and chat using different apps that run on the same higher-level platform (the web browser as "the new OS"). Ethereum is attempting to do something similar with crypto-currency/p2p clients. The vision for BitTorrent Inc.'s Project Maelstrom (also utilizing Chromium, like Ethereum's Mist) is along similar lines, but they're starting as a torrent client rather than as a crypto-currency client.
Bitcoin isn't legacy code...it is running right now. In fact, it is the most robust, most up-to-date version of "blockchain code". It does not get any less legacy than this, which is exactly my point: Bitcoin is being used today, Bitcoin is being updated today, Bitcoin is being audited for security and stability today, March 26th, 2015.
If Joe Armstrong (who specifically uses the word "sometimes", by the way, which would seem to indicate his usual agreement with management...even before we set aside our comments about how cheap talk can be when it is in the form of an offhand presentation joke) wants to rewrite the operating system as well as the application, I won't try to stop him. But people ask for my advice, I give it to them: embrace software modularity, do not leave Bitcoin.
As you know, I believe that: Just as people realized that a web browser could replace all of those other things (no need for a separate "chat application"), they will realize that Bitcoin can replace everything Ethereum plans to do, except oracles (where the Truthcoin sidechain comes in).
Ethereum is a complex, new operating system. While it is "technically" simpler than Bitcoin, it is economically/strategically several orders of magnitude more complicated. No one can even address Vitalik's concern that oracle-contracts will leech each other to death, and I have dreamed up all kinds of nightmare scenarios. It is like trying to go game theory in a game where anyone can cheaply introduce a new game at any time ..."metagame theory". On principal, practically by definition, it is impossible to predict or understand what will happen to the system as a whole or its many interacting pieces.
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
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.
They cannot even get atomic swaps to work on bitcoin. Transaction malleability ruins it.
I doubt bitcoin or ethereum could ever be good enough to run truthcoin.
If Jae Kwon's blockchain isn't good enough for truthcoin, then I'll make another single purpose blockchain, even better than last time.
Quote from: zack on March 28, 2015, 08:12:15 PM
They cannot even get atomic swaps to work on bitcoin. Transaction malleability ruins it.
I doubt bitcoin or ethereum could ever be good enough to run truthcoin.
If Jae Kwon's blockchain isn't good enough for truthcoin, then I'll make another single purpose blockchain, even better than last time.
Zack,
Why isn't ethereum good enough to run truthcoin?
Quote from: joeykrug on March 28, 2015, 05:46:01 PM
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).
His proof chains will probably end up actually being used by someone, though. More importantly, I do not suggest anyone build "on" Bitcoin the way Counterparty is (and that is how PT would interpret such a phrase, if you didn't clarify), I merely advise taking a recent fork of the Bitcoin codebase as a starting point and design framework. Feel free to invite PT to the forum to explain what he would use instead, I would be surprised to hear him say "start from scratch in Python, and then use the Python flavor of Ethereum", and, what's more, I'd be happy to wager with him on what's more likely to be in use a year later.
Quote from: joeykrug on March 28, 2015, 05:46:01 PM
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
One of the reasons I am not concerned about leeching is because I believe that Ethereum will fail. I'm interested in how you would leech from a Truthcoin sidechain...build another sidechain? One example: If not merged mining, how do you acquire miners? If merged mining, why would miners mine both?
Quote from: joeykrug on March 28, 2015, 05:54:21 PM
People love the romantic idea of building on Bitcoin (I did) until they actually build on Bitcoin.
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". Code is hard to understand...experts agree that writing your own new thing is deceptively painless by comparison (http://www.joelonsoftware.com/articles/fog0000000069.html), because the vision in your head ignores all of the labor required (http://en.wikipedia.org/wiki/Planning_fallacy) to polish and maintain the software.
Quote from: joeykrug on March 28, 2015, 05:54:21 PM
With this project we're adding enough functionality that the idea that Bitcoin's security is worth anything is slightly humorous.
It may be worth very little, but it is worth more than anything else (nothing)...your own team has recently complained of Ethereum's occasional changes (gas pricing, use of various types of memory, etc) that -both in the past and in the future- you have to just deal with. Opening yourself up to that kind of
additional uncertainty is a bad idea; it's that simple.
Quote from: joeykrug on March 28, 2015, 05:54:21 PM
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.
I see it more like taking Windows 95, building Vista on top of that, and saying "we tried to introduce as few new/untested things as possible, but it will probably still need a lot of work". Building Truthcoin on Ethereum is like saying, in an alternate universe, "Windows 95 hasn't even been finished yet, and -having not been tested at all (and in fact having never tested anything from Microsoft at all)- might have tons of catastrophic technical bugs, and might be ultra-susceptible to internet viruses, and -come to think of it- we don't actually know if anyone
wants to buy Windows 95 at all, because Ubuntu [Bitcoin] already has nearly 90% of the market share (http://coinmarketcap.com/) and it has already put loads of competitors out of business, and, sure, the guys at Microsoft plan on tearing out the kernel anyway (http://www.reddit.com/r/ethereum/comments/2wi479/when_will_ethereum_switch_to_proof_of_stake/) and replacing it with something that they dreamed up (https://blog.ethereum.org/2014/10/03/slasher-ghost-developments-proof-stake/)...that leading experts openly laugh at and compare to perpetual motion (https://www.youtube.com/watch?v=jE_elgnIw3M&feature=youtu.be&t=1h19m34s), but we've decided we really don't care about that, and so, nonetheless, we're starting work on our flagship Windows application. Look at all the hard work we saved ourselves, by pretending that someone else will do it competently!"
One may argue that Ethereum is designed to be simple, so it cannot amount to something as bulky as any operating system, let alone Windows 95. That would be true, were it not for the fact that Ethereum is designed to have contracts which interact with each other, and can even interact with the behavior of the agents who maintain and operate Ethereum (https://blog.ethereum.org/2015/01/28/p-epsilon-attack/). So Ethereum is much more complicated than Bitcoin,
precisely because it is less restricted.
You are wrong when you imply that I believe that Bitcoin is modular, or intended to be customizable. I do not believe this (although, obviously, it has been customized -in various ways- an overwhelming number of times (http://mapofcoins.com/bitcoin)). In fact, I believe that one of Bitcoin's greatest strengths is how specialized and conservative it is...it is precisely this ability to resist any (unnecessary) change that I find so valuable.
The true romantic blindness is that of young idealistic programmers trying to do everything (Ethereum-style) and allowing mission creep to swell a few good ideas into an unmaintainable monstrosity. Once the maintenance-upkeep is too expensive, software rot inevitably kills the project. In your case, if Ethereum fails, then all of your work is largely wasted, and if a non-Ethereum competitor succeeds, your work will be entirely wasted.
@Bitcoinfan
Augur found a way to make it cheap enough.
My mistake.
Quote from: psztorc on March 28, 2015, 08:55:06 PM
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!
Quote from: Jack on March 29, 2015, 07:07:47 AM
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 |
Quote from: psztorc on March 29, 2015, 04:53:43 PM
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 (http://www.academia.edu/291490/Code_Injection_In_C_and_C_A_Survey_of_Vulnerabilities_and_Countermeasures) 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 (https://news.ycombinator.com/item?id=7565237). 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.
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.
Quote from: psztorc on March 29, 2015, 09:30:07 PM
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.
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.
Quote from: psztorc on March 30, 2015, 01:23:37 AM
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.
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.