elective-stereophonic
elective-stereophonic
Public key for fresh accounts - this is a wrong decision.
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Stable Nxt Client: Nxt 1.12.2

Pages: 1 ... 15 16 [17]  All

Author Topic: Public key for fresh accounts - this is a wrong decision.  (Read 30116 times)

rudeboi

  • Hero Member
  • *****
  • Karma: +55/-4
  • Offline Offline
  • Posts: 633
  • Nxt Organization Member
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #320 on: October 05, 2014, 12:58:47 am »

Easier new account set up (public key) - NO CHANGE TO CORE

New addresses are stated as
NXT-XXXX-XXXX-XXXX-XXXXX:p:jhbcww1ioucnsigxc568gtfrew7zoospsks

:p: is the separator that signifies a public key is attached

When copied and pasted into default Nxt client, the wallet just copies everything after :p: and populates the public key field. Only before the :p: gets submitted as the address to the core API.

Exactly the same needs to happen on any exchange, when copied into the browser the site splits the information to the correct inputs for the API.

I believe this is much easier for new users, Wesley has already made the UI process pretty slick by checking if the account has a public key, so the above should compliment and improve his method.

The other thing that would have to be done is to openly publish the standard of how NXT address separator attachments should be mapped when submitted to the API, this can then be shared with the main exchanges and 3rd party sites.

The main benefit is that this doesn't require changes to the core.

Bonus idea for merchants:

They don't need to create new address for each transaction, but instead just state the receiving address as:
NXT-XXXX-XXXX-XXXX-XXXXX:m:0001764

:m: is the separator that signifies a message (AM) is attached, this could be used by the merchant as order number or customer number. Exact same principle as above.
Logged
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬  ▄▀▀▀▀▀▀▀▀▄  ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬●  nimirum  ●▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▬▬▬ ◖ENDING CENSORSHIP ONLINE◗  ◖ ICO OPEN NOW◗ ▬▬▬

Brangdon

  • Hero Member
  • *****
  • Karma: +229/-25
  • Offline Offline
  • Posts: 1389
  • Quality is addictive.
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #321 on: October 05, 2014, 11:28:46 am »

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.

Bitcoin uses base58 encoding, with a 32-bit checksum included. A Bitcoin address looks like 15vvFaPYBCXBcU4MFYWKtRBbqVQCZ9cbJP. That's less than twice as long as a Nxt account, but it includes 160 bits rather than 64, is easier to copy and paste, and the extra length isn't an issue in practice because they are rarely typed in. If we used 128-bit account numbers with base58, our numbers would be about 5 characters shorter than Bitcoins.
Logged

Zahlen

  • Full Member
  • ***
  • Karma: +26/-4
  • Offline Offline
  • Posts: 228
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #322 on: October 05, 2014, 03:49:54 pm »

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.
[/quote]

I hadn't thought about the double-click issue. (Ctrl-A comes too naturally to me.) Could this be solved client-side? In the same vein as how when you paste NXT-RTYD-LJXQ-EPNJ-H7AQ5 it'll automatically ignore the NXT and dashes?

Quote
Bitcoin uses base58 encoding, with a 32-bit checksum included. A Bitcoin address looks like 15vvFaPYBCXBcU4MFYWKtRBbqVQCZ9cbJP. That's less than twice as long as a Nxt account, but it includes 160 bits rather than 64, is easier to copy and paste, and the extra length isn't an issue in practice because they are rarely typed in. If we used 128-bit account numbers with base58, our numbers would be about 5 characters shorter than Bitcoins.

Actually, one of the reasons we went with a 32-character alphabet without lowercase was to make the addresses easier to dictate, e.g. over a phone. The dashes were to break up the address into manageable "chunks". I was part of that discussion (which is lost in the now defunct nxtcrypto forum), and the first one to suggest a 32 char alphabet. If we went with both upper and lower cases, to avoid ambiguity you'd need to specify which case, which doubles the time taken to recite. Personally I felt it would handy to be able to recite and type out an address, like you could do for phone numbers or credit card numbers. (I was thinking about brick and mortar shops, not just online and on your comp where you can copy and paste.)

We also needed the alphabet size to be a prime power, so that it can be mapped to a field, which makes it much easier to then encode into an error-correcting scheme like Reed-Solomon. Ricot's original proposal was for 64 chars, we could have added extra chars like # in addition to the alphanumerics to reach that.

In the end, we felt that the current 32-char set (with 0, O, 1, I removed to hopefully reduce confusion) was the best balance of all these factors.
« Last Edit: October 05, 2014, 03:53:34 pm by Zahlen »
Logged

Brangdon

  • Hero Member
  • *****
  • Karma: +229/-25
  • Offline Offline
  • Posts: 1389
  • Quality is addictive.
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #323 on: October 05, 2014, 04:58:06 pm »

I hadn't thought about the double-click issue. (Ctrl-A comes too naturally to me.) Could this be solved client-side? In the same vein as how when you paste NXT-RTYD-LJXQ-EPNJ-H7AQ5 it'll automatically ignore the NXT and dashes?
Your mention of Ctrl-A suggests you are thinking of account numbers presented in forms. They also appear in other places. For example, your account number is in your signature. If I wanted to tip you, I'd have to copy from there, and Ctrl-A won't help. They may also appear in emails, text messages, and tweets, to name a few. It's not practical to make double-click work on them everywhere.

Quote
Actually, one of the reasons we went with a 32-character alphabet without lowercase was to make the addresses easier to dictate, e.g. over a phone.
Well, OK, but I think it optimised the wrong use-case. I've never actually read out either a Bitcoin address or a Nxt account over the phone. I have copy and pasted them many times. Still, it's not a big deal to drag-select, and RS was a big improvement over the unchecked numeric format.

I think we will have to switch to 128 bit accounts eventually, and then I think base 32, with dashes, will be too verbose. Hopefully brick and mortar shops will be able to use NFC, or QR codes, or some such. From what I've read, BCNext always knew 64 bits wouldn't be enough.

Quote
We also needed the alphabet size to be a prime power, so that it can be mapped to a field, which makes it much easier to then encode into an error-correcting scheme like Reed-Solomon.
Bitcoin just appends 32 bits of the hash of the data to the data, which doesn't need any particular alphabet size. I believe that gives good error detection without giving good error correction. I don't think error correction is important here?
Logged

Zahlen

  • Full Member
  • ***
  • Karma: +26/-4
  • Offline Offline
  • Posts: 228
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #324 on: October 05, 2014, 07:06:57 pm »

I hadn't thought about the double-click issue. (Ctrl-A comes too naturally to me.) Could this be solved client-side? In the same vein as how when you paste NXT-RTYD-LJXQ-EPNJ-H7AQ5 it'll automatically ignore the NXT and dashes?
Your mention of Ctrl-A suggests you are thinking of account numbers presented in forms. They also appear in other places. For example, your account number is in your signature. If I wanted to tip you, I'd have to copy from there, and Ctrl-A won't help. They may also appear in emails, text messages, and tweets, to name a few. It's not practical to make double-click work on them everywhere.

Yeah that's true. Back then we also discussed that the NXT and -s were just "sugar". Only the alphanumeric chars are important. It was up to clients, websites, users etc how they want to present them, and it's a trivial task to convert variants to an unambiguous address. Right now the NXT-...- addys are the "default" presentation that we started with and "popularized". If folks feel they prefer not to have -s, they can still present addys that way.

Quote
Quote
Actually, one of the reasons we went with a 32-character alphabet without lowercase was to make the addresses easier to dictate, e.g. over a phone.
Well, OK, but I think it optimised the wrong use-case. I've never actually read out either a Bitcoin address or a Nxt account over the phone. I have copy and pasted them many times. Still, it's not a big deal to drag-select, and RS was a big improvement over the unchecked numeric format.

I've never had to read out a bitcoin addy before either (thank goodness! :D) I was hoping that one day, Nxt addys would be mainstream enough that there would be people who would find it useful to dictate/write out addys to others (like phone numbers, bank account numbers) As you say, it might've been optimizing for something that's too far in a very ideal future.

Quote
I think we will have to switch to 128 bit accounts eventually, and then I think base 32, with dashes, will be too verbose. Hopefully brick and mortar shops will be able to use NFC, or QR codes, or some such.

The good thing is that the current RS addy format doesn't have to be set in stone, so long as backward compatibility can be maintained. QR codes were talked about as well, though I don't remember if that discussion led to any implementation. This would definitely be an improvement for many use cases.


Quote
Bitcoin just appends 32 bits of the hash of the data to the data, which doesn't need any particular alphabet size. I believe that gives good error detection without giving good error correction. I don't think error correction is important here?

Yeah that gives good "probabilistic" error detection, in that there's only a 1/(2^32) chance of a mistake still being a valid address. But it doesn't lead to a computationally feasible* way of suggesting an address that you might have mistyped. Error correction isn't absolutely necessary, since once you know there's a mistake you can check again and fix it yourself. Personally I liked that the option to suggest the nearest valid address was available. A client could still choose not to use the offered error correction (the suggestion isn't guaranteed to be the right address; maybe the user made 3 typoes, that's beyond what the current RS encoding can is guaranteed to correct, and the suggestion will may be the wrong addy. And maybe users click "Accept Suggestion" like how I accept EULAs :D), and stick with just error detection.

Even without error correction, a smarter error detection scheme means fewer "check bits" are needed, and hence a shorter code. The hash approach relies on the probability of getting a valid address at random being small; you need more bits to make "unlucky" errors very unlikely. Error detection guarantees that if you have errors, but not more than n in total, you definitely will end up with an invalid address. (In our case, n is 4 for typoes, and I think 2 for character omissions). It's a lot more likely that you make a few typoes compared to a bunch of random mistakes. That's why, even though our RS addys have only 17 x 5 - 64 = 21 "check bits" compared to bitcoins 32, I think it's effectively as safe.


*now that I think more about it, 1 char error correction is still computationally feasible: just run through all 57 * address length 1-char variants and suggest the ones that are valid. But there's still a small chance of having 2 or more valid variants. RS, or some other error correction scheme guarantees at most 1 valid address within the error correcting range, as well as an easy way to find that valid address even if it's further than 1 mistake away (in our case, we can correct 2 typos)


Quote
From what I've read, BCNext always knew 64 bits wouldn't be enough.

Much wiser than Bill :D CfB kept alluding to additional bits being reserved for some purpose, but he never went into details.

« Last Edit: October 05, 2014, 07:32:15 pm by Zahlen »
Logged

Squeaker

  • Jr. Member
  • **
  • Karma: +1/-0
  • Offline Offline
  • Posts: 30
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #325 on: October 05, 2014, 07:22:11 pm »

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=
Logged

Zahlen

  • Full Member
  • ***
  • Karma: +26/-4
  • Offline Offline
  • Posts: 228
    • View Profile
Re: Public key for fresh accounts - this is a wrong decision.
« Reply #326 on: October 05, 2014, 11:32:53 pm »

QR codes for Nxt addresses are implemented, I just saw this: https://nxtforum.org/mynxt-info/mynxt-info-mobile-apps-%28android-iphone-maybe-windows-phone%29/msg112822/#msg112822  Not sure if it's a standardized implementation, or just one specific to Abuelau's client.
Logged
Pages: 1 ... 15 16 [17]  All
 

elective-stereophonic
elective-stereophonic
assembly
assembly