NXT :: descendant of Bitcoin - Updated Information

[S3MKi]

Hello!

My project is Wordpress plugin, that allow log in with NXT token. Plugin name nxtAuth .

How it's works:

• Click on the image with NXT logo and enter valid NXT token
• If NXT server online and token valid - you log in to site with subscriber account
• On the Wordpress settings page you can change address of NXT server. By default - localhost

ToDo:

• Adding modal jQuery window
• Add User page with additional Info, such as transactions, etc
• Integrate with my AM project - http://nxtdb.info

How to test:

• Go to http://nxtdb.info and click "Authenticate with NXT token" in header
• On the top-right corner click logo and enter valid (or not) NXT token for site: nxtdb.info
• Or you can install this plugin on your Wordpress blog. Find nxtAuth plugin, install and activate it.

Bug report:
If you find some bug, send me PM with description and I pay you 100 NXT

P.S. Sorry for my bad english

this guy needs to get some bounty ...

Agree.

[1714245533]

1714245533

[1714245533]

1714245533

[1714245533]

1714245533

[1714245533]

1714245533

[Bitventurer]

https://www.youtube.com/watch?feature=player_embedded&v=McNclx2Zck8

well, we still have the chance to come not first, but best ...
cant wait to make the better video when the asset ex will come..
PS: bounties will be needed

The soundtrack from the video scares me. I would use something like http://www.youtube.com/watch?v=vOTURWqJyhU&list=PL4518B1FCFD912E2F

or we can imput the same mix like on olimpicgames : the Game has changed" , from TRON

but your one is sorry : лaжa
we need agrresivity, agrRresive marketing

[brooklynbtc]

my advice:

HODL!

[gimre]

That will STILL not solve the underlying problem and errors will occasionally occur. (It's x-h that matters)

(Also it wouldn't be that simple, as most likely also verify would have to be changed...)

I think that it does solve the problem and verify() does not need to be changed.

You are right, that it probably wouldn't require changes in verify, but in such case...

I was thinking about it for a while, and tell me, HOW exactly would you like to alter x value?

a) values passed to Curve25519.sign and Curve25519.verify are in PACKED form ok, that one, doesn't have much meaning...
b) x still needs to be valid priv key and Y it's corresponding public key (I call this pair "session key", as it's generated based on message and secret key)
c) you need to make sure that (x-h) will NOT be "negative" in the meaning defined by 'xmath':

Note that there isn't actually such a thing as positive or negative in
a finite field, but you should just pick some definition.  My favorite
is to define elements with the least significant bit set (when fully
reduced) to be negative, and non-zero elements with the least
significant bit clear (when fully reduced) to be positive.  This makes
sure that if x is positive then -x (= p-x) is negative and vice versa.
 - xmath

PS, you know, that thanks to this change, we could most likely get rid of that stupid loop inside Transaction.sign...

[rriky92]

Is there any public node or test node running the latest NRS version that allows
api calls?

Is this documentation at http://www.thenxtwiki.org/wiki/Nxt_API#Description
already obsolete as there were already several daily updated  from 0.5.11 to 0.7.2?

https://wallet.nxtarea.com:7875

[Come-from-Beyond]

You are right, that it probably wouldn't require changes in verify, but in such case...

I was thinking about it for a while, and tell me, HOW exactly would you like to alter x value?

a) values passed to Curve25519.sign and Curve25519.verify are in PACKED form
b) x still needs to be valid priv key and Y it's corresponding public key (I call this pair "session key", as it's generated based on message and secret key)
c) you need to make sure that (x-h) will NOT be "negative" in the meaning defined by 'xmath':

Note that there isn't actually such a thing as positive or negative in
a finite field, but you should just pick some definition.  My favorite
is to define elements with the least significant bit set (when fully
reduced) to be negative, and non-zero elements with the least
significant bit clear (when fully reduced) to be positive.  This makes
sure that if x is positive then -x (= p-x) is negative and vice versa.
 - xmath

If I got an incorrect signature I would use another ephemeral key.

Edit: About "HOW exactly" - I would use SHA256(privateKey + message + nonce) instead of SHA256(privateKey + message).

[Bitventurer]

can anyone please post here the last design with the cells , of NXT ?  from Fartih

[Bitventurer]

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...

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...)

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 )

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?

[gimre]

If I got an incorrect signature I would use another ephemeral key.

Edit: About "HOW exactly" - I would use SHA256(privateKey + message + nonce) instead of SHA256(privateKey + message).

And add a loop over nonce? Don't you see a problem in that?

It's not the math that is wrong in Curve25519.sign(),
it's the implementation that is wrong... and afaik, you wanted to pay 10 BTC to do audit of the code...

PS, you know, that thanks to this change, we could most likely get rid of that stupid loop inside Transaction.sign...

[Come-from-Beyond]

If I got an incorrect signature I would use another ephemeral key.

Edit: About "HOW exactly" - I would use SHA256(privateKey + message + nonce) instead of SHA256(privateKey + message).

And add a loop over nonce? Don't you see a problem in that?

It's not the math that is wrong in Curve25519.sign(),
it's the implementation that is wrong... and afaik, you wanted to pay 10 BTC to do audit of the code...

PS, you know, that thanks to this change, we could most likely get rid of that stupid loop inside Transaction.sign...

Loop over nonce is how it is supposed to work by design. I agree that loop inside Transaction.sign is stupid but it was necessary to hide the injected fatal flaw. Now we can get rid of the loop in Transaction.sign and use a loop inside Crypto.sign.

[gimre]

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

Ahhh, so u want it for cold wallet, now everything is clear. (you should have started, that user won't have access to priv key )

But As I've written:

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...)

Funny thing, I was thinking about making escrow for NXT, but haven't thought about MPK

I need to think about it, but I think that on super-duper secure server, you'd have to do check first, as there's chance, that addrGen(MPubK, userid) would generate key, that does NOT have corresponding private key... (curve25519(priv, basepoint)-> public is not surjective)

[gimre]

Loop over nonce is how it is supposed to work by design. I agree that loop inside Transaction.sign is stupid but it was necessary to hide the injected fatal flaw. Now we can get rid of the loop in Transaction.sign and use a loop inside Crypto.sign.

That's what I'm trying to say, patching Curve25519.sign should allow to avoid those loops at all.

The fact that Curve25519.sign generates WRONG signature FOR SURE wasn't made by design...

[Ola]

https://www.youtube.com/watch?feature=player_embedded&v=McNclx2Zck8

well, we still have the chance to come not first, but best ...
cant wait to make the better video when the asset ex will come..
PS: bounties will be needed

The soundtrack from the video scares me. I would use something like http://www.youtube.com/watch?v=vOTURWqJyhU&list=PL4518B1FCFD912E2F

or we can imput the same mix like on olimpicgames : the Game has changed" , from TRON

but your one is sorry : лaжa
we need agrresivity, agrRresive marketing

Seems XCP is indirectly competing for the 1^st spot, to be out buy Friday as one of their front end devs posted here: https://bitcointalk.org/index.php?topic=430998.msg5031563#msg5031563

First to market: network effect is very important especially in the wake of the mtgox fiasco, but I don't think a week's difference will make xcp come out on top, especially when we have a marketing budget to increase mindshare. The XCP strategy has been basically "we built it they ill come" until recently. They now have a marketing bounty, still nothing compared to NXT'S.

[Come-from-Beyond]

Loop over nonce is how it is supposed to work by design. I agree that loop inside Transaction.sign is stupid but it was necessary to hide the injected fatal flaw. Now we can get rid of the loop in Transaction.sign and use a loop inside Crypto.sign.

That's what I'm trying to say, patching Curve25519.sign should allow to avoid those loops at all.

The fact that Curve25519.sign generates WRONG signature FOR SURE wasn't made by design...

I give 99% that fix of Curve25519 is safe, but the rest 1% doesn't let me to use the fix coz this part is the most critical part of Nxt. So without a formal proof I'll stick to loop inside Crypto.sign.

[Come-from-Beyond]

Seems XCP is indirectly competing for the 1^st spot, to be out buy Friday as one of their front end devs posted here: https://bitcointalk.org/index.php?topic=430998.msg5031563#msg5031563

First to market: network effect is very important especially in the wake of the mtgox fiasco, but I don't think a week's difference will make xcp come out on top, especially when we have a marketing budget to increase mindshare. The XCP strategy has been basically "we built it they ill come" until recently. They now have a marketing bounty, still nothing compared to NXT'S.

We r not competitors, IMO. XCP works with BTC, our AE works with NXT.

[gimre]

I give 99% that fix of Curve25519 is safe, but the rest 1% doesn't let me to use the fix coz this part is the most critical part of Nxt. So without a formal proof I'll stick to loop inside Crypto.sign.

Last one from me:
There's nothing to prove, math stays the same, it's the implementation that's wrong not the math,.
All the math is already in the file in the comments, those comments were made by this "xmath" dude from sci.crypt (I assume this is Matthijs van Duin).

But ok, I can understand, that you're afraid of such change.

[Ola]

Seems XCP is indirectly competing for the 1^st spot, to be out buy Friday as one of their front end devs posted here: https://bitcointalk.org/index.php?topic=430998.msg5031563#msg5031563

First to market: network effect is very important especially in the wake of the mtgox fiasco, but I don't think a week's difference will make xcp come out on top, especially when we have a marketing budget to increase mindshare. The XCP strategy has been basically "we built it they ill come" until recently. They now have a marketing bounty, still nothing compared to NXT'S.

We r not competitors, IMO. XCP works with BTC, our AE works with NXT.

maybe not completely but for popularity and IPO-ing companies we most definitely are...these companies have to decide which platform they want to use to issue tokens which customers can investing in..And they are part of the seed to spur the demand for the platform currency.

[Bitventurer]

Seems XCP is indirectly competing for the 1^st spot, to be out buy Friday as one of their front end devs posted here: https://bitcointalk.org/index.php?topic=430998.msg5031563#msg5031563

First to market: network effect is very important especially in the wake of the mtgox fiasco, but I don't think a week's difference will make xcp come out on top, especially when we have a marketing budget to increase mindshare. The XCP strategy has been basically "we built it they ill come" until recently. They now have a marketing bounty, still nothing compared to NXT'S.

We r not competitors, IMO. XCP works with BTC, our AE works with NXT.

AE will rock, faster better , FX will use our AE , can see it already in my visions

[ChuckOne]

So 2 questions.

1) What is the tecnical term for the assets that will be issued on the asset exchange. Specifically what is the technical term for this type of financial instrument? I know they will be a type of security but they are not futures. When the us treasury issued promissory notes redeemable for gold or silver they called them certificates. Is "certificate" the most accurate term? I, with my silver bullion gateway, would be issuing "silver bullion certificates"?

Share?

2) Even if we know what the technical term is than we probably shouldn't call it that. We may solicit unwanted attention from financial regulators. So what are we going to call them?

Asset?

[ChuckOne]

So 2 questions.

1) What is the tecnical term for the assets that will be issued on the asset exchange. Specifically what is the technical term for this type of financial instrument? I know they will be a type of security but they are not futures. When the us treasury issued promissory notes redeemable for gold or silver they called them certificates. Is "certificate" the most accurate term? I, with my silver bullion gateway, would be issuing "silver bullion certificates"?

2) Even if we know what the technical term is than we probably shouldn't call it that. We may solicit unwanted attention from financial regulators. So what are we going to call them?

I would call it "token".

Token could be a good alternative regarding regulation.

But I think in the end the users will decide anyway how to call it. It is always like that. The many decide.