Search content
Sort by
Showing 20 of 334 results by Jean-Luc
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.
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.
Re: | ARDOR | Scalable Blockchain-as-a-Service Platform | Proof of Stake
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
https://www.jelurida.com/ico
Re: [IOTA] Крипто-токен для "интернета вещей" (Internet-of-Things)
Вторые сутки не принесли существенных изменений. Никаких попыток выполнить передачу удерживаемой чужой собственности, товарищ дэвид не предпринимает.
Беспечность бородача поражает воображение простого человека,например, такого как я.
я с 18 июня жду ответа от Дэвида Беспечность бородача поражает воображение простого человека,например, такого как я.
Ну садись тогда рядом, подождем пока красавица проснется
Тебе, кстати, сколько лямов задолжали?
Please share your experience here:
https://bitcointalk.org/index.php?topic=2000113.0
The deadline for the ico claim is almost over and still no update from iota team 
you need claim some money? join slack, devs are over there i believe
done that no responce from david.
I was told David is busy but confirmation of my claim email would have set my mind at ease.
have tried to contact PM and mail for reclaiming...
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.
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.
We have given 'official responses' to this endless times. Everyone (that claims) will have their tokens before exchange listing and before 'expiration date of July 11th'. This has been repeated on every communication platform of ours ad nauseam.
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.)
Quote
It's not our fault that people such as yourself did not care enough about the project to claim within months.
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.
Has any manual claim been processed? If you got contacted by David, pls tell us so we know where we are at. No manual claims, no exchanges, easy.
I have the same question. Can we get an official public response from the Iota team on the status of the manual claim processing?Re: Nxt about to release cheap, decentralized Bitcoin [and Altcoin] Mixer
You 100,000 lines of code is a big waste of time
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.Re: Nxt about to release cheap, decentralized Bitcoin [and Altcoin] Mixer
whats the average fee now a days for a btc mixer? and how does that compare to using nxt as a mixer? what are the savings if someone wanted to mix 100BTC?
According to the changelog link I posted above, shuffling requires a deposit of 1000NXT. This is about $6.5 right now.
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.
Re: [LRD] - Libertyreserved.is - Cryptocurrency with fixed rate
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?
Quote
The Nxt software is released as open source, which allows anyone to freely inspect the code, use it, modify it, and build on top of it.
No open source license however, neither the MIT License under which NRS versions prior to 1.5 were released, nor the GPL which applies to 1.5 and all later NRS versions, allows copying the work of others and presenting it as your own. Doing that is plain old plagiarism.
This also applies to release notes, change logs, and similar documentation included with the NRS distribution. You cannot copy, whether fully or partially, such texts, and make it appear as if you wrote them, or did the work described in them, while in fact it is the Nxt developers that did both.
Any derived work must make it clear which part of it, if any, is original, and give proper credit to the Nxt developers for their work.
You cannot remove the Nxt copyright notices, and you can only add your own copyright notice to a source code file if you really made a copyrightable contribution to this file. Changing the values of a few constants, or variable names, for example, is not a copyrightable contribution.
Starting from version 1.5, the NRS software is released under GNU General Public License (GPL), version 2. Including code from 1.5 or later Nxt version into your clone coin requires placing your work under GPLv2 too, with no exceptions. The Nxt core developers have the option of negotiating use of the Nxt code under a different license (a practice known as "selling exceptions to the GPL"), because they own the copyright. You will not have this option for your clone coin, once it incorporates GPL'd Nxt code, because you don't own the copyright to this Nxt code, and you are only allowed to use it under the conditions imposed by the GPL. Make sure you understand the long term implications of this, before "borrowing" Nxt code.
Here are some useful references about handling copyright in open source development, what is a copyrightable contribution, and compliance with the GPL:
https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
https://softwarefreedom.org/resources/2007/originality-requirements.html
https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
https://softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.html
No open source license however, neither the MIT License under which NRS versions prior to 1.5 were released, nor the GPL which applies to 1.5 and all later NRS versions, allows copying the work of others and presenting it as your own. Doing that is plain old plagiarism.
This also applies to release notes, change logs, and similar documentation included with the NRS distribution. You cannot copy, whether fully or partially, such texts, and make it appear as if you wrote them, or did the work described in them, while in fact it is the Nxt developers that did both.
Any derived work must make it clear which part of it, if any, is original, and give proper credit to the Nxt developers for their work.
You cannot remove the Nxt copyright notices, and you can only add your own copyright notice to a source code file if you really made a copyrightable contribution to this file. Changing the values of a few constants, or variable names, for example, is not a copyrightable contribution.
Starting from version 1.5, the NRS software is released under GNU General Public License (GPL), version 2. Including code from 1.5 or later Nxt version into your clone coin requires placing your work under GPLv2 too, with no exceptions. The Nxt core developers have the option of negotiating use of the Nxt code under a different license (a practice known as "selling exceptions to the GPL"), because they own the copyright. You will not have this option for your clone coin, once it incorporates GPL'd Nxt code, because you don't own the copyright to this Nxt code, and you are only allowed to use it under the conditions imposed by the GPL. Make sure you understand the long term implications of this, before "borrowing" Nxt code.
Here are some useful references about handling copyright in open source development, what is a copyrightable contribution, and compliance with the GPL:
https://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
https://softwarefreedom.org/resources/2007/originality-requirements.html
https://softwarefreedom.org/resources/2007/gpl-non-gpl-collaboration.html
https://softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL_Compliance_2d_ed.html
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?
Re: [NAUT] Nautiluscoin to Nxt-based Nautilus redemption process.
Already had Java 8. I needed Oracle Java version 1.7.
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:
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:
Code:
public static byte[] aesGCMEncrypt(byte[] plaintext, byte[] key) {
try {
byte[] iv = new byte[16];
secureRandom.get().nextBytes(iv);
GCMBlockCipher aes = new GCMBlockCipher(new AESEngine());
CipherParameters ivAndKey = new ParametersWithIV(new KeyParameter(key), iv);
aes.init(true, ivAndKey);
byte[] output = new byte[aes.getOutputSize(plaintext.length)];
int ciphertextLength = aes.processBytes(plaintext, 0, plaintext.length, output, 0);
ciphertextLength += aes.doFinal(output, ciphertextLength);
byte[] result = new byte[iv.length + ciphertextLength];
System.arraycopy(iv, 0, result, 0, iv.length);
System.arraycopy(output, 0, result, iv.length, ciphertextLength);
return result;
} catch (InvalidCipherTextException e) {
throw new RuntimeException(e.getMessage(), e);
}
}
try {
byte[] iv = new byte[16];
secureRandom.get().nextBytes(iv);
GCMBlockCipher aes = new GCMBlockCipher(new AESEngine());
CipherParameters ivAndKey = new ParametersWithIV(new KeyParameter(key), iv);
aes.init(true, ivAndKey);
byte[] output = new byte[aes.getOutputSize(plaintext.length)];
int ciphertextLength = aes.processBytes(plaintext, 0, plaintext.length, output, 0);
ciphertextLength += aes.doFinal(output, ciphertextLength);
byte[] result = new byte[iv.length + ciphertextLength];
System.arraycopy(iv, 0, result, 0, iv.length);
System.arraycopy(output, 0, result, iv.length, ciphertextLength);
return result;
} catch (InvalidCipherTextException e) {
throw new RuntimeException(e.getMessage(), e);
}
}
Mixer is essentially this
1) You send bitcoins to an address(from the bitcoin mixer service)
2) After the payment is recieved in the address, the service sends you your btc to your 2nd address through a completely random address.
1) You send bitcoins to an address(from the bitcoin mixer service)
2) After the payment is recieved in the address, the service sends you your btc to your 2nd address through a completely random address.
This is how a centralized mixer works. The way coin shuffling will work in Nxt is a bit different:
You announce that you want to shuffle for example 10,000 NXT, or join an existing shuffle that somebody else started. You enter in your wallet the recipient address, known only to you, where those 10,000 NXT should be sent. Those are deducted from your account. Each shuffle participant does the same (shuffling exactly the same amount), and each shuffle when created is set to require a certain number of participants (say 20) and the amount being shuffled. When the shuffle completes, each participant finds that amount in the recipient account he specified, yet none of the other participants, and no external observer, can find out which recipient account belongs to which participant.
Shuffling will be possible not only for the NXT coin itself, but for any asset on the NXT Asset Exchange too.
The jumblr service that James is working on is for BTC and similar coins, but the idea is the same.
Actually, I don't think we use AES in authenticated mode, here is how it is called, using the BouncyCastle library:
However, after encryption, the full list of ciphertexts that each participant sends to the next becomes a part of the transaction bytes that are signed by this participant (using his regular private key, as derived from the secret phrase without additional nonces, as done for all Nxt transactions). So modifying anything inside the encrypted payload will invalidate the transaction and it will no longer be acceptable in the blockchain. And the transaction that the next participant submits, includes the hash of this previous transaction, so is only valid as a response for this specific encrypted payload.
Note that we use the same method for encrypting messages between Nxt accounts, with the difference that the shared key is derived adding a random nonce for each message, and the regular secret phrase, same for every transaction of this account, is used:
Code:
public static byte[] aesEncrypt(byte[] plaintext, byte[] key) {
try {
byte[] iv = new byte[16];
secureRandom.get().nextBytes(iv);
PaddedBufferedBlockCipher aes = new PaddedBufferedBlockCipher(new CBCBlockCipher(
new AESEngine()));
CipherParameters ivAndKey = new ParametersWithIV(new KeyParameter(key), iv);
aes.init(true, ivAndKey);
byte[] output = new byte[aes.getOutputSize(plaintext.length)];
int ciphertextLength = aes.processBytes(plaintext, 0, plaintext.length, output, 0);
ciphertextLength += aes.doFinal(output, ciphertextLength);
byte[] result = new byte[iv.length + ciphertextLength];
System.arraycopy(iv, 0, result, 0, iv.length);
System.arraycopy(output, 0, result, iv.length, ciphertextLength);
return result;
} catch (InvalidCipherTextException e) {
throw new RuntimeException(e.getMessage(), e);
}
}
where the shared key is obtained as:try {
byte[] iv = new byte[16];
secureRandom.get().nextBytes(iv);
PaddedBufferedBlockCipher aes = new PaddedBufferedBlockCipher(new CBCBlockCipher(
new AESEngine()));
CipherParameters ivAndKey = new ParametersWithIV(new KeyParameter(key), iv);
aes.init(true, ivAndKey);
byte[] output = new byte[aes.getOutputSize(plaintext.length)];
int ciphertextLength = aes.processBytes(plaintext, 0, plaintext.length, output, 0);
ciphertextLength += aes.doFinal(output, ciphertextLength);
byte[] result = new byte[iv.length + ciphertextLength];
System.arraycopy(iv, 0, result, 0, iv.length);
System.arraycopy(output, 0, result, iv.length, ciphertextLength);
return result;
} catch (InvalidCipherTextException e) {
throw new RuntimeException(e.getMessage(), e);
}
}
Code:
public static byte[] getSharedKey(byte[] myPrivateKey, byte[] theirPublicKey) {
return sha256().digest(getSharedSecret(myPrivateKey, theirPublicKey));
}
private static byte[] getSharedSecret(byte[] myPrivateKey, byte[] theirPublicKey) {
try {
byte[] sharedSecret = new byte[32];
Curve25519.curve(sharedSecret, myPrivateKey, theirPublicKey);
return sharedSecret;
} catch (RuntimeException e) {
Logger.logMessage("Error getting shared secret", e);
throw e;
}
}
return sha256().digest(getSharedSecret(myPrivateKey, theirPublicKey));
}
private static byte[] getSharedSecret(byte[] myPrivateKey, byte[] theirPublicKey) {
try {
byte[] sharedSecret = new byte[32];
Curve25519.curve(sharedSecret, myPrivateKey, theirPublicKey);
return sharedSecret;
} catch (RuntimeException e) {
Logger.logMessage("Error getting shared secret", e);
throw e;
}
}
However, after encryption, the full list of ciphertexts that each participant sends to the next becomes a part of the transaction bytes that are signed by this participant (using his regular private key, as derived from the secret phrase without additional nonces, as done for all Nxt transactions). So modifying anything inside the encrypted payload will invalidate the transaction and it will no longer be acceptable in the blockchain. And the transaction that the next participant submits, includes the hash of this previous transaction, so is only valid as a response for this specific encrypted payload.
Note that we use the same method for encrypting messages between Nxt accounts, with the difference that the shared key is derived adding a random nonce for each message, and the regular secret phrase, same for every transaction of this account, is used:
Code:
public static byte[] getSharedKey(byte[] myPrivateKey, byte[] theirPublicKey, byte[] nonce) {
byte[] dhSharedSecret = getSharedSecret(myPrivateKey, theirPublicKey);
for (int i = 0; i < 32; i++) {
dhSharedSecret[i] ^= nonce[i];
}
return sha256().digest(dhSharedSecret);
}
and after the AES encryption step, same as above, the encrypted text becomes part of the transaction bytes that are signed by the sender.byte[] dhSharedSecret = getSharedSecret(myPrivateKey, theirPublicKey);
for (int i = 0; i < 32; i++) {
dhSharedSecret[i] ^= nonce[i];
}
return sha256().digest(dhSharedSecret);
}
Thanks for the explanation, now I added a check for duplicate data at each processing step.
For the encryption, for each sender we generate a new public/private key pair using curve25519, unique for each sender/shuffle/recipient combination, and then use this plus the recipient public key to generate a DH shared key, then use AES for the actual encryption. If you take a look at the current way public keys are generated based on secret phrase: https://bitbucket.org/JeanLucPicard/nxt/src/369546f91ba32142562c18d224369ea64a3f0720/src/java/nxt/crypto/Crypto.java?at=master#Crypto.java-63 , for shuffling I have added generation of one-time keys based on secretPhrase plus known nonces:
and for the one-time keys used in the shuffle, shuffleId and recipientId are used as nonces. Then the one-time sender public key is added to the encrypted data, to allow its decryption by the recipient, yet it is not possible for the recipient (or anyone else) to tell who the sender of each encrypted data is.
If the blame phase needs to be entered, each participant discloses the array of sha256 digests ("keySeeds") used to generate each public/private key pair he used to encrypt to each of the next participants, which allows anyone to decrypt the content ot the data.
For the encryption, for each sender we generate a new public/private key pair using curve25519, unique for each sender/shuffle/recipient combination, and then use this plus the recipient public key to generate a DH shared key, then use AES for the actual encryption. If you take a look at the current way public keys are generated based on secret phrase: https://bitbucket.org/JeanLucPicard/nxt/src/369546f91ba32142562c18d224369ea64a3f0720/src/java/nxt/crypto/Crypto.java?at=master#Crypto.java-63 , for shuffling I have added generation of one-time keys based on secretPhrase plus known nonces:
Code:
public static byte[] getKeySeed(String secretPhrase, byte[]... nonces) {
MessageDigest digest = Crypto.sha256();
digest.update(Convert.toBytes(secretPhrase));
for (byte[] nonce : nonces) {
digest.update(nonce);
}
return digest.digest();
}
public static byte[] getPublicKey(byte[] keySeed) {
byte[] publicKey = new byte[32];
Curve25519.keygen(publicKey, null, Arrays.copyOf(keySeed, keySeed.length));
return publicKey;
}
public static byte[] getPublicKey(String secretPhrase) {
byte[] publicKey = new byte[32];
Curve25519.keygen(publicKey, null, Crypto.sha256().digest(Convert.toBytes(secretPhrase)));
return publicKey;
}
public static byte[] getPrivateKey(byte[] keySeed) {
byte[] s = Arrays.copyOf(keySeed, keySeed.length);
Curve25519.clamp(s);
return s;
}
public static byte[] getPrivateKey(String secretPhrase) {
byte[] s = Crypto.sha256().digest(Convert.toBytes(secretPhrase));
Curve25519.clamp(s);
return s;
}
MessageDigest digest = Crypto.sha256();
digest.update(Convert.toBytes(secretPhrase));
for (byte[] nonce : nonces) {
digest.update(nonce);
}
return digest.digest();
}
public static byte[] getPublicKey(byte[] keySeed) {
byte[] publicKey = new byte[32];
Curve25519.keygen(publicKey, null, Arrays.copyOf(keySeed, keySeed.length));
return publicKey;
}
public static byte[] getPublicKey(String secretPhrase) {
byte[] publicKey = new byte[32];
Curve25519.keygen(publicKey, null, Crypto.sha256().digest(Convert.toBytes(secretPhrase)));
return publicKey;
}
public static byte[] getPrivateKey(byte[] keySeed) {
byte[] s = Arrays.copyOf(keySeed, keySeed.length);
Curve25519.clamp(s);
return s;
}
public static byte[] getPrivateKey(String secretPhrase) {
byte[] s = Crypto.sha256().digest(Convert.toBytes(secretPhrase));
Curve25519.clamp(s);
return s;
}
and for the one-time keys used in the shuffle, shuffleId and recipientId are used as nonces. Then the one-time sender public key is added to the encrypted data, to allow its decryption by the recipient, yet it is not possible for the recipient (or anyone else) to tell who the sender of each encrypted data is.
If the blame phase needs to be entered, each participant discloses the array of sha256 digests ("keySeeds") used to generate each public/private key pair he used to encrypt to each of the next participants, which allows anyone to decrypt the content ot the data.
Each peer must check that there are no duplicate plaintexts after decrypting. Otherwise attacks on unlinkability are possible.
Is that the same as checking that no two recipient addresses are the same, once the shuffle reaches the last participant, or is there more to it?Multiple participants submitting the same recipient account would be a trivial attack to counteract, however there is no way to protect against a real sybil attack in which multiple participants, each submitting a different recipient address, are actually controlled by the same entity.
Independently of James' work, we are also working on implementing coin shuffling using your algorithm in the upcoming version of Nxt. The blame phase is really the complicated part to get right, and here we are taking the approach to disclose the one-time keys used by each participant, to find and penalize the rogue participant. When ready, we would certainly welcome you to have a look at our implementation too.
The development of HZ consists of plagiarizing the work of the Nxt developers, even including the changelogs and readme files that I write.
well.... they changed the color of the wallet too. I gave them and future cloners a notice: https://nxtforum.org/nrs-releases/notice-to-nxt-clone-creators