Topic: [NEM] NEM -New Economy Movement - No Envy Movement - Updates+Discussion thread - page 467. (Read 661525 times)

I do not understand this system. I have even a share but what:

- Makes NEM from?
- For what is NEM?
- Which raises NEM from over the other 100 Coins?
-where NEM seeks to distinguish against Nxt?
-what is the purpose of NEM?

Another aspect:

I would like to see if NEM knows where it wants to do a fundraiser.

It would be cool if each shareholder $ 100 for a huge advertising campaign donate that has not seen the world before

Sounds crazy? YES but it works! For all!

OMG your idea is even worse than mine 
This way you don't even have to create 1 million wallets to get the coins:)
Cheers

1.1 Agree, storage must be transactional secure

1.2 lightweight browser, maybe I do not get the point, but this is already available...IMHO GUI not very nice or attractive and not easy to unerstand
@UF could you ask to elaborate on this a little bit more

1.3 In principle I would agree, snapshots which get propagate are open for attacks and easy targets to fake snapshots

Nope, you don't need whole chain for security purposes.

Also 'normal' clients would also be part of the network.
They just wouldn't store whole history, only those snapshots + blockchain history since last snapshot till present.
Most people don't need whole history anyway (i.e. compare to btc, where download of whole the blockchain takes days if not weeks...)

When you would receive initial snapshot, there would be additional step of verification,
that the snapshot you've received is actually CORRECT one (there are number of ways this could be done),
to make sure the peers from which you've received it are not EVIL ones.

@Jaguar and Theis. Some thoughts from a friend.

-----------
There are things that I don’t like about NXT or that I think could be done differently.

1. Storing whole blockchain in memory.
    imo, “app” should be split into 3 parts:
    1.  server, storing blockchain and all related info in DB - this one would be used for all the SERIOUS stuff (so exchages, faucets, and any other apps like that would run this)
    2.  lightweight IN-BROWSER client - I think CfB has similar idea - that one, would have ZERO knowledge itself it, but I think it’d be possible to do whole singing in-browser.
    3.  ‘normal’ client - for users, that want to participate in the network, but don’t want to deal with DB setup. This one would keep blockchain in memory, BUT it would rely on “snapshots”
               a. snapshot would be created every X days (I was thinking about X=10)
               b. they would contain information about state (of accounts), but would drop all the history
               c. snapshots (for new clients) could be propagated in torrent-like fashion.

2.  TPS rate. I’ve seen somewhere info, that Nxt could handle 100_000 TPS. I have some doubts about it. (current hardcoded limit for tx in block is 255, that would imply ~400 BLOCKS per sec).
     I think software, should be thought upfront to handle large amount of transactions per second. (so for sure, somewhere “in future” there should be switch to binary protocol, also it might be beneficial  to use UDP to propagate information).  what do you think about GHOST?
     Also I got interesting idea, but I’m not sure how it would work in practice...

3.   Lack of Wallet. People simply got used to this. I don’t think generating Secret Key by doing SHA on a string (like Nxt is doing currently) is a good idea.

4.   Curve. You’ve already written, you’d like to switch to Ed, so I guess you think the same.

A.   Server as a servlet - I think this is good choice for initial implementation (before adding binary protocol, also servlet, would still be needed if one would like to have IN-BROWSER client). But I’d change one simple (and quite obvious) thing: instead of embedding type of query in json, It should be in URL itself.
-----------

CUT

Nope, you don't need whole chain for security purposes.

@Jaguar and Theis. Some thoughts from a friend.

There are things that I don’t like about NXT or that I think could be done differently.

1. Storing whole blockchain in memory.
    imo, “app” should be split into 3 parts:
    1.  server, storing blockchain and all related info in DB - this one would be used for all the SERIOUS stuff (so exchages, faucets, and any other apps like that would run this)
    2.  lightweight IN-BROWSER client - I think CfB has similar idea - that one, would have ZERO knowledge itself it, but I think it’d be possible to do whole singing in-browser.
    3.  ‘normal’ client - for users, that want to participate in the network, but don’t want to deal with DB setup. This one would keep blockchain in memory, BUT it would rely on “snapshots”
               a. snapshot would be created every X days (I was thinking about X=10)
               b. they would contain information about state (of accounts), but would drop all the history
               c. snapshots (for new clients) could be propagated in torrent-like fashion.

2.  TPS rate. I’ve seen somewhere info, that Nxt could handle 100_000 TPS. I have some doubts about it. (current hardcoded limit for tx in block is 255, that would imply ~400 BLOCKS per sec).
     I think software, should be thought upfront to handle large amount of transactions per second. (so for sure, somewhere “in future” there should be switch to binary protocol, also it might be beneficial  to use UDP to propagate information).  what do you think about GHOST?
     Also I got interesting idea, but I’m not sure how it would work in practice...

3.   Lack of Wallet. People simply got used to this. I don’t think generating Secret Key by doing SHA on a string (like Nxt is doing currently) is a good idea.

4.   Curve. You’ve already written, you’d like to switch to Ed, so I guess you think the same.

A.   Server as a servlet - I think this is good choice for initial implementation (before adding binary protocol, also servlet, would still be needed if one would like to have IN-BROWSER client). But I’d change one simple (and quite obvious) thing: instead of embedding type of query in json, It should be in URL itself.

Is it possible that there still exist some good idea ...
the fees would be given/divided to all accounts, which are active at that moment (which are doing the work for the network) ?
Or would there be problems in the implementation?

I wouldn't worry much about NEM forging problem even if we have an exact forging implementation. In NXT, most forging fees go to accounts with 10 millions and up (out of 1 billion), especially with few 50 million accounts ; NEM won't have a problem with big accounts thanks to the initial distribution design.

That's being said I don't think forging design is a problem with NXT. There are problems somewhere else but still I am a NXT ambassador so ...

Just an idea :
I don't know if you would concider google ads?
Google is probably the most efficient in finding the right audience!  And it's pretty cost effective.... at least,it was a while ago.

Who is nemcoin ? are you a new user or a sockpuppet ? 

OMG your idea is even worse than mine  
This way you don't even have to create 1 million wallets to get the coins:)
Cheers

Yes it should depend on target audience. I am still tweaking the front page because I want perfection in wordings and represent exactly what NEM aspires to be. Suggestions welcome.

I agree, but the problem is that if I have a million NEM, I could open up 1,000,000 NEM wallet and put 1 NEM in each and receive 99,999,999 more share of the fee than everyone else. I don't see how we could get around that a side from rigid account control or minimum balance, but even then, people would find way around that.

I think the most frustrating part of NXT for small account was to see the next block could be forged in 325 days 12h 22min. I didn't look at the NXT code yet, so I don't know if this is possible, but if we could introduce fraction, we could pay divide the fee amongst all NEM user based on the ratio of money the have.

So, i we divide 1/4,000,000,000 we get 0.00000000025. This mean that for each NEM of fee, every user would receive 0.00000000025 NEM for each NEM they own. If we decide that the smallest unit is 0.00000001 NEM, we would then have to wait until 40 NEM in fee has been collected before distributing 0.00000001 NEM to everyone for every  NEM that they own.

Anyway, just an idea 

Cheers