The reason for all the number crunching is to prevent double spending (sending the same coin to two different accounts) without needing a central authority that keeps track of who has which coins. If you want a locking mechanism that ensures your transaction will succeed before you pay any fees, you either need a central authority that keeps track of which coins are currently locked and where they're due to be sent (which goes against what cryptocurrency is supposed to be), or the locking mechanism will be subject to the same constraints on throughput as the blockchain itself (and will probably have its own set of fees).

I haven't looked into this in any detail, but I understand that there are services that keep track of coins held by members, without using the blockchain. Moving coins between members is very quick and cheap. Periodically, the service writes transactions out to the blockchain. (I'm guessing there are economies of scale.) If this kind of service sounds familiar, that's because it is. It's basically a bank - the thing that cryptocurrencies were supposed to make irrelevant. The difference is that it's not regulated like a bank, so if it gets hacked or goes bust, or the owners decide to run off with everyone's coins, there's nothing you can do.

Ethereum (and any other proof-of-work cryptocurrency) can't scale to more than a few tens of transactions per second. If you had to pay a transaction fee only if the transaction was successful, it would be trivial to DDoS the network by sending lots of transactions for the equivalent of a fraction of a cent. As it is, you can still try that, but it quickly gets expensive.

I work on an enterprise application that's probably about that big. The only figure I'm confident of is the server side of the GUI, which is mostly what I'm responsible for, and that's about 0.5 million LOC. The rest is bigger, but I don't know how much bigger.

Refactoring is improving the design or implementation of a program without changing its behaviour. If the program produced the wrong results, and you change it to produce the right results, or (as seems likely in this case) results that are less wrong, that's not refactoring.

You're quite right that refactoring can introduce regressions and new bugs, but (especially with a program of that size) you shouldn't try it until you have a comprehensive suite of automated tests. You don't refactor or try to change the program's behaviour unless all the tests are currently passing. Then if some tests start failing, you know that your recent change broke something. You're not guaranteed to catch all bugs by doing this, but (as long as the tests are good) you're much more likely to catch regressions than you are with manual testing.

Or, instead of not accepting a valid form of payment, just tack on a VISA service fee with a little balloon that explains the situation.

Unfortunately, this is currently illegal in the UK. Retailers aren't allowed to charge different prices for different payment methods, at least not when they get paid in full. Charging more when the customer pays in instalments is still allowed. Back when they were allowed to charge different prices for different payment methods, smaller retailers would tack on as much as 3% for paying by credit card, or have a minimum purchase of £5 (about $6) for debit cards.

If the law changed to allow this again, it probably wouldn't limit the surcharges to the retailer's actual transaction costs, so the retailers would just increase the surcharges to whatever the market would bear and pocket the difference.

If nobody collects it, that's a very convincing argument that it was all fake.

You know that, and I know that, but the misinformation-mongers would just twist such an offer into more "proof" that you're lying. For instance...

• "Senator Misnohmer promised that if I proved X or Y or Z was true, I'd get a million dollars a year for life! Well, I proved X and Y and Z [of course they've done nothing of the sort], and I haven't got a million dollars! More proof that the Senator can't be trusted on anything!"
• "Senator Misnohmer promised us all a million dollars a year!" [omitting the part about having to prove X or Y or Z]
• "My friend proved X and Y and Z, and when he tried to claim the million dollars a year, Senator Misnohmer disappeared him!" [said "friend" disappeared years before the promise was made, assuming he ever even existed]

The USA passed the DCMA to meet its obligations under the WIPO (World Intellectual Property Organisation) Copyright Treaty of 1996. The EU passed a directive in 2001 that obliged member states to implement anti-circumvention rules in their own copyright laws.

"Not owning anything" might have come about without these laws, but the laws make it easier. If it's legal for consumers to root hardware, a vendor that wants subscription revenue to keep coming in has to spend a lot of time and money to make the hardware impossible or impractical to root. With a DMCA-like law on the books, the vendor can implement the simplest access control that will keep most of their users paying the subscription, and let the lawyers deal with any geeks who figure out how to give control back to the user.

We live in a world where a non-zero number of people have stopped drinking Corona beer because they think it has something to do with the virus. If Smith Corona still made typewriters, some people would've stopped using them...

If it's booting entire operating systems to check a one-line change, it could doubtless be made more efficient. But if you switched it off, how much energy would you (and your users) waste in finding and fixing bugs that it would've caught? There's that much-repeated quote about how if it costs $10 to fix a bug that a developer finds while coding, it costs $100 to fix the same bug if QA find it, and $1000 if a user finds it. A lot of that money is people's wages, but energy costs come into it too.

FTFA:

In 2019, the Iranian government established a licensing process in an attempt to control the crypto industry, with requirements that miners register with the government and pay higher prices for electricity, but that did little to deter unregistered mining.

Seeing as the unregistered (illegal) miners are using ten times as much electricity as the registered (legal) ones, I'm guessing that the cost of complying with the law is more than the cost of bribing government officials to ignore your unregistered operation - assuming they made any effort to find it.

...but that won't stop the boss's brother-in-law's nephew who "knows computers" from building the company's inventory management system in it.

Yeah, I wondered if that was what it meant. It would make more sense - a few years ago, we had to add anti-CSRF tokens to all the pages in our application, and write a couple of server-side classes to generate them and validate them. We've never had to worry about CRLF injection. I assume (!) that the web server we're running on takes care of preventing that.

Prof Wikipedia says it's another name for HTTP response splitting. An HTTP response consists of a header and a body, separated by two CRLF sequences. The header consists of fields separated by single CRLF sequences. In HTTP response splitting, the attacker tricks the web server into printing a field that has two CRLFs embedded in it, so that the browser will treat whatever follows them as the body, not the header.

For this to work, the web server or web application usually has to have a bug where it echoes back some input that the user provided without sanitising it. Offhand, I can't think of a scenario where you'd want to echo user input in the HTTP header, and I've never seen it come up as a vulnerability in a security scan. So I'd have to question the survey's assertion that this type of bug is common in Java code.

The thieves intercepted some real invoices and altered the payee details. That allows them to bypass most of the checks that the victim should be doing (e.g., "is this an invoice for something we've actually ordered?") That should require some skill and determination, but I expect at least one person in this story has an email password of "maga2020!", so... yeah.

Or allocate the visas in descending order of salary. Companies that genuinely want to hire someone who has skills and experience that are rare or non-existent in the US should have no problem with paying that person a high salary. Companies that just want lots of $15/hr Java developers or $20/hour Oracle DBAs can either raise the salaries for the immigrants or make a genuine effort to hire Americans.