Everyone talking about malware in dev dependencies as if dependabot only raises issues about that, but it does not. It raises warnings about all sort of "vulnerabilities" irrespective of the threat model.
Even worse, it incentivizes randomly updating dependencies, which is what actually allows supply chain attacks.
> A bad abstraction would at least have had one fire in one place
That's true only for "good" abstractions. Bad abstractions will often require you to change code in all the places using it, requiring you to understand how all of them work and what are their requirements, _all at the same time_.
If someone's account gets lost or hacked, the person with the most incentive to own that account is usually the original owner, so just give it to whoever is willing to pay the most, problem solved. We can call it "proof of stake", where you always stake a certain amount to keep owning your account, and when contested, whoever stakes the most gets it.
Poor people don't deserve rights on the blockchain anyway, it's not like they can afford the transaction fees, if they didn't want their account stolen they should have tried being rich, or buying into nearer the top of the pyramid.
Don't worry about people who pass away or lose internet for an extended period, we'll deal with that in v2, when we get "proof of death" and "proof of internet disconnectivity" on the blockchain somehow.
I think you're right that transaction fees are a key problem. It's ultimately a bandwidth problem. You're bidding for the limited vbytes, and the bidding price only increases with traffic, kicking poor users out.
I think the key thing to recognise with petname systems is that there doesn't need to be this sort of "top-level consensus" as opposed to ecash systems.
You can have two instances of namecoin, say Namecoin1 or Namecoin2. You can just have different domains like alice.nmc1 and bob.nmc2 and have them interoperate properly. You can just keep forking blockchain-based petname systems to overcome the bandwidth/fee problem.
What this means is that Namecoin1 full nodes don't need to synchronize all the domain names on Namecoin2 and vice-versa. Similar to TLDs on DNS. We can imagine that there might be different petname TLDs for different global regions, and they might be merge-mined.
This isn't true for money applications like bitcoin or eth, because by forking BTC or ETH or something, you are creating new coins.
Perhaps some sort of namecoin or ENS-like petname system with multisig or some type of scripting that enables different recovery methods.
For example, you could set your petname up so it can be controlled by a single keypair, which can be overridden after a certain time by a ring signature based on keypairs held by friends, family, peers, and trusted computing devices you leave in a safe deposit box.
Or maybe you could trust your identity with some centralized entity, but only as part of a 2-of-3 multisig with yourself and another trusted entity.
Basicially namecoin with bitcoin-like scripting controls.
Do you need a blockchain for that though? There are cryptography schemes to share a secret (e.g. the recovery keys) between multiple parties, requiring at least N of them to get together to recover the original value of the secret.
And you did not notice how many things require Google Apps/Play Integrity? Heck, most people don't even know how to install apps without the Play Store.
> I've been thinking about this in art. Is it the end result that matters, or the process of creating it?
What is the "end result" you're talking about here?
Programs are complex beasts, you cannot just quickly look at them and get an idea of what's they are actually doing. You might look at the behavior of the program in some limited circumstances, but that will make you blind to all the other situations where bugs will likely hide! In the end a code review is looking at what the "end result" is, and it requires quite a lot of effort!
So without knowing what the end result is, how can you justify the effort for such code review? And that's where the process comes in, as an indicator of what to expect.
Others say that moderate load means a lifespan of ~5 years
Not sure what that means but I would assume that a datacenter will start replacing a node once the error rate hits a certain threshold without really investigating why it failed, so the practical lifespan may be shorter than 5 years even if it would technically still be usable enough
Even worse, it incentivizes randomly updating dependencies, which is what actually allows supply chain attacks.
reply