Nexus - Pure SHA3 + CPU/GPU + nPoS + 15 Active Innovations + More to Come

[Supercomputing]

Supercomputing,

The traders that exchange their petitioned clone coins into an exchange channel are the ones that are going to profit from the second Decay Equation. There is a check in the Coinbase TX that verifies it goes to one of the proper addresses to prevent block manipulators of just this sort. The same goes for the amount that comes from the Reserves, for it must fall under a specified set of rules.

Let me know if you have any more questions.

I am still confused on two issues:

1). Who manages these funding addresses and why should we trust them. Why not give miners the option to opt-out.

2). How is it possible to trade a worthless coin and still make a profit - defies logic.

[phzi]

1). Who manages these funding addresses and why should we trust them. Why not give miners the option to opt-out.

If I am interpreting "funding addresses" correctly here, I take it you mean where the dev fee and channel funds go?   Well, obviously to Viz at this point.  Why should you trust him?  Well, you already do - if you're using this coin, you're using closed source cryptography, so you better trust him!

2). How is it possible to trade a worthless coin and still make a profit - defies logic.[/b]

The exchange channel concept, as I understand it, isn't for exchanging worthless (in value) coins, it is for exchanging (and absorbing the economy of) technically worthless coins.

---

sorry for insisting viz, but wouldn't a block explorer make everything more transparent thus trustful?

I agree a block explorer would be nice to see - would be reasonably trivial to put together. However, without source to the wallet, I doubt anyone is going to spend the time to recreate all the hashing etc functions needed.

[skunk]

I agree a block explorer would be nice to see - would be reasonably trivial to put together. However, without source to the wallet, I doubt anyone is going to spend the time to recreate all the hashing etc functions needed.

let's suppose viz would put together a block explorer by himself, would that be trustful enough?

[phzi]

let's suppose viz would put together a block explorer by himself, would that be trustful enough?

You tell me, lol?  Trust is a very individual thing.  Personally, I do think Viz is trustworthy; but, even from someone I trust, I don't trust closed-source cryptography.  For others that would never look at or compiled the source code anyway, it might be entirely irrelevant.

[Videlicet]

Everyone,

The funds that are from decay equation #2 go to an automated bot system that I will be creating.

I am generally an observer to the community, and this is my first user account here because this is the first time I have actually needed one. I'm glad you brought this to everybody's attention, as I foresaw this as being an issue. By the nature of how this system will work, yes there will need to be a level of trust involved. This trust is beginning to be established at this point in time, now that you raised the question of it. The way we have decided to deal with this issue is ABSOLUTE TRANSPARENCY. When the first channel opens, there will be an archive page started on main website of every single executed trade of SHIT DUMP, and every single executed BTC buy order. This will of course be in real time on the left sidebar of the channels for reference. The second point is I will design the channels to have one deposit address for the channel. This means that you will be able to see every single SHIT that is transfered to the channel, every single SHIT that is transfered to the exchange, and every single SHIT sell order. These numbers can be verified with the automation supplied on archives page, or by your own discretion if independent verification is chosen as the suited means for your veracity.

The trust can only be established over time, with transparency being the best means of expressing it.

I can work on a block explorer, but this will have to be after the pools are done for both the Prime Channel and SK-1024 Channel.
In the meantime, this is the list of the addresses:

   const string CHANNEL_ADDRESSES[] =  {         "2Qn8MsUCkv9S8X8sMvUPkr9Ekqqg5VKzeKJk2ftcFMUiJ5QnWRc",
                                     "2S4WLATVCdJXTpcfdkDNDVKK5czDi4rjR5HrCRjayktJZ4rN8oA",
                                     "2RE29WahXWawQ9huhyaGhfvEMmUWHH9Hfo1anbNk8eW3nTU7H2g",
                                     "2QpSfg6MBZYCjQKXjTgo9eHoKMCJsYjLQsNT3xeeAYhrQmNBEUd",
                                     "2RHjigCh1qt1j3WKz4mShFBiVE5g6z9vrFpGMT6EDQsFJbtx4hr",
                                     "2SZ87FB1zukH5h7BLDT4yUyMTQnEJEt2KzpGYFxuUzMqAxEFN7Y",
                                 "2STyHuCeBgE81ZNjhH5QB8UXViXW7WPYM1YQgmXfLvMJXaKAFCs",
                                 "2SLq49uDrhLyP1N7Xnkj86WCHQUKxn6zx38LBNoTgwsAjfV1seq",
                                 "2RwtQdi3VPPQqht15QmXnS4KELgxrfaH2hXSywtJrfDdCJMnwPQ",
                                 "2SWscUR6rEezZKgFh5XkEyhmRmja2qrHMRsfmtxdapwMymmM96Q",
                                 "2SJzPMXNPEgW2zJW4489qeiCjdUanDTqCuSNAMmZXm1KX269jAt",
                                 "2Rk2mBEYWkGDMzQhEqdpSGZ77ZGvp9HWAbcsY6mDtbWKJy4DQuq",
                                 "2Rnh3qFvzeRQmSJEHtz6dNphq3r7uDSGQdjucnVFtpcuzBbeiLx" };
                                 
                                 
   const string DEVELOPER_ADDRESSES[] = {     "2Qp1rHzLCCsL4RcmLRcNhhAjnFShDXQaAjyBB9YpDSomCJsfGfS",
                                   "2SFx2tc8tLHBtkLkfK7nNjkU9DwvZZMNKKLaeX4xcG8ev4HQqVP",
                                   "2SawW67sUcVtLNarcAkVaFR2L1R8AWujkoryJHi8L47bdDP8hwC",
                                   "2QvzSNP3jy4MjqmB7jRy6jRGrDz6s6ALzTwu8htdohraU6Fdgrc",
                              "2RxmzQ1XomQrbzQimajfnC2FubYnSzbwz5EkU2du7bDxuJW7i2L",
                              "2S2JaEbGoBFx7N2YGEUJbWRjLf35tY7kezV8R9vzq9Wu1f5cwVz",
                              "2S9bR5wB6RcBm1weFPBXCZai5pRFisa9zQSEedrdi9QLmd5Am8y",
                              "2S6NjGDuTozyCWjMziwEBYKnnaC6fy5zRjDmd2NQhHBjuzKw4bg",
                              "2RURDVPFD14eYCC7brgio2HF77LP22SdN5CeAvwQAwdSPdS95dT",
                              "2SNAEJ6mbmpPXbP6ZkmH7FgtWTWcNnw2Pcs3Stb4PDaq3vH1GgE",
                              "2SDnQuMgW9UdESUUekrrWegxSHLQWnFWJ2BNWAUQVecKNwBeNh5",
                              "2SCLU4SKxh2P27foN9NRoAdtUZMdELMvBpfmVER98HayRRqGKFx",
                              "2SLN8urU2mERZRQajqYe9VgQQgK7tPWWQ1679c5B3scZKP2vDxi" };


I reset the seed nodes, you will be able to get on the main chain now if you have been having issues.

Viz.

[skunk]

You tell me, lol?  Trust is a very individual thing.  Personally, I do think Viz is trustworthy; but, even from someone I trust, I don't trust closed-source cryptography.  For others that would never look at or compiled the source code anyway, it might be entirely irrelevant.

i have to admit the closed source wallet was (and still is) a concern and posted it on this thread, but well, viz had a point about fearing cut&paste for yet another shit coin...
however it's slowing coming the time to make the code public, as it would take the attention of those that don't trust binary blobs thus new miners... i doubt a stupid cut&paste of this coin would ever get traction at this point...

[phzi]

i have to admit the closed source wallet was (and still is) a concern and posted it on this thread, but well, viz had a point about fearing cut&paste for yet another shit coin...
however it's slowing coming the time to make the code public, as it would take the attention of those that don't trust binary blobs thus new miners... i doubt a stupid cut&paste of this coin would ever get traction at this point...

I agree.  However, I can also see that if the exchange channels are actually launched _soon_, then it might be reasonable to wait.  Why?  Well, because you've waited this long to release source code anyway. And, once the exchange channels are up (if the concept works as hoped/planned), then there is at least a method of dealing with these clone coins.

That said, I have long presumed that the choice to keep the source closed is mostly to do with protecting the dev fee.  The only real risk of a clone coin I would suggest, is if it took the XMR vs BCN route of re-balancing distribution away from the developers.  That's a bad thing for Viz, certainly; but probably wouldn't matter much to anyone else (unless Viz lost interest in development as a result).

[Videlicet]

skunk,

I agree, this is why I am currently working on building a small development team. These people that don't trust closed source binaries are usually the type that understand the code they are looking at hence, being able to help strengthen it. My biggest concern is to ensure Coinshield has time to get off the ground, and to not be polluted with garbage clone coins before it has a chance to prove the many features that go to make it what it is. This happened in the past [Litecoin is a clone of the First Scrypt coin, that failed launch; and got overtaken at relaunch]. I am only working towards giving enough time for the code to be protected, so that it can spawn more creativity and innovation in the environment, rather than plagiarism. I feel the only way towards this goal, is to increase the costs of plagiarism with the Exchange Channels. This is what will be protecting the innovation of other Coinshield Verified Coins.

Edit: The Developer Tx is Designed as a Commission [to pay our bills: servers, development, food, housing, etc.], it is protected with Coinbase TX Checks regardless if the source is open or closed. The same goes for the Exchange Channels Supply. This gives another point of distribution to traders, along with Proof of Stake.

Viz.

[phzi]

I mostly agree with your above post, Viz.  But, you might want to be careful with the word plagiarism...  This is GPL licensed software we're talking about here, and cloning it with credit certainly isn't plagiarizing. 

But, as I said above - since it's been this long without source, it kinda makes sense to just wait for the exchange channels now (kinda...).

[Videlicet]

phzi,

And now is the time to build a small Development Team that will help strengthen the code before the time it is released to the public. And yes - you are correct on my wording, thank you for correcting me: I will stick with Clone then. I feel very strongly about this because this is people's money, and lively hood that goes if they invest in a Crypto. I think as a developer it is our responsibility to these people, to develop them a stable currency in which to get out of the atrocities the monetary system already operates within. This is why I don't take Clones / Scams lightly, because many people are losing money from a Developer making a Clone and pretending its going to be the next Bitcoin, when these people are just trying to free themselves from the biggest scam of all: The Fractional Reserve Banking System.

I feel it my duty to help protect those seeking a better way,
Viz.

[phzi]

I think as a developer it is our responsibility to these people, to develop them a stable currency in which to get out of the atrocities the monetary system already operates within. This is why I don't take Clones / Scams lightly, because many people are losing money from a Developer making a Clone and pretending its going to be the next Bitcoin, when these people are just trying to free themselves from the biggest scam of all: The Fractional Reserve Banking System.

I feel it my duty to help protect those seeking a better way,
Viz.

Here here!  And this is why I'm still actively watching this project.

[Supercomputing]

I trust Viz and I hope that this coin succeeds.

Private Key Upgrades:
Using the EC_KEY algorithms allocated in OpenSSL, Coinshield has upgraded the private keys to a non prime based elliptical curve encryption of 571 bits. This was the largest algorithm that was available, and also not dependent on prime numbers. The reason for this is simple: Coinshield CPU Miners are searching for very large prime numbers, so if any 'discoveries' happen from such actions, it could compromise the whole private key system. The exact algorithm Coinshield uses is secp571r1 compared to sect256k1 that is utilized by most cryptocurrencies today. This compliments the upgraded hashing algorithms to ensure the highest security possible by today's standard.

Please explain what you said above as it does not make sense to me. I would say this is my primary reason for a source code review.

[Videlicet]

I trust Viz and I hope that this coin succeeds.

Private Key Upgrades:
Using the EC_KEY algorithms allocated in OpenSSL, Coinshield has upgraded the private keys to a non prime based elliptical curve encryption of 571 bits. This was the largest algorithm that was available, and also not dependent on prime numbers. The reason for this is simple: Coinshield CPU Miners are searching for very large prime numbers, so if any 'discoveries' happen from such actions, it could compromise the whole private key system. The exact algorithm Coinshield uses is secp571r1 compared to sect256k1 that is utilized by most cryptocurrencies today. This compliments the upgraded hashing algorithms to ensure the highest security possible by today's standard.

Please explain what you said above as it does not make sense to me. I would say this is my primary reason for a source code review.

I'll let the code do the talking: From key.cpp

   bool CKey::SetSecret(const CSecret& vchSecret, bool fCompressed)
   {
      EC_KEY_free(pkey);
      pkey = EC_KEY_new_by_curve_name(NID_sect571r1);
      if (pkey == NULL)
         throw key_error("CKey::SetSecret() : EC_KEY_new_by_curve_name failed");
      if (vchSecret.size() != 72)
         throw key_error("CKey::SetSecret() : secret must be 72 bytes");
      BIGNUM *bn = BN_bin2bn(&vchSecret[0],72,BN_new());
      if (bn == NULL)
         throw key_error("CKey::SetSecret() : BN_bin2bn failed");
      if (!EC_KEY_regenerate_key(pkey,bn))
      {
         BN_clear_free(bn);
         throw key_error("CKey::SetSecret() : EC_KEY_regenerate_key failed");
      }
      BN_clear_free(bn);
      fSet = true;
      if (fCompressed || fCompressedPubKey)
         SetCompressedPubKey();
      return true;
   }

Coinshield Private Key: 571 Bit, 72 Byte
6WuPzv2yY9GrdKuDHbn1n8Cnkz9rjkizsHg4EZjkRnpZKvKUXEfgNrHjc9zs5AbWjfuMQLocQN3Drb7 DNBU46ws1G5hSmbUYkEMmq6jRyGQ

Viz.

[Supercomputing]

...Coinshield has upgraded the private keys to a non prime based elliptical curve encryption of 571 bits...

What are the domain parameters for the curve that you are using? I assumed that they are not the same as the parameters used for secp571r1 which happens to be a prime based curve.

[Videlicet]

...Coinshield has upgraded the private keys to a non prime based elliptical curve encryption of 571 bits...

What are the domain parameters for the curve that you are using? I assumed that they are not the same as the parameters used for secp571r1 which happens to be a prime based curve.

From what I understand from my research, they are random domain parameters hence the r where secp256k1 uses a Koblitz curve for domain parameters hence the k.

From OpenSSL Source Code: https://github.com/luvit/openssl/blob/master/openssl/crypto/ec/ec_curve.c
Coinshield:  Line 1890: { NID_sect571r1, &_EC_NIST_CHAR2_571B.h, 0, "NIST/SECG curve over a 571 bit binary field" },
Bitcoin:       Line 1850: { NID_secp256k1, &_EC_SECG_PRIME_256K1.h, 0, "SECG curve over a 256 bit prime field" },

Largest Prime based secp is: Line 1854: { NID_secp521r1, &_EC_NIST_PRIME_521.h, 0, "NIST/SECG curve over a 521 bit prime field" }

Thank You,
Viz.

[Supercomputing]

...Coinshield has upgraded the private keys to a non prime based elliptical curve encryption of 571 bits...

What are the domain parameters for the curve that you are using? I assumed that they are not the same as the parameters used for secp571r1 which happens to be a prime based curve.

From what I understand from my research, they are random domain parameters hence the r where secp256k1 uses a Koblitz curve for domain parameters hence the k.

From OpenSSL Source Code: https://github.com/luvit/openssl/blob/master/openssl/crypto/ec/ec_curve.c
Coinshield:  Line 1890: { NID_sect571r1, &_EC_NIST_CHAR2_571B.h, 0, "NIST/SECG curve over a 571 bit binary field" },
Bitcoin:       Line 1850: { NID_secp256k1, &_EC_SECG_PRIME_256K1.h, 0, "SECG curve over a 256 bit prime field" },

Largest Prime based secp is: Line 1854: { NID_secp521r1, &_EC_NIST_PRIME_521.h, 0, "NIST/SECG curve over a 521 bit prime field" }

Thank You,
Viz.

Thanks Viz, I understand now. There is a typo in your original posting.

...The exact algorithm Coinshield uses is secp571r1 compared to sect256k1 that is utilized by most cryptocurrencies today...

[skunk]

thank you viz, i'm sure the posts above will contribute increase trust in this coin until the code will made public, meanwhile it would be a good idea to merge them into a faq (even expanding the qa at the end of the op would be fine) just for giving more value to the time spent by you answering and making answers more accessible...

[Videlicet]

Supercomputing,

Yes sir, I noticed this when you brought it up, Thank You for catching it. Krypto Kash will update the OP. I'll update the site.


-----------------------


skunk,

Thank you, yes this is a good idea. I'll start a FAQ section with these answers on coinshieldtalk support. We'll link that from the OP, this way if the question arises again I can provide links, or someone else who is also aware of the FAQ section.

Thank You,
Viz.

[kev7112001]

is the diff 4.7 block 15848

[Videlicet]

Current Block 15938: Difficulty 6.125768

E-Mail me your debug.log, clear your app data minus wallet.dat, download 1.0.1a, resync
Viz.