This thread has now collected evidence and documented the experience of several IOTA purchasers whose manual claims have been ignored for almost one year now. We have seen that contrary to the statements by the IOTA team that it is the users' fault for leaving the claim till the last moment, most such users have been trying to claim multiple times since last year, never to receive a response. Others, whose claims may have formally been processed, still can't get hold of their IOTA because the software now doesn't let them access the same addresses. A few users I have talked to privately prefer not to post their case in public, so the number of submitted but ignored claims is actually higher.

Several of the claimants I have been in talks with are more than willing to consider taking legal action (and unlike me, do not care to remain anonymous). The IOTA team is no longer unaccountable. Unlike the common scams here, they do have a business presence in the real world and have even managed to attract traditional VC investors. So I would be curious to find out how would Jamie Burke and his partners from Outlier Ventures feel about having their investment in IOTA spent on fending off lawsuits, settling legal claims, and fixing bad PR, instead of on technical and business development? Will they like the fact that the names of Outlier Ventures and IOTA now appear together in the context of scam accusations and lawsuit threats? I plan to ask them. In fact, it may be a good idea for all of you with outstanding manual claims to also copy them, in one last claim request. Their contact info is conveniently posted at https://outlierventures.io/#contact and they proudly (for now) list IOTA as a startup they have invested in. And unlike David, who may just say he never got your request, those guys are used to being accountable and wouldn't take the risk of ignoring you.

50% of the Ignis coin supply, the first child chain of the Ardor platform, will be sold in an ICO to be performed on the Nxt blockchain. Updated Ignis ICO announcement by Jelurida:

https://www.jelurida.com/ico

The IGNIS ICO will be conducted on the Nxt blockchain. Details announced at the Jelurida Ignis ICO page:

https://www.jelurida.com/ico

Please share your experience here:

https://bitcointalk.org/index.php?topic=2000113.0

I started a dedicated thread to keep track of the manual claims. Please post your story there too.

https://bitcointalk.org/index.php?topic=2000113.0

The purpose of this thread is to document the outstanding IOTA manual claims, and the response, if any, they have received from the IOTA team.

The IOTA team has ignored my request to make the process transparent and to publish a list of these claims with the status of each of them. Since they also do not respond to emails or PMs, and there is no clear and up to date information regarding what constitutes a valid claim request, there is a real danger that after the arbitrarily set deadline of July 11th many of the manual claims will be rejected as not submitted in time, or not containing enough information.

I am asking all participants in the IOTA ICO who still did not receive their IOTA, despite having submitted a claim, to document this fact by posting in this thread:

1. The IOTA Genesis account address to which you hold the seed (NOT the seed itself).

2. A copy of the claim(s) you have submitted (with any confidential info removed).

Participating in this thread does NOT constitute a claim submission. You still need to submit your claim to the IOTA team, but posting in this thread should help document what and when you have submitted.

To reduce noise and trolling, I will be moderating this thread and will allow only posts from IOTA stakeholders (containing the above info), or official responses from the IOTA team.

I have seen this official response. However, I have never received a response to my manual claim request(s) sent to contact@iotatoken.com, so I have no proof that you have received and will process my manual claim. (Don't bother searching for Jean-Luc in your mailbox - I used an email linked to my real identity, and I am afraid I can't tell you which one it is.)

Except that I did claim. With the 0.9.something version. Your software failed to register my claim on the network, and of course now I have no proof that I did claim. Which puts me in the not so small group of users who had to send you their seeds for manual claim, never to hear back again. Not exactly the way to make them care about the project.

To avoid ending up in the same situation after the deadline of July 11th (with no proof that I have claimed in time), I kindly ask you to post a list of the outstanding manual claims pending to be processed so that users can be certain theirs will be taken care of, and don't need to bother you with emails or PMs again.

Why should I get involved in a project that never sent me the tokens I paid for?

I have the same question. Can we get an official public response from the Iota team on the status of the manual claim processing?

Who can break an Nxt Coin Shuffling? We will be holding Shuffling Sundays on testnet again, but this time the goal is to find a way to break a shuffling and get away with it! Now that the source code is released, everyone is invited to dig in, find an exploitable loophole, and get a bounty.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Release 1.7.4

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

sha256:

baf0286983fee3f718ea755dd76f5e9bb3d6a2962560368d513ffc9517d10c9b  nxt-client-1.7.4.zip

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

sha256:

13a4437bce4941b06f9ce3b0bf8f2371f2240db264712371094e22fc5152b34b  nxt-client-1.7.4.jar

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


https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-installer-1.7.4.dmg

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


Change log:

This is the first stable release in the 1.7 series. It is a mandatory update
for everyone. There is a hard fork scheduled for block 621000, estimated to
occur around Jan 21, 2016, at which new features will be enabled. Nodes that
do not update to 1.7.4 or later by this date will be left on a fork.

On testnet, the hard fork block is already passed, and all new features are
fully functional.

There were incompatible API changes introduced in the 1.6 series. API users
still on 1.5.15 and earlier should make sure to read the 1.6 series changelogs
and forum announcements, before upgrading to 1.7. These changes do not affect
regular end users who just run the NRS client on their desktop or VPS node.

The new features and improvements in the 1.7 series have been documented in
the 1.7.0e through 1.7.3e changelogs, available in the changelogs directory.


Here is a high level summary of the new features to be enabled after the
hard fork:

Coin Shuffling, a fully decentralized coin mixing, to improve account privacy.

Account Control for phased transactions, the Nxt equivalent of multisignature.

Immediate release of certain types of phased transactions on approval.

Improved block times, 60 s average, long block times now extremely unlikely.

Account Properties, assigning arbitrary name/value metadata to user accounts.

Singleton Assets, useful for representing single tradeable objects.

Dynamic fees, proportional to the relative transaction size.

Improved Exchange Booth UI.

Data Cloud, adding a UI and multiple enhancements to the existing Tagged Data
feature, to allow decentralized, censorship-free and tamper-proof publication
and retrieval of small files, documents, or arbitrary data. This feature is
not dependent on the hard fork and will be fully usable immediately on update
to this release.


Changes added since the 1.7.3e release:

Added detectMimeType utility API, allowing auto-detection of the mime type of
uploaded file or data, using the Apache Tika library.

The uploadTaggedData API now uses such mime type auto-detection to determine
the mime type of uploaded data when the user has not explicitly provided a
type parameter. It also automatically sets the isText property to true for
data of type text/plain only.

Made the maximum permitted number of forgers or shufflers running at the same
time configurable, default 100 each, using the nxt.maxNumberOfForgers and
nxt.maxNumberOfShufflers properties.

The default value of includeCounts parameter in the searchDGSGoods API is now
also false, this API was inadvertently missed when globally changing the
defaults to false in the 1.6 branch.

Various UI improvements.

Updated Bouncy Castle library to version 1.54.


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

iQIcBAEBCgAGBQJWhlCtAAoJENqvaxkWiP4ZlJwQAM6XodzaiUeyjdOVQhqYTmTr
H2jioMMyuYpztRlzhzv6UjTuCETDjtUX9a7cHTX4c44Q7WnM1aiIV9/lYsgRa4Aq
my2pSK91OL++/w173rIKbFamw83DWKzU5ozm3pnyIGYiJv6HP1VxajOk8R2E6R2G
haazNDp7IoMBssHWev4uY4O2gJEIqRu2l9s9pXKe5A93o/pSReIQvWx6HY0/3WyP
qkmuSGv9K78SR8JIWrNAU97nFyZ6edBkLnHJH6RwfWkoQhqvXWEomAln1stDN8Xi
FhBTqy1s9utMSl5gMg4Dy9xpB+Fsdo6gCMsoY6R5fgeVnkthv87kXecBETqZCPYm
e74qYjUWCqRsrXsjd239cYCq4f2l25QcppKdj0vZAapGK5RyNhHSV78r7FL3e6+e
s4Xw6YwlDiw2cQTtBnY/jyC7sTVwkKxmP/ifRMDFTjpiJvnOwoOI/J66Pr8oOYDy
HWXNXAspv9bNSJum1NQ2gWvPdjvbKdiZTBq9nfpcUkq2v6rgUgpRqY7sO8aB7OKN
mdXxSyiNNPLM3xEkkUC11JWROlvGgnIAf8T1tkr3QKsrkR9o3CjrvBzktTNNUR2h
bmQTnQ1BR2g61Wbvjn76no+VeNOYfhh8q+FLZXLFGYSPi+Pv9C3jS76xqU7+oy2o
u0vEoIUc1B4S4h3Y1GWB
=t7Nb
-----END PGP SIGNATURE-----

This statement is false.
This is also false. There is no mixing of transactions. Transaction volume at the time of shuffling makes no difference.

As usual, the troll is spreading misinformation without having checked the facts.

Not sure which coin your are talking about. The implementation of coin shuffling in Nxt is in less than 4,000 lines of code, including whitespace.

The total fee for each participant in a shuffling is only 12 NXT, this is around $0.08. The 1000 NXT deposit is fully refundable at the end of the shuffling. It is there to prevent intentional sabotage of shufflings by rogue participants - when someone intentionally submits invalid data or does not complete his part, the deposit of this participant is retained. Deposits of innocent participants are refunded in such case.

The main advantage over using a centralized mixer is that there are no trusted parties, coins shuffling in Nxt is fully decentralized. No trusted special nodes, no websites that may keep logs, and of course no need to trust the other shuffling participants either.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Release 1.6.1e

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

sha256:

7aa513062d2c6ff686900ca59665b46b173826610a2c78c17283b8e66f6782f5  nxt-client-1.6.1e.zip

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

sha256:

c45d0edfaef98f05a768bc7f7b42baed2027c10dd16f7adecc05b2032df6961e  nxt-client-1.6.1e.jar

https://bitbucket.org/JeanLucPicard/nxt/downloads/nxt-client-1.6.1e.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.

New feature: ShapeShift exchange integration.

The ShapeShift plugin is now integrated in the core NRS package. A detailed
description of this in-client coin exchange functionality is available at:

https://bitbucket.org/JeanLucPicard/nxt/issues/316/shapeshift-integration


This release also adds several API changes and optimizations.

Added getExpectedTransactions API, to return the non-phased unconfirmed
transactions expected to be included in the next block (only), plus the phased
transactions scheduled to finish in that block (whether approved or not).
Takes an optional multivalued "account" parameter, to filter the result by
transaction sender or recipient account.

The "account" parameter of getUnconfirmedTransactions and
getUnconfirmedTransactionIds APIs can also be repeated multiple times now, to
specify more than one account.

Several APIs have been enhanced to make dealing with phased transactions
easier.

getBlock and getBlocks now take an optional includeExecutedPhased boolean
parameter, default false. If true, the phased transactions approved and
executed in each block (which were accepted in some previous block), if any,
are included separately in the response, as either an array of transaction ids
or full transaction json depending on the value of the includeTransactions
parameter.

getTransaction and getBlockchainTransactions now take an optional boolean
parameter includePhasingResult, default false. If true, the execution status
of each phased transaction is also retrieved and included in the result.
The status of each phased transaction is retrieved in a separate database
query, so for getBlockchainTransactions requests that retrieve many phased
transactions at the same time the performance of this API may not be optimal.

getBlockchainTransactions now takes an optional executedOnly boolean
parameter, default false. If true, phased transactions that were not executed
are not included in the result.


Incompatible changes:

As a performance optimization, many query APIs that accept an object id as
parameter, i.e. account, asset, currency, and so on, now no longer load this
object from the database if only having the id is sufficient to retrieve the
required records. This has the side effect that such APIs now will return an
empty result list instead of an error when supplied with a non-existent object
id. Missing or malformed id parameters will still return an error as expected.

For example, getAssetAccounts will now return an empty shareholder list
instead of unknown asset error, when supplied with a non-existent asset id.

This change affects the query APIs only, not the create transaction APIs.

As another performance optimization, for all APIs that accept optional
"include" parameters to retrieve additional data, e.g. includeCounts,
includeAssetInfo, includeCurrencyInfo, and so on, the default value of those
parameters (i.e. when not explicitly specified) is now assumed to be false.
API users will have to set those parameters to true when these extra data
are really needed. One important API affected by this change is getAccount,
for which now includeLessors, includeAssets, includeCurrencies,
includeEffectiveBalance are all assumed to be false if not specified, i.e.
only the account NXT balance and info are returned by default.

As announced with the 1.6.0e release, upgrade to the 1.6 branch is optional,
users who depend on the current 1.5 API behavior can stay with 1.5 up until
the 1.7 hard fork.


The default search query operator, used when searching the MS currencies or
the marketplace, is now AND instead of OR.

The Lucene full text search library has been updated to version 5.3.1, and
Jetty has been updated to version 9.3.3. Remove the old lib subdirectory if
unpacking on top of a previous installation.


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

iQIcBAEBCgAGBQJWEC0LAAoJENqvaxkWiP4ZQP8QAN3Cg8cGEnxVfIi5BoGFhHsu
SDJIR5etdiN8HvHx7OtueW4o+X260m0QmIe9pMYWd8mL7JMoFv3+OZzr6paRfbsa
lrdBOO9gErQ4f0uu78oKZD5ftlVM/lacYnsPQtqSDeeGEUSF/DquxasHcXnTAosA
uYyispIRiszaVCcaW0iG8XV27KSCoO+GYIDi/o20CDlFzoY2brqKBkGDI8SSW9Oc
Vg3mYgxmNX7AeLEhrhNUHd5uPIrhTKKRdSkw7/UOtQs7L39BFQc1z7tEbW2kAKCs
uOHYHTDVlwiYlRjYIFNdNLolhqtPQJac8G16HYGzkwqVEgnpcc903g9ob9Tm3Lhg
OtMXASMOFHII+M0w8MLl7M61MeHLf5Y6S4PAMcu/rfIjc2hgjezrjQfERSUakPwR
iv9WEmXGa9UeSRAw7o+3qWvV9tyIKrsAi5v54JB9/LErdkH/9HKrRhug9cvtt1Ul
+Fy2wCUq7yEM1xI4X+GnphC/vVqhhCMXxh0+JehJ6SZ0mhw9UhWK5olnupXnsr1I
ctHtIM949PNQUmwByT96TR+DEl2vUgA2Frp/1ooueEnNpOKO5XgjSoc9OSQScNuA
peY8pTh31wGc6xHHC0k2w6OCtxRGpiV9t2rnJd7CwprZOtzFl14s18qikRbA5vu/
es4z3SsKeXZTR6WC59/l
=9lyV
-----END PGP SIGNATURE-----

And it is not just the GPL license file and source code repository that you need to add. You cannot remove or change any of our copyright notices, and you cannot represent our work as yours. Let me quote myself, to clear any misunderstanding: https://nxtforum.org/nrs-releases/notice-to-nxt-clone-creators/


Oh, and btw, it is not just the Nxt copyright you are violating, you have removed the copyright notices of all third-party software also included in the Nxt distribution - such as H2, Jetty, Lucene. Makes me wonder, why would a legitimate business do that?

This was only trolling the troll, thus the haiku style, I have nothing against Monero really. But is it really a coincidence that he went on a rage against Nxt just as it became known that our coin shuffling anonymity feature is going in the next release, thus threatening the major selling point of his favorite coin?

Coin Shuffling. It is coming to Nxt.
The trolls are going rabid,
because now Monero is irrelevant.

You need Java 8, not 7. It could be that you have both installed, and java 8 is the one actually used. On MacOS, it has been reported that just installing the Java 8 JRE is not enough to setup the path correctly, one needs to install the full JDK.

But then you trust the initiator of the shuffle to not be an attacker himself. If he occupies the first k spots, it is as if the shuffle starts from k+1. At least in the Nxt core implementation, the shuffle creator is equal to all other participants, and will be penalized the same way if discovered to cheat.

I have all parts of the algorithm implemented and working now, including the blame phase of detecting and penalizing rogue participants who either submit invalid data or do not submit their transactions in time, with all integration tests passing. What remains is only to make the shuffle process user friendly, by automating the submission of process/verify/cancel transactions.

For the AES encryption, I now use GCMBlockCipher: