[*] 8BIT [Dark Masternodes][Anon][Roadmap Stage 4] - page 156.

skidog

legendary

Activity: 1393

Merit: 1001

Quote from: 8-bit-Party on July 19, 2015, 03:53:56 PM

I guess many of you are curious why last days I was not as active here as before.
So, first I am not scammer nor serial scammer so I did not have qt wallet compilation ready enviroments ready. Therefore I am busy with creating and testing those enviroments as well as creating a right gitian specs since those you can find on bitbucket are completely irrelevant. For instance, they say that used qt version is 4.x while wallet requires version 5. Actually all gitian descriptors are heavy outdated. It's not a problem for me, it just requires extra work. Like I said my primary client is non-qt daemon so those works are not show stoppers.

Second, testing. Me and three other community members who actively requested access to my testnet are testing new code and different scenarios (who said it's guaranted that everyone will update their client on time? we don't assume anything, we test). I will send inviations to some of you soon.

Third, I planned to make final public release next week with hardcoded hardfork 2-3 weeks later to make sure people will update without hurry. Now I see that hardfork will have to be made immediately (1-2 days) after public release. So just stay tunned and during incoming week (UTC) do not transfer your coins without reading latest news here first. Thanks for your cooperation!

Thank you for your support...

Dimitry

hero member

Activity: 896

Merit: 501

Quote from: 8-bit-Party on July 19, 2015, 03:53:56 PM

I guess many of you are curious why last days I was not as active here as before.
So, first I am not scammer nor serial scammer so I did not have qt wallet compilation ready enviroments ready. Therefore I am busy with creating and testing those enviroments as well as creating a right gitian specs since those you can find on bitbucket are completely irrelevant. For instance, they say that used qt version is 4.x while wallet requires version 5. Actually all gitian descriptors are heavy outdated. It's not a problem for me, it just requires extra work. Like I said my primary client is non-qt daemon so those works are not show stoppers.

Second, testing. Me and three other community members who actively requested access to my testnet are testing new code and different scenarios (who said it's guaranted that everyone will update their client on time? we don't assume anything, we test). I will send inviations to some of you soon.

Third, I planned to make final public release next week with hardcoded hardfork 2-3 weeks later to make sure people will update without hurry. Now I see that hardfork will have to be made immediately (1-2 days) after public release. So just stay tunned and during incoming week (UTC) do not transfer your coins without reading latest news here first. Thanks for your cooperation!

Great! community is not in a hurry and things shouldn't be rushed!

testing needs time, better safe than sorry! Keep up the good work! Love you guys (girls) Cool

8-bit-Party

legendary

Activity: 1036

Merit: 1000

8b 16b DEMOSCENE FTW

I guess many of you are curious why last days I was not as active here as before.
So, first I am not scammer nor serial scammer so I did not have qt wallet compilation ready enviroments ready. Therefore I am busy with creating and testing those enviroments as well as creating a right gitian specs since those you can find on bitbucket are completely irrelevant. For instance, they say that used qt version is 4.x while wallet requires version 5. Actually all gitian descriptors are heavy outdated. It's not a problem for me, it just requires extra work. Like I said my primary client is non-qt daemon so those works are not show stoppers.

Second, testing. Me and three other community members who actively requested access to my testnet are testing new code and different scenarios (who said it's guaranted that everyone will update their client on time? we don't assume anything, we test). I will send inviations to some of you soon.

Third, I planned to make final public release next week with hardcoded hardfork 2-3 weeks later to make sure people will update without hurry. Now I see that hardfork will have to be made immediately (1-2 days) after public release. So just stay tunned and during incoming week (UTC) do not transfer your coins without reading latest news here first. Thanks for your cooperation!

skidog

legendary

Activity: 1393

Merit: 1001

Quote from: ?? on ??

Quote from: 8-bit-Party on July 18, 2015, 08:10:16 AM

Nope. MNs actually don't affect blockchain much.
Moreover, as long as you are not fully synced your client does not care about MN (eg he does not ask other peers for MNs list).

Your syncing issues are because of forks horde on the beginning and lack of checkpoints.

yep, extremely slow synching, very odd database behavior, exactly the same as SPHR coin,
so i had to delete both, total waste of sunshine and neural energy

After it's synced, it should all work OK. This should all be fixed after the next wallet update.

8-bit-Party

legendary

Activity: 1036

Merit: 1000

8b 16b DEMOSCENE FTW

MN codebase is not excellent, it has minor drawbacks, but they are not dangerous to coin nor they can affect syncing.

drays

legendary

Activity: 2576

Merit: 1073

Quote from: 8-bit-Party on July 18, 2015, 08:10:16 AM

Nope. MNs actually don't affect blockchain much.
Moreover, as long as you are not fully synced your client does not care about MN (eg he does not ask other peers for MNs list).

Your syncing issues are because of forks horde on the beginning and lack of checkpoints.

I didn't mean this is because of MN themselves, just I thought maybe the codebase of the coin's with MN could be different, eg. they could be forked from different version of bitcoin core, or some other specific coin which introduced some changes causing the blockchain validation slowness...

Anyway, lets see if this is fixed with the new wallet and its new checkpoint. If it gets fixed, then you are correct, and I'll very happily accept that

. You even could tell "next time listen what I tell" then Grin

8-bit-Party

legendary

Activity: 1036

Merit: 1000

8b 16b DEMOSCENE FTW

Nope. MNs actually don't affect blockchain much.
Moreover, as long as you are not fully synced your client does not care about MN (eg he does not ask other peers for MNs list).

Your syncing issues are because of forks horde on the beginning and lack of checkpoints.

drays

legendary

Activity: 2576

Merit: 1073

Quote from: allZuckedUp on July 17, 2015, 03:20:46 PM

I've noticed several other coins sync MUCH faster on the same bandwidth, on the same machines on my end, and often with many more blocks to sync than 8bit. Also, when the blockchain is syncing (not a little sync, a big one, new wallet, weeks worth to go) the wallet application will become unresponsive for several minutes at a time (again, both Linux and windows). You can see from the debug.log that it's still working, but even just a getinfo call on the linux side will take up to 10 minutes to respond sometimes, and the qt GUI on the windows just says "not responding" in the title-bar. In either case a single wallet will rip up the cpu as well, 100% used. Both the unresponsiveness and cpu usage do go away once the wallet is synced, and small syncs (just a day or two of blockchain data) don't seem to cause this problem.

Soooo, I do not know if that slowness is a part of the technologies being employed here on 8bit, if the block sizes or complexity differs significantly, or if there's something that can be fixed in the code. But, I've seen a few other similar observations in this thread and wanted to pipe up as well.

This is very good description of what I was experiencing with 8bit wallet from the very beginning. Truly saying, I don't think this is because of lack of checkpoints (because it was the same when the coin just started), but time will show.

What I have indeed noticed, is the following:

8bit was the first MN coin I was following, and it was extremely slow to sync. Since that I noticed that exactly the same syncing behavior can be observed on other new MN coins I have followed (there were 2 of them). Non-MN coins sync pretty fast on the same machines, both new and old ones (right at the moment I run Vibranium wallet, which freezes the operation of explorer from time to time, just like 8bit wallet does).

Here I have a question to 8-bit-Party, as he seems to be very knowledgeable on the internals of the latest blockchain tech. Are MN coins much different from regular ones when it comes to block validation, or blockchain sync? Do they use a different code base? They seem to be much more heavy on CPU, and tend to freeze the wallet and slowdown the PC (right at this moment I have Vibranium wallet running on my PC, and it freezes up explorer from time to time, just like 8bit wallet does).

8-bit-Party

legendary

Activity: 1036

Merit: 1000

8b 16b DEMOSCENE FTW

Great, so we have second block explorer.

8-bit-Party

legendary

Activity: 1036

Merit: 1000

8b 16b DEMOSCENE FTW

Code:

146.0.32.101
65.129.216.236
78.238.254.189
101.165.90.37
130.180.65.30
58.160.130.189

Tinkles

full member

Activity: 126

Merit: 100

Quote from: Gumbork on July 17, 2015, 07:38:16 PM

When should new masternode prices take effect?

I know there are 2 updates coming, first one is next week, so at least not until then. The dev can answer better.

Gumbork

hero member

Activity: 583

Merit: 500

When should new masternode prices take effect?

Tinkles

full member

Activity: 126

Merit: 100

Quote from: allZuckedUp on July 17, 2015, 03:20:46 PM

I don't have a specific question with this.

But, I also want to point out, I've noticed the blockchain is very slow to sync for 8bit even with the bootstrap file.
A new wallet (both Linux and windoze) will take something like 2 or 3 days to sync the blockchain from scratch, and about 1 day (full day, 24'ish hours) to sync with the bootstrap file.

I've noticed several other coins sync MUCH faster on the same bandwidth, on the same machines on my end, and often with many more blocks to sync than 8bit. Also, when the blockchain is syncing (not a little sync, a big one, new wallet, weeks worth to go) the wallet application will become unresponsive for several minutes at a time (again, both Linux and windows). You can see from the debug.log that it's still working, but even just a getinfo call on the linux side will take up to 10 minutes to respond sometimes, and the qt GUI on the windows just says "not responding" in the title-bar. In either case a single wallet will rip up the cpu as well, 100% used. Both the unresponsiveness and cpu usage do go away once the wallet is synced, and small syncs (just a day or two of blockchain data) don't seem to cause this problem.

Soooo, I do not know if that slowness is a part of the technologies being employed here on 8bit, if the block sizes or complexity differs significantly, or if there's something that can be fixed in the code. But, I've seen a few other similar observations in this thread and wanted to pipe up as well.

If there's testing to be done, I can certainly start syncing a few new wallets and script up some data analysis, I am an IT engineering guy by trade.

Cheers.

I think that would be good.

I noticed the slowness in the sync on my crappy laptop, but like the Dev said this will be fixed in the update with the chekpoints (planned for next week)

The exchanges and everything else is all working 100% now, once the sync speed issue is solved we are ready to rock!

8-bit-Party

legendary

Activity: 1036

Merit: 1000

8b 16b DEMOSCENE FTW

Its because of lack of checkpoints. Current height is 115902 while latest checkpoint is at 1888. This is drama however incoming release will fix this problem. Stay tuned!

allZuckedUp

full member

Activity: 164

Merit: 100

find / -name base -exec chown -R us

I don't have a specific question with this.

But, I also want to point out, I've noticed the blockchain is very slow to sync for 8bit even with the bootstrap file.
A new wallet (both Linux and windoze) will take something like 2 or 3 days to sync the blockchain from scratch, and about 1 day (full day, 24'ish hours) to sync with the bootstrap file.

I've noticed several other coins sync MUCH faster on the same bandwidth, on the same machines on my end, and often with many more blocks to sync than 8bit. Also, when the blockchain is syncing (not a little sync, a big one, new wallet, weeks worth to go) the wallet application will become unresponsive for several minutes at a time (again, both Linux and windows). You can see from the debug.log that it's still working, but even just a getinfo call on the linux side will take up to 10 minutes to respond sometimes, and the qt GUI on the windows just says "not responding" in the title-bar. In either case a single wallet will rip up the cpu as well, 100% used. Both the unresponsiveness and cpu usage do go away once the wallet is synced, and small syncs (just a day or two of blockchain data) don't seem to cause this problem.

Soooo, I do not know if that slowness is a part of the technologies being employed here on 8bit, if the block sizes or complexity differs significantly, or if there's something that can be fixed in the code. But, I've seen a few other similar observations in this thread and wanted to pipe up as well.

If there's testing to be done, I can certainly start syncing a few new wallets and script up some data analysis, I am an IT engineering guy by trade.

Cheers.

skidog

legendary

Activity: 1393

Merit: 1001

Quote from: 8-bit-Party on July 16, 2015, 01:20:25 PM

Don't replace anything, just put bootstrap.dat to the data dir. 8bitd will detect it by this name and will know what to do next.
When loading of bootstrap.dat will be finished, it will be automatically renamed to bootstrap.dat.old.

thanks again

8-bit-Party

legendary

Activity: 1036

Merit: 1000

8b 16b DEMOSCENE FTW

Don't replace anything, just put bootstrap.dat to the data dir. 8bitd will detect it by this name and will know what to do next.
When loading of bootstrap.dat will be finished, it will be automatically renamed to bootstrap.dat.old.

skidog

legendary

Activity: 1393

Merit: 1001

When installing the bootstrap which files do i need to replace? Just replace database file...or do i need to remove more files?

skidog

legendary

Activity: 1393

Merit: 1001

Thanks...

8-bit-Party

legendary

Activity: 1036

Merit: 1000

8b 16b DEMOSCENE FTW

Quote from: sacskate on July 15, 2015, 05:32:55 PM

I still wouldnt mess with cryptsy. Several of us tried to withdraw weeks ago and those coins are no where to be found.

According to info I got all stuck withdrawals have status pending, and can be either cancelled or resent. You have to find where on their website you can proceed with those actions.

Quote from: skidog on July 15, 2015, 08:14:44 PM

when will we launch the new thread?

Probably with the first wallet update next week.

Topic: [*] 8BIT [Dark Masternodes][Anon][Roadmap Stage 4] - page 156. (Read 379550 times)