I think he did explain it: Most coins have a centralized development team who are focused on increasing the coin's value. It's a classic investment no different than a startup.
Bitcoin has a centralized development team who is focused on increasing the coin's value. By writing more efficient clients, coordinating soft forks, and curating standards, the Bitcoin Core dev team is directly supporting the asset. So why did the SEC declare it not to be a security? We could speculate as much as we want, but at the end of the day these are the hard-hitting questions that the SEC has been avoiding, and their avoidance of these questions has been bad for everyone involved.
Right now everyone is guessing why exactly the SEC considers most of the top 10 coins to be securities, except Bitcoin, with Ethereum apparently in limbo. Most importantly, it leaves companies guessing whether they'll have to wage a bankrupting 50-million-dollar lawsuit against the SEC to try to defend themselves if they launch a coin they believe not to be a security, but that the SEC later classifies as one through their opaque reasoning process.
I mentioned it in a comment above, but the SEC needs to release something like a 10-step process for determining whether a certain crypto is a security. Something that's clear enough that a company's lawyers can apply it to their products to determine without a doubt whether they are in compliance with the law.
What do you call the group of developers who control write access and pull request approvals for the Bitcoin Core GitHub repository? You can't just apply to become one of these devs; they're grandfathered in from the early days. And they're the sole group who effectively have the final say on what features make it into the network protocol.
To me, that sounds like a centralized team employing centralized decision making.
The Bitcoin network is steered by these developers, but as we saw with the User Acitvated Soft Fork (UASF) of 2016, the users ultimately decide what Bitcoin is.
The vast number of users, or at least, those who run their own node, choose to run a forked version of the client software that activated a contentious upgrade (the upgrade was Segregated Witness).
Only after the fact, this code was merged into the Core branch.
The difference is that nobody has to actually accept updates that the core team make - and this has happened a few times, resulting in forks, although those cases were for things the core team refused to do - how can you “fork” a security? What is the common enterprise when forking a PoW chain?
Exactly the same way you fork a non-security. Security is a legal designation, not a description of how a particular asset is implemented (in a forkable structure like a blockchain).
> What is the common enterprise when forking a PoW chain?
The developers/promoters of the fork, potentially.
