NXT :: descendant of Bitcoin - Updated Information

[BitcoinForumator]

One word: werewolfe 

[1714213754]

1714213754

[1714213754]

1714213754

[1714213754]

1714213754

[1714213754]

1714213754

[1714213754]

1714213754

[Coinonaer]

please send my some Test-Nxt for the Asset Exchange:
11843877519810994380

- 5k testNXT sent

Thank you Sir

[msin]

wolfe?

https://i.imgur.com/3oBkcGF.jpg

 

The dog is so cute that for a moment I wanted to trade all my nxts for dogecoins...

Haha, that is so good.

[zorke]

What a heck is going on with BTER and Vircurex? I got 2 NXT deposits sitting in both exchanges since yesterday..
Emailed them but nobody responds..
Anyone else?

[miramare]

wolfe?

https://i.imgur.com/3oBkcGF.jpg

 

The dog is so cute that for a moment I wanted to trade all my nxts for dogecoins...

By giving me all your nxt,  I can send you one doge.
Just do you a favor.

[BitcoinForumator]

[l8orre]

Inside Bitcoins Berlin - Great Day, too wasted for detailed Report.

Created Interest in NXT, been parading around in our NXT T-Shirts!

MORE TOMORROW!

[tylerbrad85]

Inside Bitcoins Berlin - Great Day, too wasted for detailed Report.

Created Interest in NXT, been parading around in our NXT T-Shirts!

MORE TOMORROW!

wooo! 

[Coinonaer]

What a heck is going on with BTER and Vircurex? I got 2 NXT deposits sitting in both exchanges since yesterday..
Emailed them but nobody responds..
Anyone else?

same problems for me 

[Daedelus]

I'm surprised that someone didn't already make an altcoin called BullDoge. Or PitbullDoge for that matter.

I can see your point. I don't know what the response will be, it might be both ways. But you can be sure it will garner attention for those that don't look into the direction of NXT - to notice it, at least.

You will have to have "PitbulDOGE" if the AE is implemented as is, names are limited to 10 chars. I have issued them on the TestNet Made a bit of a mess of it, I can transfer them to you if you give me your TestNet account no. Oh what fun...

[jl777]

How long would it take to add support for two types of Assets, fixed and variable, along with the ability to change the amount of variable Asset?

If there was an Asset type field, with 0 for current one, 1 for dynamic, then we can always add other types later with new properties.

I have a solution for fully automated gateways, but it requires people to trust the hardware + software that operates it, so the simpler the code is, the easier for people to understand that the code is clean.

Not very long assuming that community approved the changes and the coder is familiar with Nxt source code.

So basically, we need to create a process for community approved changes, get that process approved, submit a proposal using this process that we dont have, get it approved, somehow allocate a dev to implement it (seems like we even need a dev resource allocation process).

What you are basically saying is that it wont happen anytime soon, unless somebody pushes all that through. I dont have the energy for all that, I want to get fully automated gateways implemented.

If we keep the behavior of asset type 0, all the current usage is preserved. We are only talking about a few hours work here. Why do we need to spend hundreds of hours on process, voting, etc. to implement an extra functionality that is easy to do?

[Come-from-Beyond]

By giving me all your nxt,  I can send you one doge.
Just do you a favor.

The catch is that I own 0 NXT atm. An exchange owns them.

[Come-from-Beyond]

Why do we need to spend hundreds of hours on process, voting, etc. to implement an extra functionality that is easy to do?

To nail the process. For future usage.

[BloodyRookie]

I got the original C version of curve2559 from





Here is the link to both files:

https://drive.google.com/folderview?id=0B7kbeA6whDvNUzVMWXVHWGZtdEU&usp=sharing

First one (left) is total crap:

/* v = x - h k  mod q
 * returns v != 0  */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const priv25519 k) {
   uint8_t tmp[65];
   unsigned w, i;
   for (i = 0; i < 32; i++)
      tmp = x;
   for (i = 32; i < 64; i++)
      tmp = 0;
   mula32(tmp, h, k, 32, -1);
   divmod(tmp+32, tmp, 64, order25519, 32);
   for (w = 0, i = 0; i < 32; i++)
      w |= v = tmp;
   return w != 0;
}

Second one is the one we use in Nxt.

/* v = (x - h) s  mod q  */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const spriv25519 s) {
   uint8_t tmp[65];
   unsigned w;
   int i;
   for (i = 0; i < 32; i++)
      v = 0;
   i = mula_small(v, x, 0, h, 32, -1);
   mula_small(v, v, 0, order25519, 32, (15-(int8_t) v[31])/16);
   for (i = 0; i < 64; i++)
      tmp = 0;
   mula32(tmp, v, s, 32, 1);
   divmod(tmp+32, tmp, 64, order25519, 32);
   for (w = 0, i = 0; i < 32; i++)
      w |= v = tmp;
   return w != 0;
}

[Eadeqa]

I got the original C version of curve2559 from





Here is the link to both files:

https://drive.google.com/folderview?id=0B7kbeA6whDvNUzVMWXVHWGZtdEU&usp=sharing

First one (left) is total crap:

/* v = x - h k  mod q
 * returns v != 0  */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const priv25519 k) {
   uint8_t tmp[65];
   unsigned w, i;
   for (i = 0; i < 32; i++)
      tmp = x;
   for (i = 32; i < 64; i++)
      tmp = 0;
   mula32(tmp, h, k, 32, -1);
   divmod(tmp+32, tmp, 64, order25519, 32);
   for (w = 0, i = 0; i < 32; i++)
      w |= v = tmp;
   return w != 0;
}

Second one is the one we use in Nxt.

/* v = (x - h) s  mod q  */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const spriv25519 s) {
   uint8_t tmp[65];
   unsigned w;
   int i;
   for (i = 0; i < 32; i++)
      v = 0;
   i = mula_small(v, x, 0, h, 32, -1);
   mula_small(v, v, 0, order25519, 32, (15-(int8_t) v[31])/16);
   for (i = 0; i < 64; i++)
      tmp = 0;
   mula32(tmp, v, s, 32, 1);
   divmod(tmp+32, tmp, 64, order25519, 32);
   for (w = 0, i = 0; i < 32; i++)
      w |= v = tmp;
   return w != 0;
}

ok, so "curve25519_i64-wip.tgz" is the one used in Nxt. I deleted the first one

[Come-from-Beyond]

First one (left) is total crap:

/* v = x - h k  mod q
 * returns v != 0  */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const priv25519 k) {
   uint8_t tmp[65];
   unsigned w, i;
   for (i = 0; i < 32; i++)
      tmp = x;
   for (i = 32; i < 64; i++)
      tmp = 0;
   mula32(tmp, h, k, 32, -1);
   divmod(tmp+32, tmp, 64, order25519, 32);
   for (w = 0, i = 0; i < 32; i++)
      w |= v = tmp;
   return w != 0;
}

Second one is the one we use in Nxt.

/* v = (x - h) s  mod q  */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const spriv25519 s) {
   uint8_t tmp[65];
   unsigned w;
   int i;
   for (i = 0; i < 32; i++)
      v = 0;
   i = mula_small(v, x, 0, h, 32, -1);
   mula_small(v, v, 0, order25519, 32, (15-(int8_t) v[31])/16);
   for (i = 0; i < 64; i++)
      tmp = 0;
   mula32(tmp, v, s, 32, 1);
   divmod(tmp+32, tmp, 64, order25519, 32);
   for (w = 0, i = 0; i < 32; i++)
      w |= v = tmp;
   return w != 0;
}

That's bad.

What about comparing outputs of NRS, ur and some other implementation, like NaCl? If ur and NaCl return the same values and NRS returns different ones then we could assume that ur implementation is correct.

[farl4web]

Sometimes I feel a bit frustrated about the fee-system of Nxt, when I see these kind of blocks passing by:


Fee = 0,0016%


Fee = 33,33%

It's not really fair and the rich are getting even richer this way. I love Nxt, but there are small flaws which needs to be addressed. The critics will talk negative about Nxt because of these kind of issues. 

Maybe a percentage instead of a fixed fee? Curious to hear about the options.

[Eadeqa]

First one (left) is total crap:

/* v = x - h k  mod q
 * returns v != 0  */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const priv25519 k) {
   uint8_t tmp[65];
   unsigned w, i;
   for (i = 0; i < 32; i++)
      tmp = x;
   for (i = 32; i < 64; i++)
      tmp = 0;
   mula32(tmp, h, k, 32, -1);
   divmod(tmp+32, tmp, 64, order25519, 32);
   for (w = 0, i = 0; i < 32; i++)
      w |= v = tmp;
   return w != 0;
}

Second one is the one we use in Nxt.

/* v = (x - h) s  mod q  */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const spriv25519 s) {
   uint8_t tmp[65];
   unsigned w;
   int i;
   for (i = 0; i < 32; i++)
      v = 0;
   i = mula_small(v, x, 0, h, 32, -1);
   mula_small(v, v, 0, order25519, 32, (15-(int8_t) v[31])/16);
   for (i = 0; i < 64; i++)
      tmp = 0;
   mula32(tmp, v, s, 32, 1);
   divmod(tmp+32, tmp, 64, order25519, 32);
   for (w = 0, i = 0; i < 32; i++)
      w |= v = tmp;
   return w != 0;
}

That's bad.

What about comparing outputs of NRS, ur and some other implementation, like NaCl? If ur and NaCl return the same values and NRS returns different ones then we could assume that ur implementation is correct.

There is also this c# version

https://github.com/hanswolff/curve25519

Can't this ported to java?

[Come-from-Beyond]

There is also this c# version

https://github.com/hanswolff/curve25519

Can't this ported to java?

R u sure it's bug free?

[Eadeqa]

First one (left) is total crap:

/* v = x - h k  mod q
 * returns v != 0  */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const priv25519 k) {
   uint8_t tmp[65];
   unsigned w, i;
   for (i = 0; i < 32; i++)
      tmp = x;
   for (i = 32; i < 64; i++)
      tmp = 0;
   mula32(tmp, h, k, 32, -1);
   divmod(tmp+32, tmp, 64, order25519, 32);
   for (w = 0, i = 0; i < 32; i++)
      w |= v = tmp;
   return w != 0;
}

Second one is the one we use in Nxt.

/* v = (x - h) s  mod q  */
int sign25519(k25519 v, const k25519 h, const priv25519 x, const spriv25519 s) {
   uint8_t tmp[65];
   unsigned w;
   int i;
   for (i = 0; i < 32; i++)
      v = 0;
   i = mula_small(v, x, 0, h, 32, -1);
   mula_small(v, v, 0, order25519, 32, (15-(int8_t) v[31])/16);
   for (i = 0; i < 64; i++)
      tmp = 0;
   mula32(tmp, v, s, 32, 1);
   divmod(tmp+32, tmp, 64, order25519, 32);
   for (w = 0, i = 0; i < 32; i++)
      w |= v = tmp;
   return w != 0;
}

That's bad.

What about comparing outputs of NRS, ur and some other implementation, like NaCl? If ur and NaCl return the same values and NRS returns different ones then we could assume that ur implementation is correct.

There is also this c# version

https://github.com/hanswolff/curve25519

Can't this ported to java?

Ops that's actually port from same Java  that Nxt uses.

Maye look at that C# version on how (if) he fixes the bug