Show Posts - McFly singapore
Please login or register.

Login with username, password and session length
Advanced search  


Latest Stable Nxt Client: Nxt 1.12.2

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.

Topics - McFly

Pages: [1]
API discussion / How to handle "public key announcement" correctly?
« on: January 22, 2015, 10:25:03 am »

i would like to request a comment on the subject  - How to handle "public key announcement" correctly?

I'm not new to NXT in general, but now slowly think about coding a bit which rises some questions. I would like to understand the handling around the public key announcement a bit better. I know why it is important to announce the public key to the network. Beside i think that this is an entry barrier for new users (but i don't want to start another discussion about this again) i would like to implement it as hassle free as possible for new accounts.

I have seen many web pages with just displaying a phrase like "if you have a new account enter your public key here" which will give the users 3 possibilities that i would like to handle from a coding point of view:

1. The easy one: a new user enters address and public key, tx goes trough, everybody happy! No question.

2. User does not enter the public key for a new account into the textbox. What will happen? Can the tx still go trough (as in the older days) with the account beeing less secured? Or is this tx not accepted by the network anymore?
I would do an API "getAccountPublicKey" query and only ask the user for a pubkey if not announced yet, is this the corrent procedure?

3. The user wants to be double sure and always enters the address & pubkey combination into the textbox, even if the pubkey has been anounced already. What will happen? Could it be just announced twice if the pubkey is the same? I think i would be better to query before annoucing it twice, right?

It seems as if it doesn't matter for the API if "RS-Addresses" or "old style account ID's" are used because of the flexible Account ID's support in the API. Are there plans to discontinue the "old style" support in the future?

I would like to follow a design guide to be future ready and within the standards. Hopefully you can help me a bit, especially for points 2. and 3.


General / Flexible TX fees possible?
« on: January 19, 2015, 09:47:15 am »
Hey, I'm new to this forum, so first of all "Hello!" to everybody.

Has the discussion about lowering tx fees ever been finished?

Could it be an option to give the forgers the possibility to define fees on a flexible basis?

The FlexFee idea:
1. Define a minimum base fee as spam protection (Lets assume 0.1NXT for "normal" tx types like Messaging, finance tx, AE bid/sell etc. The minimum base value may in future be queried by a vote.)
2. Make the fee configurable in the NRS for forgers(lowest limit would be the minimum base fee, default would be 1 NXT for now)
3. Every forger (therefore every Stakeholder) can decide about fees by configuring the client. Some may include transactions with 0.1NXT fees into a block, some with 0.5NXT, some will stay with the default of 1NXT, some may only incluede a tx if the fee is beyond 1NXT...)
4. Let the users choose the fee of a sending tx, the message would be: If you want it fast include the default fee, if you have time you can try to send the tx with a lower fee which will then take longer to be accepted and included into a block.
Maybe in the final state it would be possible to query the nodes on the network to give the user a fee recommendation.

Was the approach above ever discussed before, and would it work? I think it should not be too difficult to be realized and NXT could be used more if someone does not need to spend about 2 Cents for a simple Message.

Would be fun to get a comment on this.

Pages: [1]