Proof isn't always possible

 If I want to certify object code but don't want to share the source, ONE idea would be to provide an interpretive script that duplicates it. Encryption would be an example. My idea was: if I can write C++ code that decrypts text enciphered by my python3 implementation, that would certify it while capitalizing on faster execution, yet defeating efforts to brute force cryptograms.  Specifically in encryption, the rule is: nothing secret except the message and the password. Ethically, derived key material represents a grey area. If I use a C++ object from an unknown source, and this object decrypts what Python has enciphered AND Python decrypts what the object has enciphered, then the object is valid - as long as I check EVERY message. A back door treats some passwords (or messages) differently. As a learned rule, this helps me think more clearly about it.

 Cryptocurrency is NOT a suitable medium of exchange for the 21st century. Cryptocurrency is conceptually, non-counterfeitable coins attached to a resilient blockchain. By associating the blockchain entry with a jpg, we get the idea of an NFT. These are worth what someone will pay for them in the same way as a painting. However, the coins are subject to failings. 1. Cryptomining of the currency (computing new coins) is inflationary. 2. Cryptowallets can be summarily deleted, by either a hacker or a despotic government. A Backup wallet is a workaround, but by the mechanism you reconnect the wallet to the blockchain, you can introduce a mathematical attack. 3. Marked bills do not name criminals. They identify the holder by possession or transaction participation. Each cryptocoin contains literally EVERY transaction it has ever been associated with as part of the coin. So arguably EVER coin acts as a marked bill. 4. No one regulates the capitalization of the blockchain. If by some art...

We love to hate DRM, because we associate it with degraded quality or loss of data control. Sometimes we associate it with loss of privacy when we register.  Here is a formative "Open DRM." The kernel of the system is going to be the idea that a salted hash is a member of a class of some kind. If I start with a MEMBER md5 hash and run 200,000 iterations of the correct salt, I hit a control value predictably.  The potential problem arises not from providing 199,999 different possible keys, but from providing a registered customer with his own valid replacement, on that rare occasion when he proves he has purchased it, and we must re-present his original key. Standing behind the warranty is what makes us reputable. To preserve his privacy AND the security of our system, we do not want to store the enumerated value on the server.  However, we can reasonably suppose that we can manage to keep a secret value secure. I propose that the DBM or LLC choose a passphrase of some kin...