I would have a huge list of things to evaluate you to see if you are bang material or romance.  Difficult question now for you, Monica, what do you think men would prefer: to be bang material or romance? Take some time to think. |
|
|
|
NCC-1701-D is running on 8 GB VPS, with -Xmx6144M, and java is currently using 3065M. On another server I have java is currently using 2124M.
 Why so much? Am I missing something? Why on my PC it only takes 200 M? Starship has to be big |
|
|
|
Noody interested to trade some next for coinye west?
 |
|
|
|
They are investing one or few Bitcoins with hope of turning it into hundred. Of course they are not telling you anything ! They share and spread FUD but no good advices  They are pointing at NXT as a distraction while they are investing on an other coin ...to fuck you later. Who woulda thunk!  |
|
|
|
don't see any problem there.
Maybe it would make sense to replace unlimited by an defined number to avoid "Monopo(o)ls".
(don't know how to do in open source SW)
Big pools could become bigger and bigger due to more frequently forging.
This allure (more accounts => more frequently forging) + self gaining...
Node owners must be allowed to configure it to any number, 'unlimited' or '0' or '42' by default, I don't care. It'll be a nice parameter to have, that's all. The way it's set up now is 'unlimited', because there is no configurable restriction at all. |
|
|
|
yeah, its a question how it becomes implemented.
I also think in general, every user should decide how to handle it.
getState shows "numberOfUsers":2 When user unlocks their account on the node, check against how many users are already forging on that node, check if AllowedForgingUsers is set to 'unlimited', allow to unlock, if the number is less than AllowedForgingUsers in web.xml - allow to unlock, and if it's equal to that parameter, display 'Node forging capacity is full' or something like that. Or do you see any other difficulties in implementing this? Please explain. |
|
|
|
Added a poll for you guys to decide  I vote Sexy. That's good enough for me |
|
|
|
Transparent Forging will lead the user to jump directly to the nxt node which will forge nxt block.
This also leads to "self-fulfilling prophecy".
What would be the purpose of this jump? It's not the node that forges, it's the particular unlocked account that forges. The node is just a platform to forge. There will be internal account<=>connection and external account<=>connection. +Internal is e.g. connect forging power of your own VPS Nodes to earn NxT for paying them. +External is you and me and other people will connect there forging power. External Connection: From my understanding, all particular unlocked accounts will "point" to one Node to accumulate the forging power. This Node would be split the forged NxT based on contract parameters. Now, if we would know the next Node will forge an Block we could point our account to this Node for participation. This assumes the participation is higher than possible contractual penalties for leaving directly after the Block was forged and the interest was payed. If that is how it works, great! Why not let the node owner decides how many accounts are allowed to forge on his node? This is easy to implement, is not against freedom, shows respect for property (node is the owner's property and he should decide how many people are allowed to unlock on his property), good for decentralization (motivates others to set up their own nodes). I assume that's enough reasons to code in this additional parameter to the config file. Don't see any single reason why freedom of choice must be limited here. |
|
|
|
Transparent Forging will lead the user to jump directly to the nxt node which will forge nxt block.
This also leads to "self-fulfilling prophecy".
What would be the purpose of this jump? It's not the node that forges, it's the particular unlocked account that forges. The node is just a platform to forge. |
|
|
|
Well, yeah I know they live both, I was asking if you guys had a preference. It is obvious you don't.  And I am smart. Or at least smarter than the average. I can mine and have done a little. I am pretty techie, have a degree, worked professionally at at fortune 50. Maybe you mean a different type of smart. But can't we have both? Sexy and smart? Or that is a no no. No, you should decide whether you join sexy or smart, can't join both groups at once. |
|
|
|
Then he will paste 100000000000 and we will have "only one VPS". It should be calculated based on uptime, connected peers, technical characteristics, etc
Why would he do that? I'll do that. Forbid me (how?). And why would everyone go to just one node?
Other users will have to give me some public key once, lay down and gain nxt on forging. Why they should seek for another node if they are all the same? If you'll create new crypto-currency will you setup your own forum or just come to the popular one? Calculating it brings more bugs, why not just set it in the web.xml?
Solvable technical problem. Hire good programmers to do that. Why forbid you? Please do that, 'unlimited' should be there by default. But if someone wants to restrict, it's a nice paremeter to have, along side with the max number of connected peers and other settings. |
|
|
|
And lets combine one user his split-capital due to weighted VPS-Nodes to forge...
-Hammer-Feature-
We need to introduce measure that prevent everybody to forge @ one VPS because as the result will have this only one VPS. There will be no reason to own nxt node Agreed. Need to have a parameter in web.xml to configure how many user accounts are allowed to forge on a node. Let the owner of the node decide that number in the config file. ahh, now I see.... The owner of the node can already block everyone from forging on his node with the AllowedUserHosts parameter, but why not make it a little more configurable, if it's not too much coding work. And display a 'No vacancies' message when people try to unlock their account if the node is full. Default parameter can be 'unlimited' of course. This is beneficial for decentralization. |
|
|
|
Then he will paste 100000000000 and we will have "only one VPS". It should be calculated based on uptime, connected peers, technical characteristics, etc
Why would he do that? And why would everyone go to just one node? Calculating it brings more bugs, why not just set it in the web.xml? |
|
|
|
And lets combine one user his split-capital due to weighted VPS-Nodes to forge...
-Hammer-Feature-
We need to introduce measure that prevent everybody to forge @ one VPS because as the result will have this only one VPS. There will be no reason to own nxt node Agreed. Need to have a parameter in web.xml to configure how many user accounts are allowed to forge on a node. Let the owner of the node decide that number in the config file. |
|
|
|
So much hot air is wasted here, could as well use it for heating houses in New York or something |
|
|
|
Annnd it's gone...
cheer up, sweetie, things always get more rosy in spring thank you for the Mexico sunshine and warmth. |
|
|
|
Please everyone stay away from NXT.
you have 70% or more of the coins owned by a few individuals, meaning 700 million of the billion coins. They will dump at any price increase.
Please Edward50 then stay away from Bitcoin, Litecoin, Peercoin etc. They have a similar situation. I would suggest staying away from any form of money, because:  |
|
|
|
Number of zombie nodes became much smaller. Is it only me or others see the same picture?
Zombies are probably working on a new deadly plan |
|
|
|
And that's way changings in basics of Nxt shouldn't be globally voted by coins.
There is no other way. Another way: Voting power by some logarithm of fraction owned of all coins, weighted by account age. The latter discourages endless scattering of NXT to circumvent the logarithm (which would be a real problem in a naked log system). As if there is not enough bugs to fix already... now NXT needs more bugs with complicated algos to calculate votes, min fees, etc. I'd say, until major bugs are fixed, like those that allow to take down the network, everything else should be as simple as possible, no complex algos. |
|
|
|
|
Show Posts
