Topic: [LAUNCH CANCELLED] - page 2. (Read 10669 times)
Right... but wouldn't it be the same for the multithreaded client? ProcessBlock will still be slow. Single-threaded it'll still only work on at most 1 stale block (the one it's working on when a block comes in), which is the same if it were multithreaded (the miner would still only work on at most 1 stale block, the one it's working on when a block comes in).
On newer versions of windows, the technique used to keep the hashing single-threaded sometimes doesn't allow processblock to run for tens of seconds at a time while mining. This is an OS-specific behaviour.
seems a new algorithm, but how to mine , solo or pool, the information is so lack
Since ProcessBlock is so slow, there is a window where a new block will arrive for processing while the miner is working off stale data (assuming the incoming block is valid). Slow hash validation was one of the objections that the Litecoin devs had to switching from scrypt to X11, even though X11 isn't all that slow.
Right... but wouldn't it be the same for the multithreaded client? ProcessBlock will still be slow. Single-threaded it'll still only work on at most 1 stale block (the one it's working on when a block comes in), which is the same if it were multithreaded (the miner would still only work on at most 1 stale block, the one it's working on when a block comes in). Interesting. That makes sense to at least let people with the resources to use them all to mine from just one node. Though if someone doesn't have 3.2 gigs to spare they should still be able to run with just 1 thread.
So with the threading issue the following happens:
- Miner starts hashing what will be a valid block
- New block comes in, ProcessBlock locks on the hash part
- Miner finishes, creates orphan block & broadcasts
- ProcessBlock finishes, now the wallet realizes it was an orphan
But wait if you have two threads won't the same thing happen? Since ProcessBlock came later, even if it's running simultaneously in a separate thread, it'll still finish after the miner generates the block already.
And how likely is this? It only happens if you happen to hit the 1 in 512 (or whatever it ended up being) jackpot right when a block comes in. Although granted the blocks were coming pretty quickly.
Since ProcessBlock is so slow, there is a window where a new block will arrive for processing while the miner is working off stale data (assuming the incoming block is valid). Slow hash validation was one of the objections that the Litecoin devs had to switching from scrypt to X11, even though X11 isn't all that slow. Maybe the block time could be increased to compensate? I don't know the theory behind block times...
I think the biggest problems with the launch were caused by the threading problem in the client. Since only 1 hashing thread at a time can be run out-of-the-box there were two problems:
1> people with multiple cores had to start multiple instances of the daemon, which caused high amounts of connections between nodes
2> when mining from the daemon, the mining thread caused the processblock thread to stall frequently. This would wedge incoming blocks and cause orphans to be mined by the miner thread, along with slow relaying of blocks across the network.
The dev needs to AT LEAST allow concurrency between hashing for mining and running processblock. Memory usage will be doubled, however. If it's launched without a fix for this the same thing will happen.
Since I modifed my daemon to workaround this problem, I was able to obtain a good amount of non-orphaned blocks from the start with only a few processors -- even so, I'm looking forward to the relaunch!
1> people with multiple cores had to start multiple instances of the daemon, which caused high amounts of connections between nodes
2> when mining from the daemon, the mining thread caused the processblock thread to stall frequently. This would wedge incoming blocks and cause orphans to be mined by the miner thread, along with slow relaying of blocks across the network.
The dev needs to AT LEAST allow concurrency between hashing for mining and running processblock. Memory usage will be doubled, however. If it's launched without a fix for this the same thing will happen.
Since I modifed my daemon to workaround this problem, I was able to obtain a good amount of non-orphaned blocks from the start with only a few processors -- even so, I'm looking forward to the relaunch!
This will also be fixed, I will change the mining algorithm will multithread and use all available cores efficiently, so only one chain will be necessary.
what's the algorithm of this coin?? different from other coins??
I think the biggest problems with the launch were caused by the threading problem in the client. Since only 1 hashing thread at a time can be run out-of-the-box there were two problems:
1> people with multiple cores had to start multiple instances of the daemon, which caused high amounts of connections between nodes
2> when mining from the daemon, the mining thread caused the processblock thread to stall frequently. This would wedge incoming blocks and cause orphans to be mined by the miner thread, along with slow relaying of blocks across the network.
The dev needs to AT LEAST allow concurrency between hashing for mining and running processblock. Memory usage will be doubled, however. If it's launched without a fix for this the same thing will happen.
Since I modifed my daemon to workaround this problem, I was able to obtain a good amount of non-orphaned blocks from the start with only a few processors -- even so, I'm looking forward to the relaunch!
Interesting. That makes sense to at least let people with the resources to use them all to mine from just one node. Though if someone doesn't have 3.2 gigs to spare they should still be able to run with just 1 thread. 1> people with multiple cores had to start multiple instances of the daemon, which caused high amounts of connections between nodes
2> when mining from the daemon, the mining thread caused the processblock thread to stall frequently. This would wedge incoming blocks and cause orphans to be mined by the miner thread, along with slow relaying of blocks across the network.
The dev needs to AT LEAST allow concurrency between hashing for mining and running processblock. Memory usage will be doubled, however. If it's launched without a fix for this the same thing will happen.
Since I modifed my daemon to workaround this problem, I was able to obtain a good amount of non-orphaned blocks from the start with only a few processors -- even so, I'm looking forward to the relaunch!
So with the threading issue the following happens:
- Miner starts hashing what will be a valid block
- New block comes in, ProcessBlock locks on the hash part
- Miner finishes, creates orphan block & broadcasts
- ProcessBlock finishes, now the wallet realizes it was an orphan
But wait if you have two threads won't the same thing happen? Since ProcessBlock came later, even if it's running simultaneously in a separate thread, it'll still finish after the miner generates the block already.
And how likely is this? It only happens if you happen to hit the 1 in 512 (or whatever it ended up being) jackpot right when a block comes in. Although granted the blocks were coming pretty quickly.
I think the biggest problems with the launch were caused by the threading problem in the client. Since only 1 hashing thread at a time can be run out-of-the-box there were two problems:
1> people with multiple cores had to start multiple instances of the daemon, which caused high amounts of connections between nodes
2> when mining from the daemon, the mining thread caused the processblock thread to stall frequently. This would wedge incoming blocks and cause orphans to be mined by the miner thread, along with slow relaying of blocks across the network.
The dev needs to AT LEAST allow concurrency between hashing for mining and running processblock. Memory usage will be doubled, however. If it's launched without a fix for this the same thing will happen.
Since I modifed my daemon to workaround this problem, I was able to obtain a good amount of non-orphaned blocks from the start with only a few processors -- even so, I'm looking forward to the relaunch!
1> people with multiple cores had to start multiple instances of the daemon, which caused high amounts of connections between nodes
2> when mining from the daemon, the mining thread caused the processblock thread to stall frequently. This would wedge incoming blocks and cause orphans to be mined by the miner thread, along with slow relaying of blocks across the network.
The dev needs to AT LEAST allow concurrency between hashing for mining and running processblock. Memory usage will be doubled, however. If it's launched without a fix for this the same thing will happen.
Since I modifed my daemon to workaround this problem, I was able to obtain a good amount of non-orphaned blocks from the start with only a few processors -- even so, I'm looking forward to the relaunch!
I am not lying and no i will not say how to gain advantage and mine at low difficulty with less orphans.
Good luck with the next launch suckers.
Good luck with the next launch suckers.
Quote
You didn't answer my question. And you are lying. The linux daemon I compiled connected to 2 peers sometimes, and the windows one instacash posted ended up connecting to 4 peers. Even if it were true, that doesn't answer why *your node* had access to the seed node, but nobody else did.
Maybe he just got connected before anyone else and had enough instances running to overload it?
Also I just checked out the peercoin repository and compared it with the shinycoin code I still have, and I see no significant differences in net.cpp or net.h . If peercoin's wallet isn't broken re: connecting to peers, then neither is shinycoin.
Honestly, it'd be way easier to redistribute the holdings of you and primer(I think?) than it would be to relaunch the coin... Since apparently crypto has gone egalitarian.
But hey, everyone wants to relaunch and spend more money to mine the coin. Doesn't make sense to me.
But hey, everyone wants to relaunch and spend more money to mine the coin. Doesn't make sense to me.
Since primer- was the one to DDoS I'm not shedding a tear for him.
I'm not really taking sides here, but it seems to me that there was not any intentional DDoS. The node was simply not capable of handling the traffic from the start, and the wallet didn't allow for p2p connections. Eh, oh well.
Quote
You didn't answer my question. And you are lying. The linux daemon I compiled connected to 2 peers sometimes, and the windows one instacash posted ended up connecting to 4 peers. Even if it were true, that doesn't answer why *your node* had access to the seed node, but nobody else did.
Maybe he just got connected before anyone else and had enough instances running to overload it?
You are a one incompetent idiot. I've had nothing to do with the DDoS. I dedicated an entire 8core server to run as a node only as the seeds you hardcoded were dead at block 5.
Good luck with this retard guys, i would not let him change my tire, let alone develop an e-currency.
Why could your node connect to the seed but nobody else could? My daemon would disconnect the seed as soon as it connected, it kept trying but never succeeded. Don't see why an 8-core server would have better luck with it. Good luck with this retard guys, i would not let him change my tire, let alone develop an e-currency.
I had the code changed to connect to more peers at once which the original broken wallet was not capable of. There is absolutely no truth in his claims.
You are a one incompetent idiot. I've had nothing to do with the DDoS. I dedicated an entire 8core server to run as a node only as the seeds you hardcoded were dead at block 5.
Good luck with this retard guys, i would not let him change my tire, let alone develop an e-currency.
Why could your node connect to the seed but nobody else could? My daemon would disconnect the seed as soon as it connected, it kept trying but never succeeded. Don't see why an 8-core server would have better luck with it. Good luck with this retard guys, i would not let him change my tire, let alone develop an e-currency.
I had the code changed to connect to more peers at once which the original broken wallet was not capable of. There is absolutely no truth in his claims.
You are a one incompetent idiot. I've had nothing to do with the DDoS. I dedicated an entire 8core server to run as a node only as the seeds you hardcoded were dead at block 5.
Good luck with this retard guys, i would not let him change my tire, let alone develop an e-currency.
Why could your node connect to the seed but nobody else could? My daemon would disconnect the seed as soon as it connected, it kept trying but never succeeded. Don't see why an 8-core server would have better luck with it. Good luck with this retard guys, i would not let him change my tire, let alone develop an e-currency.
Honestly, it'd be way easier to redistribute the holdings of you and primer(I think?) than it would be to relaunch the coin... Since apparently crypto has gone egalitarian.
But hey, everyone wants to relaunch and spend more money to mine the coin. Doesn't make sense to me.
But hey, everyone wants to relaunch and spend more money to mine the coin. Doesn't make sense to me.
Since primer- was the one to DDoS I'm not shedding a tear for him.
You are a one incompetent idiot. I've had nothing to do with the DDoS. I dedicated an entire 8core server to run as a node only as the seeds you hardcoded were dead at block 5.
Good luck with this retard guys, i would not let him change my tire, let alone develop an e-currency.
Honestly, it'd be way easier to redistribute the holdings of you and primer(I think?) than it would be to relaunch the coin... Since apparently crypto has gone egalitarian.
But hey, everyone wants to relaunch and spend more money to mine the coin. Doesn't make sense to me.
But hey, everyone wants to relaunch and spend more money to mine the coin. Doesn't make sense to me.
Since primer- was the one to DDoS I'm not shedding a tear for him.
Thank you everyone for the feedback. At relaunch will be properly prepared.
I will get the following sorted/done and relaunch.
1) I will have working web wallet and website. As the blockchain gets longer if downloading the entire blockchain for the first time it may take a long time to verify the blockchain because the ramhog algorithm requires multiple scratchpads to verify a hash.
2) I will add support for looking up a wallet userid on both the client and website. Adding a userid to an address is working, but there wasnt the functionality of lookup on the client
3) I will have source as well as linux, windows, and mac binaries on github well before launch. At the time of launch will release a config file with genesis block and will release exact time of launch.
4) I will modify the algorithm to scale up the amount of coin released linearly for the first two days, so that someone mining starting an hour in doesn't miss much.
5) I will seed many servers to prevent the DDoS nonsense
6) Currently looking into setting up p2p mining pool, will let everyone know about that.
Will post times of code and launch when I know exactly. Shouldn't be too long.
I will get the following sorted/done and relaunch.
1) I will have working web wallet and website. As the blockchain gets longer if downloading the entire blockchain for the first time it may take a long time to verify the blockchain because the ramhog algorithm requires multiple scratchpads to verify a hash.
2) I will add support for looking up a wallet userid on both the client and website. Adding a userid to an address is working, but there wasnt the functionality of lookup on the client
3) I will have source as well as linux, windows, and mac binaries on github well before launch. At the time of launch will release a config file with genesis block and will release exact time of launch.
4) I will modify the algorithm to scale up the amount of coin released linearly for the first two days, so that someone mining starting an hour in doesn't miss much.
5) I will seed many servers to prevent the DDoS nonsense
6) Currently looking into setting up p2p mining pool, will let everyone know about that.
Will post times of code and launch when I know exactly. Shouldn't be too long.
That's cool, i registered the reddit if you tell me your username i'll make you a mod there and you should probably look into hanging out in the #shinycoin channel on freenode during dev/launch. At least to work out the first few bugs.
Thank you everyone for the feedback. At relaunch will be properly prepared.
I will get the following sorted/done and relaunch.
1) I will have working web wallet and website. As the blockchain gets longer if downloading the entire blockchain for the first time it may take a long time to verify the blockchain because the ramhog algorithm requires multiple scratchpads to verify a hash.
2) I will add support for looking up a wallet userid on both the client and website. Adding a userid to an address is working, but there wasnt the functionality of lookup on the client
3) I will have source as well as linux, windows, and mac binaries on github well before launch. At the time of launch will release a config file with genesis block and will release exact time of launch.
4) I will modify the algorithm to scale up the amount of coin released linearly for the first two days, so that someone mining starting an hour in doesn't miss much.
5) I will seed many servers to prevent the DDoS nonsense
6) Currently looking into setting up p2p mining pool, will let everyone know about that.
Will post times of code and launch when I know exactly. Shouldn't be too long.
I will get the following sorted/done and relaunch.
1) I will have working web wallet and website. As the blockchain gets longer if downloading the entire blockchain for the first time it may take a long time to verify the blockchain because the ramhog algorithm requires multiple scratchpads to verify a hash.
2) I will add support for looking up a wallet userid on both the client and website. Adding a userid to an address is working, but there wasnt the functionality of lookup on the client
3) I will have source as well as linux, windows, and mac binaries on github well before launch. At the time of launch will release a config file with genesis block and will release exact time of launch.
4) I will modify the algorithm to scale up the amount of coin released linearly for the first two days, so that someone mining starting an hour in doesn't miss much.
5) I will seed many servers to prevent the DDoS nonsense
6) Currently looking into setting up p2p mining pool, will let everyone know about that.
Will post times of code and launch when I know exactly. Shouldn't be too long.
Honestly, it'd be way easier to redistribute the holdings of you and primer(I think?) than it would be to relaunch the coin... Since apparently crypto has gone egalitarian.
But hey, everyone wants to relaunch and spend more money to mine the coin. Doesn't make sense to me.
But hey, everyone wants to relaunch and spend more money to mine the coin. Doesn't make sense to me.
Jump to: