Quote from: lophie on February 09, 2014, 08:41:39 PM

Quote from: gimre on February 09, 2014, 08:13:08 PM

Quote from: lophie on February 09, 2014, 06:04:47 PM

Signing on the client side is already implemented in the android client and the code is open source. The only problem is the desktop client communicates over browser so the signing should be java script, But anyway I honestly don't know how this is related.

With MPK you can have one public key that is able to generate other public keys without touching the private keys. Because they are linked from the seed in a certain way, Both chains (Private key chain, public key chain), will generate corresponding keys in a sequence.

A very good example is AcceptBit.com which is a private key free POS system.

The MPK functionality is VERY important to my new exchange, Also I believe it to be a key element in the automation of decentralized markets, At gateway level.

- Lophie

p.s: There is no way to do this in NXT, I am lacking proper knowledge to surpass the dam of different curve functions between Bitcoin and NXT...

Quote from: lophie on February 09, 2014, 06:04:47 PM

Signing on the client side is already implemented in the android client and the code is open source. The only problem is the desktop client communicates over browser so the signing should be java script,

Signing in JS has been done, there was bounty for it.

I was thinking more about it, and it wouldn't be as straightforward as I thought, mainly because curve25519 is not bijective.
(But it would still be partially doable...)

Quote from: lophie on February 09, 2014, 06:04:47 PM

But anyway I honestly don't know how this is related.

It is related, since it's easy to do it on actual PRIVATE key, but most APIs in NRS, do not operate on PRIVATE key, but on a password, that is passed to SHA and the output is your actual PRIVATE key.

This additional step (sha) makes it currently currently impossible. (well it would be possible, it hash function would be transitive, but transitive hash function, wouldn't have much sense Wink

)

So YOU are able to generate derived public keys and user is able to generate derived private keys, BUT
is there a client that accepts actual PRIVATE key and not password?

But the whole point is isolation of private keys!. Ok I will just give away my implementation idea here to explain, So basically the exchange market is 100% cold because it doesn't even hold pre-generated address pool to assign to users. It only holds a single master public key. Whenever a user asks for thier deposit address a single invocation of addrGen(MPubK, userid) would always generate instantly the same address (Note that there is no private keys involved here!), On the secure super duper server that does not directly communicate to the exchange the coins can be spent by addrPrivGen(MPrivk, userid) <-(Not that addrPrivGen takes significantly more time since you actually have to generate from 1 up to userid number of private keys, but that private key will be able to spend the coins in that address).

The dangers of exposing MPK are only limited to expose all possible public keys in the sequence.

Note that this idea is DONE bitcoin side... with oh many new ideas coming this way

you working on sms gateway for nxts?