NXT :: descendant of Bitcoin - Updated Information

[CIYAM]

Well, there is more to consider. Humans and machines need to uniquely identify an asset.
For machines, a cryptic number is okay. They simply do not care.
For humans, that numbers are not. They need readable and catchy names.

+ 1440 !!  I wonder, why it isn't obvious for all...

There *will be a readable* name - the choice is one of two:

Microsoft (a fake but readable name)

or

Microsoft:12334
Microsoft:12345

Uh oh? What it this - seems I need to find out more.

Which method is "helping" the end user to get *scammed* and which is not?

[mthcl]

Another thing that springs to mind wrt randomness would be looking at "the past" (so say the payload hash of the block at height x - 1440).

Other things to "add entropy" might be the account's public key and their balance at whatever point in time and one could even require "hash iterations" or the like so that "trying to calculate" ticket values for all possible accounts in order to try and game might be more costly that the time it takes to forge a block.

But, "the past" is known to the attacker at the current time, so why does this add randomness?

[CIYAM]

But, "the past" is known to the attacker at the current time, so why does this add randomness?

True not adding randomness - but if they have to check "all tickets" then provided the information is *different per ticket* then it will take "more effort" to do this checking.

If you add in hash rounds the amount of time required to do all the checking might just end up being *not worth the effort* (as you do need to forge within 1 minute).

[eXme]

someone else having problems with their account like, i installed latest version entered my key and i have 0 coins but on blockchain i have my coins.. ??

8182846507686630691 0.00 on my PC

my wallet on blockchain http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=8182846507686630691

[pandaisftw]

The whole broken idea of DNS names was something from the 1980's.

It is now getting closer to 2020 and we *need to do things differently* and in a *decentralised manner* rather than just "it was good enough back then".

The aliases is basically .bit and look how well that went.

If a user gets *confused* by duplicate names *then that is good* as they are unlikely to just "click one at random" and "buy shares".

Unique suffixes is as close to decentralized identification as you get (beside account #'s, but that's not easily readable)... all other methods require some sort of trust from outside of NXT.

Last part applies to suffixes as well.

[CIYAM]

Unique suffixes is as close to decentralized identification as you get (beside account #'s, but that's not easily readable)... all other methods require some sort of trust from outside of NXT.

Unique suffixes give us:

Software:Microsoft (scam)

I am the one *trying to prevent this*. Why are you *against that*?

If Joe sees "two confusingly same named Assets" he *does not waste his money*.

In your system - he can easily get tricked.

In either system some sort of "proper check" needs to occur - but my approach can make it "obvious" there is a problem whereas your approach *hides that*.

Being *easily readable* BUT A SCAM is just what a scammer wants!

[GCInc.]

Offspring standalone crypto client v0.3.4e has been released

Main updates: Clickable blockchain explorer and Asset Exchange with current testnet features enabled.

http://offspring.dgex.com/

[mthcl]

But, "the past" is known to the attacker at the current time, so why does this add randomness?

Yes - but if they have to check "all tickets" then provided the information is *different per ticket* then it will take "more effort" to do this checking.

If you add in hash rounds the amount of time required to do all the checking might just end up being *not worth the effort*.

So, this depends on the assumptions about the processing power the attacker has? Then one never knows...

[CIYAM]

So, this depends on the assumptions about the processing power the attacker has? Then one never knows...

True - the question is whether or not we can do any better than just using the block sig. for x + 1440 (current thinking).

[BrianNowhere]

I already have (client side) contacts in my web client. Check it out. An asset will show up as issued by "Bob" if you have set that person up as a contact.

Ok I went into the assett exchange and clicked on "assett issuer" which gave me the issuers public address. I then went in a created a new contact with that address and named it "BOOB SELLER".

What I think might solve a lot of the problems you are referring to is if now when I went back into the Asset Exchange and looked at BOOBS
that any assets being issues by "BOOB SELLER" would be readily apparent in that window. I'd know "BOOB SELLER" was a trusted vendor of boobs and would choose his assets. Would also be nice to be able to filter the BOOBS sell order so only "BOOB SELLER" showed up there so I know that if I buy BOOBS I am only buying them from that seller..

Well there is right click , add to group functionality in the sidebar.

Yes, but this appears to add BOOBS to a group, but doesn't seem to be tied to one particular issuer of boobs?

I guess what I am saying it that the ASSET ISSUER (array?) is tied to the issuers unique Nxt address which seems like it would provide a way to tell who you are buying the asset from and thereby the non-unique asset names can be identifiable as being issued by a unique entity by the unique Nxt address it's coming from.

If "Bob's BTC" owns 9234904623235235235 Nxt address, then any BTC asset issued by them would be identifiable by seeing it's issued by
the address 9234904623235235235, which the user could then permanently identify by connecting 9234904623235235235 to the contact name "BOB's BTC"

Once the user has done this, anytime they look at ASSET ISSUER it will say "Bob's BTC" there instead of a hard to remember address.
From there the user should be able to only buy BTC from the issuers they choose.

[mthcl]

@CIYAM, @CfB, @ChuckOne, ..., - can you comment on this randomization procedure I proposed on the previous page?

First X accounts (w.r.t. the inverse weights) choose some "random" numbers locally, and publish their hashes. X is supposed to be large enough so that the bad guy would never control exactly all of them. Then, they publish numbers themselves; if the published number does not correspond to the hash or is not published at all, then the corresponding account is heavily penalized. If that happens for at least one account, the whole procedure is invalidated (and we wait for the next try).

[CIYAM]

Once the user has done this, anytime they look at ASSET ISSUER it will say "MICROSOFT" there instead of a hard to remember address.

Of course that is how you'd expect a UI should work.

[Jerical13]

Service providers will rate all assets traded, if someone uses ciyam.ciyam and it is verified that this is in fact not you, and he sues this asset without good reason other than to scam, the service provider can in fact "blacklist" the asset (and the alias), solving the issue.

This isn't in existence (such service providers) and "blacklists" are *never a good way to go*.

Please stop trying to push for this "unique name" and let other methods be developed as we progress.

Note that if every 2nd generation platform does the same thing (allow unique names) then you'll never be able to trust "the same name" on any 2 platforms (so all such *brands* have become *useless*).

Just because there are no current providers for these types of services doesn't make it a reason to exclude the potential for there existence. It is error to assume that  private business and enterprise is "never a good way to go", and this option should not be excluded whether asset names are unique or non-unique. The market should decide for itself what is or isn't a good direction.

[CIYAM]

First X accounts (w.r.t. the inverse weights) choose some "random" numbers locally, and publish their hashes. X is supposed to be large enough so that the bad guy would never control exactly all of them. Then, they publish numbers themselves; if the published number does not correspond to the hash or is not published at all, then the corresponding account is heavily penalized. If that happens for at least one account, the whole procedure is invalidated (and we wait for the next try).

Sorry - I hadn't noticed that post - looks like something that we should think about.

[CIYAM]

The market should decide for itself what is or isn't a good direction.

How do you propose that decision should be made?

Auction it?

Vote on it?

We've pretty much already come to the conclusion that "you can't change this" once you've launched it (in which case the "market decision" might be a Nxt "clone").

[abctc]

Twitter kind of had the same problem with usernames, and everything is fine.Even some big companies had to add a number or letter to their brand name,because it was already taken, or buy it for not a lot of money,as it isnt such a big problem.Then the name that appears on your profile can be repeated,and people is used to going to the official website or googling to verify which account is the official one of who they want to follow. They follow it,and never see fake ones again.

- agree!  Keep it simple ...  JL, please return the unique names.

[Sebastien256]

Well, there is more to consider. Humans and machines need to uniquely identify an asset.
For machines, a cryptic number is okay. They simply do not care.
For humans, that numbers are not. They need readable and catchy names.

+ 1440 !!  I wonder, why it isn't obvious for all...

There *will be a readable* name - the choice is one of two:

Microsoft (a fake but readable name)

or

Microsoft:12334
Microsoft:12345

Uh oh? What it this - seems I need to find out more.

Which method is "helping" the end user to get *scammed* and which is not?

Finally, the idea of unique alias tied to asset name is a bad idea. It clear that this solution is problematic, this problematic is the same as the unique asset name.
The only method that will be working is to allow free registration  of non-unique asset full name (prefix+suffix). The user should not be taken as dumb. Let the user find out what is the good asset. At first it will be difficult to find the good one, but eventually, when we can sort the asset by volume, it will be easy to find which asset are good and the one that are not good. Volume is like massive positive Vote.

Anyway, if wesley want to do his client like this. It is his choice in some sense. If this solution is not working well, another client will find another solution or he will adapt his client. As long as in the Nxt core, asset name are non-unique, Nxt is strong I think.

[CIYAM]

Keep it simple ...  JL, please return the unique names.

Keep it simple for *scammers* is what you are actually saying - I think JL changed it because of this exact point.

An Asset is not a Twitter account - people are likely to end up buying fake shares (rather than reading a wrong tweet) - will you be refunding anyone who gets scammed?

[Come-from-Beyond]

@CIYAM, @CfB, @ChuckOne, ..., - can you comment on this randomization procedure I proposed on the previous page?

First X accounts (w.r.t. the inverse weights) choose some "random" numbers locally, and publish their hashes. X is supposed to be large enough so that the bad guy would never control exactly all of them. Then, they publish numbers themselves; if the published number does not correspond to the hash or is not published at all, then the corresponding account is heavily penalized. If that happens for at least one account, the whole procedure is invalidated (and we wait for the next try).

Won't work if the penalty < reward.

[Damelon]

Twitter kind of had the same problem with usernames, and everything is fine.Even some big companies had to add a number or letter to their brand name,because it was already taken, or buy it for not a lot of money,as it isnt such a big problem.Then the name that appears on your profile can be repeated,and people is used to going to the official website or googling to verify which account is the official one of who they want to follow. They follow it,and never see fake ones again.

This is a use case that basically clinches it for me.
Thanks for being a beacon of common sense.