Topic: NXT :: descendant of Bitcoin - Updated Information - page 2087. (Read 2761645 times)

By mixing you mean making a transaction anonymous? Then yes, that would be a top-priority for me.

Do u mean Asset Exchange?

If you've had an alias nabbed: it's always possible for a bot to listen to the network for new alias request messages, and quickly submit a new one for the same alias and +1 fee, on the basis that if it's requested by one person it might be valuable one day, and so worth a (probably 2nxt) punt. Doubt anyone would bother now though.

All but sooner or later mixing is essential.
Any ideas whether zerocoin is applicable with NXT?

I want opinions before I ask the professor and his team - I think they may match idealy...

Transparent Mining is an advanced feature and won't be included into released source code. It's the most powerful feature of Nxt atm.

Could we get, or is there a location for descriptions for each of what these do?

The software keeps the passphrase in memory? That would be a bad idea.

distributed exchange not on the list?

In continuation of the announcement that we r looking for more Nxt core devs, there are features we r planning to implement till block 525960 (in alphabetical order):

- Alias System (done)
- Arbitrary Messages (partially)
- Asset Exchange (done)
- Distributed Computing (concept not ready)
- Distributed Storage
- Instant Transactions (requires peer review)
- Mixing Service (concept not ready)
- Multisignatures
- Service Providers
- Shrinking
- Smart Contracts (concept not ready)
- Transparent Mining (partially)
- Two-phase Payments
- Voting System
- some non-revealed features

I'd like to get ur opinions what features should be implemented in the 1st place.

but how would that work?
We are nearly at 1/minute, with your formula that means that nearly all 1 billion coins are forging? Thats 100% not the case

I never saw Java memory issues with my node, and it served several tens of GB of traffic (public static IP; hallmarked). It did get stuck on some occasions (running and serving requests, but not on the latest block even after browser refresh), and a restart usually fixed that, although sometimes it required reverting to a backup blockchain.

I'd like to look at any Java memory issues you see. If you consistently see out of memory exceptions, please run the client with the following parameters:

 -verbose:gc -Xloggc:gc.log -XX:+PrintGCDateStamps -XX:+PrintGCDetails

And then share the resulting gc.log file. NB: this gets overwritten on start, so take a copy first.

You can also run it with this parameter:

 -XX:+HeapDumpOnOutOfMemoryError

This will produce a large file which is basically a copy of the entire heap at the point, so it's best to do it on a node with moderate memory settings (e.g. 512MB, not 4GB) and make sure you have sufficient disk space. Zip/gzip this up and upload it somewhere (e.g. mega) and share details. NB: very important, if you do this DO NOT enter your secret key on that node as it is likely to be visible in the heap dump (hallmarks are okay).

Not sure, it's in the software code somewhere, maybe there is even a limit. Plus I'm sure there a bunch of nodes behind NATs like people running on their home desktop, likely that 50M account.

Look at statistics, we went to ~1440 blocks per day not so long ago. DDoS splitted network and calculatable low % of all coins was forging main chain with low speed against needed 1440/24h. I'm little surprised why "Transparent Forging" wasn't built-in. Code wasn't ready?

I have deployed additional nodes. I've been focussing on regions that don't have many nodes yet.

Total nodes deployed: 20

Regions:

South America (Sao Paulo, Brazil): 10 (nxt2.tweetmondo.com to nxt11.tweetmondo.com)
Australia (Sydney): 5 (nxt12.tweetmondo.com to nxt16.tweetmondo.com)
Malaysia (Singapore): 5 (nxt17.tweetmondo.com to nxt21.tweetmondo.com)

If you want more nodes in these regions, please donate 1000 NXT per month per additional node to: 9060914620736248721

Thanks!

no, that means, that node chose to only take these nodes as active peers. The number of active peers is limited and the peers are chosen randomly if i am not mistaken.

So you will be an active peer somewhere

So does this mean that some who are listed in the known peer list on a particular desktop client are actually active peers, and the given desktop client hasn't figured that out yet?  Just how long does it take for a desktop client to sync up and see all of these new VPSs out there on the cloud?

Correct, every computer running NRS will show up eventually as long as they aren't behind a NAT. The reason for all the nodes we setup is to ensure there are a steady supply of nodes that are full open and accessible to everyone (i.e. not behind a NAT/firewall, running 24x7)

There are active peers and known peers. If your client runs long enough, you will see EVERYONE forging as an known peer.

EDIT: haha someone launched a node called giantdildo

I have a gap in my knowledge so I'm gonna ask a dumb question.  Just what IS the difference between a node up in the cloud and a peer running as a desktop (or Pi) client??  

We've got all these VPNs set up all over the world now - ferment alone has set up almost 100 - and these are "nodes".  They are all running the NXT 0.4.7e Java server software.  They are forging blocks.  Yet if I look at the "peer" list on my desktop client (where I have actually generated 9 blocks myself so far the past couple of days) I only see 52 "online peers".  If the "nodes" are generating "blocks" too, why aren't they considered "peers" as well and show up in the online "peer" list?  

I note one of the most prolific block generators is 4747512364439223888, a 50,000,000+ NXT account that has generated 3304 blocks so far, earning 56,290 NXT in fees.  Yet this chap  doesn't show up at all in the "online peer" list, which for me only lists two multi-million NXT accounts out of 54 as forging blocks : 78:46:63:221 at 6.6 million NXT and vps07.nxtcrypto.org with 2.1 million.   Somebody looking at just his desktop client with his minimum 10 NXT in it hoping to forge a block not only is at the back of the pack statistically speaking, he can't even see the front of the pack.

Am I missing something here?  Any elaboration somebody feels like sharing would be appreciated, thanks.