< 100 XEM balance - XYM allocation

General Discussion
#18

Trying to wrap a few questions into one post

Pre-Launch Opt In - reason for 100 XEM threshold

  • The nemesis/genesis block has a limited amount of space, allowing smaller accounts to opt in risks bloating the block to the point that bigger accounts may not be included in block 0 which has multiple potential knock on effects (harvesting, supernodes, namespaces, multi-sig configuration etc)

  • Setting a minimum threshold also makes it more expensive to initiate a spam disruption by placing a barrier on someone for example opting in 100,000 “dust” accounts with tiny balances

  • When 100 XEM was selected, it was expected to be necessary for namespaces owners to need to pay for 1 year’s fees (~20 XEM/XYM) so setting it above that made namespace opt in safer, this has since been removed by a minor enhancement allowing namespaces to be created for 0 rental fee in the nemesis/genesis block

Post-Launch Opt In - reason for 100 XEM threshold

  • Setting a minimum threshold helps avoid spam of the post launch opt in process and makes it easier to ignore spam attempts

  • The holding of each balance on-chain takes up an amount of resource in terms of storage, memory etc on nodes, it is preferable at a technical level to have only “real” accounts at the start of the chain to reduce chain bloat in the early days

Why was 100 XEM the number selected?
It was a combination of:

  • A number higher than 20 was required for namespaces, and 100 is a nice round, easy number (no longer relevant, see comment above, but was at the time of opt in opening)

  • To be significant enough to deter spamming, but low enough to not be exclusionary. When the number was selected the price was ~$0.05 so represented an account with approx $5 of XEM in it. Changing a number to 10 XEM for example would have been 50c. In terms of spam protection, issuing 10,000 spurious requests costs $50k or $5k with the two different options (100 vs 10) this was also factored in. There is no technical reason for saying 10, 50, 100 XEM from a spam protection perspective

  • The number of accounts with less than 100 XEM is significant in number but not volume held (~114k accounts according to the rich list last time I looked) which is 114k accounts that hold less than $10 of XEM at current prices and if each opts in contribute to the size of the chain. Of course if they are combined into larger accounts, or held on exchanges which are opting in, then they also become included.

6 Likes
#19

Thanks for the detailed answer Dave.

It raises some additional questions though :sweat_smile:

General questions:

  1. Who made this decision?
  2. To the decision maker: What if we lose a part of our community if we exclude them?
  3. To the decision maker: How many of the 114k accounts did you expect will optin?

Specific questions:

  1. Wouldnt we only have real accounts if they are opted in?
  2. Do you think that there is one large holder which controls a big part of the 114k accounts with <100 XEM? Asking because if someone wants to spam he has to have control over alot of accounts.

I think this only applies if there is indeed 1 or a few big holders which control a big part of the 114k accounts.

Again, this would only be possible if there is indeed 1 or a few holders which control the 114k accounts.

Just some assumptions… Lets say there is indeed 1 or a few holders which control 114k accounts, which waits to spam the symbol blockchain. What would stop them (besides from fees*) from sending everything to one account, optin, create 114k accounts on symbol and start spamming?

*(fees would be higher if the attacker opts in every single account vs opting in just one big account and create 100k new accounts on symbol to spam the chain)

My opinion on it: I think most of the 114k accounts are “lost” and not controlled by anyone anymore. I do think there will be few active ones. I dont want to lose them just because some theoretical problems which seem to be mostly made up on the “spam problem”.

However, I see the problem with genesis block (limited amount of space) and why they cant be included from start.

5 Likes
#20

Not including the smaller accounts in the genesis block is acceptable because of the block size limit.

I however do not follow the reasoning to block them post launch. Just make it posible that they opt in after x blocks post launch if it is technologically not posible to put them in genesis (say 10 days blocktime). If they really want to spam they will find a way around it or do it without.

Lost accounts will be lost even if there is no 100 xem limit because they need to send a transaction to claim.

5 Likes
#21

to my understanding there is nothing to stop us to allow below 100 XEM addresses at snapshot to claim their XYM balance after start of chain

technical it make sense limit the genesis included addresses
but after genesis we could use a more reasonable number example 1 XEM

as 1 XEM was aready above 1$ in the past anything that size cant be seen as dust

u dont leave a 1$ note on ground without pick it up

its not dust!

4 Likes
#22

Thanks for the detailed reply @spizzerb I will try and break up the chunks, let me know if I miss something.

Thanks for the detailed answer Dave.

It raises some additional questions though :sweat_smile:

General questions:

  1. Who made this decision?

There are two decisions - Pre and Post, I’m not sure which you mean so will answer both

  • PreLaunch, by a combination of the Dev Teams, Core Devs and NGL exec based on the size that is possible in the Genesis/Nemesis block, this one has been made
  • Post Launch, HAS NOT YET BEEN MADE and is being discussed in various places including this thread as per my comment above in this thread, copied below for ease of reference

the post launch opt in process will be confirmed in the next few weeks. The 100 XEM limit per the terms an conditions will apply to any account pre-launch, it may also apply to the post launch. I have forwarded this specific use case to the team to consider

  1. To the decision maker: What if we lose a part of our community if we exclude them?

This is a consideration and why we are watching these threads and conversations.

  1. To the decision maker: How many of the 114k accounts did you expect will optin?

This is impossible to know, and impossible to know if more will be created pre-snapshot and opt in (for example a spam scenario).

There is a natural follow on question - who should make this decision and how. My preference for example if 100XEM, Rene’s is around 10XEM I think) others are at 0 XEM. This decision isn’t mine or NGL’s to take and is the subject of a discussion. I have no issue for example having this conversaton run and then having a vote on it but what should be the question, what should be the answer options? (0, 10, 50, 100 etc they are all personal preferences).

My personal take is it should be somewhere above 0, it was set at 100xem for pre-launch due to numbers involved and space in the block based on estimates, that has been assumed as the start point post launch but is not decided/set in stone and we have some time to decide this (community not NGL)

I will add a seperate reply shortly for the specific questions to try and avoid a wall of text

Edited: to make formatting easier to read

5 Likes
#23

Specific questions:

The holding of each balance on-chain takes up an amount of resource in terms of storage, memory etc on nodes, it is preferable at a technical level to have only “real” accounts at the start of the chain to reduce chain bloat in the early days

Q: Wouldnt we only have real accounts if they are opted in?

Yes for those that are real opt ins. But it opens the door for malicious actors which has been seen before on the Votes module and Token spam for example, a specific example if we allowed 0.000001 XEM to opt in, the cost of the opt in Tx is 0, so it would be relatively simple and cheap to set up 10k of them and programmatically opt in.

Do you think that there is one large holder which controls a big part of the 114k accounts with <100 XEM? Asking because if someone wants to spam he has to have control over alot of accounts.
Setting a minimum threshold helps avoid spam of the post launch opt in process and makes it easier to ignore spam attempts

I think this only applies if there is indeed 1 or a few big holders which control a big part of the 114k accounts.

I have no idea or way to be certain but my gut tells me it is unlikely. The logic outlined I think holds for the existing 114k, but the number can number increase any time from now to snap shot if someone wanted to do so.

Setting a minimum threshold also makes it more expensive to initiate a spam disruption by placing a barrier on someone for example opting in 100,000 “dust” accounts with tiny balances

Again, this would only be possible if there is indeed 1 or a few holders which control the 114k accounts.

If you just create some new ones and register say 1m with 0.0001 XEM, now we have 1.1m account with less than 100XEM and 90% are controlled by a single person.

Just some assumptions… Lets say there is indeed 1 or a few holders which control 114k accounts, which waits to spam the symbol blockchain. What would stop them (besides from fees*) from sending everything to one account, optin, create 114k accounts on symbol and start spamming?

There is nothing to stop them opting in one large account and then splitting it up when they are on Symbol, they would be spamming the network. This approach doesn’t stop that, I haven’t said it would and it is a valid, albeit annoying, action on the Symbol mainnet (or NIS1 for that matter). There would be no spamming of the opt in process, but there would be spamming of the Symbol chain and it would bloat the number of accounts.

Fees as you note would be the disincentive to do this on the mainnet post launch.

I dont want to lose them just because some theoretical problems which seem to be mostly made up on the “spam problem”.

All security/dns/spam risks are theoretical unless they are utilised, if they aren’t used they don’t become an issue. We discussed this informally with the security review company and there is a risk there, how big, how likely etc is a judgement, I don’t pretend to know the answer and don’t think anyone else does either, it is a guess based on preference.

My opinion on it: I think most of the 114k accounts are “lost” and not controlled by anyone anymore. I do think there will be few active ones. I dont want to lose them just because some theoretical problems which seem to be mostly made up on the “spam problem”.

However, I see the problem with genesis block (limited amount of space) and why they cant be included from start.

I think this is the crux of your feedback and is probably valid, it looks to be shared by others on the chain as well.

Question
Are you suggesting then that a 0XEM threshold is preferable, or some kind of minimum threshold but not as high as 100XEM or something else?

3 Likes
#24

Correct, there is no technical reason it cannot be done

1 Like
#25

Thanks again for your detailed answer @DaveH.

This comment from you made it sound like it is already set.

Thats the reason i asked who made the decision.

Happy to hear that it is still up for discussion.

I was under the impression that everyone who holds XEM can optin to Symbol and claim XYM. From that point of view i am against any threshold.

Maybe there are other ways of preventing a scenario where someone misuses small balances to spam/attack the optin process?

2 Likes
#26

Just an idea that popped up when i thought about it again.

What if we introduce a seperate way, post launch, for small amount accounts to optin? Maybe a second optin account which only traces accounts with balances <100 XEM.

This way the main optin process will not be disturbed if someone spams with small accounts. however, small amounts may have to wait longer for their XYM if someone spams the second optin account.

It would also be less likely that someone will attack the second optin account because they will only block small accounts from getting XYM.

I dont know what that means in amount of work on the backend but theoretically it sounds like a solution which will make it possible for everyone to claim XYM.

2 Likes
#27

Another problem is perhaps the opt-in flyers that I have seen so far.
There is nothing to read from >=100 XEM.
It says 1XEM = 1XYM (Symbol Opt-in is open). That could cause legal problems.

3 Likes
#28

Many people will not read the questions.

Screenshot_20201014_181733
Screenshot_20201014_1817331761×646 81.1 KB

2 Likes
#29

About that there is information in Terms and Conditions which must be accepted during opt-in so I don’t think it can be legal problem (https://nemplatform.com/wp-content/uploads/2020/09/Symbol-Terms-and-Conditions-for-XYM-9-Sep-2020.pdf)

2 Likes
#30

There are some flyers on social media. They seem official. There is no reference to the required amount of XEM or this paper. :man_shrugging:

PS: And many will just click on in the Terms and Conditions section(NEM wallet - Optin ).

1 Like
#31

I think the problem is the lack of advance notice by the NGL.

2 Likes
#32

Thanks @spizzerb, sorry for slow reply, that’s a good idea.

We are putting together easier to read requirements doc and process flow for post launch opt in which we are hoping to publish on the forum in the next few days, I like the idea of the alternative account to separate them.

Just didn’t want you to think this had been lost in comments. The requirements/process doc will be a suggestion for how NGL thinks it could/should work but as a working draft with a call for input, not a statement that its got to work that way

3 Likes
#33

The legal advice that has been given is there are no issues in this regard.

1 Like
#34

Just curious to know when would the terms and conditions for post-launch on whether the accounts <100XEMs would also be able to claim their XYMs (if opted in prior).

Also I think @DaveH brought up an interesting point on how low the number should be. Right now, most people would not blink an eye losing 0.001 XEMs, just like no one would bother losing a couple of Satoshis 5 years ago. I’m of the opinion that any XEMs is good XEMs, and that as long as you opt-in, you can claim the equivalent XYMs in the future before the burn date (which is 5 years from launch?)

2 Likes
#35

There are 3 discussion threads coming out this week - post launch opt-in (generally and including min XEM thresholds) is one of them.

In terms of min. threshold - there are two specific things worth considering I think:

  1. It takes 0.85 xem to opt in on NIS1 (without VRF)

  2. It will take an amount of XYM to send the payment from unclaimed tokens account to the recipient post launch, on testnet this is ~0.2 XYM plus the co-signer/multi-sig fees (its not working in current wallet so I can’t check it quickly right now).

My assumption is that the fees on symbol should come out of the XYM being claimed by each individual account - the only tokens in the unclaimed tokens account will be the unclaimed balances, so if the recipient doesn’t pay, it means it is deducted from someone else’s potential balance

This means in practice the account will need something like 2 XEM in it to complete the opt in process and at the time of the snapshot block it must have had ~1 XEM in or there won’t be enough to cover the Symbol fees for token allocation.

Based on the above it seems reasonable to assume that at snapshot block height the account must have had AT LEAST 1 XEM in or they won’t be able to opt in, subject to the multi sig fees on Symbol just being double checked.

(which is 5 years from launch?

6 years

4 Likes
#36

Discussion thread is here: Symbol Launch Discussion Topic (1/3) - Post Launch Opt In

2 Likes
#37

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.