Nvidia cuda miner available from start ?
I'm working on the AMD miner first. I'm setting it up for easy CUDA integration.
If I have time I will implement the CUDA portion but ensuring the AMD miner works efficiently comes first.
Topic: Nexus - Pure SHA3 + CPU/GPU + nPoS + 15 Active Innovations + More to Come - page 369. (Read 785531 times)
August 23, 2014, 04:43:37 PM
I'm working on the AMD miner first. I'm setting it up for easy CUDA integration.
If I have time I will implement the CUDA portion but ensuring the AMD miner works efficiently comes first.
August 23, 2014, 03:48:55 PM
Watching this coin.
August 23, 2014, 03:42:20 PM
Nvidia cuda miner available from start ?
August 22, 2014, 04:07:18 PM
August 20, 2014, 07:13:09 PM
With these updates my best estimate is next week.
After reading that, I think you may need till next month or longer, and would also suggest you move development to something open like github so that people can help you test and contribute along the way.
This isn't an alt coin, it's a new set of technology, you need more time and more eyes to do this correctly.
Keep up the good work, and please to keep things positive and for your own sanity, move it to be considered as a software development project until tested and proven, and then turn it in to a currency.
I wanted to help you test and couldn't as I didn't know what the binaries you sent contained, we need source to compile, honestly nobody will steal or can steal it, as it's under development and would take anybody weeks to catch up to your understanding of your own code.
Best of luck,
Mark
August 20, 2014, 06:36:09 PM
I like to see there is no absence of humor on this thread 
As for a time frame on launch, here is an update, and my best prediction.
I. Lower Level Protocol
I've spent the last week building the lower level protocol. It handles any amount of connections, and processes up to 50k requests per second on my local computer. Implemented in a basic DDOS protection detecting request acceleration and velocity per address, to detect any large "traffic spikes" which usually come from a DDOS attack.
Now, I spent quite a bit of time designing the LLP to be portable, and expandable. This is achieved by using template classes for the Client / Server to allow anybody to build a new protocol with ease. It simply requires you to construct your own packet type class with a packet processor Funcion PacketType Process(); the template classes handle all the data processing and messaging using your packet type. Inside your custom Process function is where all the magic will happen by interpreting the header, and sending data responses. This allows for different structures inside the packet to be interpreted differently by different customized protocols.
So with that, I built two Messaging Protocols on top of the LLP Templates.
Core LLP:
The Core LLP will allow a client to get their External IP, a Unified Time Seed, or a list of recent Peers. This keeps address seeding away from the main Coinshield Messaging system [as Bitcoin uses an IRC channel]. This LLP can also be used for the Automatic Updates.
Mining LLP:
The Mining LLP will act to replace Getblocktemplate and Getwork. It will allow an external miner to interact with the Coinshield Network, without the need for the RPC server [RPC Server will still process non mining requests]. The Mining LLP will broadcast new blocks to miners [reducing stale shares], accept new blocks, customize coinbase tx [a little later], etc. This will simplify the networking required to build an external miner, and reduce the overhead associated with boost serialization [from old mining protocol]. This will keep the mining as efficient as possible.
II. Decentralized Checkpointing
Will get to this once LLP is woven into Coinshield Core.
III. POS Timed Release
Mostly done with core components, still need to tune the coinstake reward and implement release in blockchain.
IV. External CPU / GPU Miner
As far as I know Bitslapper has the Kernal hashing working. I will be sending him an LLP Mining Client so he can integrate that into his miner. CPU Miner is done, just needs to be woven with LLP Mining Client. Not far off once LLP is integrated into Coinshield Core.
With these updates my best estimate is next week, but I think we all know how accurate my estimates can be [this doesn't always mean longer]
Viz.
edit: added more detail about LLP templates
As for a time frame on launch, here is an update, and my best prediction.
I. Lower Level Protocol
I've spent the last week building the lower level protocol. It handles any amount of connections, and processes up to 50k requests per second on my local computer. Implemented in a basic DDOS protection detecting request acceleration and velocity per address, to detect any large "traffic spikes" which usually come from a DDOS attack.
Now, I spent quite a bit of time designing the LLP to be portable, and expandable. This is achieved by using template classes for the Client / Server to allow anybody to build a new protocol with ease. It simply requires you to construct your own packet type class with a packet processor Funcion PacketType Process(); the template classes handle all the data processing and messaging using your packet type. Inside your custom Process function is where all the magic will happen by interpreting the header, and sending data responses. This allows for different structures inside the packet to be interpreted differently by different customized protocols.
So with that, I built two Messaging Protocols on top of the LLP Templates.
Core LLP:
The Core LLP will allow a client to get their External IP, a Unified Time Seed, or a list of recent Peers. This keeps address seeding away from the main Coinshield Messaging system [as Bitcoin uses an IRC channel]. This LLP can also be used for the Automatic Updates.
Mining LLP:
The Mining LLP will act to replace Getblocktemplate and Getwork. It will allow an external miner to interact with the Coinshield Network, without the need for the RPC server [RPC Server will still process non mining requests]. The Mining LLP will broadcast new blocks to miners [reducing stale shares], accept new blocks, customize coinbase tx [a little later], etc. This will simplify the networking required to build an external miner, and reduce the overhead associated with boost serialization [from old mining protocol]. This will keep the mining as efficient as possible.
II. Decentralized Checkpointing
Will get to this once LLP is woven into Coinshield Core.
III. POS Timed Release
Mostly done with core components, still need to tune the coinstake reward and implement release in blockchain.
IV. External CPU / GPU Miner
As far as I know Bitslapper has the Kernal hashing working. I will be sending him an LLP Mining Client so he can integrate that into his miner. CPU Miner is done, just needs to be woven with LLP Mining Client. Not far off once LLP is integrated into Coinshield Core.
With these updates my best estimate is next week, but I think we all know how accurate my estimates can be [this doesn't always mean longer]
Viz.
edit: added more detail about LLP templates
August 20, 2014, 01:38:54 PM
LoL 
0
0
I wonder which one will be released first?
Half Life 3 or this.
Half Life 3 or this.
August 20, 2014, 11:36:06 AM
I wonder which one will be released first?
Half Life 3 or this.
Half Life 3 or this.
August 20, 2014, 09:39:19 AM
I lost interest for this coin. Hope that launch will be this year
August 19, 2014, 02:18:18 PM
Any news about launch?
August 14, 2014, 04:37:03 PM
Is this going to be launched while i am still young? 
No seriously, how much more time do you need to finish coin?
No seriously, how much more time do you need to finish coin?
August 12, 2014, 12:59:10 PM
IV and V?
V. Automatic Updating: Not sure if I will get to this pre-launch or post-launch.
I'm concentrating mainly on III and IV at the moment. We'll see about V when those are complete.
Viz.
Thanks for clarifying. I was confused because you said "last two" but then "III && IV".
August 12, 2014, 07:04:06 AM
IV and V?
V. Automatic Updating: Not sure if I will get to this pre-launch or post-launch.
I'm concentrating mainly on III and IV at the moment. We'll see about V when those are complete.
Viz.
August 12, 2014, 06:30:14 AM
I will keep everyone posted on the progress of these last two components [III && IV], and will always accept suggestions for further optimization as I approach completion.
IV and V?
August 12, 2014, 02:12:29 AM
It seems I am overdue for an [Update]:
I. Organization: Rebuilt Coinshield Core from Source, organized code into Namespaces [Core, Net, Wallet], restructured filesystems, relinked headers. Made the build more "hardy" giving more precise "instruction"; this speeds up productivity and from my results slightly increases runtime execution.
II. Qt Development: Fixed issues in Qt. Added styling to dress it up in presentation. TODO [Post Launch] Add theme options to set your color themes / eventually add skins to the Qt for more personalization.
III. Unified Time: Working on lower level network protocol for Unified Time. This will allow more precision and greater tuning with connection latency, etc. Updated the UNIFIED_TIME_OFFSET to not be created from connected peers/seeds, but to be a consistent growing average in the TimeDB. This will strengthen your UNIFIED_TIME, eventually getting everyone synchronized as close as I can get it. I want to bring down the UNIFIED_ALLOWED_DRIFT to < 5 seconds to reduce impact from Time Warp attacks. This average will also cause any Bad Time Seed to have little influence on your overall Unified Time.
IV. Decentralized Checkpointing: I do not like the code for Checkpointing in Peercoin, because it is based off of a "Master" node broadcasting the Checkpoints. I would like to keep the Network as decentralized as possible, so this has led me to design a Decentralized Checkpointing Feature. Here is a basic rundown of how it will work.
After 60 minutes, the next block produced will be flagged by all nodes as a "pending checkpoint". After 30 minutes, all nodes will broadcast this checkpoint. In order for your node to change its pending checkpoint, it will have to receive a checkpoint different than yours, and from the majority of your peers. This will make the checkpointing based on a majority consensus by the nodes, reducing an attackers impact on the Main Chain. This is because it puts the effort of an attack in mining power and the sheer number of nodes agreeing on that chain.
Finally after 30 minutes of the "pending checkpoint" broadcast, that checkpoint will become hardened, and a new pending checkpoint will be flagged. The time between checkpoints, and corresponding block number will also be a fingerprint, because for the checkpoint to be accepted by other nodes as valid, it will require that block to be produced within the proper beginning of minute 60 and also hold a majority acceptance by the network.
V. Automatic Updating: Not sure if I will get to this pre-launch or post-launch. It will give you a message box on startup alerting you that there is a new update for Coinshield Core, and what is included in the new update. Upon acceptance, the update will be downloaded only from a trusted source [seed nodes], and it must contain a trusted signature [signed by private keys I will hold]. This will expedite the process of network updates, and ease the process for the everyday user. This would also prompt me to remove the Alerts Broadcasting System [local alerts will remain] as it would not be needed anymore. Final option will be for "automaticupdates=1" in coinshield.conf to automatically download and install verified updates.
I will keep everyone posted on the progress of these last two components [III && IV], and will always accept suggestions for further optimization as I approach completion.
Thank You to Everyone for your continued patience... we are almost there!
Viz.
edit: slight rewording
I. Organization: Rebuilt Coinshield Core from Source, organized code into Namespaces [Core, Net, Wallet], restructured filesystems, relinked headers. Made the build more "hardy" giving more precise "instruction"; this speeds up productivity and from my results slightly increases runtime execution.
II. Qt Development: Fixed issues in Qt. Added styling to dress it up in presentation. TODO [Post Launch] Add theme options to set your color themes / eventually add skins to the Qt for more personalization.
III. Unified Time: Working on lower level network protocol for Unified Time. This will allow more precision and greater tuning with connection latency, etc. Updated the UNIFIED_TIME_OFFSET to not be created from connected peers/seeds, but to be a consistent growing average in the TimeDB. This will strengthen your UNIFIED_TIME, eventually getting everyone synchronized as close as I can get it. I want to bring down the UNIFIED_ALLOWED_DRIFT to < 5 seconds to reduce impact from Time Warp attacks. This average will also cause any Bad Time Seed to have little influence on your overall Unified Time.
IV. Decentralized Checkpointing: I do not like the code for Checkpointing in Peercoin, because it is based off of a "Master" node broadcasting the Checkpoints. I would like to keep the Network as decentralized as possible, so this has led me to design a Decentralized Checkpointing Feature. Here is a basic rundown of how it will work.
After 60 minutes, the next block produced will be flagged by all nodes as a "pending checkpoint". After 30 minutes, all nodes will broadcast this checkpoint. In order for your node to change its pending checkpoint, it will have to receive a checkpoint different than yours, and from the majority of your peers. This will make the checkpointing based on a majority consensus by the nodes, reducing an attackers impact on the Main Chain. This is because it puts the effort of an attack in mining power and the sheer number of nodes agreeing on that chain.
Finally after 30 minutes of the "pending checkpoint" broadcast, that checkpoint will become hardened, and a new pending checkpoint will be flagged. The time between checkpoints, and corresponding block number will also be a fingerprint, because for the checkpoint to be accepted by other nodes as valid, it will require that block to be produced within the proper beginning of minute 60 and also hold a majority acceptance by the network.
V. Automatic Updating: Not sure if I will get to this pre-launch or post-launch. It will give you a message box on startup alerting you that there is a new update for Coinshield Core, and what is included in the new update. Upon acceptance, the update will be downloaded only from a trusted source [seed nodes], and it must contain a trusted signature [signed by private keys I will hold]. This will expedite the process of network updates, and ease the process for the everyday user. This would also prompt me to remove the Alerts Broadcasting System [local alerts will remain] as it would not be needed anymore. Final option will be for "automaticupdates=1" in coinshield.conf to automatically download and install verified updates.
I will keep everyone posted on the progress of these last two components [III && IV], and will always accept suggestions for further optimization as I approach completion.
Thank You to Everyone for your continued patience... we are almost there!
Viz.
edit: slight rewording
August 11, 2014, 09:26:43 AM
Any news about launch date?
Videlicet will release a launch date soon. cancelled scam?
Videlicet is currently in the final stages of coding. I'll ask him to post an update shortly.
A launch date will be released very very soon.
I really hope that you guys will deliver and make us happy for waiting so long
August 10, 2014, 04:33:11 PM
Any news about launch date?
Videlicet will release a launch date soon. cancelled scam?
Videlicet is currently in the final stages of coding. I'll ask him to post an update shortly.
A launch date will be released very very soon.
August 10, 2014, 04:17:29 PM
Any news about launch date?
cancelled scam? August 10, 2014, 03:05:02 AM
Any news about launch date?
August 09, 2014, 12:26:45 PM
Because we've already been through this loop.
You're right, circles are superfluous. Thank you for your feedback.
Viz.
Jump to: