Topic: NXT :: descendant of Bitcoin - Updated Information - page 445. (Read 2761644 times)
If we go this route, we can have our global nxt chain with TF. What would be the current implementation of it?
Did mintpal refund people the money?
Demand your money back if you paid them for listing Nxt
Just for the record. I seem to have got mine back.
Can't we have specific clients for each chain like we have now with Wesley's webclient for testnet.
That could be a good idea - perhaps if we added a few extra APIs that control things like fees then it would make it very simple to "add a blockchain" to a client.
This is a software problem and what's best for the user. Let's skip that for a moment.
Can't we have specific clients for each chain like we have now with Wesley's webclient for testnet.
That could be a good idea - perhaps if we added a few extra APIs that control things like fees then it would make it very simple to "add a blockchain" to a client.
What else?
It would allow for TF in a country that is blocking or slowing down access to the main chain (also allowing for "local/community currencies" that might appeal to some).
Also it would mean that there is less incentive to clone Nxt (particularly if the motivation for doing that is because of the "initial distribution").
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.
Thats how I did it already. Your approach intrigues me because I don't know how to do that, I dont like that
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.
Can't we have specific clients for each chain like we have now with Wesley's webclient for testnet.
Basically you could have NxtINDIA client linked to only NxtINDIA chain.....& NxtCHINA client to NxtCHINA chain. etc.
Maybe NxtINDIA client is for HIGH END SUPERFAST chain & NxtCHINA is for SLOW low end chain.
The CLIENT would be the gateway to specific features.
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?
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
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.
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.
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.
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.
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?
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).
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
Did you want some TestNxt ?
423539966622014338
please.
cheers
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
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.
I Found a bug in the client 0.8.8 (test)
Why the effective balance is :
"effectiveBalance": -100,
Not a bug, effectiveBalance can be negative. Code:
{
"balance": 100097400,
"effectiveBalance": -100,
"unconfirmedBalance": 100097400
}Why the effective balance is :
"effectiveBalance": -100,
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).
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!
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).
Maybe: We would have the slow one for the average user (minimal fee) and the high speed one for businesses (more fee).
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.
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
Jump to: