Yay! I like dreaming
I'm trying to look into NXT... and I have a hard time.
As for the expodential groth, I read somewhere something like: Replacing two inputs from the stack with one output that is only as long as the two inputs together... is unlikely to exhaust the memory. And I agreed very much.
There are several scenarios:
Casino, dice, gambling:
Say a casino (dice type for this sake) where a secret is held by the house, while the hash of the secret is published in advance of the game. The numbers "drawned" are determined by hashing the concatenation of a secret and [something else, like a sequence and/or a seed from the player, etc.] which can be verified by the player after the secret is published.
Now, let's say the house is waiting for its "lucky day" and decide that it's the day it cheats, willing to pay the cost of loosing its reputation. Now the player may prove that the house cheated and may say "well, I can prove that I have been scammed", which doesn't get him his money back.
Now, let's say the house made a transaction that would pay the player of proof that hash(secret+seq)!=drawnhash, then the player is guaranteed not to be scammed..... unless the house never reveals the secret.
Then the house may make another deposit, which requires the house to publish the secret to the blockchain before a deadline in order to get it refunded. A transaction that pays the player with a locktime take cares of compensating the player if the secret is never released.
After the funds are deposited, the player may safely play with no possibility of being scammed. If the house cheats or doesn't publish the secret, it is compensated.
Instant transaction:
Barely-trusted (i.e. untrusted) bank runs its service.
The account holder sends a deposit that is redeemable with:
(proof of bank's wrongdoing + accHolderSig) or
(proof of accHolder's wrongdoing + bankSig) or
(accHolderSig + bankSig)
The account holder signs a transaction, with a locktime that will allow the bank to redeem the funds in the future in case the account holder stops collaborating or disappear.
If the bank wanted to send funds to the account holder, the bank may do so by creating a new transaction that requires the client to declare something like:
"My last transacton was [transaction+amount...] at [sometime in the past]
Today is [date/time]
I collected $y from BankX and acknowledge that [my current balance is now $z"
If we concatenate the parts and verify the signature, the bank could prove that the account holder is not being a gentlemen if he signed contradicting declarations such as "As of today, the last transaction was two days ago" and another message states that a transaction occurred yesterday.
The bank may take that withdrawal at any time, unless the account holder already claimed it legitimately.
The same applies the other way around. The bank does not fulfill its obligation, the account holder remains unharmed.
And more...
Here, much can be done instantly outside the blockchain, while remaining totally safe for all parties. If is yet interesting to be able to trust a protocol without having to worry about trusting the centralize bank itself. Even though this example is about a centralized bank, a protocol can be made so that banks have account with each other... and collaborate in a way that allows inter-bank transactions... and finally a decentralized instant payment network for cryptocurrencies. (did I say I like dreaming?)
Not only would that allow decentralized instant transaction, but it would also help keeps the blockchain smaller.
...and it seems to me that only OP_CAT is missing. And you know what? I would argue that this actually IS a bit of transformation, even though it seems that getting it done in bitcoin is not at the door step. But I am still dreaming
Yes, it also require the actual engines to run this on top of the cryptocurrency... and now I am looking for one over which we can actually build this.