|
I'm just a bit busy last days so unfortunately I will have to publish beta-test on github only... I mean still no windows binary yet. I had some random issues with qt5, already fixed them but no time to start gitian process again (there are no working gitian specs for 8bit, all I did was custom stuff). Anyway this week new source will be published.
|
|
|
|
|
Since staking protects our network, yes - enable reservebalance (to don't let faucet go dry too fast) and enable staking.
|
|
|
|
|
allZuckedUp, awesome job!
|
|
|
|
|
My logs say that within last ~13500 blocks (last ~11 days) there were 267 orphan entries what is less than 2 percent. However, another log with last ~2500 blocks (last ~2 days) say there were 13 orphans what is 0.5 percent.
Once we will go with bumped and enforced protocol version those numbers should stabilise.
|
|
|
|
I woke up this morning to mostly orphan blocks, anyone else having the same problem?
Maybe you should go back to sleep and wake up again. Or realize that it was just a nightmare. |
|
|
|
I moved some coins, just want to make sure nobody freaks out. I am not selling. By the way the rich list on the block explorer is only up to 7-19-2015
I had to pause masternode updates for few days because my testnet nodes need memory... while building rich list process loves memory too. I have just issued a manual update so you can see fresh data ATM, but auto-mode will be reenabled in few days as I have to move block explorer to another machine. |
|
|
|
Multipool
I'm confused, I thought all new 8bit at this point was created via staking and masternodes. Are you looking to change that? Or was I mistaken about how this works? I want to setup up a multipool which will mine most profitable coin and make payout in 8BIT. Mined coins will be sold and 8BITs will be bought on exchanges. Nothing fancy, classic model. Useful to keep small but predictable demand. Personally I prefer PoW over PoS (thus paying for effort not balance), however fixed PoS is acceptable (unlike high % PoS) so I am fine with it and not gonna change anything here with deep discussion before, don't worry. |
|
|
|
Do we have miners with own equipment here? |
|
|
|
Price is looking good nobody dumping  Maybe we can see 100K as new floor  To be honest... I would rather see panic sell instead of this market clinch. I still have not shown anything absolutely brilliant so, hey people, don't you think you should at least put some reasonable ASKs? I know most of us paid more than 100k sat for a single coin, but hey, we all either stake or install masternodes, I am not saying you should sell anything below buy-price, just put some of your extra income to orderbooks to bring liquidity to the market. Grasp all, lose all. And don't tell me - you first. I owe you noting. Some people send me with ideas like 'hey man if it's takeover and restart why don't you simply disappear for a week or claim you are not sure that you will stay here because of your personal issues just to restore liquidity on bittrex'. Stop this. We must be reasonable, we must be sensible. Don't send me such ideas as, besides I think it's pretty pity, it looks like a provocation. Weeks ago I said I am not intersted in P&D here, so don't expect me being happy of market value growth without reason. Just because I believe it's all about speculation it does not mean I love speculation. Yes, I am happy that people believe in this coin, but my goal is to deliver success, not to see success in people belief. |
|
|
|
|
N270 is 32-bit CPU so it's obvious your 8bitd is 32-bit.
My bet is that VM is also 32-bit. Am I right? I am trying to verify that my observations are correct.
Official Windows binary is 32-bit one, although 200M is stil not bad, I bet 64-bit version would consume even more.
|
|
|
|
Nope, this is not how it works. 8bitd is killed by OOM killer, so it does not even know that it has been killed. There's no warning before. There are signals you can intercept, analyze and shut down graceful, but not not this one. And this is how it always work, not matter if it's 8bitd or bitcoind or Xorg or vim. What I recommend is running simple script like: while 1:
pgrep 8bitd && 8bitd
sleep 1m
this is proof of concept, not tested. |
|
|
|
|
This also affects most PoS coins, they are memory hungry.
Anyway 1G RAM is enough to run 5-7 instances of 8bitd. I have not tested that numbers with masternodes, but for staking needs it's OK.
There are 8bit.conf parameters you tweak on lowmem boxes like par, dbcache, maxconnections, rpcthreads, maxorphanblock that may help with reducing memory usage.
Also, on lowend box I recommend 32-bit OS or at least 32-bit 8bitd on 64-bit OS.
|
|
|
|
Hey hey mastertrader.
This is how you treat people who fund your food?
RESPECT COMMUNITY
|
|
|
|
thank you for the update. but:
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.
can you explain that please? why 1-2 days instead of weeks? slow wallets? they also can wait 2 weeks longer.. |
|
|
|
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!
|
|
|
|
|
MN codebase is not excellent, it has minor drawbacks, but they are not dangerous to coin nor they can affect syncing.
|
|
|
|
|
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.
|
|
|
|
|
Great, so we have second block explorer.
|
|
|
|
|
Show Posts
