Topic: NXT :: descendant of Bitcoin - Updated Information - page 1755. (Read 2761645 times)

My client is crashing every time I send a transaction. The money gets sent (and confirmed later on), but the client crashes before I get the "The money is sent" message.

This is absolutely terrifying.


Yet this terrifies me even more, that people are not free to say what they really want to say, because they are bound by laws that are not decided by them! And also by other things not decided by them, like religion, social ostracism, bad education and bad parenting.



Trying my darnest May your days be awesome too.

I suggest creating an UPDATE button in the basic interface,
and relating this button to http://localhost:7874/update.html

I do this on the nxtcrypto forum post when I update it for new clients.  Ill get the info guy to do the same


But I dont think itll work out perfectly.  Most of the time, linking back to a post here just gets you to the top of the page the post is on.  Know how to fix that?

@Luc @CfB @info.nxtcrypto

I suggest @info.nxtcrypto link @Luc's BTT post for each client update, so we can do a fast simple comparison with @Luc's post and confirm the sha256sum. If hacker replaced the download file and also replace sha256sum at info.nxtcrypto, it's not so easy to find it, but I think hack those 2 and Luc's account at the same time is more difficult.

Thanks.

Could be through a 3rd-party web of trust type plugin, or blacklists maintained by 3rd parties. Most important I think is that the user retain the choice of how they want to filter malicious aliases (if at all). So ultimately users, and user demand decides.



The solution to that does not have to be through CRC, or other checksums. For instance, to prevent miscommunication for short spoken strings, militaries pad out letters and digits. For instance, they may say NINER instead of NINE. If the problem is the number of digits, e.g. if folks worry about sending 800000 instead of 80000, commas can be used. Easier to spot the difference between 800,000 and 80,000. Different solutions for different problems.

I personally worry about these sort of inputs and double and triple check. As a newcomer to crypto$, all this worrying and checking stressed me out the night I made the trade offer in this thread. So it is a problem for me; I would much rather feel safer with more safeguards built into the protocol/client. For the amount to send, having to type it in two separate fields and disallow pasting in one of them (like email address confirmations) could be a way of solving the problem, and relieving user anxiety.

But I worried about the accuracy of addresses much, much more. NXT addresses are not easily eyeballed like transaction amounts or aliases.

A while back, when I asked CfB about using some of the 192 reserved address bits for check bits, he replied "We can't", which I took to mean it was impossible (without messing up a lot of things). I have much less coding experience and knowledge than most folks here, so on things like the current protocol I trust and defer to others. Now I'm reading stuff that suggests it might be possible. But whether client or protocol side, something MUST be done about this.

One of NxtChg.com's concerns is that if checksums are not implemented at the protocol level, it will not gain widespread adoption. I'm not so sure about this; seems like if no better solutions emerge, this could be adopted as a best practice when designing clients. I'm sure client designers also worry about address accuracy and don't want donations to get sent to the wrong places And after a while, maybe standard libraries/code fragments would get reused, so clients (and consequently users) would converge to standard ways of guarding against errors. He's got some server-side concerns too, which I don't have the experience to say anything about.

Breaking up NXT addresses into groups of digits (like credit cards) might help a little.

The problems we have been seeing were mostly due to one specific type of attack combined with a ddos. These attacks seem to have stopped now that they don't have the "desired" effect anymore.
The parameters are fine as they are, no need to adjust them. As are the peers, as soon as you see one peer, it will send you all it's other peers and you're good to go

What web.xml options add most to stability of NXT server? The stability problems could simply be from suboptimal web.xml settings.

Does the 0.5.3 install use the most stable options in web.xml?
Are there any other files that need to be tweaked?

I am thinking that a lot of the problems in the field could be related to having a wrong set of settings. We are so close to a stable NXT server. I updated my peers list and now it is not going brain dead. Still need more time, but looking good so far.

The only thing that was changed was the list of peers, but I remember seeing a bunch of different tweaks. Has anybody tested the effect of the different tweaks on NXT server stability. So much work has been put into NXT, it would be a shame if a new NXT'er gets a bad experience due to suboptimal settings.

James

kickass, well  guess ill have to figure out another little project...  but after apt-get install of ruby1.9.1 and those 4 gems when running your nxt help I get

root@vps1:~/tmp# nxt help
/usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- httparty (LoadError)
        from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require'
        from /usr/local/bin/nxt:6:in `

'
root@vps1:~/tmp#

thanks,

got: 12345678612257264594

ricot,

Plz don't worry about me. Your time much better spent coming up with more evil twisted ways to break NXT. I am super impressed so far by your work!

Just wish I was fluent in java instead of C.  I knew that at a high level, getting untrustworthy data to get trusted was the key, but having to lookup every java call, just made me unable to see the forest through all the trees.

James

Ah, ok, found a thread about it in some russian forum
Yes, it's basically just displaying a browser window in a different frame, so unless you refresh that browser window, it won't show correct results...
you can try apple+r, maybe that works, depends on how he implemented it.

Wont give you diffs though!

My understanding is that MacNXT embeds the official client, it says it is using 0.5.3

All caught up:
36420      14571285356259793594      January 9, 2014 3:16:56 AM GMT+02:00   
5      500'000 + 13      691 B   
2      15607836971861154475      188 %

The problem seems to happen after a few hours. I did "update peers" before this redownload of blockchain, so I am hoping for better stability.

James

P.S. I did not change anything from default installation other than Update peers

What's that? Why aren't you using the official client?

Well, if it's based on the official client before 0.5.3 (very likely), then you still have that bug...
Solution: Get the official client

Here's mine in ruby: nxt

To use (assuming you have ruby installed):

Let me know what other API calls you want and I can knock them out quick.

UPDATE: added getAliasURI and listAccountAliases.

I am using wesleyh's MaxNXT so not sure how to refresh browser in this context. I click lock and login again, but all the same orphans are there.

I can redownload the entire block chain, that is one option and it fixes it for a few hours, then goes bad again. At least it did the first time. I will do it again and see what happens

James

See if refreshing your browser window helps...

Is there a vanity generator for NXT addresses out there?

This guy got a nice one: 666666817378784428

why did you go to this desert? were you curious and wanted to get to know some iraqis or their favorite dish?
if not so, were you alone and depressed and eager to find friends(or partners) in the army?
are you maybe from alaska and did you want to see the sun?

tell me, I am all ears!
I charge 100 NXT for that.

PS. I am from Germany and find it incredible, that their are soldiers, financed from my taxes who drive up the prices for appartments in Kabul, so that Afghanis can't affort them anymore. I find it incredible, that these soldiers, who are freely going to this nonsense in Afghanistan, come back and need psychological help, because they saw a kid die. Fewer kids would die, if they weren't going there.
At least they should pay for this psychological help themselfes.