7 ms·

Completely agree. Judging from the technical description [1] and the most recent version of the draft white paper [2] alone, I think the project would benefit

by gone35 13y ago

Completely agree. Judging from the technical description [1] and the most recent version of the draft white paper [2] alone, I think the project would benefit greatly from more substantial input and expertise from the academic cryptography community. I'm afraid they are spending a lot of effort cargo-culting on the wrong things, while missing where the real challenge lies: How to deal with the inevitable orders-of-magnitude increase in transaction size/complexity while preserving consensus-based distributed verification. To be more precise: The metered computation mechanism is a very clever solution for dealing with unrestricted computation and unbounded data storage, but their proposed solution does not convincingly address the inevitable increase in space required. Hand-waving about greedy subtree verification without actual numbers/scenarios that shows this could work at all (which would be very surprising to say the least) is not convincing. In all a great idea, though. It would be great if it works out. [1] http://gavwood.com/Paper.pdf http://gavwood.com/Paper.pdf [2] https://github.com/ethereum/wiki/wiki/Whitepaper-2-Draft https://github.com/ethereum/wiki/wiki/Whitepaper-2-Draft

vbuterin 13y ago
> I'm afraid they are spending a lot of effort cargo-culting on the wrong things, while missing where the real challenge lies: How to deal with the inevitable orders-of-magnitude increase in transaction size/complexity while preserving consensus-based distributed verification. Umm... that's exactly one of the issues that we're cargo-culting about the most. There are two general categories of solutions to this problem: technical increments (ie. a better constant factor), and fundamental cryptographic upgrades (eg. the stacktrace challenge-response concept we have been talking about on our blog). The first category we are not yet doing because we are following the well established advice of "don't prematurely optimize". The second category, well, that's why we're thinking of ideas like distributed blockchain storage, clever algorithms to force more people to be full nodes, and challenge-response protocols. There is also another idea I was thinking of, which I'll have a post up over the next week or two. In the long term, we are already beginning the development of a very widespread collaboration with academic groups to try to tackle the problems in cryptocurrency, and at this point we fully expect we'll end up releasing Ethereum 2 at some point in 2016 which would take a lot of new cryptography into account.
- nullc 13y ago
  > (eg. the stacktrace challenge-response concept we have been talking about on our blog) You wrote on your blog: > Altogether, what this means is that, unlike Bitcoin, Ethereum will likely still be fully secure, including against fraudulent issuance attacks, even if only a small number of full nodes exist; as long as at least one full node is honest, verifying blocks and publishing challenges where appropriate, light clients can rely on it to point out which blocks are flawed The fact that someone can extract compact proofs of an invalid state transition was pointed out by me years ago (e.g. https://bitcointalk.org/index.php?topic=96644.msg1064601#msg1064601 https://bitcointalk.org/index.php?topic=96644.msg1064601#msg...), and I believe I described it you personally in Mountain View. It's equally applicable to Bitcoin (though not implemented anywhere for any system yet). It's a bit irritating to see ideas from Bitcoin recycled as "innovations" in altcoins and incorrectly claimed as as not applicable to Bitcoin, especially when they're not even implemented yet. This one has a bunch of gnarly engineering issues that make it hard to implement. You end up with fraud codepaths that are virtually never executed, so how do you gain confidence that multiple implementations actually implement them consistently? The best proposal I'd had on this (from bitcoin-wizards) was to always produce two versions of a block, committed under a common root, one which has a random flaw, and then always kill it and select the right block using a proof. But thats kind of complex and indirect.
  - vbuterin 13y ago
    > It's equally applicable to Bitcoin (though not implemented anywhere for any system yet). I don't recall you describing it to me, but it's likely you did and I didn't realize it was important at the time. Also, I never claim that challenge-response protocols are not applicable to Bitcoin; theoretically, we know that any scalability improvement that is applicable to Ethereum would also applicable to Bitcoin simply because you can implement Bitcoin as an Ethereum contract. Rather, I made the claim that Bitcoin _does_ not have full support for such protocols. I count myself among those who are skeptical that substantial changes to the Bitcoin protocol will ever be made, primarily because of the "changing an engine on the run" problem and the nasty political issues involved (see: the recent Counterparty spat). Cryptocurrencies are not sets of abstract ideas, they are protocols that are implemented in code today and have to be judged on their merits as they actually are. And Bitcoin, as it actually is, is not fully secure with a light client.
bachback 13y ago
I believe a solution would look more like what Hal Finney called transparent servers [1]. This would be a way to solve the issue of scaling (and getting rid of mining oligarchs), but also dealing with the necessary privacy issues of contracts. Also DNS is not really a contract between 2 parties, but N parties, and there is a relationship between DNS and contracts (more on that per PM by request). [1] http://www.finney.org/~hal/rpow/security.html http://www.finney.org/~hal/rpow/security.html

by gone35 13y ago

vbuterin 13y ago

> I'm afraid they are spending a lot of effort cargo-culting on the wrong things, while missing where the real challenge lies: How to deal with the inevitable orders-of-magnitude increase in transaction size/complexity while preserving consensus-based distributed verification. Umm... that's exactly one of the issues that we're cargo-culting about the most. There are two general categories of solutions to this problem: technical increments (ie. a better constant factor), and fundamental cryptographic upgrades (eg. the stacktrace challenge-response concept we have been talking about on our blog). The first category we are not yet doing because we are following the well established advice of "don't prematurely optimize". The second category, well, that's why we're thinking of ideas like distributed blockchain storage, clever algorithms to force more people to be full nodes, and challenge-response protocols. There is also another idea I was thinking of, which I'll have a post up over the next week or two. In the long term, we are already beginning the development of a very widespread collaboration with academic groups to try to tackle the problems in cryptocurrency, and at this point we fully expect we'll end up releasing Ethereum 2 at some point in 2016 which would take a lot of new cryptography into account.

nullc 13y ago
> (eg. the stacktrace challenge-response concept we have been talking about on our blog) You wrote on your blog: > Altogether, what this means is that, unlike Bitcoin, Ethereum will likely still be fully secure, including against fraudulent issuance attacks, even if only a small number of full nodes exist; as long as at least one full node is honest, verifying blocks and publishing challenges where appropriate, light clients can rely on it to point out which blocks are flawed The fact that someone can extract compact proofs of an invalid state transition was pointed out by me years ago (e.g. https://bitcointalk.org/index.php?topic=96644.msg1064601#msg1064601 https://bitcointalk.org/index.php?topic=96644.msg1064601#msg...), and I believe I described it you personally in Mountain View. It's equally applicable to Bitcoin (though not implemented anywhere for any system yet). It's a bit irritating to see ideas from Bitcoin recycled as "innovations" in altcoins and incorrectly claimed as as not applicable to Bitcoin, especially when they're not even implemented yet. This one has a bunch of gnarly engineering issues that make it hard to implement. You end up with fraud codepaths that are virtually never executed, so how do you gain confidence that multiple implementations actually implement them consistently? The best proposal I'd had on this (from bitcoin-wizards) was to always produce two versions of a block, committed under a common root, one which has a random flaw, and then always kill it and select the right block using a proof. But thats kind of complex and indirect.
- vbuterin 13y ago
  > It's equally applicable to Bitcoin (though not implemented anywhere for any system yet). I don't recall you describing it to me, but it's likely you did and I didn't realize it was important at the time. Also, I never claim that challenge-response protocols are not applicable to Bitcoin; theoretically, we know that any scalability improvement that is applicable to Ethereum would also applicable to Bitcoin simply because you can implement Bitcoin as an Ethereum contract. Rather, I made the claim that Bitcoin _does_ not have full support for such protocols. I count myself among those who are skeptical that substantial changes to the Bitcoin protocol will ever be made, primarily because of the "changing an engine on the run" problem and the nasty political issues involved (see: the recent Counterparty spat). Cryptocurrencies are not sets of abstract ideas, they are protocols that are implemented in code today and have to be judged on their merits as they actually are. And Bitcoin, as it actually is, is not fully secure with a light client.

bachback 13y ago

I believe a solution would look more like what Hal Finney called transparent servers [1]. This would be a way to solve the issue of scaling (and getting rid of mining oligarchs), but also dealing with the necessary privacy issues of contracts. Also DNS is not really a contract between 2 parties, but N parties, and there is a relationship between DNS and contracts (more on that per PM by request). [1] http://www.finney.org/~hal/rpow/security.html http://www.finney.org/~hal/rpow/security.html