elective-stereophonic
elective-stereophonic
Show Posts - Squeaker singapore
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Nxt Client: Nxt 1.11.15

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Squeaker

Pages: [1] 2
1
Official Nxt Releases / Re: NRS v1.5.14
« on: July 28, 2015, 10:31:13 am »

which brings up another question... is it possible to make changes to an asset after creation? lets say NXT value has gone way up, and we have assets pricing in whole numbers... are they able to change the price decimals from 0 to 4 later, or are decimals (both share and price) fixed permanently?


It's permanent, hence the problem. Some issuers have had to reissue a new asset and try to do a share swap to get around this, which is an ugly solution.
Even a limited change would be a big help... like just changing decimal settings.

This would allow for a 10:1 split (so say, allowing trading to change from min 1 share to min 0.1 share, at the expense of a decimal place in price) but I wouldn't suggest doing the reverse. It can be too messy for those who have an odd amount of shares...

Are issuers at least able to update the information? Like description? Say, if a domain name has to change, it can be changed in the asset's info?

=squeak=

2
Official Nxt Releases / Re: NRS v1.5.14
« on: July 28, 2015, 08:30:52 am »
perhaps make it clearer in the UI, that between both, you cannot have more than 8 places total... and that one is for share quantity, and the other share price? (with an: "eg: setting this to 2 would set the smallest {price|qty} to 0.01 {NXT|shares}")

don't really see why this would need more than a cosmetic UI change... I know when I was looking at an asset's info and it showed 2 decimals, I thought it meant quantity (so I could buy 0.01 share), when it was apparent in the order book, that it was actually for the price instead...

also, you could make it automatic during asset creation... say, by default, a new asset would be set to 0 (non-fractional shares), and price set to 8, and if they change it to 2, then price also changes to 6. I can't think of a reason why any asset would need to restrict the price possibilities any further than that... (say, shares set to 0, and price set to 0)

which brings up another question... is it possible to make changes to an asset after creation? lets say NXT value has gone way up, and we have assets pricing in whole numbers... are they able to change the price decimals from 0 to 4 later, or are decimals (both share and price) fixed permanently? (and if permanently, any plans to change this in the future?)

=squeak=

3
Official Nxt Releases / Re: NRS v1.5.14
« on: July 25, 2015, 06:01:33 am »
I should have mentioned yesterday, that it appears to have cleared up after a few hours of running, so no problems now...

=squeak=

4
Official Nxt Releases / Re: NRS v1.5.14
« on: July 24, 2015, 04:33:45 am »
is anyone else seeing an unusual amount of 'block from the future' messages with this version?

I've verified my clock is current with the time server... is this version less tolerant than the *.13 version?

=squeak=

5
Official Nxt Releases / Re: NRS v1.5.13
« on: July 13, 2015, 05:29:59 pm »
The forging indicator is green if at least one account is forging. But on mouseover it should show how many accounts are forging, and whether the current account is forging or not.
Um, ok, this just doesn't seem proper to me, and is not the behavior I was accustomed to seeing before this latest update.

Perhaps using a different color to indicate _this_account_isn't_forging_but_others_on_this_node_are_?

Perhaps a dark yellow "not forging"? Otherwise, it is clearly displaying a misleading status for the particular account.

=squeak=



6
Official Nxt Releases / Re: NRS v1.5.13
« on: July 13, 2015, 03:01:33 pm »
Minor bug noticed...

I have 2 tabs open, each showing a different account.

Tab #1, is the account I forge on
Tab #2, is the account I trade assets with

After updating, I reloaded Tab #1, and set that account to forging again

Then I reloaded Tab #2, signed in, and the forging indicator on that account was also showing green.

I click on 'forging', and I get the expected prompt asking for my secret phrase to enable forging, even tho the indicator is showing I already am.

I switch back to Tab #1 (without enabling forging on #2), click on 'forging', and get the expected prompt to disable forging.

I go back and forth a couple more times to make sure... Tab #1, shows forging, prompt expected if I was forging... Tab #2, shows forging, prompt expected if I was _NOT_ forging... as they should be, for my typical usage.

So... looks like a cosmetic bug, where Tab #2's account is showing forging when it isn't, because the account in Tab #1 _is_ forging. Tab #2 isn't forging (or shouldn't be) but indicator showing that it is.

=squeak=

edit: just tested a little more... when both tabs/accounts are signed in first, and I start forging on #1, the indicator on #2 stays red 'not forging', as it should... this bug only seems to come up, when I start forging on #1, and then log in on #2's tab, after forging on #1 has started.

edit2: spoke too soon... once the page on #2 refreshed when I switched from Dashboard view to Assets view, the forging indicator went green too.


7
I think you refer to the non browser version of the client, or is the browser version no longer gonna be updated???
I already said non-browser version, and I also said it was Wesley's client that looks like it won't be updated... (I'm in no position to know that for certain, it is just how it appears to me)

It was Wesley's client I had been using up until now.
Quote
you do not need to keep your browser open constantly to forge... Just press logout instead of log out and stop forging.
You do need to keep the cmd window open where the server is started...
Yes, I already know this, and it isn't all about forging... but about me having to keep too many windows and tabs open in my browser already, the last thing I need is a program interface open in it too, competing within the limited resources of my browser against everything else...

Also, since whenever I sign back into my account, the forging indicator shows disabled. I have no reason to be confident that my account is still forging when my browser is closed, since forging stops whenever I refresh the page or reload my browser. (this is a separate, unrelated issue to my not wanting to have to use the browser as my interface however)
Quote
As alternative to windows, there is Mofo wallet to.
Thank you, I will hunt that down and take a peek.
Quote
Also a great offline option, not for forgen though, is vapor wallet.
Thanks, but offline usage isn't an issue... just want to be able to game on one monitor while keeping my assets visible on the other monitor, with a smaller footprint than I would get keeping the browser open.

=squeak=

8
Alternative Clients / fully functional non-browser client for Win?
« on: July 13, 2015, 11:36:12 am »
Since it doesn't appear Wesley's client will be updated anymore, I am in need of another fully-functional non-browser wallet client for windows (pre-compiled)...

I have absolutely no idea what else is available, and the functionality of what is...

Anyone have any recommendations for a replacement? (preferably a low-resource one?)

Keeping my browser open constantly is impractical for me...

=squeak=

9
Nxt General Discussion / Re: Problem after updating NXT wallet
« on: July 05, 2015, 07:11:09 am »
The OP's post was about Wesley's client too... so unless a reply is about Wesley's client, it isn't really on-topic here, since it doesn't address the issue.

=squeak=

10
Nxt General Discussion / Re: Problem after updating NXT wallet
« on: July 04, 2015, 02:26:42 pm »
Been there, done that, please read the message you're about to reply to next time...

=squeak=

11
Nxt General Discussion / Re: Problem after updating NXT wallet
« on: July 03, 2015, 02:05:48 pm »
I need help with this too... I think I'm using the last of Wesley's wallet (2.2.0), and with NXT 1.5.12, I never get any peers, and after a little while, a message saying NRS has exited, and then another message saying it is shutting down NRS... since NRS has already exited, it never gets to shut down NRS and I have to kill it in task manager (Win7)...

I won't use the browser version... ever... so would appreciate a solution to this...

=squeak=

ps: Oh, and Wesley... could you do something to your client to differentiate it from the NXT program of the same exact name? Perhaps having Wesley's NXT Client in the title bar instead of just NXT Wallet?

12
need someone to launch ICBMcoin to counter that...

=squeak=

13
This part makes absolutely no sense to me... what letters and symbols make it hard to copy|paste?
When you double-click on a word, most browsers and editors will select the word. Symbols such as '-' terminate the word, so an account number like NXT-RTYD-LJXQ-EPNJ-H7AQ5 is seen as multiple words and can't be selected with a single double-click. You have to click-and-drag. Some people see that as a major problem.
Ok, so that is a browser/editor issue, not a copy|paste issue... I have never, ever, selected text to copy|paste in that manner... I have always drag-highlighted what I wanted to copy|paste, and never had an issue.

=squeak=

14
... but it does not have to imply letters and other symbols that make it hard to copy&paste.
This part makes absolutely no sense to me... what letters and symbols make it hard to copy|paste?

=squeak=

15
Official Nxt Releases / Re: NRS v1.2.8
« on: September 06, 2014, 11:23:00 am »
If I remember the announcements right, 1.2.5 is supposed to follow the new fork, while versions before would not.

Admittedly, I have not been keeping current on the specifics of which versions come in at various stages of development, but when I set my client up, I believe that this is what I had read, and that I had to update very soon to 1.2.5 at least, by a block that was expected to be reached within a few days.

If I remember that correctly, this could explain why you are not staying connected to previous versions anymore, if the client is programmed to drop misbehaving peers... which I assume it is.

=squeak=

16
Official Nxt Releases / Re: NRS v1.2.8
« on: September 06, 2014, 04:28:22 am »
No reason to stay connected to forked nodes...

=squeak=

17

We shouldn't have to make the end user do extra things that can be handled in a streamlined fashion with code, under the hood.
This just seems to be a bigger debate/fight, than it needs to be.

Exactly. This isn't a difficult change for the core. It's pretty simple parsing the reference ID (which is same as "message") from account ID.
I was thinking more about 'reference' being separate from 'message'... with 'reference' serving a very specific purpose, and 'message' being more general, and could be anything.

That's just how I'd do it... :shrugs:

=squeak=

18
It seems that some are making it more difficult than it needs to be...

Take network addressing for example... (IPv4 in this one)

Say my computer is at 127.1.45.90... we're already accustomed to routing packets to 127.1.45.90:80 or 127.1.45.90:6333 or whatever other service is on whatever port... It is absolutely nothing to us to include the port with the IP address as just a part of the whole destination address. When we leave it off? The destination port is chosen by default, depending on what we're doing, as far as we can see, but everything is routed to a port.

Now, say my wallet is at NXT-S48J-AVQZ-WBER-5B7HB... so the coin will be routed to me at that address, but what is the coin is for? Use a reference number, same function as a port number would be... if you don't have a reference number, your coin gets routed to the default reference # (zero)

A vendor who has specified their address on the blockchain as requiring a reference/destination number, will need all funds sent to them to include a reference number. Anything except a 0 (zero).

The coin itself wouldn't be held separate from the rest of the coin at that address, effectively, all piece of coin would be at reference/destination zero... the blockchain itself wouldn't have to keep those separate... but when the client reports the received transactions, it will list the reference/destination code included in the transaction... and that destination address, can be saved in the client as NXT-S48J-AVQZ-WBER-5B7HB:4227 ... that 4227 could be the order number, or it could be my customer number. It may be better off for it to be customer number for some vendors, and order number for other vendors, depending on how they interact with their customers... but that doesn't matter to the client.

"NXT-S48J-AVQZ-WBER-5B7HB:4227" would be the full destination address you put into the destination field of your transaction. The client would parse it out itself... and you could save that fully-qualified destination address in your contact list, so the :4227 would always be attached in your contact list, if you wish.

To me, this would be the simplest way for the end user, and there shouldn't be any reason why you couldn't include it in a QR code. It doesn't even have to be the colon, could be an equals, or a tilde, something that parses well in URLs...

It would need to be included in the transaction in the blockchain, but functionally, it would be ignored as far as where the coin is credited to, since only the end-user would make use of the reference/destination #.

We do seem to have a habit of overthinking things, sometimes, when the KISS method works best for the user's usability.

We shouldn't have to make the end user do extra things that can be handled in a streamlined fashion with code, under the hood.

This just seems to be a bigger debate/fight, than it needs to be.

=squeak=

19
You  absolutely do not understand the problem. You can't rely on your users that they will remember to attach reference ID. '

Who will be paying for the support call for large percentage of people who keep forgetting to attach a message?
This is where I thought my idea of being able to designate your address as a vendor address, so the client _requires_ the user to include a reference number along with the address to send coin to.

Then, when some lazy sender tries to send coin to the address, without filling the "Reference:" field with a number, the send button stays greyed out until they do.

Won't stop them from sending to the wrong reference #, but it should take care of all of those "oh, damn, maybe I should have sent a message saying what the payment was for? oh well, too late now... they'll figure it out..." dweebs...

=squeak=

20
This doesn't work. You can't put public key on the blockchain if you don't have have Nxt in your account.
but perhaps it could be propagated for a period of time as the equivalent of an unconfirmed transaction, that won't go in the block chain, and just expire away.
Not a bad suggestion, but isn't there still a risk of spam/DOS attack?
It could be... I'll leave it to those familiar with the code and protocols to evaluate that risk, and how effective it could be.

Since it would be extremely unusual for that kind of a broadcast informational transaction to ever need to be sent more than once within a small amount of time (say, 1 minute) from a given IP address, peers could just drop new ones, and don't relay them to their other peers, if they already have one unexpired in their unconfirmed transactions list.

=squeak=

Pages: [1] 2
elective-stereophonic
elective-stereophonic
assembly
assembly