5 ms·
Relevant quote: "Moving forward, developers will seek to protect the network’s ASIC resistance by slightly modifying its PoW algorithm at every scheduled hard f
by tom_mellior 9y ago
Relevant quote: "Moving forward, developers will seek to protect the network’s ASIC resistance by slightly modifying its PoW algorithm at every scheduled hard fork, which generally occurs twice annually. These changes will not be noticeable to ordinary XMR users, but they will alter the network’s hashing algorithm enough that Cryptonight ASIC miners would become obsolete following every fork."
We'll see how this works out. Hard to tell without any technical details about what these changes to the algorithn will be. I'm not quite sure though about amateurs mucking with the details of hash functions, it smells like going against the rule of "don't roll your own crypto".
Also, and in the full understanding that this ship has sailed, it's stupid to call a planned update everyone goes along with a "hard fork".
- DINKDINK 9y ago>it's stupid to call a planned update everyone goes along with a "hard fork" No, a hard fork indicates a set of consensus rules that is incompatible with the current set of consensus rules. This occurs when the domain of valid blocks expands. When the domain of valid blocks decreases, it's a soft fork.
- tom_mellior 9y agoI understand the first part of this, but I don't know what you mean by the "domain of valid blocks". Anyway, I understand the issue of an incompatible change. The point is, it's dumb to use the same term for an incompatible change everyone goes along with (like here) with an incompatible change that causes two different chains to be kept up by two different communities (like Ethereum vs. Ethereum Classic). The difference is between calling a fork-shaped thing a "fork" and calling a knife-shaped thing a "fork".
- wmf 9y agoSome good thinking about forks and upgrades: http://www.truthcoin.info/blog/forks-and-splits/ http://www.truthcoin.info/blog/forks-and-splits/
- tom_mellior 9y agoThat makes clear that the meaning of "fork" has changed over time in exactly the way I said. It then goes on to try to rationalize the current usage, which I don't happen to agree with.
- jmeyer2k 9y agoHe means hard forks make block validity more restrictive whereas soft forks do not.
- MertsA 9y agoYou got that backwards. Hard forks make blocks that are not considered valid by previous versions. Soft forks make blocks that are considered valid by previous versions. A soft fork does stuff like e.g. changing Bitcoin blocks to be 512KB in size. In that case, all new blocks would still be seen as valid blocks for anyone still running the old version.
- stale2002 9y agoThere is no reason why the upcoming Monero hardfork couldn't cause a split. If a faction disagrees with the scheduled update, they very well could cause 2 different chains, in the exact same way that Ethereum, and Ethereum clasic happened. There is no free lunch. A hard fork is a hard fork. It is perfectly possible that you will be incorrect in your prediction that the hardfork will be uncontroversial.
- DINKDINK 9y ago>I don't know what you mean by the "domain of valid blocks". Blocks are considered valid by a consensus set if they have certain attributes. Consider each attribute an axis in a multi-dimensional space. One axis for the block size [1], one for the type of PoW function it has[2], one for the sign of the R S values used in an ECDSA function[3], another for the required difficulty[4] For example, Bitcoin went through a soft fork when the domain of valid blocks was reduced in BIP66 to decrease the number of domains DER signatures could exist in [3]. Bcash /increased/ the domains in which blocks would be considered valid in their chain by changing the difficulty-retargeting algorithm used in Bitcoin[4], 8X'ing the blocksize [1]. As a result, if you turn on a bitcoin node running ~0.6-.7 it won't sync to the bcash chain but will sync to the bitcoin chain (with implementations such as Bitcoin Knots, bcoin, Bitcoin Core) because bcash is a hard fork of bitcoin.
- TillE 9y ago> the rule of "don't roll your own crypto". That's an extremely important principle when doing the routine work of protecting sensitive information, but less relevant when you're making hash modifications that are going to be obsolete in a few months anyway. By the time anyone's done serious cryptanalysis, it's probably too late. Anyway, the worst case scenario is that things get screwed up and you need to do a premature hard fork that rolls back some transactions. Not the end of the world.
- ethbro 9y ago> premature hard fork that rolls back some transactions. Not the end of the world That sounds pretty bad. Especially if mucking with the hash function is now business as usual. (I.e. there's a chance of this happening after every hard fork)
- madez 9y ago> the rule of "don't roll your own crypto". There is no such rule in general. In many situations it might be better to use available solutions, but in others it might be better to do something different. It depends on your attack model and what you are trying to achieve.
- cocktailpeanuts 9y agoThe only people who say things like "you can do things differently" are those who don't understand the fundamentals of crypto. (I've been one in the past) Because once you do get to a point where you understand (You don't have to be a crypto guru or actually invent a new crypto algorithm, but just to a point where you understand how the fundamental bits and pieces work), you will find yourself saying the same thing: "Don't roll your own crypto".
- madez 9y agoYou are wrong in assuming I don't know about cryptography and it's fundamentals. I'm not a professional expert in them, but I do have formal theoretical and implementation experience. The "don't roll your own crypto" is simply wrong in general. For comparison, most often injecting chemical agents into your veins in high concentration is highly detrimental, so most often the rule "don't inject highly concentrated chemicals into your blood" is valid, but sometimes the chemical is an antidote and is the only way to save a life. Therefore, in general, the rule "don't inject concentrated chemicals into your blood" isn't valid. It's the same with cryptography. There are tradeoffs at play and one needs to know what they are trying to achieve. Custom cryptography is a (rarely used) tool in the box, but it is rightfully there. Maybe this is a misunderstanding. I certainly would tell children never to inject chemicals into their veins, but I wouldn't tell that so absolutely to an adult. I treat people here with respect and as adults. That's why I nitpick and say "don't rule your own crypto" isn't true in general.
- cocktailpeanuts 9y agoThe reason people say "don't roll your own crypto" is not because rolling your own crypto is something reserved for super-intelligent elites, but it's because if you use a cryptosystem that's been around and running in public for a long time, it's "empirically proven" (as well as mathematically proven) that it can't be easily broken. Rolling your own crypto can work, and maybe it's even mathematically provable, but unless there's a very strong reason for rolling your own, all the risk that comes along with it is not justifiable. This is why people criticize companies like Telegram for running their own crypto. They could have just used the existing cryptosystems for key exchange, etc., but they decided to go with their own, and since there are no other public systems that implement that specific algorithm, nobody can be sure what the agenda is. Same reason why people don't trust certain algorithms released by NSA even though they're completely public and open source. No matter how provable an algorithm is, things are super subtle in crypto-land and you never know what might be hiding behind the scenes or what unknown vulnerability there may be. I get your analogy about chemicals, but cryptography is its own special beast with its own inherent quirks which I described above, so I don't think the analogy fully translates to this context.
- ricardobeat 9y agoTalking of ships, the term “hard fork” is just as correct as your use of “crypto”: technically correct.