Nxt Forum

Nxt Discussion => Nxt Software Releases => Official Nxt Releases => Topic started by: Jean-Luc on November 29, 2015, 10:59:59 pm

Title: NRS v1.7.0e
Post by: Jean-Luc on November 29, 2015, 10:59:59 pm
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Release 1.7.0e

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

sha256:

431f0bc71e4ff4734cac1df493e89d9af4cd8d129db448ae1ab0cdadeb4a6617  nxt-client-1.7.0e.zip

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

sha256:

99e19887bb41a52197062f78e68c798eefb999c2db0e73d38100ef0b3c8588b9  nxt-client-1.7.0e.jar

https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.7.0e.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 release. The new features will be activated at block
483000 on testnet (Nov 30) and 621000 on production (estimated Jan 21, 2016).

All testnet nodes are required to upgrade to this release. Those that don't
will remain on a fork.

Production nodes will need to upgrade to the stable 1.7 version once it is
released (expected before end of December), but in any case before the
hardfork scheduled for block 621000.


New features:

Coin Shuffling. This feature is based on the paper by Tim Ruffing et al,
http://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf .

Coin shuffling can be used to perform mixing of NXT, MS currencies (unless
created as non-shuffleable), or AE assets. Any account can create a new
shuffling, specifying the holding to be shuffled, the shuffle amount, number
of participants required, and registration deadline. This is done using the
shufflingCreate API. The subsequent shuffling steps can be done either
manually, by using the shufflingRegister (for accounts other than the
creator), shufflingProcess, shufflingVerify or shufflingCancel APIs, or, much
more conveniently, by starting an automated Shuffler, using the startShuffler
API. Once started, the Shuffler monitors the blockchain state for transactions
relevant to the specified shuffle, and automatically submits the required
transactions on behalf of the user, performing shuffle processing,
verification, or cancellation as needed. To do this, the Shuffler is required
to keep the user secret phrase in memory, therefore it should be run on a
trusted local machine only. A restart or a crash of the node requires the
shuffler to be started again using the startShuffler API, as it should never
save the user secret phrase on disk.

To participate in a shuffling, a deposit of 1000 NXT is needed, in addition
to the amount of currency or asset being shuffled. Or if shuffling NXT, the
amount of the shuffle must exceed this 1000 NXT minimum. If the shuffling
completes successfully, this amount is added to the recipient account balance,
to allow it to send outgoing transactions (as it is required that only new,
unused accounts are specified as recipients). If the shuffle fails due to
a registered participant failing to participate as required, or intentionally
submitting false data, the participant responsible for the shuffle
cancellation is penalized by retaining this deposit and sending it to the
forgers of the shuffle finish block and the previous three blocks instead.
If a shuffle is cancelled because the required number of participants is not
met, nobody is penalized and all deposits are refunded. On testnet, the deposit
and penalty is 7 NXT only.

After shuffling registration is complete, participants must submit processing
data within a 100 blocks period each (10 blocks on testnet). For the
verification and blame phase, the total allowance for all participants is 100
+ numberOfParticipants blocks (again reduced to 10 + n blocks on testnet).
Full blocks are not counted towards the limit. If at any stage the deadline is
reached without some participant submitting the next required transaction, the
shuffling is cancelled at this participant's fault. It is therefore critical
that after registering for a shuffling, the shuffler started is left running
until its successful completion. If the node must be restarted, all previously
running shufflers must be started again manually.

Query APIs to retrieve currently running shufflers, shufflings, and shuffling
participants are: getAllShufflings, getAccountShufflings,
getAssignedShufflings, getHoldingShufflings, getShufflers, getShuffling, and
getShufflingParticipants.

If desired, finished shufflings can be automatically deleted from the database
if the nxt.deleteFinishedShufflings property is set to true (default is false).

The fee for creating a shuffling or registering in one is 1 NXT, for the
shuffling process or shuffling cancel transactions 10 NXT, and for the verify
transaction 1 NXT.


Account control for phased transactions. Any account can be restricted to only
be allowed to issue phased transactions subject to a specific voting model.
This is achieved by the account submitting a setPhasingOnly transaction using
the setPhasingOnlyControl API. The getPhasingOnlyControl API can be used to
retrieve the status of an account phasing control, and
getAllPhasingOnlyControls to get all accounts subject to phasing control with
their respective restrictions.

Once set, the phasing only account control can only be disabled or changed
with another setPhasingOnly transaction, itself subject to the currently set
phasing restrictions.

Note that by-transaction and by-hash voting models are not allowed for phasing
control, and setting voting model to none is used to disable the control.

To prevent deadlocks due to cyclic account control restrictions, approval
transactions themselves (PhasingVoteCasting) are not subject to phasing only
account control.

When setting phasing account control, a maximum fees total can be specified,
limiting the total fees for currently pending phased transactions of the
controlled account, and limits can be placed on minimum and maximum phasing
duration allowed.

Transactions of accounts subject to phasing account control with restriction
on maximum fees are throttled at one per account per block.


Immediate release of phased transactions on approval. Phased transactions with
a voting model that does not depend on account balance (such as by-transaction
or by-hash), or by-account with no minimum balance and with a whitelist, will
be released before their finish height as soon as approved (in the block in
which the transaction causing their approval is executed), if possible. Such
early finish is guaranteed for transaction types known to be phasing safe. For
others, if the early finish does not succeed due to the transaction failing
validation at this height or conflicting with another transaction in the same
block, a second, final release attempt will be performed at finish height.


New base target adjustment algorithm. Average block times will be 60 s, with
1440 blocks per day. Block times should practically never exceed 10 min.

Limit of 1000 NXT on minimum forging balance. This applies to the total of the
account own guaranteed balance plus any balances leased to it, but not to each
individual balance lease. An account with balance lower than the limit can
still lease its balance to another.


Account properties. Those are name / value pairs that can be set on any
account (except Genesis), by either the account owner, or by another account.
Names are limited to 32 characters, and values to 160 characters. Names are
unique per account and per setter account, but not globally unique. Account
properties cannot be transferred between accounts. The setter of an account
property can edit it by replacing its value with another. Either the setter,
or the recipient (if different) of an account property can delete it. There
is no limit on the number of properties an account can have. Fee for setting
account property is 1 NXT for value up to 32 chars, with additional 1 NXT fee
for every 32 chars after that.

Account properties are managed using the setAccountProperty and
deleteAccountProperty APIs. To query the properties of an account, or those
set by an account, the getAccountProperties API can be used.


Singleton assets. Issuing an asset with a quantity of 1, decimals 0, and
description length not exceeding 160 characters, will require a base minimum
fee of 1 NXT only, instead of the regular 1000 NXT asset issuance fee. For
description of more than 32 chars, an extra 1 NXT fee is added for each 32
chars. Asset name for singleton assets is limited to 10 chars, same as for
regular assets.

Throttling of unique resource allocation transactions. Asset issuance
(excluding singleton assets), monetary system currency issuance, and alias
assignment (excluding re-assignment), will be limited to only one transaction
of each type accepted per block.


Spreading back block fees for asset and currency issuance. The transaction
fees for asset (excluding singleton assets) and currency issuance will be
split between the forgers of the current and the previous three blocks in a
4:3:2:1 ratio.


Prunable plain and prunable encrypted message attachments both allowed in the
same transaction. The maximum data size for each such attachment is 42 kbytes,
but when coexisting in the same transaction the sum of the two is still being
limited by the maximum payload size of 44880 bytes.


Peers that provide http or https API access open to anyone, configured with
nxt.apiServerHost=0.0.0.0 and nxt.allowedBotHosts=* , are now labelled as
providing a service, API or API_SSL, and can be found using the getPeers API
with the corresponding "service" parameter. This API has been modified to
accept multivalued "service" parameter, returning peers that match all
requested services. The ports on which the open API access is running are
included in the peer info of peers providing those services as apiPort and
apiSSLPort fields.


Incompatible changes:

Deletion of asset shares will be performed as a separate AssetDelete
transaction type instead of as sending the shares to Genesis. Sending shares
to Genesis will no longer be allowed. A new API, getAssetDeletes has been
added to retrieve asset deletions, as using the getAssetTransfers API to find
transfers to Genesis account no longer can be used for that purpose. There is
also a new API, getExpectedAssetDeletes, to get asset deletes expected in the
next block, analogous to getExpectedAssetTransfers.

Since both prunable plain and prunable encrypted messages can now be added to
the same transaction, the APIs getAllPrunableMessages, getPrunableMessage, and
getPrunableMessages cannot continue to use just a single "isText" boolean field
in the JSON response to indicate if the prunable message is text or binary.
For all prunable plain messages, a new "messageIsText" boolean field is added,
and for all prunable encrypted messages, a new "encryptedMessageIsText" boolean
field is added in the response of the above APIs, for each message.
For backwards compatibility, the "isText" field will continue to be added, but
only for transactions that have either plain, or encrypted, prunable message
attachment, not for those that have both.
This change does not affect the attachment JSON returned from getTransaction
API, as there are already separate messageIsText and encryptedMessage.isText
fields there.


Fees and size limit changes. Several transaction types or attachments will
have new fees and size limits, to encourage users to utilize the prunable
versions when available, and to make fees proportionate to actual blockchain
space consumed.

Aliases:
Base fee 2 NXT, with 2 NXT additional fee for each 32 chars of name plus URI
total length, after the first 32 chars. Name and URI size limits remain at
100 and 1000 chars respectively.

Messages and EncryptedMessages (non-prunable):
Maximum length reduced to 160 bytes. 1 NXT fee for each 32 bytes after the
first 32 bytes. For encrypted messages, the length is measured excluding the
nonce and the 16 byte AES initialization vector, and to account for those
there is an extra fee of 1 NXT.
Fees and size limit for prunable messages remain unchanged.

AccountInfo:
Base fee 1 NXT, with 2 NXT additional fee for each 32 chars of name plus
description total length, after the first 32 chars. Name and description size
limits remain at 100 and 1000 chars. AccountInfo transactions throttled at
one per block.

Polls:
Base fee 10 NXT for polls with up to 20 options, and total size of poll name
plus poll description plus total option length not exceeding 320 chars. For
each option above 20, an additional fee of 1 NXT, and for each 32 chars after
320, an additional fee of 2 NXT. Poll creation throttled to one per block.
Name, description, and option length limits remain at 100, 1000, and 100 chars
respectively.

DGS Listing:
Base fee 2 NXT, with 2 NXT additional fee for each 32 chars of name plus
description total length, after the first 32 chars. Name and description size
limits remain at 100 and 1000 max. DGS Listing throttled at one per block.

DGS Delivery:
Base fee 1 NXT, with 2 NXT additional fee for each 32 bytes of encrypted goods
data after the first 32 bytes, nonce and AES initialization bytes excluded.
Encrypted goods data size limit remains 1000 bytes.

Phasing:
In addition to the current fee for phasing (1 NXT for balance independent,
20 NXT otherwise), 1 NXT will be added for each 32 bytes of hashedSecret or
linkedFullHash fields.

Referenced transactions:
An extra fee of 1 NXT for the 32 byte referencedTransactionFullHash if set,
i.e. if the transaction is using the referenced transactions feature.


To facilitate migration of legacy client code to the new fees, if the property
nxt.correctInvalidFees=true has been set in nxt.properties (default is false),
the server will automatically replace insufficient fees for submitted unsigned
transactions with the minimum fee needed, depending on the transaction, as if
feeNQT=0 has been specified. Fees exceeding the minimum, or fees for already
signed transactions, will not be corrected.

This release will perform a blockchain rescan on first start.


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

iQIcBAEBCgAGBQJWW3D0AAoJENqvaxkWiP4Z5kwQAMSyWK1g8SdtYLzN6GCc8dGV
vIRCPOGOfZn1WfzfJwTY1itSg2EfFp88c7I9BaHex6QT++37YA4wmtzXE3cyQ+zP
gGAj37IbcR/Tj4Y9L9BYjmVnoJAxvKx2/X1U+GkQf2k1XVr3PINtSlCbbedU1oMc
maS83CTgBO2OcCKEhP+zjwxAIBIbTSRPFdsIUB76yAD20tEdI7lbS7QRGGVyedoC
+AfNVwmgYRtXJiWL8kN9bTj6nc6MVEJ0XwNkPStgS6sk2u0w0iacbHDId5NCDT/g
kXlkKBaatSV5EfWf8echPJCGX5X2xuhUJ2YNIFMXtRxseqgaEcPcmFStacH2GlGP
stiO+ot7eYA3A9tO9kjkAq8stToY2SIhd42SoNhPItYPb2UCEzEc8tAPz9l/Ez37
HzglxdjW2vFQUnn5OMwPt/xUBP+ncb0Rx9YGCH4ugns8tT77sHAitKvUqqq9Q0sC
t8nmeFaFcQ+x5U1XB7qni4MW+fD5Q4rGO3uyvwhGoDV9N22yQQt4+jMKEC/wqerA
ej5wLau8aEXOY7HajPsesOVlgvFVLFsxX6gq25sVoBd/IBOQdZblGF8WkuIbcVdq
6euQ7Prrm3jEwkdkmWxqYnGekOeCn7giIYzZkR3BRI9VIE07Sn+CwM/axuX5sVxM
F8RLOjPY+wrWs01crjzH
=VYpu
-----END PGP SIGNATURE-----
Title: Re: NRS v1.7.0e
Post by: Sebastien256 on November 29, 2015, 11:07:10 pm
Thanks as usual and keep up the good work!  :-*
Title: Re: NRS v1.7.0e
Post by: slothbag on November 29, 2015, 11:19:57 pm
Woah, now thats a changelog!

Well done.
Title: Re: NRS v1.7.0e
Post by: coretechs on November 30, 2015, 12:20:45 am
JL, can you confirm the block time adjustments are the same as the code specified here?
https://nxtforum.org/nxt-improvement-proposals/fixing-the-blocktimes/msg195694/#msg195694

Or does it use the default values in the BaseTargetTest.java that shipped with 1.6.2?

Code: [Select]
#:~/nxt/src/java/nxt/tools$ diff BaseTargetTest.java BaseTargetTestForum.java
36,37c36,37
<     private static final int MIN_BLOCKTIME_LIMIT = 54;
<     private static final int MAX_BLOCKTIME_LIMIT = 66;
---
>     private static final int MIN_BLOCKTIME_LIMIT = 53;
>     private static final int MAX_BLOCKTIME_LIMIT = 67;
39c39
<     private static final int GAMMA = 70;
---
>     private static final int GAMMA = 64;
45,46c45,46
<     private static final int SMA_N = 6;
<     private static final int FREQUENCY = 3;
---
>     private static final int SMA_N = 3;
>     private static final int FREQUENCY = 2;
Title: Re: NRS v1.7.0e
Post by: qq2536007339 on November 30, 2015, 01:59:37 am
Great,updated,blockchain rescaning now.
Title: Re: NRS v1.7.0e
Post by: Tosch110 on November 30, 2015, 02:05:48 am
Thanks! I will go through and help testing. I am looking forward to the new features!

Edit: Installing and rescanning blockchain took ~1 hours. Everything worked fine.
Title: Re: NRS v1.7.0e
Post by: Riker on November 30, 2015, 05:41:08 am
MAC OS/X installer uploaded https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-installer-1.7.0.dmg
The installer is signed using digital signature by "Stichting NXT"
Title: Re: NRS v1.7.0e
Post by: Riker on November 30, 2015, 06:38:03 am
MAC OS/X installer uploaded https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-installer-1.7.0.dmg
The installer is signed using digital signature by "Stichting NXT"

Instructions in short:
1. Download the disk image file, open it and drag the nxt-installer app to the Applications folder
2. Invoke the nxt-installer app from the Applications folder to launch the standard installer
3. Install the NXT server to any folder, the default is /Applications/NXT
4. Start the runtime by invoking run.command from the installation folder (you can double click this file from the finder)
5. The blockchain is created by default in the user's folder
Title: Re: NRS v1.7.0e
Post by: martismartis on November 30, 2015, 07:10:14 am
1. Just to be sure, is it OK to run public node and local note with 1.7.0.e on mainnet?
2. Are there some plans for coin shuffling infographics  for not very tech savy users?
Title: Re: NRS v1.7.0e
Post by: farl4bit on November 30, 2015, 07:15:42 am
Thank!

Question: Jean-Luc wants higher fees to prevent spam, but why costs a singleton asset only 1 NXT to create? I bet that sqatters will register a lot of names after the release, such as happened with the MS, although they are not unique. From user experience point-of-view it will look like Nxt is spammed again.
Title: Re: NRS v1.7.0e
Post by: dude on November 30, 2015, 07:38:45 am
Throttling of unique resource allocation transactions. Asset issuance
(excluding singleton assets), monetary system currency issuance, and alias
assignment (excluding re-assignment), will be limited to only one transaction
of each type accepted per block.

Why limit creation of aliases to 1 per block? I know they are not used much, but I don't see a reason for it?
Title: Re: NRS v1.7.0e
Post by: NxtSwe on November 30, 2015, 07:44:19 am
As usual, Impressive.
Hopefully we can manage to teach the rest of the world about this fabulous and rich crypto platform.
Title: Re: NRS v1.7.0e
Post by: abctc on November 30, 2015, 08:04:33 am
Thank you so much!
Testnode successfully updated.
Title: Re: NRS v1.7.0e
Post by: coinomat on November 30, 2015, 08:38:00 am
Account control is very cool feature, congrats!
Title: Re: NRS v1.7.0e
Post by: starik69 on November 30, 2015, 09:03:35 am
MAC OS/X installer uploaded https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-installer-1.7.0.dmg
The installer is signed using digital signature by "Stichting NXT"
Why it is 1.7.0 not 1.7.0e? ???
It is confusing :'(
Title: Re: NRS v1.7.0e
Post by: lurker10 on November 30, 2015, 09:51:17 am
Do you have bug bounties for this release? :)
Title: Re: NRS v1.7.0e
Post by: yassin54 on November 30, 2015, 10:34:22 am
Thanks and Tweeted!! https://twitter.com/MagicNxt/status/671275777384648704  ;D
Title: Re: NRS v1.7.0e
Post by: qq2536007339 on November 30, 2015, 11:05:13 am
MAC OS/X installer uploaded https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-installer-1.7.0.dmg
The installer is signed using digital signature by "Stichting NXT"
Why it is 1.7.0 not 1.7.0e? ???
It is confusing :'(

Because it's a "experimental release",that's the e for.
Title: Re: NRS v1.7.0e
Post by: starik69 on November 30, 2015, 11:20:28 am
MAC OS/X installer uploaded https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-installer-1.7.0.dmg
The installer is signed using digital signature by "Stichting NXT"
Why it is 1.7.0 not 1.7.0e? ???
It is confusing :'(

Because it's a "experimental release",that's the e for.
I know. But Mac version doesnt have this "e" - thats about what i am asking ::)
Title: Re: NRS v1.7.0e
Post by: Riker on November 30, 2015, 12:13:32 pm
Why it is 1.7.0 not 1.7.0e? ???
It is confusing :'(

This is a technical limitation of the javapackager tool we are using (probably inherited from OS/X itself), it only accepts numeric version numbers when creating the disk image.
The actual package content still uses 1.7.0e as the version id and that's what you'll see in the log and the wallet.
Title: Re: NRS v1.7.0e
Post by: Riker on November 30, 2015, 12:19:47 pm
1. Just to be sure, is it OK to run public node and local note with 1.7.0.e on mainnet?
2. Are there some plans for coin shuffling infographics  for not very tech savy users?

1. Yes, but bare in mind that this is essentially a beta version. The new features are already enabled on testnet and will become enabled on mainnet on block 621000.
2. If someone would like to create one I'll be glad to assist.
Title: Re: NRS v1.7.0e
Post by: Riker on November 30, 2015, 12:25:58 pm
Thank!

Question: Jean-Luc wants higher fees to prevent spam, but why costs a singleton asset only 1 NXT to create? I bet that sqatters will register a lot of names after the release, such as happened with the MS, although they are not unique. From user experience point-of-view it will look like Nxt is spammed again.

Assets (unlike currencies and aliases) do not enforce a unique name, you can allocate all the common asset names but this won't prevent anyone else from using the same name.
Asset issuers should always promote the asset id and not the asset name which should only be used for reference.
Title: Re: NRS v1.7.0e
Post by: petko on November 30, 2015, 12:40:33 pm
Why limit creation of aliases to 1 per block? I know they are not used much, but I don't see a reason for it?

It's a part of the forgers spam prevention - https://nxtforum.org/general/preventing-spam-by-forgers/msg196405/#msg196405
Title: Re: NRS v1.7.0e
Post by: CryptKeeper on November 30, 2015, 02:54:45 pm
If I want to do a tx from a "controlled" account, I have to select a finish block height which is within the account control range.
There is even a nice error message if you don't enter the correct values, but it would be better if you had a valid default to start with and maybe a slider with which you can only go as far as the account control allows to. Please have a look at the hardcopy and you will understand what I mean:

(http://i.imgur.com/xparu68.png?1)

Current block height is 483180 which isn't valid and neither is the default value in the input field of 490180. The "+" and "-" buttons are useless here because they work in intervals of 500.

This is not an error, but it lacks user friendliness and can be improved.
Title: Re: NRS v1.7.0e
Post by: BTCDDev on November 30, 2015, 03:23:41 pm
Code: [Select]
2015-11-30 10:21:40 INFO: nxt.dbDefaultLockTimeout = "60"
2015-11-30 10:21:40 FINE: Database jdbc url set to jdbc:h2:nxt_db/nxt;DB_CLOSE_ON_EXIT=FALSE;MVCC=TRUE;CACHE_SIZE=262144 username sa
2015-11-30 10:21:53 SEVERE: org.h2.jdbc.JdbcSQLException: General error: "java.lang.RuntimeException: page[22] data leaf table:387 T387 entries:8 parent:293685 keys:[1730203, 1730204, 1730205, 1730206, 1730207, 1730208, 1730209, 1730210] offsets:[1849, 1623, 1422, 1197, 972, 747, 420, 194] parent 293685 expected 1409519" [50000-176]
java.lang.RuntimeException: org.h2.jdbc.JdbcSQLException: General error: "java.lang.RuntimeException: page[22] data leaf table:387 T387 entries:8 parent:293685 keys:[1730203, 1730204, 1730205, 1730206, 1730207, 1730208, 1730209, 1730210] offsets:[1849, 1623, 1422, 1197, 972, 747, 420, 194] parent 293685 expected 1409519" [50000-176]
at nxt.db.a.a(Unknown Source)
at nxt.ea.a(Unknown Source)
at nxt.ez.<clinit>(Unknown Source)
at nxt.Nxt.e(Unknown Source)
at nxt.Nxt.main(Unknown Source)
Caused by: org.h2.jdbc.JdbcSQLException: General error: "java.lang.RuntimeException: page[22] data leaf table:387 T387 entries:8 parent:293685 keys:[1730203, 1730204, 1730205, 1730206, 1730207, 1730208, 1730209, 1730210] offsets:[1849, 1623, 1422, 1197, 972, 747, 420, 194] parent 293685 expected 1409519" [50000-176]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:344)
at org.h2.message.DbException.get(DbException.java:167)
at org.h2.message.DbException.convert(DbException.java:294)
at org.h2.engine.Database.openDatabase(Database.java:291)
at org.h2.engine.Database.<init>(Database.java:254)
at org.h2.engine.Engine.openSession(Engine.java:57)
at org.h2.engine.Engine.openSession(Engine.java:164)
at org.h2.engine.Engine.createSessionAndValidate(Engine.java:142)
at org.h2.engine.Engine.createSession(Engine.java:125)
at org.h2.engine.Engine.createSession(Engine.java:27)
at org.h2.engine.SessionRemote.connectEmbeddedOrServer(SessionRemote.java:331)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:107)
at org.h2.jdbc.JdbcConnection.<init>(JdbcConnection.java:91)
at org.h2.Driver.connect(Driver.java:74)
at org.h2.jdbcx.JdbcDataSource.getJdbcConnection(JdbcDataSource.java:191)
at org.h2.jdbcx.JdbcDataSource.getXAConnection(JdbcDataSource.java:354)
at org.h2.jdbcx.JdbcDataSource.getPooledConnection(JdbcDataSource.java:386)
at org.h2.jdbcx.JdbcConnectionPool.getConnectionNow(JdbcConnectionPool.java:228)
at org.h2.jdbcx.JdbcConnectionPool.getConnection(JdbcConnectionPool.java:200)
... 5 more
Caused by: java.lang.RuntimeException: page[22] data leaf table:387 T387 entries:8 parent:293685 keys:[1730203, 1730204, 1730205, 1730206, 1730207, 1730208, 1730209, 1730210] offsets:[1849, 1623, 1422, 1197, 972, 747, 420, 194] parent 293685 expected 1409519
at org.h2.message.DbException.throwInternalError(DbException.java:241)
at org.h2.index.PageDataIndex.getPage(PageDataIndex.java:247)
at org.h2.index.PageDataNode.getLastKey(PageDataNode.java:215)
at org.h2.index.PageDataNode.getLastKey(PageDataNode.java:215)
at org.h2.index.PageDataNode.getLastKey(PageDataNode.java:215)
at org.h2.index.PageDataIndex.<init>(PageDataIndex.java:88)
at org.h2.table.RegularTable.<init>(RegularTable.java:84)
at org.h2.store.PageStore.addMeta(PageStore.java:1693)
at org.h2.store.PageStore.readMetaData(PageStore.java:1624)
at org.h2.store.PageStore.recover(PageStore.java:1406)
at org.h2.store.PageStore.openExisting(PageStore.java:368)
at org.h2.store.PageStore.open(PageStore.java:289)
at org.h2.engine.Database.getPageStore(Database.java:2366)
at org.h2.engine.Database.open(Database.java:657)
at org.h2.engine.Database.openDatabase(Database.java:260)
... 20 more
2015-11-30 10:21:53 INFO: Shutting down...
2015-11-30 10:21:53 INFO: nxt.adminPassword not defined

Title: Re: NRS v1.7.0e
Post by: TwinWinNerD on November 30, 2015, 04:32:22 pm
Thank!

Question: Jean-Luc wants higher fees to prevent spam, but why costs a singleton asset only 1 NXT to create? I bet that sqatters will register a lot of names after the release, such as happened with the MS, although they are not unique. From user experience point-of-view it will look like Nxt is spammed again.

Where does it say that singelton asset names are unique?

edit: oh ryker already ellaborated.
Title: Re: NRS v1.7.0e
Post by: petko on November 30, 2015, 04:45:15 pm
This is not an error, but it lacks user friendliness and can be improved.

Indeed! I'll think how to improve it in the next version, maybe I'll clamp the default value and the values that can be set with the (+) and (-) buttons
Title: Re: NRS v1.7.0e
Post by: lurker10 on November 30, 2015, 05:16:20 pm
Code: [Select]
Cannot check shuffler status. Incorrect administrator password. (the specified password does not match nxt.adminPassword)
Code: [Select]
Incorrect administrator password. (the specified password does not match nxt.adminPassword)
I have set nxt.adminPassword in the properties file, is there something else I missed?
Title: Re: NRS v1.7.0e
Post by: Riker on November 30, 2015, 05:29:21 pm
Code: [Select]
Cannot check shuffler status. Incorrect administrator password. (the specified password does not match nxt.adminPassword)
Code: [Select]
Incorrect administrator password. (the specified password does not match nxt.adminPassword)
I have set nxt.adminPassword in the properties file, is there something else I missed?
You need to also set the admin password in the wallet settings under the cog wheel
Title: Re: NRS v1.7.0e
Post by: CryptKeeper on November 30, 2015, 05:52:31 pm
This is not an error, but it lacks user friendliness and can be improved.

Indeed! I'll think how to improve it in the next version, maybe I'll clamp the default value and the values that can be set with the (+) and (-) buttons

Thanks. Best default value for finish height would be (current block + account control range) IMHO.
Title: Re: NRS v1.7.0e
Post by: BTCDDev on November 30, 2015, 06:18:45 pm
Mine immediately shuts down.
Title: Re: NRS v1.7.0e
Post by: qq2536007339 on December 01, 2015, 07:15:25 am
After update,testnet stuck on block 483001,and I'm not alone.
https://nxtforum.org/testnet/testnet-not-working/msg202308/?topicseen#msg202308

Seems hardfork in testnet is too early,many nodes didn't update yet.

Title: Re: NRS v1.7.0e
Post by: Jean-Luc on December 01, 2015, 07:51:16 am
JL, can you confirm the block time adjustments are the same as the code specified here?
https://nxtforum.org/nxt-improvement-proposals/fixing-the-blocktimes/msg195694/#msg195694

Or does it use the default values in the BaseTargetTest.java that shipped with 1.6.2?

The values right now are as in that post:
Code: [Select]
    private static final long MIN_BASE_TARGET = Constants.INITIAL_BASE_TARGET * 9 / 10;
    private static final long MAX_BASE_TARGET = Constants.isTestnet ? Constants.MAX_BASE_TARGET : Constants.INITIAL_BASE_TARGET * 50;
    private static final int MIN_BLOCKTIME_LIMIT = 53;
    private static final int MAX_BLOCKTIME_LIMIT = 67;
    private static final int GAMMA = 64;
    private static final int SMA_N = 3;
    private static final int FREQUENCY = 2;

At the time I settled on those values because they seemed to give slightly better standard deviation and maximum blocktime, but did those changes on the 1.7 branch only.
Title: Re: NRS v1.7.0e
Post by: lurker10 on December 01, 2015, 04:02:32 pm
Is it possible to show current/total in the Participant count? It saves a click on the shuffling to check status.
Title: Re: NRS v1.7.0e
Post by: stdset on December 01, 2015, 08:07:04 pm
Great work. This release is probaly second only to the AE release. Or maybe it's even the greatest NXT improvement ever.
I hope to see apps applying power of phased transactions to real world use cases. That's what will drive NXT market cap to the Moon.
Title: Re: NRS v1.7.0e
Post by: Eveready on December 02, 2015, 12:50:32 am
Just tested out a cool use case - set up a mandatory approval account with self as the approver. This way you get to double confirm your transactions (an indirect undo function), but it'll cost you 2+1 NXT for a simple send ;D
Title: Re: NRS v1.7.0e
Post by: CryptKeeper on December 02, 2015, 07:43:14 am
Just tested out a cool use case - set up a mandatory approval account with self as the approver. This way you get to double confirm your transactions (an indirect undo function), but it'll cost you 2+1 NXT for a simple send ;D

Do you mean "self" as the same account? I've tested with another account I control and that works fine (though gui could need to be polished in terms of usability). It's real multi-sig.

IMHO 3 NXT is not much if you could secure a substantial amount!
Title: Re: NRS v1.7.0e
Post by: Eveready on December 02, 2015, 08:03:55 am
Just tested out a cool use case - set up a mandatory approval account with self as the approver. This way you get to double confirm your transactions (an indirect undo function), but it'll cost you 2+1 NXT for a simple send ;D

Do you mean "self" as the same account? I've tested with another account I control and that works fine (though gui could need to be polished in terms of usability). It's real multi-sig.

IMHO 3 NXT is not much if you could secure a substantial amount!

Yes. Same account. It works bcos approving a transaction (Approval Request) is not covered by the Mandatory Approval status, even when approving for other accounts (ie if your account has mandatory approval status, you can still approve other users' approval requests without requiring your whitelisted accounts approving your approval). So if ppl are paranoid about doing a fat finger send from a large account, or are asking for an Undo feature,  this blockchain-based double confirmation account might do the trick.
Title: Re: NRS v1.7.0e
Post by: lurker10 on December 02, 2015, 10:15:09 am
I was able to submit a shuffling registration for the asset I don't have, is this correct behavior? My account is not in the registration list, only browser message popped up and was logged that shuffler was started, did I get in or not after all?
Title: Re: NRS v1.7.0e
Post by: NxtSwe on December 02, 2015, 03:22:15 pm
A question about the getHoldingShufflings api function.
Is it expected to return empty array if you don't specify any holding?
Example: http://localhost:6876/nxt?requestType=getHoldingShufflings&includeFinished=true

While if I add on a holding parameter, I get result back.
Example: http://localhost:6876/nxt?requestType=getHoldingShufflings&holding=9836948456938609454&includeFinished=true

This indicates that the holding parameter is required, yet I get no error message saying it is required, just an empty result back.
It does not seem to be intentional, as it is not the way the api works in other cases.
Title: Re: NRS v1.7.0e
Post by: cc001 on December 02, 2015, 05:29:04 pm
Ever thought about combining the shuffling- with the voting-feature? The idea is to allow anonymous voting.
The voters would not vote directly, but vote into a shuffling-pool. After the shuffling the result of the voting is shown, but nobody knows which account voted what.
Of course it is not feasible that all voters must be online at the end of the voting for the shuffling (a big disadvantage of the current shuffle implementation, IMHO).
Thoughts about that?
Title: Re: NRS v1.7.0e
Post by: blackyblack1 on December 02, 2015, 05:34:06 pm
Ever thought about combining the shuffling- with the voting-feature? The idea is to allow anonymous voting.
The voters would not vote directly, but vote into a shuffling-pool. After the shuffling the result of the voting is shown, but nobody knows which account voted what.
Of course it is not feasible that all voters must be online at the end of the voting for the shuffling (a big disadvantage of the current shuffle implementation, IMHO).
Thoughts about that?
I doubt it is cryptographically possible. There are protocols for anonymous voting though.
Title: Re: NRS v1.7.0e
Post by: Jean-Luc on December 02, 2015, 07:41:56 pm
I was able to submit a shuffling registration for the asset I don't have, is this correct behavior? My account is not in the registration list, only browser message popped up and was logged that shuffler was started, did I get in or not after all?
The shufflers are designed to resist failure, and keep trying to resubmit failed transactions. If you transfer some of this asset to your account from another one, as long as the shuffling is still accepting registration, the shuffler will try again and succeed registering once you get the asset.
Title: Re: NRS v1.7.0e
Post by: Jean-Luc on December 02, 2015, 07:57:24 pm
A question about the getHoldingShufflings api function.
Is it expected to return empty array if you don't specify any holding?
This is fixed in 1.7.1e, it should return shufflings of NXT if holding is not specified (or zero).
Title: Re: NRS v1.7.0e
Post by: coretechs on December 03, 2015, 03:56:24 am
Ever thought about combining the shuffling- with the voting-feature? The idea is to allow anonymous voting.
The voters would not vote directly, but vote into a shuffling-pool. After the shuffling the result of the voting is shown, but nobody knows which account voted what.
Of course it is not feasible that all voters must be online at the end of the voting for the shuffling (a big disadvantage of the current shuffle implementation, IMHO).
Thoughts about that?
I doubt it is cryptographically possible. There are protocols for anonymous voting though.

I'm guessing it can be done if you first issue an asset and create the poll based on the asset balance.  Send each voter a unit of the asset (public) and then have all voters participate in an asset shuffle before voting.  The new shuffled accounts can then cast the votes anonymously.
elective-stereophonic
elective-stereophonic
assembly
assembly