During catching up I got an idea. I'd like some feedback on that:

We should not confuse two different issues: I1) finding consensus and I2) stabilizing the network. Each of these have two different purposes, therefore two different audiences and should therefore have two different incentive mechanisms. We cannot urge people to do something, we only can encourage them by offering rewards.

I1) TF is designed to do that. Transactions fees are the reward/incentive.

I2) More nodes will make the network more secure against switching nodes off. Reward for running a node: X

One could think of a special asset X that is only available for those running verifiable DIFFERENT nodes (in terms of databases, hardware, IPs etc). These accounts will get a portion of X for running a node.

I don't think this adds much to the discussion but thanks for the input.

We need as many nodes as we can get in order to make sure that the network doesn't "fail" (if there are too few nodes then our TPS would drop dramatically and in fact the whole network could be at risk).

Whether these nodes are "pool operators" or "individual forgers" is what we are discussing in regards to the "penalty" situation.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Release 0.8.1e

http://download.nxtcrypto.org/nxt-client-0.8.1e.zip

sha256: 4c665609a08fc5e79143e715c0f46246c66d35c1db6138ca9b025a1188d9aa3c


Change log:

Improved handling of peer announced addresses and ports. Setting
nxt.myAddress is now optional, which will help users with dynamic IP
addresses. When connecting to a peer, as long as nxt.shareMyAddress is
enabled, it will at a later time attempt to connect to your announced
address, or if not set, to the address your request came from.
If successful, the peer will use this address to connect to you in the
future, and will share it with others. This also does verification of
announced addresses, and considers your node connected only after a
successful connection to the announced address is made. This will prevent
invalid announced addresses from being spread to other peers too.

If you need to use a non-default port, the port has to be appended to your
announced address too. It does not need to be the same as
nxt.myPeerServerPort, so you can run the server on one port but forward
a different router port to it. If the port is not set in announced address
however, but nxt.myPeerServerPort is non-default, nxt.myPeerServerPort
will automatically be appended to the announced address.

To summarize: For users with dynamic IPs, you don't need to put anything
in nxt.myAddress, but still need to set up port forwarding at your router.

Verification of hallmarks has also been improved to attempt to resolve
hostnames to IP addresses. Note that if you use a non-default port,
the hallmark should include your address only, without the port.

Added generateToken API request. Parameters are secretPhrase and website,
response is the token string wrapped in JSON. This is also available
on the admin.html page.

Improved handling of init and shutdown. Nxt.shutdown() is now public and
client developers can call it. When Nxt is started as a standalone
application by calling main(), it will schedule a shutdown hook, otherwise
if started using init(), the caller of init() is responsible for calling
shutdown() or scheduling a shutdown hook.

Delayed starting the blockchain scan and the jetty servlets until the
initialization of all classes has completed. This should allow registering
listeners with those, and will also help prevent errors due to servlets
starting to accept requests before the system is fully initialized.

If nxt-default.properties is not found in the classpath, Nxt will also
make an attempt to load it from the file defined in the system property
nxt-default.properties, so you can define it on the command line:
java -Dnxt-default.properties=conf/nxt-default.properties. This is of
interest to client developers only.

Support use of POST in addition to GET for all API and UI http requests.
To enforce use of POST only, for those requests that require the user
secretPhrase, the nxt.properties nxt.apiServerEnforcePOST and
nxt.uiServerEnforcePOST can be set (default is false for API, true for
UI). This way client developers can enforce that only POST requests are
used for handling sensitive data.

The default NRS browser UI has been changed to use POST only, and so have
the tools - admin.html, message.html, alias.html. This way the user
secretPhrase will no longer be cached in the browser memory.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBAgAGBQJTC23tAAoJEFOhyXc7+e2AoW0P/iRzGr2E4h0kfKJdVE6lbmim
BE5X4uksz8A8Amdo8KoVKEAnTlEGkOHEPPXl2jegiJZi4CupxYNqOR7EaXdPwFNg
eQbA+pOgazpG7ljoZAfdKve4qEEQj4/enBgWRAMMnwEeysi/SMMxSPbzk2QI3EA+
h/kFHHuZjerbdbWghqaaETG11RzZYLiFt0xhFQtBcgCxjdTTGJ3eA9euRuP2VpGo
vsy4UhwjS1nZsv1B6DVuZpZcviDR2siXTTiZNPO/pxOvHP9rbGhKK7DUwrgLkI23
aqi52c8beCRfNIszhqfO+qPrRQOl51a3KeuedkNyt5QyaKoKSyRb8pKSk7H6D3n8
F9u9zWdl4+97a0KZVsl9sOKHN6oQW4CKjFD+/P0xz6FAVz29IrFmUAS1582mwjGB
LtcleI4LzBhYLXP9xblOQw8DMhrSz0kInMSlXkhjHrwMgQ/Z706RcPa4m3E7Itp7
4212I4kgQOj2CMB0Dj2F+M7msbpJ4fOgZwe3n7dU5d0CqkyfDHqS59qdoSEw+m8P
OVFqYGccLgwC4oqISV9MKGXK+GQmAnOsk3qUmuk7IwuFLvKFiOH2ONezlEgNf3Nq
H9ishR4Kz5EmL+lxMVVdFKJv4F+wBvrJ46kCn6dLpdE3AAQ8UE3igHuuzWSfuN9b
IDqSgNO/e6KgYRNSw5N3
=xPDQ
-----END PGP SIGNATURE-----

68 signups as of this mornings, we need 32 more people to sign up at Bittrex, please do so if you have not.  Thank you.

Thank you for update, trying my stick for public node. To be sure, do I need to change something in nxt-default.properties or I can use from previous 0.8.0e?

My point for this discussion is:

Don't confuse why we need more nodes, what properties these nodes should have and how an optimal incentive architecture for running nodes should look like.

Pump


Since this is so OS-special, maybe two different developers for Windows and Mac. Come on, guys. Raise your hand for this project!