the most notable part of this for me is that instead of working on their main business, they are veering off in an unrelated direction just because it's potentially lucrative. Does it mean they've given up on storage as a business to go after?
Also potentially concerning is that whenever the PoW algorithm changes, Obelisk will have a head start, since they're run by the people deciding what the PoW algorithm will be.
Ha. I really hope we start seeing some truly useful and widely adopted decentralized apps, but everyone seems to get stuck in get-rich-quick schemes. I can't blame people for going where the money is. But this is starting to look bad for blockchain tech. Eventually the economy has to be about something other than buying in and hoping the next guy buys in for more or trying to make more and more effective mining hardware.
I'm running a fairly large mining farm. This article is spot on.
Another point that isn't discussed is that the software solutions to manage large numbers of Pi/Beaglebone class machines is non-existent.
Because of the fast time to market, these machines are unstable... parts burn out all the time, they go offline randomly, a bad PSU can make a machine reboot every 10 minutes (making doing anything with it difficult), etc. Never mind, just keeping track of where an individual machine is in a data center (needle in a haystack).
There is a couple commercial and open source offerings, but the majority of them were built for when farms were only a handful of machines. Scaling to thousands of machines across different data centers has a lot of the same scaling issues I'd have running the same number of EC2 instances.
If you look on Github, you can see that most public development in the mining community stopped around 2014-2015 and hasn't picked up again. Even the largest pools have taken things closed source.
I find it amazing that literally billions of dollars is flowing through this stuff. If it wasn't for math being so factual, I'd really question it all because it is all barely held together with heat sink grease.
> Never mind, just keeping track of where an individual machine is in a data center (needle in a haystack).
I have a friend who contracted to develop a custom DHCP server to allocate addresses based on Ethernet ports. This is superior to static IP configuration because you invariably make configuration mistakes.
Cisco provides this feature, but Cisco is expensive, hence a lucrative side job for my friend. There seems to be lots and lots of opportunities like this to provide custom softwares for mining farm.
Actually, no. DHCP is the common misconception in this industry.
The machines are originally come out of the box booting with DHCP and I immediately switch to static when we deploy them. This is based on experience running a large number of these machines originally with DHCP.
There is a few reasons:
1. They are physical machines in a physical location. Every DC, Row, Rack, Shelf, Position is defined and set with an IP address before the machine is even installed. It is very important to track which machine is where for maintenance reasons (remote hands, etc). If I don't use IP address, I'm stuck using MAC addresses and now I'm keeping track of two pieces of information instead of one. Oh and MAC address isn't printed on the outside, sigh.
2. DHCP can leave gaps in IP ranges. Unless you deploy your own custom server that is smart about always giving out the next IP, in practice, I see gaps form. You end up wasting private space and having machines cross subnets. I don't run the network in my DC, so if I want more IP space, I have to ask for it. One more thing to do, no thanks.
3. These machines tend to reboot a lot since they are basically hastily made junk from China. Time is money. Every second they are down means lost revenue. DHCP takes a minimum of 5-30 seconds to assign an IP. It adds up when you have thousands of machines.
4. More network load. 100mbit at best. Even updating software on them all can take hours.
5. An extra dependency, what happens if my DHCP server dies? The fewer moving parts, the better.
6. Speeds up the installation process, which uses DHCP to assign the initial IP range. Can't have two DHCP servers on the network conflicting with each other.
Installation is as follows:
1. Set the DHCP server to the range I want to use.
2. Unplug ethernet on all machines.
3. Turn them all on and get them warmed up.
4. Plug ethernet in one at a time, in order (to match their location) and watch the leases file.
5. Run a script that bulk sets their IP address as static (same address).
When you're turning on 500 new machines and it is an all day ordeal, this is the fastest process I've found so far.
In the future, I'd like to have a custom DHCP server (there is a DHCP golang server that I'd like to use) that already knows the ranges necessary, allocates the IP and pings my management system to set the location of the machine. Right now, I just keep the data in a Google Sheet, which works well enough.
Eh... your conclusion is that you'd like to have a custom DHCP server. I mentioned such custom DHCP server. Why do you start with "Actually, no"? We seem to be in agreement.
The DHCP server is just to get the machines booted, not to assign IP's on an ongoing basis. I don't keep it turned on (reference to your 'superior to static IP configuration').
In other words, if I could have the machines come out of the box with the correct static IP address (flashed at the factory), I would go that route and not have a DHCP server at all. That would be the absolute optimal solution. We aren't there yet.
Some of our hardware has a serial usb port for TTL. For those, we can set the IP address before we even put it on the shelf.
I also mentioned why it is superior to static IP configuration. If you never make mistakes settings static IP addresses static IP is okay. But you will make mistakes.
I know exactly how many machines I have, where they are located and what IP address they should have. If a single machine isn't doing what I expect, it is immediately obvious in the pretty graphs that I have with Grafana/Prometheus. Any 'mistakes' are easily rectified, but so far, we haven't had a single issue along these lines. I've tried it both ways, the benefits of static IP, for the reasons I mentioned, far outweigh any negatives.
DHCP is great for a coffee shop, workplace or college campus, where you don't know anything about your clients or care to. In my case, I need to know exactly who is on my network at all times and exactly where they are located, without having to cross reference switch ports and MAC addresses. In one DC, I don't even have access to the switches.
Eh... the point of port-based DHCP is exactly not to cross referene switch ports... Cross referencing MAC addresses is stupid and unworkable. Full agreement there.
There is location and cabling, and static IP addresses. You seem to make sure they agree, going so far as "plug ethernet in one at a time", WTF. Port-based DHCP makes those two agree, automatically.
You're also assuming that someone in the DC doesn't mix up the cables. I've seen that happen multiple times.
Agreed, plugging one in at a time isn't the best, but it works and only happens once per machine. Short of writing a lot of code, it is not the end of the world.
We are using Hive OS to manage ~1500 GPU and ASIC rigs. Switched to it from our custom developed management layer. Saved us a lot time on development. Though it lacks true industrial datacenter management capabilities we are hashing 10-12% more on m-o-m basis.
Awesome that it works for you. Unfortunately, it doesn't support all of the hardware we use.
Probably could be made to support it, but I'm honestly a bit wary of how much it installs onto each machine and their complicated bash code has zero tests [1]. I'd prefer a much simpler and solid solution.
Why do you think PoS is workable in the long run? I'm hesitant about the implications of solely tying voting power to how much currency you hold.
Hash rate isn't much better, since it's the definition of a capital-intensive business, but there's still some possibility of getting better performance through clever innovations
Something I am interested in but haven't seen much on is the idea of creating a proof of stake system where the value of one's stake is directly related to how liquid it is. i.e. how much they actually use their funds. Think currency regularly moving in and out of their account, providing smart contract loans, etc.
I feel as if a proof of stake system that requires those staking to not only support the network but also be heavily involved in it as well would resolve some of the issues with current proof of stake systems.
How do you deal with spam tx? In other words pretending to use your stake but you’re not actually?
The same issue as what i’ve encountered when trying to imagine a cryptocurrency that is slightly inflationary, like 1% yearly. There is no objective way to decide how much the money supply should grow, as far as I can tell, because there is no way to separate “real” from “fake” usage.
One aspect that wouldn't eliminate the issue of "useless" or fake tx would be to have the liquidity aspect be a modifier where stakes being il-liquid devalue but over some threshold, the stake modifier is at a constant 1x.
Another potential mitigation tool would be to have the protocol look for tight tx loops (i.e. Naive liquidity falsifying) and either negate or reduce their influence on the liquidity calculation. Whether this is actually possible I have absolutely no idea. If I was to have any real trust in this idea I would have to look for/develop either formal proofs or some real demonstrable examples of it working.
Beyond that I think it boils down to game theory and economics. If it could work, it would likely require careful calibration to minimise the benefit of gaming the system or otherwise being a bad actor.
My brain isn't working very well right now so I'm having trouble understanding what you're saying, but is what you're getting at similar to the metric of "coin days destroyed"? (ie if you send 5 BTC to address foo and those 5 BTC haven't been moved for 365 days then you've destroyed 365*5 coindays
More or less ya that is about right. Now that would still only be part of the overall calculation as I think that assets such as loans and smart contracts should be considered in the calculation. The money from loans and such is in use by people on the network but its owner should still be able to claim it for staking purposes.
"Nothing is cheaper than proof of work" is a ludicrously overstated claim from an overstated article.
Proof of work is as expensive as it can feasibly be. When you say "nothing is cheaper than proof of work", it means you have the problem that only proof of work solves, which is that you want to achieve decentralized consensus and you trust nobody.
Everything is cheaper than proof of work, as long as you trust somebody. And if you're an anarcho-capitalist who trusts nobody, why should I want to live in the world you create? A little bit of trust is worth it to stop burning coal to power useless computation.
This is the central problem of cryptcurrences based on bitcoin - people want trust, they want verified counter parties, they don’t want a currency just anonymous enough to make petty crime easy. That makes POW remarkably unsuited to a currency as it solves the wrong problems.
Also if you’re going to have POW, all these ASICS could at least be folding proteins or doing other grid computing, so they have a useful byproduct.
>people want trust, they want verified counter parties
then you don't understand what makes cryptocurrency useful. you can send it to anyone, anywhere, with no government to tell you "no you can't buy these [censored books / illegal drugs / unregulated services]" or "no you can't send it to [blacklisted country]". <== I'm talking about currencies like XMR (monero) there since Bitcoin is a little more trackable
The more you rely on trusted third parties, the less useful cryptocurrencies are since USD is far more stable and dominant.
PoW has problems, but PoS also has massive problems. I'm not confident a PoS coin can survive longterm - but it'll be interesting to see; many coins are trying
then you don't understand what makes cryptocurrency useful.
It solves the wrong problems, which is why it's not useful (at least in its current form).
You can't even do what you contend with cryptocurrencies right now, because as you admit they are trackable, by design. That's a very hard problem, and if you wanted to solve it, you certainly wouldn't start with a public ledger.
The more you rely on trusted third parties, the less useful cryptocurrencies are since USD is far more stable and dominant.
QED. This is exactly my point. You're trying to avoid trusted third parties when most of the world wants a trusted third party - as evidenced by thousands of years of economic systems which rely on it.
Cryptocurrencies are full of interesting ideas, but they're also based on some wild assumptions which just don't match what most people use money for. Which is a shame as it'd be nice to see government grip over currencies undermined and a truly global currency which nobody controls emerge. I just don't think our current cryptocurrencies are heading in the right direction, or even starting from the right place to do that.
To put it bluntly I don't think you've given it a fair consideration. As I alluded to, cryptocurrencies like XMR are actually secure by design (or rather, the best manifestation of the attempt for ideal privacy/security/fungibility)
Hopefully plain Bitcoin SHA-256 ASICs become more-or-less perfected and commoditized, leading to mining decentralization around local electricity deals.
> leading to mining decentralization around local electricity deals.
The amount of electricity it takes to secure the network is directly proportional to price. In order for BTC to replace traditional currency, it would require more electricity than the world currently produces each year.
Correction: The electricity cost is directly related to mining rewards.
As demand increases, so does price. So miners would purchase electricity at ever-higher marginal prices until an equilibrium is reached.
Mining rewards come from the coinbase reward and txn fees. The coinbase rewards go down over time according to a schedule. Bitcoin is currently highly inflationary to create mining incentive, but we are rapidly approaching the 'long tail' part of coinbase rewards. Txn fee behavior is less predictable, and a source of significant conflict.
To achieve asic resistance, why not switch between a large pool of different algorithms sequentially, with their order and various parameters determined by the hash of the previous block?
You could make one asic that supports all algorithms, and re-uses parts that overlap, or you could even create one asic per algorithm. This substantially increases the amount of design effort required, which puts it rather out of reach for smaller companies. But Bitmain could easily pull together a design effort of that scale, so they are even further advantaged there.
Based on the article, it wouldn’t be difficult to design an ASIC that handles multiple algorithms and accepts parameters for each.
For mining chip manufacturers the gamble of choosing a few algorithms to support, especially if constraints are promised at the start of the PoW launch, can have favorable odds. There’s only so many PoW algorithms from which to choose.
Doesn't it achieve opposite effect? All smaller, non ASIC resistant currencies can be bullied by someone with a lot of (rented) PCs. Ignore 51% attack, just sudden changes in difficulty & time between blocks would introduce chaos.
ASICs are specialized equipment which usually costs a lot. That leads to centralization, which is not something you want for a cryptocoin. Just look at bitcoin with their four people controlling a majority of hashpower.
The majority of miners are not a lot more than hobbyists. I am, too. They prefer GPU mining because they know GPUs better than ASICs and because GPUs are more flexible than ASICs. The barrier of entrance to mining is lower.
Additionally, imagine you bought GPUs. Then of course you are going to oppose to changes destroying the profitability of your GPUs. If you then read about someone writing about ASICs fostering centralisation, you'll be inclined to approve such statements.
However ironically it has been shown that quite possibly GPU mining is more prone to centralisation attacks than ASIC mining.
Resisting single-chip ASICs, by large (on the order of a GB) memory requirements, may be desirable in promoting the use of commodity memory chips, which would account for most of the power consumption and hardware cost, leaving the ASIC tying the memory chips together much simpler, and running much cooler.
The entire point of cryptocurrencies is to be decentralized, that's the key innovation. As long as I trust the overall system, I need not trust any one individual. If you're using a cryptocurrency that's centrally controlled you might as well use a fiat currency, at least those are in theory regulated.
When it comes to ASICs, it's very difficult for you or me to buy them outside the US or China. Someone wanting to set up a mining farm with 500 of them can probably arrange something, but if I want to buy just one here in Iceland, I'm screwed. No one ships single ASICs to Iceland for a sane shipping fee. Most won't ship them outside the US at all.
As a result, almost all the hashpower in bitcoin is coming from the US or China, and from the rest of the worlds perspective that's not good. It is /definitely/ within the Chinese governments power to seize all of bitmains strategic reserve of chips and use them to perform a 51% attack on bitcoin.
The benefit of ASIC resistance is that it forces everyone down to graphics cards or at least FPGA boards, and both of those can be bought over the counter in any western country, so it spreads the hashing out geographically, which is desirable from a resilience standpoint. If ASICs were widely available it would be a different matter, but since they aren't, it's overall better to force them out of the game for now.
As TFA points out no matter how ASIC-resistant you try to make your PoW algorithm you're just delaying the inevitable. If any of these cryptocurrencies actually manages to become the currency of the future the incentive to increase the hash-rate-per-kW by a few percents to be worth it.
Having a pool of different algorithms might improve the difficulty but it will also make it tricky to audit all algorithms for vulnerabilities. On top of that an ASIC might not have to implement all algorithms, they could idle and only spring into action when an algorithm they implement is selected for instance.
The main point of the article stands, no matter how complicated you make your algorithm a special-purpose solution will always be more efficient than a general-purpose one, it's just a matter of balancing the cost of developing the ASIC vs. the expected return.
If, as the article points out, developing chips for minor cryptocurrencies using ASIC-resistant PoW is cost-effective I can't imagine how anybody could hope to design as ASIC-resistant cryptocurrency designed to become the currency of the future. Think about it, in the unlikely scenario where a PoW cryptocoin eventually replaces the dollar the mining rewards will quickly amount to billions of dollars. The incentive to get an edge, no matter how small, would be tremendous.
An alternative scheme would be to change the change the PoW algorithm regularly like the article says Monero is doing, but then you give a huge amount of power to the people selecting the next PoW. Consider how incredibly tempting it would be to develop an ASIC for some PoW algorithm and then have it selected by Monero, you'd have a huge head start.
and I'm referring to the hero spot on their homepage which literally starts with "In the fictional world of Westeros, ravens are used as the messengers who carry statements of truth"
Is there a hashing algorithm whose sequence of operations is heavily determined by the input, so that an ASIC targeting it would need to be roughly as flexible as a standard CPU?
'roughly' is really poorly defined. CPUs leverage things like branch prediction and context switching, and also CPUs and GPUs both need to be designed for approximately arbitrary use cases, which is a much harder thing to do than designing for random input.
If you know for certain that the operations you get will follow some distribution, you can customize towards that distribution in ways a cpu or gpu can't.
The authors of the blog post make pretty liberal use of fantasy artwork. The art doesn't add any educational value for me. If I stretch my imagination I can see how the last image gives a connotation of "an impressive, highly skilled, well refined entity", but to be it's... cringey for a company to be doing this. Like, I see my high school self in this aesthetic.
Also, the authors would do well to credit the original sources / authors.
Lots of people have 'cringey' aesthetics in tech -- e.g., the anti-ego depletion 'own everything the same' uniform, the VC Patagonia+AllBirds, the 'free tshirts only' nerd outfit, etc. It's better to judge people on the merit of their ideas than their appearances or aesthetics. I support David choosing to present himself, and his work, as he pleases.
> as ASICs continue to infiltrate every coin on the market
I think he means "every PoW coin", because PoS coins will change the game significantly (or am I missing something). In the comments at Medium we see several question being asked about this (at this point all unanswered).
You can still use an ASIC with a PoS coin, it just doesn't benefit you as much. PoS coins still perform work on a blockchain with cryptography, but there is no reward to be the fastest. An ASIC for a PoS would allow you to lower the power requirements(Wattage and compute) of the machine running the PoS coin.
I'm not sure if this qualifies as proof of stake, proof of work, or neither - but I've just heard of SpaceMesh[0], which seems to be a well thought out alternative to Ethereum. If I understand correctly, it's "proof of space" (in the sense that scrypt requires space whereas bcrypt requires just work; spacemesh requires space, not just work).
Haven't had a chance to really look at the implementation though (its on github)
82 comments
[ 3.5 ms ] story [ 146 ms ] threadAnother point that isn't discussed is that the software solutions to manage large numbers of Pi/Beaglebone class machines is non-existent.
Because of the fast time to market, these machines are unstable... parts burn out all the time, they go offline randomly, a bad PSU can make a machine reboot every 10 minutes (making doing anything with it difficult), etc. Never mind, just keeping track of where an individual machine is in a data center (needle in a haystack).
There is a couple commercial and open source offerings, but the majority of them were built for when farms were only a handful of machines. Scaling to thousands of machines across different data centers has a lot of the same scaling issues I'd have running the same number of EC2 instances.
If you look on Github, you can see that most public development in the mining community stopped around 2014-2015 and hasn't picked up again. Even the largest pools have taken things closed source.
I find it amazing that literally billions of dollars is flowing through this stuff. If it wasn't for math being so factual, I'd really question it all because it is all barely held together with heat sink grease.
As a result, I'm building it for myself as I go, which is a fun sadistic exercise.
Prometheus / Grafana (awesome tools), React / TypeScript, golang
Had they invested their $500k in BTC in 2015 instead of HashRabbit... 100m btc @ ~$200 = $1b.
It seems like they aren't really in business. Is there something you know that I don't?
Consider reaching out, I'm not sure they've published the latest stuff
I have a friend who contracted to develop a custom DHCP server to allocate addresses based on Ethernet ports. This is superior to static IP configuration because you invariably make configuration mistakes.
Cisco provides this feature, but Cisco is expensive, hence a lucrative side job for my friend. There seems to be lots and lots of opportunities like this to provide custom softwares for mining farm.
The machines are originally come out of the box booting with DHCP and I immediately switch to static when we deploy them. This is based on experience running a large number of these machines originally with DHCP.
There is a few reasons:
1. They are physical machines in a physical location. Every DC, Row, Rack, Shelf, Position is defined and set with an IP address before the machine is even installed. It is very important to track which machine is where for maintenance reasons (remote hands, etc). If I don't use IP address, I'm stuck using MAC addresses and now I'm keeping track of two pieces of information instead of one. Oh and MAC address isn't printed on the outside, sigh.
2. DHCP can leave gaps in IP ranges. Unless you deploy your own custom server that is smart about always giving out the next IP, in practice, I see gaps form. You end up wasting private space and having machines cross subnets. I don't run the network in my DC, so if I want more IP space, I have to ask for it. One more thing to do, no thanks.
3. These machines tend to reboot a lot since they are basically hastily made junk from China. Time is money. Every second they are down means lost revenue. DHCP takes a minimum of 5-30 seconds to assign an IP. It adds up when you have thousands of machines.
4. More network load. 100mbit at best. Even updating software on them all can take hours.
5. An extra dependency, what happens if my DHCP server dies? The fewer moving parts, the better.
6. Speeds up the installation process, which uses DHCP to assign the initial IP range. Can't have two DHCP servers on the network conflicting with each other.
Installation is as follows:
1. Set the DHCP server to the range I want to use.
2. Unplug ethernet on all machines.
3. Turn them all on and get them warmed up.
4. Plug ethernet in one at a time, in order (to match their location) and watch the leases file.
5. Run a script that bulk sets their IP address as static (same address).
When you're turning on 500 new machines and it is an all day ordeal, this is the fastest process I've found so far.
In the future, I'd like to have a custom DHCP server (there is a DHCP golang server that I'd like to use) that already knows the ranges necessary, allocates the IP and pings my management system to set the location of the machine. Right now, I just keep the data in a Google Sheet, which works well enough.
In other words, if I could have the machines come out of the box with the correct static IP address (flashed at the factory), I would go that route and not have a DHCP server at all. That would be the absolute optimal solution. We aren't there yet.
Some of our hardware has a serial usb port for TTL. For those, we can set the IP address before we even put it on the shelf.
DHCP is great for a coffee shop, workplace or college campus, where you don't know anything about your clients or care to. In my case, I need to know exactly who is on my network at all times and exactly where they are located, without having to cross reference switch ports and MAC addresses. In one DC, I don't even have access to the switches.
There is location and cabling, and static IP addresses. You seem to make sure they agree, going so far as "plug ethernet in one at a time", WTF. Port-based DHCP makes those two agree, automatically.
You're also assuming that someone in the DC doesn't mix up the cables. I've seen that happen multiple times.
Agreed, plugging one in at a time isn't the best, but it works and only happens once per machine. Short of writing a lot of code, it is not the end of the world.
Probably could be made to support it, but I'm honestly a bit wary of how much it installs onto each machine and their complicated bash code has zero tests [1]. I'd prefer a much simpler and solid solution.
[1] https://github.com/minershive/hiveos-asic/blob/master/hive/b...
Hash rate isn't much better, since it's the definition of a capital-intensive business, but there's still some possibility of getting better performance through clever innovations
I feel as if a proof of stake system that requires those staking to not only support the network but also be heavily involved in it as well would resolve some of the issues with current proof of stake systems.
The same issue as what i’ve encountered when trying to imagine a cryptocurrency that is slightly inflationary, like 1% yearly. There is no objective way to decide how much the money supply should grow, as far as I can tell, because there is no way to separate “real” from “fake” usage.
Another potential mitigation tool would be to have the protocol look for tight tx loops (i.e. Naive liquidity falsifying) and either negate or reduce their influence on the liquidity calculation. Whether this is actually possible I have absolutely no idea. If I was to have any real trust in this idea I would have to look for/develop either formal proofs or some real demonstrable examples of it working.
Beyond that I think it boils down to game theory and economics. If it could work, it would likely require careful calibration to minimise the benefit of gaming the system or otherwise being a bad actor.
Proof of work is as expensive as it can feasibly be. When you say "nothing is cheaper than proof of work", it means you have the problem that only proof of work solves, which is that you want to achieve decentralized consensus and you trust nobody.
Everything is cheaper than proof of work, as long as you trust somebody. And if you're an anarcho-capitalist who trusts nobody, why should I want to live in the world you create? A little bit of trust is worth it to stop burning coal to power useless computation.
Also if you’re going to have POW, all these ASICS could at least be folding proteins or doing other grid computing, so they have a useful byproduct.
>people want trust, they want verified counter parties
then you don't understand what makes cryptocurrency useful. you can send it to anyone, anywhere, with no government to tell you "no you can't buy these [censored books / illegal drugs / unregulated services]" or "no you can't send it to [blacklisted country]". <== I'm talking about currencies like XMR (monero) there since Bitcoin is a little more trackable
The more you rely on trusted third parties, the less useful cryptocurrencies are since USD is far more stable and dominant.
PoW has problems, but PoS also has massive problems. I'm not confident a PoS coin can survive longterm - but it'll be interesting to see; many coins are trying
It solves the wrong problems, which is why it's not useful (at least in its current form).
You can't even do what you contend with cryptocurrencies right now, because as you admit they are trackable, by design. That's a very hard problem, and if you wanted to solve it, you certainly wouldn't start with a public ledger.
The more you rely on trusted third parties, the less useful cryptocurrencies are since USD is far more stable and dominant.
QED. This is exactly my point. You're trying to avoid trusted third parties when most of the world wants a trusted third party - as evidenced by thousands of years of economic systems which rely on it.
Cryptocurrencies are full of interesting ideas, but they're also based on some wild assumptions which just don't match what most people use money for. Which is a shame as it'd be nice to see government grip over currencies undermined and a truly global currency which nobody controls emerge. I just don't think our current cryptocurrencies are heading in the right direction, or even starting from the right place to do that.
The amount of electricity it takes to secure the network is directly proportional to price. In order for BTC to replace traditional currency, it would require more electricity than the world currently produces each year.
As demand increases, so does price. So miners would purchase electricity at ever-higher marginal prices until an equilibrium is reached.
Mining rewards come from the coinbase reward and txn fees. The coinbase rewards go down over time according to a schedule. Bitcoin is currently highly inflationary to create mining incentive, but we are rapidly approaching the 'long tail' part of coinbase rewards. Txn fee behavior is less predictable, and a source of significant conflict.
For mining chip manufacturers the gamble of choosing a few algorithms to support, especially if constraints are promised at the start of the PoW launch, can have favorable odds. There’s only so many PoW algorithms from which to choose.
If something designed to be hard can be made easy, you lose whatever goal you wanted to achieve by the former.
Additionally, imagine you bought GPUs. Then of course you are going to oppose to changes destroying the profitability of your GPUs. If you then read about someone writing about ASICs fostering centralisation, you'll be inclined to approve such statements.
However ironically it has been shown that quite possibly GPU mining is more prone to centralisation attacks than ASIC mining.
When it comes to ASICs, it's very difficult for you or me to buy them outside the US or China. Someone wanting to set up a mining farm with 500 of them can probably arrange something, but if I want to buy just one here in Iceland, I'm screwed. No one ships single ASICs to Iceland for a sane shipping fee. Most won't ship them outside the US at all.
As a result, almost all the hashpower in bitcoin is coming from the US or China, and from the rest of the worlds perspective that's not good. It is /definitely/ within the Chinese governments power to seize all of bitmains strategic reserve of chips and use them to perform a 51% attack on bitcoin.
The benefit of ASIC resistance is that it forces everyone down to graphics cards or at least FPGA boards, and both of those can be bought over the counter in any western country, so it spreads the hashing out geographically, which is desirable from a resilience standpoint. If ASICs were widely available it would be a different matter, but since they aren't, it's overall better to force them out of the game for now.
Having a pool of different algorithms might improve the difficulty but it will also make it tricky to audit all algorithms for vulnerabilities. On top of that an ASIC might not have to implement all algorithms, they could idle and only spring into action when an algorithm they implement is selected for instance.
The main point of the article stands, no matter how complicated you make your algorithm a special-purpose solution will always be more efficient than a general-purpose one, it's just a matter of balancing the cost of developing the ASIC vs. the expected return.
If, as the article points out, developing chips for minor cryptocurrencies using ASIC-resistant PoW is cost-effective I can't imagine how anybody could hope to design as ASIC-resistant cryptocurrency designed to become the currency of the future. Think about it, in the unlikely scenario where a PoW cryptocoin eventually replaces the dollar the mining rewards will quickly amount to billions of dollars. The incentive to get an edge, no matter how small, would be tremendous.
An alternative scheme would be to change the change the PoW algorithm regularly like the article says Monero is doing, but then you give a huge amount of power to the people selecting the next PoW. Consider how incredibly tempting it would be to develop an ASIC for some PoW algorithm and then have it selected by Monero, you'd have a huge head start.
One potential issue perhaps would be that it would presumably violate the memorylessness principle, which really changes the mining dynamics.
Is there a difference between what you're proposing and the more memory-intensive hash algos like Scrypt, etc?
https://ravencoin.org/wp-content/uploads/2018/03/X16R-Whitep...
If you know for certain that the operations you get will follow some distribution, you can customize towards that distribution in ways a cpu or gpu can't.
Also, the authors would do well to credit the original sources / authors.
> as ASICs continue to infiltrate every coin on the market
I think he means "every PoW coin", because PoS coins will change the game significantly (or am I missing something). In the comments at Medium we see several question being asked about this (at this point all unanswered).
Haven't had a chance to really look at the implementation though (its on github)
[0] https://spacemesh.io/