One of the mandatory ones, in my opinion. It's 3rd or 4th in terms of the linter that catches actual bugs for me before they are bugs, behind the number one errcheck and probably number two "unused", checking for unexported package-level variables that are unused. Go prohibits variables to be unused within a function but the compiler does not check that unexported package-level variables are used; this has helped me find a lot of places where I created a metric for something but never quite followed through to actually triggering it, log messages, bespoke errors, etc.
Why would carbon dating be relevant for extra-terrestrials? Without knowing the amount of C14 in their native environment, I don't see that you have a basis on which to calculate age from the current amount of C14.
They rely on a few assumptions that seems universal to living organism on earth. One basic one is if that org live long enough on earth, their body composition of c14 should roughly match earth. This "long enough timing" can be short as few months to years depending on which part of the body you sample the dna for analysis. Is it definitive no. It is even accurate enough to be admissible in court very similar to lie detector. But the science and statistics analysis around it are very solid and well develop that for some people it is good enough for a guesstimate than just mere gut estimate. Of course if those aliens travel to earth from their home world and immediately die, then the c14 ratio will be off. But then again given so many things we don't know, some trade-off and assumptions needed. We revere Newton even though his formula is way way wrong when we discovered Eibstein relativity. Yet, we all still use Newton good enough formula in our day to day physics. Same with C14 even if it is used for this ETs.
> With staking, the biggest holders just sit there and collect coins with few operational costs.
Every holder who is staking is rewarded for staking, in proportion to their stake.
> To me it sounds like staking has a much more powerful snowball effect than mining
No, because issuance under proof of stake is much lower than that under proof of work.
The point of validating is to secure the chain, not to get rich. The more validators that are active, the lower the per-validator rewards, reducing compounding effects.
The "kiln" testnet is currently running and will carry out the merge in the next few days, which is the final step before the existing proof of work testnets transitioned to proof of stake and then the Ethereum mainnet itself. I think that counts as "obvious evidence".
In this case the third party could be the employer that pays the salary, or the bank that receives it.
The decision to trust the issuer or not is down to the entity viewing the information, and depends on the particular requirements of the situation. A zero-knowledge proof that I am over 25 issued by my local library may be enough for the local theatre to let me in to watch a suitably rated movie, but not for the local bar to let me purchase liquor (in the latter case a proof directly from a government entity would be more appropriate).
A slight aside, but so many of these keys seem to have the touch point / button applying force perpendicular to the direction of insertion, I wonder if there is any long-term potential to cause damage to the USB interface.
I have one of those you don't need to _press_ it seems the conduction of the finger is "key" (haha, sorry). But yeah I agree if you are pressing it _hard_ it will likely damage the usb port especially considering it doesn't have the housing around the contacts which I would say might protect the port a bit better, probably translating the force not to the contacts.
The point of having separate imports for separate versions is to allow for use of (for example) both v1 and v2 of a module within the same codebase, if required. Your idea would force a single version, which means that would no longer be possible.
ok, reasonable, though it would seem that one could do both. i.e. for those that dont want to include multiple versions, be easy, for those that need them, then you have extra complexity.
It's non-obvious, though. Change something in /etc/systemd you can expect to have to tell systemd about it. Outside of that directory, there's no indicator you should do so.
"Long time" is also relative. I've been updating /etc/fstab directly for over 25 years.
We chose this method because it requires trust of just one entity (the lambda end point we provide) rather than trust of each app that might interact with SimpleID's SDK. If the seed phrase is generated client-side within an app, that developer could hold onto that seed and use it maliciously.
Identities created through SimpleID can be used across multiple apps, so it's important to us that developers are only able to access data specific to their app (i.e. app-specific encryption keys).
