Topic: [ANN] [NFDv2] - NFD Coin - Thread locked - page 10. (Read 209469 times)

It's ready when it's stable and has no known flaws.
or
It's ready when it's done. :-)

Currently we are working on a whitepaper for internal use.
Next step is integrating AT in NFD-1.3.5.

How long until AT is on mainnet?

Thanks for the vote of confidence. Unfortunately, 25'000 was all I issued and right now I'm broke. I bought a big hunk of BTC, but it's in limbo for 14 days because the exchange I bought them at doesn't trust first-time buyers.

I used to buy at Vault of Satoshi...and damn, do I miss them...

Anyhoo: I seem to have a bit of a hit with NFDMMNxt, which did surprise me a bit. You're absolutely right about a second issue providing more buy support for NFD.

Yes, there are: I just saw it.

you can buy it on nfd exchange ,there are some sellers.

More NFDMMNXT to buy means more dividend transactions.
more dividend transactions means more NFD tx volume.
more NFD tx volume means price going up and attracts more attention.

I'd really appreciate that.

Are you planning to issue any more NFDMMNXT?  Looks like there are more folks interested than you thought!

Those are very good points. AT will certainly help with cross-chain transactions. You did hit the nail on the head about having to trust the issuer of an Asset. I've stuck to alias-type Assets myself - full backing by another crypto - in order to set a good example, and (I hope) add to a tradition that would make a scammer stick out like a sore thumb. But, it still hinges upon trust.

Implementing a reasonably trust-free option would require a major overhaul of the core. Unfortunately, we're still stuck in the altcoin underworld: the only experienced and doughty coder who's joined us has been BTC2Nxt for AT.

Spread betting on regular markets opens up another trust issue, as MaWo pointed out earlier. The trouble with using regular market data is that trust is required for the source! No matter how unimpeachable the feed, you still have to trust the feed itself. And regular markets being what they are, plus latency being what it is, there's no exact-match confirm available. Gold can go from $1,261.20 to $1260.70 or $1,261.70 in a millisecond. So if some scammer decides to run a "long con" with a compromised feed that give him just a little edge, it would be all-but-impossible to detect.

As for more obvious cons, they can be detected with "many sets of eyes" - preferably with some straightforward auditing tool which offers a choice of feeds. It wouldn't be that hard to whip up an auditing tool that would catch a scammer who tries to 'settle' a gold bet using $1,500 gold, for example. But again, latency and volatility mean that an exact match is simply not possible. It seems a situation that's ripe for a lot of arguments.

Isn't HFT grand?

In fact, there was an expose on Zero Hedge about a huge gold buy that hit the Chicago market at the exact millisecond when the Fed released a gold-boosting announcement. The truth of the expose hinged upon the speed of light! I'm not kidding. The author said that there was no way that the announcement could have reached someone in Chicago quickly enough for that buy to have been placed after the announcement came out. He concluded that the buyer had inside information on what the announcement was going to be and pre-programmed his tradebot to buy at the exact millisecond of its release in order to cover his tracks.

As I said, the latency, volatility and consequent trust issues would be a permanent source of arguments.

In this sense, the AE system is a real blessing and the prefect medium for spread betting. Its virtue is its slowness! All orders go into the hopper at the same time, and none of them are good until a forger validates them and adds them to the blockchain. ~90 sec. confirm time means that bets can be settled unambiguously.

But the trouble is, we need more alias type of Assets on the NFD system for spread bets! We'd also need a lot of liquidity, or at the very least a (trusted!) market maker to, say, keep "NFDGold" in line with the real bid and real ask for gold. It's a great idea, but the old catch-22 of the altcoin underworld puts a limit on it. For now.

As for me, I'm doin' what I can.

This is a great asset and MMNXT is an excellent backing for it.  We strongly support what you are doing.  Good work.  NFD is heating up.

It would be very good to see some kind of original NFD feature going beyond what NXT can do.  I think the NXT AE's great weakness is it's centralized trust model (in the issuer of an asset).  I still would like to see NFD implement spread betting with a decentralized trust model.  Perhaps AT can help with this?

Now is operating normally, I do not know what caused it, was going to the NXT wallet as well. But is already repaired.

I can not reproduce the ssh tunnel issue.
When I remove bootstrap.min.css then I see a similar screen.

Do you also have the same problem with google chrome?
If so, could you please do a right mouse click and chose "Inspect Element".
As next click on "Network", reload page and check whether a file is not accessible through the ssh tunnel.

I can read this link.

I accessed through the putty using windows 7 and Firefox, and it worked properly.

The problem is access using Linux Mint, or ssh through the terminal.

Are you able to access/read   http://localhost:8876/css/bootstrap.min.css ?

Firefox 35.0.1 in Linux Mint 17 MATE 64bit
This happens because of the connection through ssh.
When I access the wallet from VPS, it functions properly.

Normally it should work out of the box.

Which browser version do you use? Windows Firefox? Which version?

Could you also please try the online wallet?
https://nfdcoin.com/wallet/simple.html

The tunnel works now, thanks!

Now as to client 1.3.5, the interface default and simple appears disfigured when I try to access it.



There are some additional configuration to be done?

Edit: this is because the ssh listen, on my local PC only

Thank You for the update!

I will download the blockchain tomorrow, need to go to bed now!

Yes it is!

I suggest to set nxt.forceScan=true and nxt.forceValidate=true for the first start.
This allows the client to detect forks and popOff not valid blocks.

This will look like this:

and after start up:

Just to say don't worry. The client is only solving a fork situation.

Hehe 

New NFD client release nfd-client-NFD-1.3.5.zip

This is the first release which stores most objects in the embedded SQL H2 database, instead of keeping them in memory.
This version will perform an initial build of the objects tables, which on a fast machine takes about 10 minutes,
but may take longer depending on your hardware. A VPS usually needs much longer! The database size will grow
during this rescan, but after shutdown it should shrink to around 560 MB. The memory usage of the client will increase.

This version is the first version which includes a checkpoint check at every 720th block height. It's triggered during
block download. Checkpoints are hard coded blockId checks. Only blockIds and heights in the blockchain until the time of the release are recognized.
You can manually force a check by starting a scan with validation (nxt.forceScan=true and nxt.forceValidate=true) at startup.
If the check detect that you are on a fork, it will pop off all blocks until last valid one.

This version has also a rewritten UPnP component. Now it takes care about myAddress on its own. UPnP is enabled by default.
Please add nxt.enableUPnP=false to your conf/nxt.properties to disable UPnP mapping.

With this version we introduce a simple client. Please use it with caution, it's still in experimental state.
http://localhost:8876/simple.html

Other important changes:
Blacklist peers with version older than 1.2.0.
Limit peer networking request and response sizes to prevent out of memory attacks
Insecure SSLv3 protocol disabled for API.
Improved digital good store UI.
Forced validation is disabled again.
Improved test page http://localhost:8876/test
Access to the H2 database at runtime http://localhost:8876/dbshell (only with nxt.enableDebugAPI=true)

Limit total number of known peers merged from NXT 1.4.10:
To prevent overloading a node with invalid peer addresses, the maximum total number of known peers is
limited to nxt.maxNumberOfKnownPeers (default 2000).
Once this number has been reached, new peer addresses are not added, and peers
that have been last connected to more than a week ago are removed from the known
peer list, provided the node has enough connected public peers, until the number
of known peers is again reduced to below nxt.minNumberOfKnownPeers (default
1000).

Also included are all new API calls, bug fixes and other improvements from NXT 1.3.5 and before.
Please see NXT changelogs for more details:

• changelogs/nxt-client-1.3.0.changelog.txt
• changelogs/nxt-client-1.3.1.changelog.txt
• changelogs/nxt-client-1.3.2.changelog.txt
• changelogs/nxt-client-1.3.3.changelog.txt
• changelogs/nxt-client-1.3.4.changelog.txt
• changelogs/nxt-client-1.3.5.changelog.txt