Nxt Forum

Nxt Discussion => Nxt Software Releases => Official Nxt Releases => Topic started by: Jean-Luc on December 20, 2015, 07:08:58 pm

Title: NRS v1.7.3e
Post by: Jean-Luc on December 20, 2015, 07:08:58 pm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Release 1.7.3e

https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.7.3e.zip

sha256:

07be795bb6b64df7dbe73072544ddb9236c57d827147a7eb3a98e34929698a65  nxt-client-1.7.3e.zip

https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.7.3e.jar

sha256:

ef6e145e4ba631238c8bef054e94af6d85e2be983756815fcc9f3e86b09de92b  nxt-client-1.7.3e.jar

https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.7.3e.exe

The exe and jar packages must have a digital signature by "Stichting NXT".


This is an experimental release for testing only. Source code is not provided.


Change log:

This is an experimental bugfix release. It is a mandatory update for testnet
nodes.

Added retrievePrunedTransaction API. This API can be used to force retrieval
of the prunable data for a given transaction, even if past the configured
nxt.maxPrunableLifetime. Using this API to retrieve pruned data however does
not increase its lifetime, i.e. at the next scheduled table trimming the data
will be pruned again if expired. This API queries all currently available
archival peers, until the missing data is found, therefore it can take some
time to complete, and can also return no results if there are no such peers
online, or none of them has the requested data. Consistent with the behavior
of getTransaction and related API, the returned transaction JSON will not have
the prunable parts included if they have already expired and
nxt.includeExpiredPrunable=false (default is true), but if those parts have
been successfully restored, they can be requested using the more specific APIs
such as getPrunableMessage, getTaggedData, etc.

The getPrunableMessage, getTaggedData, and downloadTaggedData APIs now support
optional "retrieve" parameter, default false. If the corresponding data has
been pruned and retrieve is true, an attempt will be made to retrieve the data
from archival peers, as if using the retrievePrunedTransaction API.

Added getReferencingTransactions API, returning the transactions referencing a
given transaction id.

Added getLinkedPhasedTransactions API, returning the phased transactions with
by-transaction voting model for a given linkedFullHash, regardless of their
phasing status (pending, approved or rejected). Since the corresponding table
is trimmed after finish height however, the result will not include those
transactions that finished before the last trimming height.

Increased maximum leasing period to 65535 blocks, to take effect after the
hard fork.

Shuffling UI improvements.

Added UI for the Tagged Data feature, now known as Data Cloud.

The Exchange Booth UI has been improved. The user must only enter the number
of currency units to be bought or sold, and the server determines the maximum
or minimum rate required in order to obtain or sell this amount, based on the
current market offers available. This avoids the creation of exchange requests
that cannot be filled, and eliminates the need for manually calculating the
required exchange rate.

To prevent clickjacking exploits, a new http header is now added by default to
all http API responses, X-FRAME-OPTIONS: SAMEORIGIN. This can be turned off by
setting nxt.apiFrameOptionsSameOrigin=false in nxt.properties.


Incompatible changes:

The taggedData field in the getAllTaggedData API response has been renamed to
data, for consistency with the other get*TaggedData APIs.

The behaviour of the currencyBuy API has been fixed, to exchange no more than
the number of currency units specified in the units parameter. Currently, the
total amount of NXT as calculated from rate * units is exchanged for currency,
even if this results in purchasing more than the number of units requested,
which is non intuitive and not consistent with the way currencySell works.
This change will take effect after the hard fork.


Updated Jetty to version 9.3.6 and slf4j to version 1.7.13. Make sure to
delete the old lib folder if unpacking over a previous installation.

This release will do a blockchain rescan on testnet and may delete blocks
after certain height, to resolve testnet forks.


-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJWdvZCAAoJENqvaxkWiP4Z+acQAL/1OPMFGbmUUkLeFlBbzKVP
M+xbtEel3RjZlnN1Q5ca1SCrNsEUgigDYY/LxRre7QdqYQ/rpkzbQB3TYx39hHSO
/G3dXt7aLJ/4vd8QI6r6/AtO5FW1tdCXW7ag8+hqb1g0tBoWDf+2FyLaSggjjExN
tznnhVlCM2HooqMKUNv9nF/Y8cuejN69Ph5IpixLzmZN3mxynZc73KhZA5bGQRCp
kRvgy9eD4aTlGEBzBy7PuIVASFQZfRuFI8Caa8Yjj9hV7uZAxt5kSYIjappgKeMV
voCSgCuSQknzleyuBdjrS295KyPygasGKQz99goYKDWcRf7DXNL+fD0NIOtgDyXS
SwK5cMgUQFckSGXfv2QouSTlDz1U5m9FBhPdGFDDY3ysj+p0Cmo+KsvusK/zlWGE
8+36UjWev1EGpH0oAcKekxYHxpdGHZxGRqTSdxNIt9ZKH8tr2bGRU2Aps+EnVGCU
8PDkB5320SU9Q+f5v1LLmL9UUVcZ26CGC0tg/n/Gs5AVjdkWWlbY2HYRNHaNxDi0
etaGgw5nIOSNizt+3scLvvqzsyQ2f8/p0VggkWnDs6aZpTYjneR1+N73rd3CplEP
uLOjb6Msv0k9nKwNj1nz3NjwaBuMqL/zhchT+TwxZTunZ57Eu/H9qnuFEJzX5eXa
eRc3l21PA3TuGzLNLCKx
=HrOr
-----END PGP SIGNATURE-----
Title: Re: NRS v1.7.3e
Post by: yassin54 on December 20, 2015, 07:38:53 pm
Thank you!!  ;)
Title: Re: NRS v1.7.3e
Post by: abctc on December 20, 2015, 09:04:51 pm
Great!
Title: Re: NRS v1.7.3e
Post by: Riker on December 20, 2015, 09:59:50 pm
Mac installer https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-installer-1.7.3.dmg signed by "Stichting NXT"
Title: Re: NRS v1.7.3e
Post by: TheCoinWizard on December 20, 2015, 10:34:52 pm
Sweet, I will give it a try...
Title: Re: NRS v1.7.3e
Post by: qq2536007339 on December 21, 2015, 01:10:29 am
No wonder I can't connect to testnet last night.Already update,thank you!
Title: Re: NRS v1.7.3e
Post by: allwelder on December 21, 2015, 04:00:50 am
o,good works. :)
Title: Re: NRS v1.7.3e
Post by: blackyblack1 on December 21, 2015, 09:04:38 am
Data Cloud feature is looking nice...
Title: Re: NRS v1.7.3e
Post by: Jean-Luc on December 21, 2015, 10:33:15 am
The Data Cloud feature is already fully usable on main net with 1.7.3e, as it doesn't depend on hard fork changes. The improved exchange booth UI also is, except for the Buy Currency side where before the hard fork it will only work for requests matching a single offer.

We expect this to be the last experimental release, and to have 1.7.4 stable before end of the year. Now is the last chance to find and report critical bugs.
Title: Re: NRS v1.7.3e
Post by: RocketBunny on December 21, 2015, 11:24:47 am
What data cloud max size limit?
Title: Re: NRS v1.7.3e
Post by: Riker on December 21, 2015, 11:47:04 am
What data cloud max size limit?

The file size limit is 42K per transaction.
Title: Re: NRS v1.7.3e
Post by: Brangdon on December 21, 2015, 11:52:11 am
Where is Account Control in the UI? I've tried reloading, and I can see Account Properties.
Title: Re: NRS v1.7.3e
Post by: Riker on December 21, 2015, 12:07:47 pm
Where is Account Control in the UI? I've tried reloading, and I can see Account Properties.

It's in the account details modal. From the dashboard click on the "account balance" box (top/left) on the resulting "account details" modal click the "account control" tab.
Title: Re: NRS v1.7.3e
Post by: Brangdon on December 21, 2015, 01:04:53 pm
Where is Account Control in the UI? I've tried reloading, and I can see Account Properties.

It's in the account details modal. From the dashboard click on the "account balance" box (top/left) on the resulting "account details" modal click the "account control" tab.
Thanks. That's well hidden. It might be an idea to combine the account balance/details with the Details button that is underneath the main account number. Or something.

Currently, clicking the account number does nothing. Clicking the account name "Brangdon TestNet" sets Account Info (ie name and description). Clicking Details gives historical info (transactions and ledger) and current state (currencies owned, etc). Clicking the balance gives another group of settings (balances, leasing, account control). There is also Account Properties underneath the Dashboard, which is something else again. This is all a bit messy and unobvious in my view. Maybe it would be better if Leasing and Account Control were together with Account Ledger, Account Properties and Approval Requests in the Dashboard section. Better organisation would make clearer what options are available to set, and the difference between "info", "details" and "properties", and which are historical, and which are current state. Or whatever, I'm not great at UI. It just really needs an overhaul at the moment. It's just growed.
Title: Re: NRS v1.7.3e
Post by: TheCoinWizard on December 21, 2015, 03:11:50 pm
Thanks for the new experimental release.

I tried to do some shuffling, and now I may no longer switch of my pc  :P

Please join my shuffle 13704879857907371065 on the testnet



I got some questions though:

Why can I not close my account after creating/joinging a shuffle?

Why is there a prefixed number of participants in a created shuffle?

Why can I not shut down my node after creating/joining a shuffle?

Why can I not shuffle to other peoples account? In other words:
Why do I need the private key of the receivers account?

What happens with shuffle joined account that must pay the 1000 fee since he closed off his node, but only have 200 nxt on his account.

Seems to me shuffling would be much better without these limitations.

keep up the good work, nxters
Title: Re: NRS v1.7.3e
Post by: coretechs on December 21, 2015, 07:04:36 pm
UI suggestions/notes:

1. rename "Deletes History" subsection of AE to "Delete History" or "Deletion History" to be more consistent with the singular form "Trade History" and "Transfer History" (they aren't Trades History or Transfers History).

2. Under Account Properties, the buttons in the upper right, "incoming" is not capitalized, but "Outgoing" and "Set" are capitalized.
Title: Re: NRS v1.7.3e
Post by: Brangdon on December 21, 2015, 09:51:12 pm
I'm not a dev, but I'll have a go at answering these, since no-one else has.

Why can I not close my account after creating/joinging a shuffle?
If by "close your account" you mean close the browser window, you can, provided your node keeps running the shuffler that the browser started.

Quote
Why is there a prefixed number of participants in a created shuffle?
Because the number is a trade-off that needs a human to decide. If it is too low, then the anonymity provided by shuffling is weak. For example, with three participants, if I am one of them, I have a 50:50 chance of guessing which way around the two are. So larger numbers of participants are more secure. However, if the number is too large, there may not be enough other people who want to join the shuffle, and it's more likely one of them will go offline and break the shuffle.

I suppose it could be made more flexible. We could specify a minimum number of participants, and a start block, and then have the shuffle start processing at the start block provided at least that minimum had joined. Then shuffles would not be arbitrarily limited in number, which would be more secure. Maybe that could be supported later. For now the devs have kept it simple.

Quote
Why can I not shut down my node after creating/joining a shuffle?
The protocol is quite a complex, multi-stage affair. It involves monitoring the blockchain, and several transactions being issued from your account. This is done by an automated process called a "shuffler" that runs on your node. If the node is shut down, the shuffler doesn't run, and when it's your turn to issue a transaction that won't happen, and the shuffle will fail.

Quote
Why can I not shuffle to other peoples account? In other words:
Why do I need the private key of the receivers account?
I think the devs thought it too error-prone. The danger is that naive users will reuse an account of their own, that can be linked to them somehow, which would defeat the object. Even reusing the same recipient account for shuffling more than once, A ==shuffle==> B, A ==shuffle==> B, would be vulnerable to statistical analysis which could undo the shuffling and link accounts A and B.

(However, personally I'd like to have the option to send to someone else's existing account - in effect, anonymous one-off payments. I'd also like to be able to send less than 1000 NXT, with the remainder of the deposit being returned to the participating account. Maybe this could be supported later. It's not urgent for me.)

Quote
What happens with shuffle joined account that must pay the 1000 fee since he closed off his node, but only have 200 nxt on his account.
The 1000 NXT deposit is deducted from the available balance as soon as the account joins the shuffle. The account can't join the shuffle if the coins aren't there. So the situation you describe can't arise.

Quote
Seems to me shuffling would be much better without these limitations.
Anonymity is hard. Shuffling is inherently complex. The current design looks to be about the simplest possible. If it turns out well, maybe it can be made more flexible, and hence even more complex, later.
Title: Re: NRS v1.7.3e
Post by: Riker on December 22, 2015, 08:59:19 am
UI suggestions/notes:

1. rename "Deletes History" subsection of AE to "Delete History" or "Deletion History" to be more consistent with the singular form "Trade History" and "Transfer History" (they aren't Trades History or Transfers History).

2. Under Account Properties, the buttons in the upper right, "incoming" is not capitalized, but "Outgoing" and "Set" are capitalized.

Fixed for 1.7.4
Title: Re: NRS v1.7.3e
Post by: Riker on December 22, 2015, 09:21:49 am
Where is Account Control in the UI? I've tried reloading, and I can see Account Properties.

It's in the account details modal. From the dashboard click on the "account balance" box (top/left) on the resulting "account details" modal click the "account control" tab.
Thanks. That's well hidden. It might be an idea to combine the account balance/details with the Details button that is underneath the main account number. Or something.

Currently, clicking the account number does nothing. Clicking the account name "Brangdon TestNet" sets Account Info (ie name and description). Clicking Details gives historical info (transactions and ledger) and current state (currencies owned, etc). Clicking the balance gives another group of settings (balances, leasing, account control). There is also Account Properties underneath the Dashboard, which is something else again. This is all a bit messy and unobvious in my view. Maybe it would be better if Leasing and Account Control were together with Account Ledger, Account Properties and Approval Requests in the Dashboard section. Better organisation would make clearer what options are available to set, and the difference between "info", "details" and "properties", and which are historical, and which are current state. Or whatever, I'm not great at UI. It just really needs an overhaul at the moment. It's just growed.

We decided to leave the account number as a non-clickable label so that power users can triple click it then press Ctrl+C to copy it, which I find myself doing very often. Until 1.6 this was available using an Adobe Flash extension which we had to remove due to security and compatibility reasons.
We actually put a lot of thought (and work) on setting the name and details links so that these functions are easily accessible.

I agree that something has to be done about all these account related modals and pages which we inherited from the original Wesley design. Currently, whenever we need to add something we decide ad hoc about the appropriate modal or page but rarely alter to overall design.

We are also missing quite a few account specific tables in the account info dialog which should have been part of this modal tabs like "Asset Delete", "Currency Exchanges" etc which we  can only see for the current account, not for other accounts.
But we already have 7 tabs on this modal and if we add all these tables there, we'll end up with 15 tabs or more.
And I also agree that there is no reason for having separate "account details" modals with yet more hidden account specific functionality.
Need to think about a better design for this.
Title: Re: NRS v1.7.3e
Post by: Jean-Luc on December 22, 2015, 09:47:08 am
I see another shuffling created on testnet, 13334123818548070566 for 30 participants. Unless 18 more accounts register in the next 100 minutes, it will not enroll enough participants and fail. If you create shufflings for testing, it is better to announce them on the forum too, and allow a long registration period, I guess nobody bothers to check frequently if there are any new active shufflings on testnet.
Title: Re: NRS v1.7.3e
Post by: Riker on December 22, 2015, 09:04:36 pm
When a shuffle is deposited into the recipient account (using the new private key) it appears from nowhere. Is there a simple explanation of how this is implemented?

The implementation is based on the ShufflingRecipients transaction submitted by the last shuffler which has the full random mapping between sender and recipient public keys. See for example tx# 2020485324057619490 on testnet.
You can see this deposit in the recipient account transaction ledger.

Quote
And if it's possible to 'magic' coins from nowhere into a fresh account then what provisions have been taken to ensure that someone couldn't hack the shuffling protocol and create a new account with 20M NXT in it? Or even 20 NXT :)

As always, you can hack a single node and do whatever you like but if you do not comply with the protocol rules the other nodes won't accept your transaction.
Soon we will release the source code for public review and then folks can double check the algorithm.

Title: Re: NRS v1.7.3e
Post by: lopalcar on December 22, 2015, 09:33:44 pm
I suppose this isn't the correct site to post this, but seems devs watch more this thread, soo... can you devs please answer https://nxtforum.org/core-development-discussion/assetasset-trading-pairs-nxt-core/msg204060/#msg204060
Thanks!
Title: Re: NRS v1.7.3e
Post by: Riker on December 22, 2015, 10:06:47 pm
I suppose this isn't the correct site to post this, but seems devs watch more this thread, soo... can you devs please answer https://nxtforum.org/core-development-discussion/assetasset-trading-pairs-nxt-core/msg204060/#msg204060
Thanks!

I'm watching the asset to asset thread but this not a simple decision, we would like to focus on stabilizing the 1.7.x release at the moment and defer the discussion of the product roadmap.
Title: Re: NRS v1.7.3e
Post by: lopalcar on December 22, 2015, 10:25:41 pm
I suppose this isn't the correct site to post this, but seems devs watch more this thread, soo... can you devs please answer https://nxtforum.org/core-development-discussion/assetasset-trading-pairs-nxt-core/msg204060/#msg204060
Thanks!

I'm watching the asset to asset thread but this not a simple decision, we would like to focus on stabilizing the 1.7.x release at the moment and defer the discussion of the product roadmap.
And how about the 3rd party doing it? If other person makes it, would you review and add to core? I understand this feature is very important for use nxt as platform, maybe doesn't increases the value of nxt "as coin" but would bring many users to the platform IMHO
Thanks for answer!
Title: Re: NRS v1.7.3e
Post by: allwelder on December 22, 2015, 10:51:33 pm
With 'Hash Calculation':
I just fill some text ,and textual data representation not clicked(default),and click calculate,
It just displayed: Incorrect "secret"
But if I click 'textual data representation' selection, it worked.

Why it displayed Incorrect "secret" ?
Title: Re: NRS v1.7.3e
Post by: allwelder on December 22, 2015, 11:20:59 pm
Can rename 'Generate Token' under gear on the right corner to just ‘Token' ?

Because it include two functions, generate and validate.
Title: Re: NRS v1.7.3e
Post by: phideas on December 23, 2015, 06:58:16 pm
Small quirk in MS Exchange Booth popover text. http://imgur.com/LL827t7
Title: Re: NRS v1.7.3e
Post by: aph5 on December 24, 2015, 10:01:22 am
I have installed 1.7.3e, but got only 2 peers :(
Title: Re: NRS v1.7.3e
Post by: Brangdon on December 24, 2015, 10:42:02 am
I have installed 1.7.3e, but got only 2 peers :(
On TestNet? The number of peers on TestNet is usually very small. Currently I have 4.

On the positive side, it means I forge relatively more blocks. 174 at the moment, on a balance of 3000 NXT. However, forged fees currently stand at 1 NXT so I'm not getting rich.
Title: Re: NRS v1.7.3e
Post by: aph5 on December 24, 2015, 10:47:41 am
I have installed 1.7.3e, but got only 2 peers :(
On TestNet? The number of peers on TestNet is usually very small. Currently I have 4.

On the positive side, it means I forge relatively more blocks. 174 at the moment, on a balance of 3000 NXT. However, forged fees currently stand at 1 NXT so I'm not getting rich.

Could you paste the working peers IP here ?
I was running 1.6.x on testnet before but the blockchain stopped on 30NOV2015... so I assumed that I should update to 1.7.x. Is that correct?
Title: Re: NRS v1.7.3e
Post by: aph5 on December 24, 2015, 11:32:59 am
Ok, I have uninstalled nxt and removed all data from roaming folder, installed again and got 5 peers.
Is version 1.6.x still supported on testnet ?
Title: Re: NRS v1.7.3e
Post by: abctc on December 24, 2015, 11:36:56 am
Is version 1.6.x still supported on testnet ?
-
Only 1.7.0e is supported on testnet now. Those running 1.6.2 or older will be on a different fork, if no-one is forging on this fork it will not grow. And the nodes from the two forks will blacklist each other.
Title: Re: NRS v1.7.3e
Post by: Riker on December 24, 2015, 11:48:03 am
Is version 1.6.x still supported on testnet ?
-
Only 1.7.0e is supported on testnet now. Those running 1.6.2 or older will be on a different fork, if no-one is forging on this fork it will not grow. And the nodes from the two forks will blacklist each other.

In fact only 1.7.3e is now supported on testnet. Any other version will get stuck on an obsolete fork.
At the moment, if you are using 1.7.3e and see peers bug.airdns.org and 107.170.3.62 then you are on the right fork.
Title: Re: NRS v1.7.3e
Post by: LocoMB on December 24, 2015, 03:56:05 pm

1.7.3e  - when I try to send an encrypted message from the standard client I get a 'deadline not specified' error - what's up with that?
Title: Re: NRS v1.7.3e
Post by: Riker on December 24, 2015, 04:05:50 pm

1.7.3e  - when I try to send an encrypted message from the standard client I get a 'deadline not specified' error - what's up with that?

I can send messages without any problem. Are you using the "Send Message" function ?
Anything special about your configuration ?
Title: Re: NRS v1.7.3e
Post by: Riker on December 24, 2015, 04:06:30 pm
Small quirk in MS Exchange Booth popover text. http://imgur.com/LL827t7

Fixed, thanks for reporting !
Title: Re: NRS v1.7.3e
Post by: LocoMB on December 24, 2015, 04:19:12 pm

1.7.3e  - when I try to send an encrypted message from the standard client I get a 'deadline not specified' error - what's up with that?

I can send messages without any problem. Are you using the "Send Message" function ?
Anything special about your configuration ?

I had to clear the browser cache- this seems to be cause for all kind of bizarre behaviour (I had just gone from 1.6.2e to 1.7.3e), but now it works! Thanks!
Title: Re: NRS v1.7.3e
Post by: rkfg on December 24, 2015, 04:40:57 pm
While Data Cloud is indeed a great feature, I'm looking forward to hear a ton of woes the moment it goes stable. It's only a matter of time until something illegal pops up there and complaints about DGS promoting drugs will fade in comparison. Especially if you shuffle the money before uploading and pay the fee with those shuffled coins...
Title: Re: NRS v1.7.3e
Post by: Sabertooth on December 24, 2015, 07:07:53 pm
While Data Cloud is indeed a great feature, I'm looking forward to hear a ton of woes the moment it goes stable. It's only a matter of time until something illegal pops up there and complaints about DGS promoting drugs will fade in comparison. Especially if you shuffle the money before uploading and pay the fee with those shuffled coins...

There have been drugs offered for sale from almost the beginning. But then again it could be argued that these listings are nothing but competing platform investors trying to make NXT look bad.
Title: Re: NRS v1.7.3e
Post by: rkfg on December 24, 2015, 08:21:50 pm
Yeah, but drugs can be tolerated by many. What possibly won't be tolerated is, uhm, so called sexual content involving infants. Images are posted directly to the blockchain and then distributed among all participants so every NXT user would store such content in a completely plain unencrypted form. I'm curious how these things will be settled legally.
Title: Re: NRS v1.7.3e
Post by: coretechs on December 25, 2015, 05:29:29 am
Yeah, but drugs can be tolerated by many. What possibly won't be tolerated is, uhm, so called sexual content involving infants. Images are posted directly to the blockchain and then distributed among all participants so every NXT user would store such content in a completely plain unencrypted form. I'm curious how these things will be settled legally.

What you describe has unfortunately already occurred in the Bitcoin blockchain.  There is a huge thread on bitcointalk somewhere but I'm not about to go searching for those terms.  Other types of information appear too, some controversial, some not - http://www.righto.com/2014/02/ascii-bernanke-wikileaks-photographs.html

That is the nature of public blockchains and censorship resistant technology.  It shifts the burden of filtering content to the client, which is arguably no different than the internet itself.
Title: Re: NRS v1.7.3e
Post by: rkfg on December 25, 2015, 07:38:27 am
That's true, I'm aware of that incident. The difference is in the ease of use. Do you know how to extract that data from the Bitcoin blockchain? I can't do it right off the bat, heck, I don't even know whether it's possible using the RPC API or if it requires some database hacking. On the opposite, NXT provides the uploaded images in two clicks. You don't have to know anything, you just open the Data Cloud tab and see that there. You don't even need to search explicitly, you have all the files available immediately and can download and view them with little to no effort. That's what I'm talking about.
Title: Re: NRS v1.7.3e
Post by: crimi on December 25, 2015, 02:28:30 pm
API getState gives false info for example.

Quote
"services": [
        "HALLMARK",
        "PRUNABLE",
        "API",
        "API_SSL"
]

Both enabled API and API_SSL doesnt seem right. Server has no service API_SSL active.
Title: Re: NRS v1.7.3e
Post by: Brangdon on December 27, 2015, 11:59:24 am
That's true, I'm aware of that incident. The difference is in the ease of use. Do you know how to extract that data from the Bitcoin blockchain? I can't do it right off the bat, heck, I don't even know whether it's possible using the RPC API or if it requires some database hacking. On the opposite, NXT provides the uploaded images in two clicks. You don't have to know anything, you just open the Data Cloud tab and see that there. You don't even need to search explicitly, you have all the files available immediately and can download and view them with little to no effort. That's what I'm talking about.
I share your concern. Any suggestions what to do about it?

We could do what we did for the market place and add a warning and an extra click to enable it. Having a line in nxt.properties that could disable decoding images and videos entirely, so it can't be re-enabled from the UI, might be good too.

That said, I'm not convinced that ease of use will carry much weight in court. Simply running an archival node would probably count as distributing child porn. I'm based in the UK, where possession is an absolute offence that carries a jail sentence. If/when it happens I'll probably just shut down my node for a few weeks and then make it non-archival when it starts up again. If it happens too often I'll stop running a node entirely.
Title: Re: NRS v1.7.3e
Post by: Sebastien256 on December 27, 2015, 05:26:32 pm
That's true, I'm aware of that incident. The difference is in the ease of use. Do you know how to extract that data from the Bitcoin blockchain? I can't do it right off the bat, heck, I don't even know whether it's possible using the RPC API or if it requires some database hacking. On the opposite, NXT provides the uploaded images in two clicks. You don't have to know anything, you just open the Data Cloud tab and see that there. You don't even need to search explicitly, you have all the files available immediately and can download and view them with little to no effort. That's what I'm talking about.
I share your concern. Any suggestions what to do about it?

We could do what we did for the market place and add a warning and an extra click to en able it. Having a line in nxt.properties that could disable decoding images and videos entirely, so it can't be re-enabled from the UI, might be good too.

That said, I'm not convinced that ease of use will carry much weight in court. Simply running an archival node would probably count as distributing child porn. I'm based in the UK, where possession is an absolute offence that carries a jail sentence. If/when it happens I'll probably just shut down my node for a few weeks and then make it non-archival when it starts up again. If it happens too often I'll stop running a node entirely.

Archival node of not, it does not make a real difference because normal node will still hold the "sensitive" data for a certain time period (90 days by default).

I agree that a few agreement click as for the marketplace would be good.
Title: Re: NRS v1.7.3e
Post by: blackyblack1 on December 27, 2015, 07:45:10 pm
Bug report: OPEN API service not running when using IPv6 bind address.

Example:

Code: [Select]
nxt.allowedBotHosts=*
nxt.apiServerHost=0.0.0.0
nxt.apiServerCORS=true

API service is active.

Code: [Select]
nxt.allowedBotHosts=*
nxt.apiServerHost=[::]
nxt.apiServerCORS=true

API service is not active.

Code: [Select]
nxt.allowedBotHosts=*
nxt.apiServerHost=[::1]
nxt.apiServerCORS=true

API service is not active.
Title: Re: NRS v1.7.3e
Post by: Jean-Luc on December 27, 2015, 09:09:46 pm
If you set nxt.apiServerHost=0.0.0.0 it will listen on all interfaces, including IPv6. Is there a reason not to use 0.0.0.0? The jetty documentation for setHost, which is where this parameter is used, says if it is 0.0.0.0 or null, it binds to all interfaces, doesn't mention how [::] is treated.
http://download.eclipse.org/jetty/9.3.6.v20151106/apidocs/org/eclipse/jetty/server/AbstractNetworkConnector.html#setHost-java.lang.String-
Title: Re: NRS v1.7.3e
Post by: blackyblack1 on December 27, 2015, 09:28:57 pm
If you set nxt.apiServerHost=0.0.0.0 it will listen on all interfaces, including IPv6. Is there a reason not to use 0.0.0.0? The jetty documentation for setHost, which is where this parameter is used, says if it is 0.0.0.0 or null, it binds to all interfaces, doesn't mention how [::] is treated.
http://download.eclipse.org/jetty/9.3.6.v20151106/apidocs/org/eclipse/jetty/server/AbstractNetworkConnector.html#setHost-java.lang.String-
The author of original bug report told me he is trying to setup a node for Hyperboria. Maybe there is a reason to bind on [::] address.
Title: Re: NRS v1.7.3e
Post by: qq2536007339 on December 28, 2015, 03:47:26 am
What's the meaning of HK,PE,AI,AL in Services column at Peers page? Can someone explain to me? Thanks in advance.
Title: Re: NRS v1.7.3e
Post by: blackyblack1 on December 28, 2015, 06:00:01 am
If you set nxt.apiServerHost=0.0.0.0 it will listen on all interfaces, including IPv6. Is there a reason not to use 0.0.0.0? The jetty documentation for setHost, which is where this parameter is used, says if it is 0.0.0.0 or null, it binds to all interfaces, doesn't mention how [::] is treated.
http://download.eclipse.org/jetty/9.3.6.v20151106/apidocs/org/eclipse/jetty/server/AbstractNetworkConnector.html#setHost-java.lang.String-
Looks like 0.0.0.0 option works for him. Is it possible to include some additional info (that IPv6 networks are supported) in the parameter description ?
Title: Re: NRS v1.7.3e
Post by: blackyblack1 on December 28, 2015, 06:00:41 am
What's the meaning of HK,PE,AI,AL in Services column at Peers page? Can someone explain to me? Thanks in advance.
Let me guess. HK = HALLMARK, PE = PRUNABLE, AI = API, AL = API_SSL.
Title: Re: NRS v1.7.3e
Post by: qq2536007339 on December 28, 2015, 07:45:22 am
Let me guess. HK = HALLMARK, PE = PRUNABLE, AI = API, AL = API_SSL.

That was a very good guess,thank you and one applaud for you.
Title: Re: NRS v1.7.3e
Post by: Brangdon on December 28, 2015, 11:55:25 am
Archival node of not, it does not make a real difference because normal node will still hold the "sensitive" data for a certain time period (90 days by default).
That's why I'd need to take the node offline (and delete the database) until it expires. It can be set to expire after a couple of weeks.
Title: Re: NRS v1.7.3e
Post by: Sebastien256 on December 28, 2015, 12:19:26 pm
Data cloud feature is cool. Good idea to have make a gui for that directly into the core wallet.  :)
Title: Re: NRS v1.7.3e
Post by: Sebastien256 on December 28, 2015, 12:33:19 pm
When a file is renew multiple time by multiple user, do the extend time period before the data is pruned is cummulative? I hope so.
Title: Re: NRS v1.7.3e
Post by: blackyblack1 on December 28, 2015, 07:10:07 pm
If you set nxt.apiServerHost=0.0.0.0 it will listen on all interfaces, including IPv6. Is there a reason not to use 0.0.0.0? The jetty documentation for setHost, which is where this parameter is used, says if it is 0.0.0.0 or null, it binds to all interfaces, doesn't mention how [::] is treated.
http://download.eclipse.org/jetty/9.3.6.v20151106/apidocs/org/eclipse/jetty/server/AbstractNetworkConnector.html#setHost-java.lang.String-
Looks like 0.0.0.0 option works for him. Is it possible to include some additional info (that IPv6 networks are supported) in the parameter description ?
Here is a description for peerServerHost parameter:

Code: [Select]
# Host interface on which to listen for peer networking requests, default all.
# Use 0.0.0.0 to listen on all IPv4 interfaces or :: to listen on all IPv4 and
# IPv6 interfaces
nxt.peerServerHost=0.0.0.0

I think it is wrong based on our previous discussion.
elective-stereophonic
elective-stereophonic
assembly
assembly