> fork the chain at a snapshot before the attack, patch the protocol, and call that Bitcoin?
It won't work. The only way to authenticate who ones what coins is with signatures. If the signature algorithm is broken, you can't tell who the original owner is to move the coins to a safe signature algorithm.
You need to more to safer signature algorithm before the break, after the break it is game over.
> It’s worth remembering that Ethereum forked for much less
Ethereum could simply return the coins to the original owners. If the signature scheme is insecure, returning the coins just means the attacker can steal them again.
> The only way to authenticate who owns what coins is with signatures
Maybe the only fully cryptographic absolutely zero-trust way? In practice there are very few bitcoin outputs that aren't linked to an offline identity and most users could easily produce a proof of ownership.
Of course, this is not ideal and everyone would prefer not to go down that route. But even if we prepare in time and Bitcoin provides a quantum-secure address scheme before "Q-day", what happens to all the wallets that didn't upgrade? Is it open season on them? Satoshi's wallet alone could crash Bitcoin's value as a currency if dumped on the open market. I think even with the upgrade plan in place, a hard-fork + recovery will be on the menu, with various degrees of community support.
> In practice there are very few bitcoin outputs that aren't linked to an offline identity and most users could easily produce a proof of ownership.
Any who is going to in charge of reading that proof of identity and moving the coins? A trusted centralized party? The point of Bitcoin is to avoid exactly that sort of trust relationship, otherwise use the banking system.
> Satoshi's wallet alone could crash Bitcoin's value as a currency if dumped on the open market.
No one knows, but the incentives are aligned with a softfork to burn Satoshi's coins.
> Any who is going to in charge of reading that proof of identity and moving the coins? A trusted centralized party?
Basically you'd have to relax the trust/decentralization guarantees, but you don't have to relax them all the way. Most likely a consortium of trusted actors (Blockstream, major miners, major exchanges, bitcoin-adjacent companies,...). Or something like a consensus mechanism with aligned incentives a la Kleros. I think "we" could come up with "something", even if it is not perfect, because the value of Bitcoin is ultimately in the community of people who use Bitcoin, not just the protocol.
"Hard-fork" might not be the right way to see this. It's more like starting a completely new protocol where people who held Bitcoin at a certain snapshot can redeem a one-time airdrop equivalent to the value they held, provided they can prove ownership. As that protocol's value overtakes the value of the original Bitcoin chain (which will eventually be completely dead), we can all agree to call it Bitcoin.
>The point of Bitcoin is to avoid exactly that sort of trust relationship, otherwise use the banking system.
Most participants don't care about this. For almost everyone, the point of Bitcoin is to go up. As long as they can find enough buyers that also believe it will go up, the rest is optional. Especially if it's temporary, for a one-time migration.
In practice, what you really need is consensus. As long as enough of the important participants agree, that's how it will be.
And since there are millions of identical copies of the entire pre-attack ledger out there, this should not be that difficult.
Potential future buyers might reevaluate whether this whole thing has any monetary value, but that's a separate concern. Bitcoin's market value was never about the technical details.
I'm not sure you fully grasped what was said in the parent comment. It literally does not matter anymore if we can all agree on the previous blocks, it would be impossible to identify who owns which wallet anymore. The seed phrase would be useless.
Ah, then yeah, in that case, it'd be basically over.
Maybe large exchanges would try to step in to make a fresh chain based on their combined account data, and just drop the people relying on self-custody. But I doubt the market would go for it - the uncertainty would crash it hard enough that it would never recover.
> It won't work. The only way to authenticate who ones what coins is with signatures. If the signature algorithm is broken, you can't tell who the original owner is to move the coins to a safe signature algorithm.
If you publish/take a snapshot of the ledger at (say) 23:59 UTC everyday, and publish it with a SHA2/3 hash, people will know what the state of ownership was at that time. Then if a break occurs at any later point you cannot trust any transaction afterwards, but some portion of folks can attest to their ownership.
There will be some portion of folks that did some legitimate transactions that could come into question, but at least it's not necessarily everyone.
> but some portion of folks can attest to their ownership.
How? Alice pay's Bob 1 BTC at random address 0x1234. Someone shows up and says, I own that address and here is signature proving it. But the signature scheme is broken so anyone can do that. So you ask for documentation they own that address, well they have screencap of a message asking for payment from Alice. Is that real? Maybe you find the email of that user and ask them, but they could be lying. Now if you paid from coinbase, coinbase could vouch for you.
So you need some sort of court that sits in judgement over who owns what. That is going to be very expensive. While you are doing this, no one can move funds. What is the most likely outcome of such a system, well there is not CEO of Bitcoin, so you would probably end up with multiple courts producing conflicting rulings that no one would respect.
The whole notion of ownership courts is anathema to Bitcoin's philosophy and would completely undermine the social trust that makes Bitcoin valuable. If we are going to save Bitcoin from a CRQC we must act before a CRQC recovers everyone's private key.
There are three workable schemes:
* For public keys that in hashed addresses such as P2PKH (Pay-to-Public-Key-Hash) et al., if the public key is not known, then you could produce a ZKP that you know the public key (proof of pre-image). The main problem with this approach is that it only protects hashed addresses where the public key has not been leaked or exposed on-chain. It doesn't have enough coverage.
* You can do commit-reveal schemes, this makes miners far more trusted and again only helps with hashed addresses that haven't exposed the public key.
* You can do ZKP proof of HD Seeds, from most modern wallets have HD seeds. AFAICT You'd have to use STARKs but STARKs for HD seeds are too big for on-chain proofs. Not all HD seeds are protected and not all addresses have HD seeds. Just today Laolu published this demo for doing this, the proofs at 1.7 mbs https://groups.google.com/g/bitcoindev/c/Q06piCEJhkI
You have to consider the network-level forwarding, not only the crypto. The noderunners could role out a new version that uses whatever heuristics to identify transactions that are likely from an attacker. If transaction aren't forwarded, they don't end up in the mempool and thus not in the blockchain. And yes, then the attacker might try to manipulate those heuristics and filter etc. It would become a cat-and-mouse game, but as long as the "good guys" act faster than the attack adapts, there is a good chance a big number of coins can be secured. It is not an all-or-nothing game.
The point is you can't distinguish transactions that are from an "attacker" when the underlying signature scheme is broken. The Bitcoin P2P network has some metrics to disconnect from nodes that might be trying to DoS you, but if a transaction has enough fees, is spending unspent coins, and has a valid signature, it's valid.
I did say heuristics, not valid/invalid. You can do all sorts of analytics upon receiving a transaction, and then decide to forward or drop the transaction based on that heuristics. Valid/Invalid could become the minimum requirement for a transaction to be forwarded.
"A CRQC is an existential threat to Bitcoin (you might believe this is very low-likehood). Your measurement of this threat should literally be:
(A) How likely you think it is a CRQC appears by a given time, multiplied by
(B) How likely it is you think Bitcoin will not successfully upgrade by that time."
It would interesting to survey people about their answers.
My off the cuff answer is:
2030: A=0.05, B=0.01
2035: A=0.50, B=0.001
2045: A=~1.0, B=~0.0
I reserve the right to change my mind on these answers at any point. This is not a serious prediction.
I'm skeptical that B is fully possible. You can create a PQ fork of bitcoin but you cannot automatically bring vulnerable wallets along - and there are a lot of vulnerable wallets, especially from the early days. There's a catastrophe ahead for bitcoin with an apparent probability of 1.0. That's hard to account for in this scheme.
It would still tank the price. Right now many Bitcoins are lost because no one holds the keys any more. When they can hack it, suddenly the sell pressure significantly goes up.
Karl Popper calls this a psychological probability(% chance I go to the gym today). This is different from objective probability (% chance a dice lands on 5).
In this case, it seems like we are rolling dice but no one is quiet sure if the dice are fair, how many sides it has and what numbers are written on the dice.
The only thing I am confident in is if it the bigger the fire, the faster the work. I want the Bitcoin community to start the work as early as possible so that it doesn't have to rush because rushing increases the chance of mistakes.
You should also consider that a CRQC needs not only to exist, but be used in a certain way. I can hardly see the first thing Google or IBM do upon their breakthrough, is stealing bitcoins. There is a reputation to have. And it is also unlikely some hacker can build a superior quantum computer in their backyard before some trillion dollar companies with a research budget can.
2045 A=~1.0 seems way off. CRQC is still a theoretical construct with hurdles to overcome. Yes, there is a significant risk that it will exist somewhere in the next decades, but there is also still a significant chance that it will be shown to be practically impossible.
That is not what I am hearing from people working on CRQC. A prediction of a CRQC with 10% by 2030 was made by own of the top experts in this field. 2045 used to be the pessimistic outlook by experts with a bunch of experts predicting earlier. Recent work has shown that CRQC is actual 20 times easier to built that previously thought, accelerating all timelines.
We are seeing significant progress in two different types of quantum computers, neutral atom and superconducting qubit.
No one really knows when it will happen, but the chance that it is practically impossible is held only by a small number of experts. Given what we have seen in 2026 has significantly shifted expectations.
> See a pattern here? Each failure from a different root cause. So multiple unsolved failure modes, not iteration. It has never reached orbit, never caught a ship, never demonstrated orbital refueling.
Wouldn't it be worse if it was all from the same root cause. That would suggest they can't figure out how to fix the problem. Multiple failures with different root causes provide almost optimal experimental data. I'm not saying the failures are necessarily good for SpaceX, but we are seeing progress and a willingness to push the envelope.
This IPO makes me more worried about the future of SpaceX then experimental rockets blowing up. That said, I can see why some people will invest in SpaceX, SpaceX has a significant lead in the space race and may end up gaining a near monopoly on access to space.
Not if the bigger models have diminishing returns. Lets say you figure out a way to reduce RAM requirements 100X, but 2x increasing RAM usage by 2x only gets you a 1% increase in effectiveness and 3x does not get you any noticeable increase over 2x at all. Sure you can reduce the price per token, but you might have already saturated the market. Even if you haven't saturated the market, your hardware based moat just got smaller and this is going to reduce your margins even more.
It doesn't have to be, defender reveals everything and attacker chooses best strategy.
1. The defender could use both electronic and physical decoys, use air and sea mobile platforms that are always in motion and are difficult to track.
2. The defender can fire at decoys, to convince the attacker the decoys work when they don't.
3. The defender could mix in cheap decoy interceptor missiles that miss so the attacker concludes defenders need 10 missiles to intercept when the real number if 3 and the attacker thinks the defenders are running low on interceptors, when in fact the defenders have held most of their interceptors in reserve.
4. Defender can pretend that expensive systems have been destroyed so that attacker adapts their strategy. For instance, if your defense hinges on a small number of extremely expensive fixed X-band radars and the attacker targets them. Allow some of them to be appear to be destroyed when in fact, you have disassembled them and moved them somewhere else to use later in the war.
I see no evidence anyone is doing any of this today, I'm not making any sort of claims about deception operations in the current conflict.
Seriously? I worked at startups and research institutions. We trained people on interviews. I know Google used to invest quite a bit on interview training.
"Well I would probably go home and work on my resume because that's a fool's errand."
I hate going to work and reinventing wheels all day because the company I work for thinks it's so special that every business function needs a 100% tailored solution to solved problems. I much prefer working somewhere that's able to tailor business processes to conform to existing standards.
I’ve interviewed a few hundred people. Probably approaching a thousand, if not already. An interview is a scenario, and if you aren’t willing to engage in the scenario that we all agreed to partake in, that’s a huge warning sign that you’re going to be difficult later down the line. The point of the question is to have something remotely understandable for both sides to talk about, that’s it.
I'd call it an interviewer failure, not an interviewee failure.
I absolutely want people I hire to be "difficult" when the moment calls for it. If the scenario is one where the right business/user choice is "let them keep using Google Sheets", then the answer I want is "Google Sheets seems fine to me", no matter what people with more power start out wanting. Too many developers have been encouraged to be minions, not professionals.
Ditto for ones who act like everything is a nail for their coding hammer. A developer who can save a company a couple hundred thousand dollars by not turning something simple into a big coding project is a rare and precious commodity. Or should be, at least.
The thing to do isn't to give demerits for "being difficult". The thing to do is to then add something to the scenario where they get into the thing you want them to get to. "For this, we need better access control than Google Sheets allows us." Or, "We need this to be more closely integrated with our accounting system."
Unless, of course, what you're hiring for is the willingness to roll over for unreasonable requests from people with more power. Which, honestly, a lot of places are.
Humans are primates, and primate dominance dynamics are going to be the default absent some conscious choice otherwise. Our whole executive/worker dichotomy is a descendant of the British class system. (E.g., note that airlines specifically have a "business class".) And MBA-driven business culture is focused on short-term managerial interest, not societal value or long-term business success.
I think all of those tendencies come to the fore at any organization that doesn't have either a strong sense of mission or a sufficiently desperate need for success that they pay attention to material reality rather than social reality. With a possible partial exception for things like co-ops and other places where the culture is fundamentally different enough. E.g., Mondragon, or Zingerman's.
I think Google, back in its don't be evil/organize the world's information era, probably qualified. They started with a very strong mission-driven culture rooted in academics and engineering. It took a fair bit of time for MBA dogmas to make it like most other places. But from everything I hear, what once felt almost like a calling now is just another job.
> MBA-driven business culture is focused on short-term managerial interest, not societal value or long-term business success.
This is a common refrain I also believe in and there's an interesting open question that comes up here about whether or not an engineering department should or shouldn't execute an order that intentionally destroys the product for short term gain.
Agreed. To me that's related to the question of minions vs professionals.
If I go to a doctor and say, "Hey, please prescribe me a lot of morphine," the answer will be some version of "hell no". That's because doctors, even if you pay for the visit, have responsibilities to the patient, the profession, and society at large. Responsibilities that should not be overridden by money or power.
The same is true for actual engineers, like the ones that build bridges. But although we often call ourselves engineers, a lot of us don't act like it. We're often more like the minions in a supervillain's volcano lair: whatever the boss says, we do.
We could, as a profession, agree to follow those. We could build an organization that supports people who do the right thing in the face of managerial pressure. We could censure those who don't. I'd love to see it happen, but I'm not going to hold my breath.
>The same is true for actual engineers, like the ones that build bridges. But although we often call ourselves engineers, a lot of us don't act like it.
Because software is the wild west. Maybe there's some exceptions in medical tech, but there's no license at risk nor ethics assossiation to be ousted from (nor to vouch for us) if one day we receive something like: "hey, we need you to triangulate and calculate the parameters needed to bomb this children's hospital. Get to it".
Either we do it and go along with our day. Or we don't and get moved or fired.
In an interview when you’ve been explicitly asked to discuss a topic to have a technical discussion about something is not when the moment calls for it. Doubly so if you’ve been asked twice. If you’re not willing to put aside being technically correct when you’re trying to show off your best self, it’s pretty likely that when things get tough, you’ll behave the same.
> unless of course what you’re being for is the willingness to roll over for unreasonable requests from people with more power
D, do you think that someone saying “can we please talk about a technical topic, here’s an example we’re both likely familiar with” is looking for yes men? I actively want my team and coworkers to challenge me, but I absolutely don’t want to work with that person who appears at every meeting with a list of reasons why we shouldn’t do X.
When I ask an interviewee a technical question, what I want is an answer that is correct technically.
If I want them to give me a different kind of technical answer, then I think it's on me to ask a question that actually requires what I'm looking for. It's not hard! All the Stripe interviewer had to say is, "Ok, great. It sounds like you have a good sense for system capacity. Now let's add another zero to all the load numbers." And then keep increasing orders of magnitude until they learn what they're looking to learn.
I am, just to be clear, not defending people being willfully obtuse or contrary jackasses. But that's not the scenario being described in either the Stripe story or the Google Sheets story I'm responding to. Two apparently reasonable people were asked technical questions and they gave answers that were the right thing for the business.
I think that's good and I like to hire people like that. I get lots of others don't, and I get the POSIWID reasons behind it. But I'm not going to pretend I think it's a healthy way to run an organization. And I also get that the people who like pretense and deference in interviews are not going to like me saying so. ¯\_(ツ)_/¯
I read that as being his emotional reaction, not something he'd say in an interview context. This being an internet forum and all.
What I think he's sincere about is not wanting to work at a place that builds unnecessary stuff. And if people are asking for answers that require building unnecessary stuff, I think it's a reasonable inference that the place is not right for him.
I think interviewing is always a two-way street. If I got the feel that a place was going to have a lot of over-complicated code for me to deal with, or expected a lot of status-driven deference against actual user and business need, I wouldn't just give an interview-ending tart reply. But I would politely finish out the interview and then write them off unless there were other signals that redeemed the bad interview questions.
>do you think that someone saying “can we please talk about a technical topic, here’s an example we’re both likely familiar with” is looking for yes men?
Probably. You say "likely familiar with" but interviews are conducted as if it's a pop quiz. Which I never understood.
If you want to have a decently technical discussion, why not just tell me ahead of time what topic and I come to the interview with research? Why do I have to guess that we're talking about dyanmic programming and be punished if you really cared about graph traversal? (meanwhile the interview is for an embedded programmer. Definitely reflects what you'll really do on the job).
I really hate how few initerviews really felt like they were testing my knowledge related to proper fundamentals and not treated as some pseudo-SAT schlock.
> You say "likely familiar with" but interviews are conducted as if it's a pop quiz. Which I never understood.
Sure - the point of being familiar with it is so that we don't have to spend a chunk of the very limited time we have explaining a problem space, and we can talk about the technical stuff.
> If you want to have a decently technical discussion, why not just tell me ahead of time what topic and I come to the interview with research?
I try really hard to design interviews to not require take home work. I don't have stats to say whether this is right or not, but my goal as a HM is to try and keep the process to recruiter/HM call, 1/2 tech interviews and an interview with someone else on the team who is not a programmer (I hire in games so you're pretty much guaranteed to be working with Artists/Designers).
but also maybe its a green flag in that this employee might see the wood for the trees and save the company a lot of money later down the line. In my experience, a lot of engineers can waste a lot of time dicking around re-inventing wheels and whatnot.
While you consider it a huge warning sign, have you ever employed someone who would answer that way or are you assuming that you're not capable of making hiring mistakes? I can't help but think this "huge warning sign" might simply be a cognative bias where the interviewer is misdirecting their frustration in the poor design of their own process at the candidate [0].
For reference, I think both answers are fine and both perspectives (its a positive or a negative) are equally valid. Its just that I don't think we can confidently state either way.
> While you consider it a huge warning sign, have you ever employed someone who would answer that way or are you assuming that you're not capable of making hiring mistakes? I can't help but think this "huge warning sign" might simply be a cognative bias where the interviewer is misdirecting their frustration in the poor design of their own process at the candidate
Yes, I did. More than once. I always regretted it. Sure it could be a cognitive bias, but the entire interview process is essentially trying to figure out “can I work with this person”.
> I think both answers are fine and both perspectives are equally valid
I disagree - refusing to engage with the interview because you don’t like the question is perfectly valid to do, but don’t expect me to want to work with you over it. We’ve only got an hour, maximum, so any scenario we come up with is going to be contrived and simplified - if you can’t accept that then I’m going to make my decision based on that.
> Yes, I did. More than once. I always regretted it.
Fair.
> I disagree - refusing to engage with the interview because you don’t like the question is perfectly valid to do, but don’t expect me to want to work with you over it. We’ve only got an hour, maximum, so any scenario we come up with is going to be contrived and simplified - if you can’t accept that then I’m going to make my decision based on that.
Sure but lets not forget the other perspective. Candidates have to interview for a cumulative many hours over the course of a job hunt, only to have many interviewers batter them with an array of 1337code, pop quizes or contrived examples, none of which reflect the day to day work of the position they will fill. From their perspective their answer could well be a good one, albeit I agree that having some level of willingness to engage in the theatre is a positive sign.
In an auto-interview I recently did, I was given extremely limited time to "refactor" a bunch of code that was clearly broken. I chose not to refactor and instead fix the brokeness of the code, however I entirely expect to fail the interview because I fixed the problems instead of removing a couple of obviously duplicated code blocks. I can see why I would fail by not "following orders" but their async code was broken and the awful exception handling botched all their telemetry. From a "big picture" perspective I did do the right thing but it might be the case they're too stupid to know that I was doing the right thing (they're a multi-language company, so I assume they're less good at the language I specialise in).
Personally I think due to lack of industry organisation around certification or any sort of guild or union, we have a seriously difficult problem around hiring across the industry. In response to the extremely challenging task of vetting programmers I feel like orgs are simply fishing for reasons to disqualify candidates, as a reaction to this problem.
The rare positive experiences I've had interviewing were Amazon, who act like they want you to succeeed instead of fail or orgs that just half-ass it with low bar challenges, who seemingly accept that they're not capable of perfectly vetting a candidate.
and if you hire only based on solely on employee compliance then you are also probably missing the wood for the trees. I've worked in such orgs and they're extremely vulnerable to cargo culting.
I’m not hiring on compliance. I’ve accepted that his answer is correct but asked for the purposes of the exercise if he can put that to a side so we can talk about it. I’ve worked with and hired people like this and they tend to turn every molehill into a mountain, which is just killer on a small team.
I think you missed the point in GP's post. Not all organizations optimize for problem solving. Some organizations prefer subordinates who follow orders (or better, is able to read the mind of the boss to decipher what order he is actually making) than those who breaks out of the box and says ”just use gsuite, boss."
sure but if its not a privately held business then using gsuite is better for the shareholders. Ultimately its the bosses choice, but for the board to fire them its worth knowing they were aware of being able to use gsuite instead of pissing away resource on a needless project.
and if you don't understand my position then you've failed to interview. Some people just seek reasons to disqualify candidates and I think that's a pretty basic approach to interviewing. Remember, we all have a cognitive bias to hire ourselves and part of improving interviewing process is about trying to mitigate that by creating an environment where the interviewee can show the best of themselves, which may not necessarily reflect our own strengths. This is why pop quiz questions are kinda crap and while 1337code is better, its still kinda crap
> What would you do if two different people were emailing a spreadsheet back and forth to track something?
> I’d use google sheets
> Excellent answer, that is what I would do as well, now what if we wanted to build it in-house?"
> Well I would probably go home and work on my resume because that's a fool's errand.
I’ve not failed to interview. The candidate has been a jerk. Could I have asked a better question? Sure. Could the candidate not have sneered at it and thrown a strop - definitely.
Most real-world scenarios aren't so arbitrary, and hardly any have a "right answer". If I had a candidate that broke out of the box of our interview to give a good answer, and that's not the answer I "want", I'd be more likely to believe the interview question is the problem, not the candidate.
remember that we already did the "Excellent answer, that is what I would do as well, now what if we wanted to build it in-house?" part.
the "good answer" was already acknowledged, the "real-world scenario" answer was accepted.
the second part ("what if we wanted to build it in-house") is purely hypothetical to gauge how the interviewee would approach the specific technical challenge (shedding some of the "real-world" constraints so that the focus is technical).
if they again say "well that is dumb i would just use sheets", that is absolutely an interviewee problem.
Depends on the dyanmic. If you have an excellent candidate you're trying to poach, it becomes an intervewing problem because you're wasting both you and their time.
If they are a dime a dozen, then it becomes their problem. Whether or not they care it's their problem depends on their circumstance.
I'm not OP but - an interview typically has a power imbalance. They have a job and you want the job, therefore the balance tips in their favor. If the candidate is a headhunted candidate (imagine a video game studio trying to hire a creative director from another studio) rather than a cold application, then the power is flipped and the company is trying to convince the candidate to join them.
I also feel it's very easy for a good interviewer to bring the conversation back to the desired scenario.
Anything from "imagine we are in a parallel universe where Google Sheets has not been invented yet" to "how would you design a google sheets competitor" would do the trick.
Yeah - for sure. When I’m interviewing I want to give the candidate the best chance of success and to show off both what they know and how they will work with me.
I generally give it three goes with questions like these - the initial ask, and two clarifications. If we’re not getting anywhere I move on.
Depends on the dynamics here. Remember that an interview is 2-way.
Someone giving an answer like "that's a silly, unrealistic scenario" is more likely than not someone who isn't in need for that job to begin with. I'm sure it's something many wish they could say, because the interview pipeline can be very grating. But not everyone needs to play that game.
> The point of the question is to have something remotely understandable for both sides to talk about, that’s it.
I think a lot of people miss this point.
Real projects are complex and have tons of context at the historic layer, political layer, and technical layer. If I have one hour to do the interview, I need to get to some shared context with the candidate quickly, or else it'll just be an hour of me whining about my job. And I usually don't need someone who is already a senior subject matter expert, so I'm not going to ask the type of question that is so far down the rabbit hole that we're in "wheels haven't been invented yet" territory.
Fundamentally, that's why I'm asking a somewhat generic design question. I do also dig into how they navigated those layers in their past experience, but if I don't see them in action in some way then that's just missing signal I can't hire on, and that helps neither me nor the candidate.
In another company or timeline perhaps I could run a different interview style, but often you're working within the constraints of both what the candidate is willing to do and what the company standardized on (which is my current situation).
I think the contrived scenarios you come up with need to not have a trivial solution. Everything about my brain is optimized for KISS, it breaks everything to turn down simple solutions to reach for something more complex.
Think of it this way: they're paying you lots of money to build something boring that has a lot of prior art/research available to you for free. This could be the easiest money maker in your life.
It's not your problem they're hellbent on building a new wheel. They're willing to pay you!
Chances are, you've thought of your own pain points in whatever they've asked you to build and you've now got an opportunity to shine by solving them and demonstrate your expertise.
There is a tool invented lately, that's very good for solving problems, that are well-researched and had been solved multiple times already.
This tool is actually why there is a RAM shortage in the world right now.
Some even say, this tool will replace a lot of workers soon(sic!).
"That does sound like something nice to have. However, recreating Google Sheets is a substantial undertaking. First, we need to evaluate the business case for duplicating something that already exists to ensure that there is a net benefit in doing so. Second, we need to determine if the business has sufficient capital to see the project through."
I suspect a lot of businesses are going to make this mistake in the "SaaS is dead" era as companies try to eliminate $50k/mo subscriptions for boring business software, and they figure it's easier to burn AI tokens creating an internal solution they didn't plan on maintaining in the far future.
> Tesla has 4 different, 4 person cars. It's redundant.
You are spot on, it makes sense to have the Model 3 (economy sedan) and Model y (upmarket crossover SUV).
My question here is why did Tesla have four 4-person cars in the first place? If you wanted to streamline engineering and supply-chain why have Cybercabs instead of using the model 3 or model y as the base? Why split the company between Optimus and making cars?
Cybertrunk does make sense, it is a technology demonstrator and test article filled with all the new ideas and tech they are going to build into the next generation. They get data on people using it by selling it to them.
What you say is a sound strategy for Telsa to peruse, but they don't seem to be perusing it.
It won't work. The only way to authenticate who ones what coins is with signatures. If the signature algorithm is broken, you can't tell who the original owner is to move the coins to a safe signature algorithm.
You need to more to safer signature algorithm before the break, after the break it is game over.
> It’s worth remembering that Ethereum forked for much less
Ethereum could simply return the coins to the original owners. If the signature scheme is insecure, returning the coins just means the attacker can steal them again.
reply