NXT :: descendant of Bitcoin - Updated Information

[bitcoinpaul]

I've seen a couple of forging pools throughout this thread and noticed a possibitly of forging only by giving "forging rights" without giving the NXTs.

Has anyone one of you tried this and which pool did you use?

I am pretty sure that possibility was only discussed, it is not possible yet

Maybe this gets implemented in Account Control, which is developed by BCNext himself right now.

[1714257541]

1714257541

[1714257541]

1714257541

[smartwart]

I've started a section on the wiki for organizing our projects. In particular, check out the List of Proposals and Bounties page. I'm thinking we could link to stuff that is "active" there. That could be links to forum threads, google docs, or other wiki pages where projects are being discussed and hashed out, and project statuses are being updated.

For a good example of this, check out the wiki page for the new address format using Reed-Solomon encoding that NxtChg started a long time ago. Very clearly organized.

My thinking is to use the Discussion pages for throwing around ideas, criticisms, suggestions, etc, and use the main pages for summary of the proposal/project status.

Not enough folks are using Discussion pages . Click on this tab more often:



James, this could be the right place for you to put up your (many, many!) ideas for comment. EvilDave, you could put your carbon offset proposal here too. Lots more projects that I don't remember (this is why we need to put all of them in a convenient place).

Pin, maybe it could be easier if you got everyone to post their projects on the wiki instead? Then you can just go through a list of links.

Don't worry about messing things up, it's a wiki, everything can be reversed. And don't worry if you don't know wiki formatting, just type/copy and paste. Other people can help you clean things up. If there's demand, I'll put up a quick guide to simple wiki editing.

I'll be technical support. Anyone has a problem, e.g. getting errors, can't figure out how to do something, ask me and I'll troubleshoot.

+1000

At least, put all your ideas and projects into this wiki. We need this! Nxt needs this!

absolutely the right thought,
but maybe this:  List of Proposals and Bounties page
is interfering with:  http://wiki.nxtcrypto.org/wiki/Planned_Features

I think we should have ONE place not to waste much time for synchronizing it later?
What do you think?

cheers

But we have

- planned features (http://wiki.nxtcrypto.org/wiki/Planned_Features)
- a big think box which contains all ideas with their possible consequences, and thoughts about target audiences (http://wiki.nxtcrypto.org/wiki/List_of_Proposals)

First one should be more clear and short, the second is more a collection and discussion point which can change several times daily.

We should keep both. What do the others think?

And:
What do others think in general about a / this place for discussion about possible features, service providers and target audiences?

so we have two options:

1. to have planned features (http://wiki.nxtcrypto.org/wiki/Planned_Features) with final description
    and a big think box which contains all ideas (http://wiki.nxtcrypto.org/wiki/List_of_Proposals)

2. to have planned features (http://wiki.nxtcrypto.org/wiki/Planned_Features) with final description
    - extended by a sub topic "Think Box"

In general, could the discussion Tab from Planned Features be the Think Box?

In any case we should restructure the "Planned_Features" to have just the feature as a link.
Behind that link we find the description of that specific feature.
The "Account Control" Page could be the reference for the detailed description.

That would make it well structured like:
+ Feature Name =link=> Detailed Description Page like.   (same as already for Account Control)

[Bitventurer]

Awesome!

can you design the cells in the chain ?

[Come-from-Beyond]

Unclaimed coins have been transferred to the keepers

2'904'675 NXT was sent to each of the accounts:

http://localhost:7874/nxt?requestType=getTransaction&transaction=8229158905562123840
http://localhost:7874/nxt?requestType=getTransaction&transaction=419112573708720396
http://localhost:7874/nxt?requestType=getTransaction&transaction=818794594833884287

PS: Only 100k left on the account controlled by me. It will be used to pay the reward for the injected fatal flaw. All other rewards/bounties must be paid from the accounts controlled by the keepers.

[gimre]

There are 2 options:

1. Patch Curve25519 class
2. Patch Crypto class

Option 1, unlike option 2, may lead to problems u can't even imagine. I would patched Crypto...

There is no way you can patch Crypto.sign. (or it would be bloody dumb)

Common sense doesn't work in cryptography. The problem is easily solvable by another way, so everyone who uses ur fix is just looking for troubles.

The statement that changes in Curve25519 can't lead to private key leakage still require a proof. If u can't provide the math, then u should prove that current implementation was incorrectly translated into Java from the original.

It's not about common sense, it's about knowing and understanding underlying problems.

Let s be your secret/priv key.
public key is nothing more than G*s in very specific finite field.

Finding priv key, while having public key == DLP on elliptic curve.

NOW, signing is actually:
v * temp, where temp is related ONLY to PUBLIC key. (v is dependent ONLY on the data)

What BloodyRookie's patch does is changing v into v' and changing the above to:
v' * temp

This leads to following OBVIOUS implication:

If OLD/original sign() doesn't leak private key bits =then=> PATCHED sign() doesn't leak them.

(whatever old one leaks is up to you, I know it doesn't, cause it's NOT related directly to private key)

[Come-from-Beyond]

There is no way you can patch Crypto.sign. (or it would be bloody dumb)

Why do u think so?

[garp]

NXT is 100% proof of stake and uses something called transparent forging instead of mining. Transparent forging allows you to predict which forgers will author upcoming blocks and if you trust those forgers than your transactions can be thought of as instantly secure. If you dont trust them than its still faster than bitcoin with 1 minute confirmations. Unlike fast coin or min coin though these 1 minute blocks actually add security similar in strength similar to bitcoins 10 minute confirmations. The fact that we dont rely on mining means that huge amounts of resources are saved in securing the blockchain. This means that transactions can still be secure at a fraction of the fee of mined coins. We also take a data driven approach to transactions rather than using scrypts which will allow visa level transaction volume when the need arises. Our devs are implementing decentralized asset exchange later this month! Stick around and keep reading and learning. There is a lot to learn about nxt and a lot that is worth learning. This is not your average copycat coin and you are very early to this party indeed.

Very well and clearly explained.
Although I'm trying to keep up with this thread since 2013, still usefull for myself as well 

Thank you.

[gimre]

There is no way you can patch Crypto.sign. (or it would be bloody dumb)

Why do u think so?

Let's say you have leaking tap.

Patching Crypto.sign is like putting bucket under the tap instead of fixing the tap itself...

[scor2k]

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

[l8orre]

For raspi (model B) use settings:



       SNl    0:34 /usr/bin/java -Xms128m -Xmx756m -jar start.jar STOP.PORT=7873 S

works fine - a common error I made usually is to set it at 450/450 or so - that limits the heap space to 450MB, which is NOT enough!

Xms128 is the MINIMUM heap size,

Xmx756 is the MAXIMUM, presto!

[gimre]

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?

[Anon136]

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?

[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

[Come-from-Beyond]

There is no way you can patch Crypto.sign. (or it would be bloody dumb)

Why do u think so?

Let's say you have leaking tap.

Patching Crypto.sign is like putting bucket under the tap instead of fixing the tap itself...

Public source code contains such comment:

Code:

		/* Signature generation primitive, calculates (x-h)s mod q
		 *   v  [out] signature value
		 *   h  [in]  signature hash (of message, signature pub key, and context data)
		 *   x  [in]  signature private key
		 *   s  [in]  private key for signing
		 * returns true on success, false on failure (use different x or h)
		 */

Why don't u want to use different x?

[Bitventurer]

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

[Come-from-Beyond]

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

[gimre]

There is no way you can patch Crypto.sign. (or it would be bloody dumb)

Why do u think so?

Let's say you have leaking tap.

Patching Crypto.sign is like putting bucket under the tap instead of fixing the tap itself...

Public source code contains such comment:

Code:

		/* Signature generation primitive, calculates (x-h)s mod q
		 *   v  [out] signature value
		 *   h  [in]  signature hash (of message, signature pub key, and context data)
		 *   x  [in]  signature private key
		 *   s  [in]  private key for signing
		 * returns true on success, false on failure (use different x or h)
		 */

Why don't u want to use different x?

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

[Come-from-Beyond]

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

[lophie]

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

[Come-from-Beyond]

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.