NXT :: descendant of Bitcoin - Updated Information

[redsn0w]

Did you want some TestNxt ?

[Eadeqa]

I think entropy from mouse is needed for javascript (like wesley client) -- not for Java's SecureRandom

As for words, as I said, don't use cryptic words from diceware. 1626 simple words dictionary will just work fine for 128-bit entropy.

Actually, newest browsers have crypto.getRandomValues - so no mouse movement needed in those cases. Of course still necessary for older browsers.

Well, even if it is not technically necessary for most of the browsers, we should use the mouse movement because

1. With this, we make sure every user (no matter which browser) has a secure account (using mouse movement only on older browsers gives no common picture of the client on every computer. looks insecure)
2. It gives a secure feeling because the user is part of the process

Hmm, anyone else's input on this? I believe relying on system cryptography is always better than having the user doing something (mouse movement). It will be available though, for older browsers.

Its not really needed if cryptographically secure number generator is available,  but it won't really hurt. It will just add more entropy if you start with crypto gen and the user adds more entropy with mouse movements.

[bitcoinpaul]

Parallel blockchains, same NXT tokens?

No - different tokens (NXT and NXG in my illustration).

Then this won't work.

As long as in the client, the user can choose on which blockchain to broadcast his desired transaction (different cost associated to broadcasting depending one the quality of the hardware supporting the blockchain), then high TPS could happen within the nxt network if the user decide to use "fast" premium quality network for specific important transaction.

[bitcoinpaul]

Its not really needed if cryptographically secure number generator is available,  but it won't really hurt. It will just add more entropy if you start with crypto gen and the user adds more entropy with mouse movements.

I really like it because it is secure, user friendly & the user feels the security.

[CIYAM]

Then this won't work.

As long as in the client, the user can choose on which blockchain to broadcast his desired transaction (different cost associated to broadcasting depending one the quality of the hardware supporting the blockchain), then high TPS could happen within the nxt network if the user decide to use "fast" premium quality network for specific important transaction.

True - you would use atomic cross-chain txs to move between NXT and NXG (something that AT will be able to provide).

[redsn0w]

I Found a bug  in the client 0.8.8 (test)

Code:

{
    "balance": 100097400,
    "effectiveBalance": -100,
    "unconfirmedBalance": 100097400
}

Why the effective balance is :


 "effectiveBalance": -100,

[Eadeqa]

I have not heard that before, please do point at any references if you know of any. If it is true it should not be used, you are right.
In that case rand.nextInt(ARRAY.length) would be the safer bet.

I don't have a reference, but say you want to map a random value R between 0 and 15 to a value P between 0 and 9 and use P=(R modulo 10):

Code:

R   P
0   0
1   1
2   2
3   3
4   4
5   5
6   6
7   7
8   8
9   9
10  0
11  1   
12  2
13  3
14  4
15  5

As you see, having the input value R completely random, doesn't mean that P is as random, since you will get values 0 to 5 twice as often as values 6 to 9.

I picked the example to show the problem. With the very large ranges for R (e.g. integer) and very small ranges for P (e.g. 0 to 8191), the problem might just be a very theoretical one.

think of  1626 words as numbers (base 1626)

1. word1
2. word2
3. word3
.
.
.
1626 word1626

so number 1627 would be equal to word1626word1

You can generate a 128-bit number (totally secure using secure random) and then convert it into words

I don't see how there can be any flaw in that implementation, as the original 128-bit was generated with secure random and it is only represented as words

This would be same as representing a binary number as hex or decimal.

 The password made with that implementation can't be any weaker than 128-bit just as converting decimal number to hex doesn't make it weaker


This by the way means only 12 words are needed to convert any 128-bit number into words

[bitcoinpaul]

Then this won't work.

As long as in the client, the user can choose on which blockchain to broadcast his desired transaction (different cost associated to broadcasting depending one the quality of the hardware supporting the blockchain), then high TPS could happen within the nxt network if the user decide to use "fast" premium quality network for specific important transaction.

True - you would use atomic cross-chain txs to move between NXT and NXG (something that AT will be able to provide).

But then it is possible, so my statement is false

[bitcoinpaul]

I think BCNext talked about different fees for different transaction speeds (and/or security?). What are the implications of our two-blockchain-solution (I keep it simple for now, so only two)?

Maybe: We would have the slow one for the average user (minimal fee) and the high speed one for businesses (more fee).

[MadCow]

Unique is being blunt as fuck here, but he does have a point. More big stakeholders opening their wallets would be good, even if only to show that they do give a fuck. But we've down this road before without much results, we can't force people to fund NXT even if it is in their own best interest to do so. So lets put selfish stakeholders on the list of things to ignore, for the moment.

I thought a group of big stakeholders started a fund managed by rickyjames for jl777 to use on all his projects. Correct me if I'm wrong, but I think some of those donations were quite large. I think klee and pouncer (and others?) have funded other projects too (one involving CIYAM?).

Who & what need funding right now who aren't getting it, or aren't just about to get it from the three committees?

From my reading of this thread it sounds like we're still in the planning stage, and we already have funds for the three committees, plus the extra private funds for jl777 etc on the side.

Instead of criticizing the big stakeholders, why not focus on getting agreement on the final plan/direction for NXT, then organise that into a set of projects with a shopping list, then ask for stakeholder donations when they know who and what they're paying for.

I think many fat cats will contribute when the time comes, and I base that on past evidence. There's too much bad blood at the moment IMO, and we don't have a clear road map with a leadership group. Save the stakeholder bashing for if & when the leadership group's pleas for donations for specific projects are being ignored. Try and stay positive on the main task - the NXT roadmap!

[CIYAM]

But then it is possible, so my statement is false

My bad - yes indeed it is possible but it would not be something you could do quickly (it would be a process with a few steps).

[Jean-Luc]

I Found a bug  in the client 0.8.8 (test)

Code:

{
    "balance": 100097400,
    "effectiveBalance": -100,
    "unconfirmedBalance": 100097400
}

Why the effective balance is :


 "effectiveBalance": -100,

Not a bug, effectiveBalance can be negative.

[verymuchso]

think of  1626 words as numbers (base 1626)

1. word1
2. word2
3. word3
.
.
.
1626 word1626

so number 1627 would be equal to word1626word1
You can generate a 128-bit number (totally secure using secure random) and then convert it into words
I don't see how there can be any flaw in that implementation, as the original 128-bit was generated with secure random and it is only represented as words
This would be same as representing a binary number as hex or decimal.
The password made with that implementation can't be any weaker than 128-bit just as converting decimal number to hex doesn't make it weaker

Just out of curiosity. Could you give a brief example, I don't immediately see how to implement this.

[voldemort628]

Did you want some TestNxt ?

423539966622014338
please.
cheers

[chanc3r]

I think BCNext talked about different fees for different transaction speeds (and/or security?). What are the implications of our two-blockchain-solution (I keep it simple for now, so only two)?

Maybe: We would have the slow one for the average user (minimal fee) and the high speed one for businesses (more fee).

the speed of transaction processing is based on the availability of a processor, the time to get the transaction to it, the time to process and the time for the requestor to see the result.

I don't see how parallel block chains address any of these issues other than making reconciliation of accounts harder because transactions are spread across multiple chains...

EDIT: and I agree with BCNext, see earlier post, the faster you want the tx confirmed the higher the fee %age is a possible model but who pays the higher fee... the merchant wanting an instant confirmation or the buyer....?? both models exist

[bitcoinpaul]

But then it is possible, so my statement is false

My bad - yes indeed it is possible but it would not be something you could do quickly (it would be a process with a few steps).

So choosing between these two block chains when making a transaction makes, at first sight, no sense. It will be technically possible, but that's it for now.

CIYAM, could you give a complete overview where we are right now in the thought process so other smart people can jump in and help?

[ZeroTheGreat]

I don't think many people will bother with forging if this is how it is.

Exactly

Hi, I would share my witness

I bought 400.000 NXT a month ago and forging. But I got nothing from this

If I bought so many it was to forge some more. But the reward looks low or inexistent. Look like only extra rich can get something.

The TX fee is okay to me, it's helping the coin to spread between forgers. If we reduce this fee, it will even harder to get something from forging.

I don't know the politic about NXT futur, 2200 pages is to high reading for me ^^ but peoples will not help to forge if they have to spend thousands dollars to receive almost nothing.

It'd be placed at first page:

Monthly ROI% of forging now about 0.1-0.25%. Dispersion of income is inverse propotional to propotion of your NXTs to all NXTs those exist. ROI%'ll change proportionally to business activity on network. So there's no reason it'll change till activity ~ current activity.

Relative amount of fees can't change ROI% drastically itself. We need to find an equilibrium. Last time community voted for decreasing fees from 1 NXT to 0.1 NXT for common txs. Devs'd respond. And then, if changes'll be implemented, we all'll find out how activity'll change.

Everyone, who's thinking about forging like a business'd consider this info. It gives straight answers: forge with this ROI%, try to speed up activity or just stay away.

[CIYAM]

CIYAM, could you give a complete overview where we are right now in the thought process so other smart people can jump in and help?

Okay - well technically I think parallel chains are not going to be very difficult as we *already have one* (it's called "test net") so we are not talking about a huge amount of extra coding that would be required to be performed.

The main thing is going to be to work out what "features" are going to be made available to a parallel chain and what differences in rules (such as say fees) might apply and in particular to get community support for it.

[Eadeqa]

think of  1626 words as numbers (base 1626)

1. word1
2. word2
3. word3
.
.
.
1626 word1626

so number 1627 would be equal to word1626word1
You can generate a 128-bit number (totally secure using secure random) and then convert it into words
I don't see how there can be any flaw in that implementation, as the original 128-bit was generated with secure random and it is only represented as words
This would be same as representing a binary number as hex or decimal.
The password made with that implementation can't be any weaker than 128-bit just as converting decimal number to hex doesn't make it weaker

Just out of curiosity. Could you give a brief example, I don't immediately see how to implement this.

Sure, but I think it's all unnecessary.  Why not just call SecureRandom 12 times to pick 12 random numbers (range  0 to 1625 ). You can use that to choose 12 random words from array. That will be pretty simple and no security/implementation complications.  The words would be chosen randomly and entropy would be 128-bit.

[bitcoinpaul]

CIYAM, could you give a complete overview where we are right now in the thought process so other smart people can jump in and help?

Okay - well technically I think parallel chains are not going to be very difficult as we *already have one* (it's called "test net") so we are not talking about a huge amount of extra coding that would be required to be performed.

The main thing is going to be to work out what "features" are going to be made available to a parallel chain and what differences in rules (such as say fees) might apply and in particular to get community support for it.

Ok, we keep the atomic cross chain transaction possibility in our mind but first talk about all technical possibilities which lead to real world implications of parallel chains.

For example: Your idea is a mix of technical possibilities (raspPis can forge, different fees) and real world implications (we can market a green nxt and forgers could be happy).

What else?