Topic: NXT :: descendant of Bitcoin - Updated Information - page 707. (Read 2761650 times)

Done.  I am in email contact with Nifty too.

Yeah I think I would stop competing unless I was the best ticket because of the penalty... If that mod comes out that is not good for the network at all.

It really is a penalty as they now have no chance to forge a block for 24 hours (I wouldn't be surprised if people ended up modifying the software to "go to sleep" for 24 hours in that situation).

Also it doesn't really matter being "the best" as we are building "chains" (the weight of the entire chain is what is best rather than each specific block in it).

Beers for you! 

I will try my best (math is not my strength - logic is).

Basically the way that TF works is that there is a crypto hash for each block which was calculated from the previous' block hash and the "forgers" account.

This hash then determines who's account is the "best" to forge the next block so in a perfect situation if we consider that the max. "weight" of a block is 100 then you would see a blockchain like this:

A(100) B(100) C(100) D(100)

but things aren't perfect as some people won't forge (or pass on their forging right) so the network allows other "less perfect" blocks to be announced and each node will accept the best one that they see to try and keep building on the chain.

A(80) B(90) C(50)

The problem of "forking" is because each node can't see everything in the network (due to latency) so you could also end up with:

A(80) B(95) C(10)

with these "forks" ending up becoming "ignored" because a longer "better" chain has been noticed by the node.

So the problem we are dealing with is that B(95) could "hide" their block and then announce it *after* B(90) which would at least for 1 block make it a "better chain".

But as others will build upon what they see then it won't necessarily *matter* that B(95) was better than B(90) because C(50) is better than C(10) and so B's attempt to "create a fork" will fail.

If though someone has the ability to produce a better B, C, D, E, etc. then they could replace a large number of blocks. This is known in Bitcoin as the >50% attack.

We need to work out the probabilities of all this including how "penalising" a node for "not forging" changes this.

This is not good. You should not have to use kill -9, because this will not let the database shutdown cleanly. Try the new version, there have been some changes in the shutdown process. You should at least see the message "Database shutdown completed" in the log, if it still hangs after that it is ok to kill it, could be that some jetty server does not want to exit, but once the database is shutdown it is safe to kill the remaining threads.

I'm not sure I understand....

So if the node with #12345 is on a slow distant part of the network and #12344 is on a nice well connected bit, nodes will see #12344 first and accept it but then they see #12345 which is the overall best ticket and accept that instead, and #12344 and #12346 which tried and ultimately were rejected when #12345 turned up a few milliseconds later both get penalised and have to wait a minimum of 1440 blocks - is that right?

But strictly speaking they could now win at that point because they were not the best ticket and they were probably not the next ticket so having to wait 1440 blocks is that really a penalty?

What do you suggest then?

-----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-----

How do we reward nodes within a PoS system?

Nodes exist outside of the NXT system. Rewarding nodes would imply having PoW.

No , but i expect at least 10-20 Nxt .. i'm helping the community and when i forge one block and the reward is 0 Nxt... i'm so angry  

I agree.
I agree.
I agree.

Believers in the NXT ecosystem are going to be running at a loss, month after month...

I only speak for myself but I think it would better not to try tying the Nxt community itself to such causes (whether they be noble or otherwise) as you are always going to "turn off some potential users".

Wouldn't it be better for interested Nxt users to just form their own groups for that?

This is the PoS system. Less transactions, less fees. If you want more NXT out of your metal, promote NXT and stimulate transactions like hell.

Can you define (in simple terms) the math model and the question about it that you need answered?  I'm a mathematician (Probability/Stochastic processes), but understand little how cryptocurrencies actually work, I have to confess that I understand almost nothing of the tech talk over here...

Should Nxt support the anti SOPA activism or not?

just have to finish polishing the idea of ​​maintaining the security of the network without penalizing the cost. but this I think with all these brainstorms will be achieved

 

Not until we make it attractive to them. They need to have very, very, very good reason for building their business on top of NXT.

The current money system is far from perfect but it works for most people.

Give me 3 reasons for the average joe/entrepreneur to join us!

Who is currently working on the Decentralized Marketplace / Auction system?

emule, dump your coins please.