There are two ideas here - how to construct a sharable model without a zero-knowledge-proof such that the receiver gains nothing from working on your model and how to construct a revenue stream from a single sale product. These generic iseas are applied to my efforts.
Two new method of software construction and sale
Non-cloud sold software as a service
Aaquantum-co-opt- Two new method of software construction and sale
Sometime, an expansive
small core can underlie a large number of applications such that the core is
required essentially in all applications. Typical example of essential core is
solution to NP-Complete problem. In these cases, a simulation of some
applications can be built using copy-left software; all except the essential
core.
The essential core is
simulated by a table lookup. The entire simulation can now be safely sent to
investors, alpha users, market specialist, venture capitalist etc. It proves
1. The progress already made
2. Safety from competition
3. Applicability to consumer uses
4. Time and cost estimates on remaining work
5. Parallelism possible in rapid deployment
6. What the investors bid on
7. Essentiality in the applications considered
It is separate from the
selling documents attached to the application. The final product is the
development of all the non-essential components given for free, without
limitations. A bounded, but functional essential core is also so available. No
one can question a proprietary component to duplicate a slow part in component
pipeline.
The essential defeat of
copy-left for some applications by doing some parts open, some closed; obeys
these cardinal rule of software from Natural Justice
1. Thou shall never call code written by others your own
2. Thou shall never interfere in viral growth of free software
3. Thou
shall never assert software-patents
Selling is accomplished by
including the complete package with extra optimized component.
The second essential method
is never sell the essential component but provide its results as a remote
software service black box which accepts an encrypted message and returns an
encrypted answer, perhaps using own values from previous transactions as well.
An
application
Rather than NP-complete,
provably hard encryption problem is used – square-root of 1000+
bit integer field. For simplicity it will be called dsqrt. Also
useful are dmul, ddiv and dexp all modulo some M, ^ is exponentiation., % is
mod. Most cryptography magic arises from remainder operation, % in C
Cryption
Put(message,
key, sender-edata, public-receiver-edata => fail | e-message, p-key, p_data)
-- all published, public-receiver-edata
has M
Get(e-message,
dsqrt(p-key,M), p-data, receiver-edata,
known-database-edata => fail |
message, who, when, serial, …)
Note
that
p-key = (key*key)%M
And
dsqrt(x,M) = (ask_me(p-key^public%M))^private%M
I know not public or
private, user finds the dsqrt since dsqrt and ^ commute! I simply calculate the
dsqrt of some number sent to me! I and consumer need each other – only customer
knows the public, only I know semiprime roots!, not sender, not receiver.
Clouds are considered union
of sub-cloud. There is one or more me in every sub-cloud. Any consumer can
select sub-clouds for enabling ask-me. Regardless of connectivity loss, as long
as one sub-cloud works, ask_me works.
Critical is me as an
essential service, whose rates can be set by marketing and advertizing
concerns, leading even to provide the whole chain as a product. Additional to
work here is conversion of any software product as periodic (annual or monthly)
service.
Elimination of
Man-in-the-middle
It is assumed that
digesting is a secure operation. How then one ensure a and b are related.
Assume that digest are half bitwidth of encryption. Then (known1^cpower%me) =
digest(a) // digest(b) && (known2^cpower%me) = digest(b) //
digest(a) where // indicates bit concatenation, implies that a, b
are related. Reason is that there is no effective way of forcing digest on
right and left implies that right has the known decryption.
Register
To setup an account in
family f, consumer does
Register(family,
f_permit,name => who,known1,known2,public,private) -- After register, only
factors of who kept.
After getting f_permit from
the family admin. After testing once, who of a name is known. Then encrypted
messages are sent. One can set up records for a name in tables and use the
digest of the block, rather than who, make who a field of the record, thus
extend binary to secure n-ary relation.
A new family is created by fregister.
fregister (
long_family_name => family, permit_base)
f_permit(name) =
permit_base ^ digest(name)
Secure broadcast
The message can be
encrypted once. So is p_data. They are published once on a cloud. The key is
squared once for any recipient in consumer who to p_key. To read, the recipient
gets the dsqrt from me. Uses that to decrypt e_message and e_data.
Secure message
To guard against malicious
cloud modification, the sender can pass the square of the digest of message.
That can also be dsqrt and checked.
Relevance to class-of-75,
other friends and me
In order to ensure freedom
from bugs most of software must be open source. But that makes software hard to
get revenue from. Also socialist FSF, with its copy-left, has collided with
other less restrictive open sources. Ideal situation is mine who claims
knowledge of a very hard problem, whose answers can be checked easily on every
use and whose veracity can be checked by testing, even by adaptive dsqrt.
Further most of the program is open source. Open or closed source replacements
are possible provided that the extender disclaims any software patent actions.
With this in mind, family,
class-of-75, other friends, investors, venture capitalists and journalists can
peruse to answer
1. Feasibility of making money
2. How much has already been
done
3. Competition and uniqueness
4. Difficulty in compete by
this method
5. Difficulty in compete by
another method
6. Lack of disadvantages by
open source
--------------------------------------------------------------------
Aaquantum-co-opt- Non-cloud sold software as a service
Sometimes, one is interested
in viewing software products as periodic service, where people buy the latest
edition as a service, and the old version develops a flaw, the certificates
issued by the old software are not valid. This entire work depends on the
principle that a semi-prime is crypt-useful only if its factors are secret. If
the owner of the semi-prime discloses the factors, all crypt-certificates lose
their certificate character! It is a dumb idea to do it for messages sent by someone.
However, it is perfectly sane to do it for defeat of the man-in-the-middle!
You want to duplicate Microsoft
windows for protecting revenue!
While none of the old
messages become reusable, the certificate of genuineness of the mail owner public
is at stake! An ordinary criminal can criminalize new customers of the buyer.
The buyer has no sane option but to buy a new identity certificate! Note that
the identity certificate semi-prime idsp
has nothing to do with communication semi-prime of the buyer! If I use it to
certify identities every year, then disclosing its factors end every year means
1. All previous identity
certificates are lost
2. No communication of anyone
is disclosed.
3. Existing customers can
reuse the semi-prime as before. However, while criminals cannot spy on mail,
they can build fake confusing identity certificates and destroy some mail,
while launch some sophisticated adaptive attacks. In short the critical
principle of mine is lost – never trust anything, even repeated, without a
certificate. But this principle, or another reason, gives me clever resale
method!
Use of these ideas
Use in my secure email system is easy.
Put( target, key, sender_full,
Target-public, Certificate => emessage, ekey, letter-cert)
Get( allowed{sender}, emessage,
ekey, letter-cert, receiver_full => message, …)
Trust in sender and letter requires
certified identity!
Kill spam
My method provides a technological solution to the worldwide
problem of spam! Note that the Get is not
from anyone but from a whitelist! The list is in consumer control! It may
consist of names or recommended_by names. If the sender is
not in the whitelist, letter goes to wastelist! Initial whitelist will include
on-government-service and essential-services (police, medical, emergency etc.).
The list can be dynamically expanded or contracted. A republican certificate may
allow republican candidates, authorized to send mail. A consumer might add
democrat, republican, libertarian etc. Point is
1. Allowed list may permit not
just individuals but idea keepers.
2. Allowed ideas may or may
not be static. People conforming (even incorrect fine, the allowed cut) after 1
or 2 errors) allowed even not known.
3. Not just political but advertisement
as well! Generally some companies allowed if selling wanted. To some extent,
consumer directed advertisement!
4. Perhaps user allows movie
stars, sports stars, typical consumer, religious, business or political stars. Everyone
is allowed to be stupid.
5. Consumers are allowed to
lie on anything, including by convincing-lie
software. Change whitelist dynamically. Prevent id detection. So much for
incentivized surveys.
6. Membership in any list
requires a certificate! Days of honest SPAM are over! Today’s spammer lies
about who sent and why sent!
Use in class-of-75
Above is just a label, to
which some subscribers send letters. Essential proposed difference is trust! At
this moment, no one can truest the sender, only possible in cryptographic
transparent scene. Use of my cryptography, when done, in billion odd groups is
intended to be transparent. Instead of submitting your jewel to current email,
you submit it to aaquantum-email, also used for transcripts of allowed senders.
Unlike email, and more like Facebook, you would have, you settable, event
generators. Those specified by at least 1
class-of-75 other than yourself will be sent, via class-of-75 to the interested
and inserted, according to policy, at once, or delayed into the transcript.
Messages have a subject,
imp0licitly if replied to, explicitly if named. On consumer list of allowed links
to messages in store computer for class-of-75 (perhaps replicated) will be kept
per consumer. Simple primitives will exist to move messages to consumers. There
is no need to repeat messages again, rather than link to set of links for that
subject.
All messages will have a
one line summary, displayed in the transcript along with a link to the
body. Complete line looks
<reasonable-reco>
<who> <subject> <line …> <detail-link>
$rea above is needed to
allow a designed reader by consumer to certify that the summary is indeed a
fair summary, not a moronic headline! $who is the writer. $sub is about. $dea
is link to real mail.
Apart from <like> and <dislike>, there will
be <n-like> and <n-dislike>, Also a link to conversations.
Class-of-75 is as if a virtual person, with Facebook
like interface!
Why confident of win
There are exactly two ways
to win trust – long trustable history, or provable can’t hack i.e. cryptography.
EVERY ONE hackable WILL be hacked and that means ALL members of class-of-75.,
specially as unhackables increase and criminals become desperate! I
hope all bless me in this confluence of fighting old age and block-medium.
Regardless of philosophical belief, 2020 onwards, earth belongs to the
unhackables!
