The Number One Milestone For Bitcoin

When constructing an Assembler or Compiler, the number one milestone is when the Assembler or Compiler can assemble or compile itself.
At that milestone it is truly decoupled from the previous tools required to generate the final product.
The same applies to Bitcoin.
The script was designed to allow embedding data.
PUSHDATA2 allowed up to 65,535 bytes of embedded data.
This would cover practically all manner of private transaction templates.
Government and company public keys for a client to encrypt personal data and only that particular government or company would be able to decrypt.
Bitcoin was originally designed and built on the Windows platform.
Whenever an application was built for the Windows platform, you had a choice whether to bundle everything within the one executable file, or to decouple portions into static or dynamic libraries.
Decoupling code into libraries allowed you to reuse the exact same libraries in other projects and to publish them for other developers to use.
The main difference between static and dynamic libraries is thus:
Static libraries embedded their data and code into your compiled application.
Dynamic libraries set markers within your application and expected the library data and code to be on the host machine.
If every application statically linked the exact same library then that would be an utter waste of HDD space and bloat the executable to an unnecessary size.
The benefit of using a static library is that all data and code goes along with the executable so you don’t have to worry whether the user has the correct DLL on their machine.
For reducing the size of an application, so that the file size is smallest and able to be sent over the internet quickly and successfully, dynamic link libraries were utilised.
This creates the situation called “DLL hell” where you don’t know in advance whether the user has the DLL on their machine, or the correct release version.
One solution to solve “DLL hell” was to send the DLL along with the executable, all neatly zipped up.
However, if you’re going to send the DLL anyway, you may as well compile it using a static library.
If you send the DLL then it usually gets dropped into the same directory as the executable and you don’t gain the benefits of the DLL being shared amongst other applications.
Wouldn’t it be great if we had a technology which allowed a repository of dynamic linked libraries to be accessible by everyone, everywhere, at the exact same time ?
Somewhere that cannot be shut down if the hosting service shuts down.
An application would only need to include information where the DLLs it relied upon were located and how to download/decrypt/unzip them.
That’s where the PUSHDATA opcodes in the Bitcoin script come into play.
PUSHDATA2 allows a DLL up to 65,535 bytes to be embedded into the main chain.
PUSHDATA4 allows for files from hundreds of kilobytes to hundreds of megabytes in size to be embedded into the main chain.
The number one milestone of Bitcoin is to embed the client executable plus any required DLLs into the chain itself.
Next would be the source-code needed to recompile the application.
Once that is done, then it no-longer matters if governments or companies shut down Bitcoin repositories.
The current codebases of the various Bitcoin clients, which are utterly dependant upon other library and code sources, are unsustainable and only requires malicious actors to target a few code dependencies to shut down development.
The code and dependencies relied upon for payments, wallets, and exchanges have to be embedded within the main chain itself before we finally gain total freedom.
