[*] 8BIT [Dark Masternodes][Anon][Roadmap Stage 4]

[Tinkles]

Bittrex is back on track - they finally got a peer and synced properly. Now you can safely withdraw your coins from Cryptsy and Bittrex and launch MOAR masternodes / staking inputs.

Tinkles offered coordination of communication with exchanges, in case of any issues he we will handle them.

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

EXCHANGE UPDATE:

So I did a test deposit / withdraw on Cryptsy and both went through fine to my wallet and confirmed on the block explorer.

That means Cryptsy and Bittrex deposits / withdrawals are working 100% for me as of today.

But I saw messages like the above, so I am in touch with Cryptsy and have asked them to resync the wallet with the new seed nodes (so their wallet might be syncing for a few hours....) and plug us into their tech guys so we can look at the previous problems, and they said they will escalate the issue and get back to us.

I would ask you fellow 8BIT'ers please do some test deposits / withdrawals to Cryptsy and let me know if you have any problems so we can look into it, or if it's working it would be helpful to know that too.

The dev said he is working on improving the sync speed for the next update so we can get everything working smoothly going forward..

I will update again when I have more info.

Thanks

[8-bit-Party]

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.

when will we launch the new thread?

Probably with the first wallet update next week.

[skidog]

Thanks...

[skidog]

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

[8-bit-Party]

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]

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

[allZuckedUp]

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.

[8-bit-Party]

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!

[Tinkles]

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!

[Gumbork]

When should new masternode prices take effect?

[Tinkles]

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.

[8-bit-Party]

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

[8-bit-Party]

Great, so we have second block explorer.

[drays]

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]

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]

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  

[8-bit-Party]

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

[skidog]

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]

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!

[Dimitry]

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)