I've rethunked my initial statement about the new mns requiring more 8bit to run than 112 (which is current amount). I have to say I kind of dig having a lot of mns running at once it makes things interesting... how many will each mn require in new release? If it goes up to 1000 or something I only can run 1 :-S also, Will new 8bitd require 500 mb RAM still :-) ? That would be cool because I'm overflowing with it at this point.
This is still open question (current proposal of collateral is 1024 coins). There are two concurrent objectives: - security: cheap masternode means people will not stake what introduces a security issue for the network - fair distribution: expensive masternodes means only small group of people will collect great rewards However, it can be also balanced using block reward and MN/stake reward ratio (block reward - current proposal 1 coin [current value: 1.2], MN reward - 0.80 [current value: 0.88]). As we can see, inflation will be slightly reduced, though MN will be still much more profitable than staking. This effect is currently mitigated because of no MN payment enforcement, however, with a new code base those payments will be enforced and MN profitability will be stunning. What is not cool from network security perspective. Therefore - I keep this topic open and and I am looking forward for your (not only r8st) feedback. I do like the idea of 1024 coins for a masternode... puts us on par with some of the bigger coins. I am a bit confused though... right now, mn requires 112 coins and I get mn rewards of .88 coins. If the mn increases to 1024 coins, are you saying that i'd just receive .8 coins? Wouldn't this go up with the increase in mn required coins? Now, i'd be able to run about 9 mn's, which means .88 * 9 = 7.92 coins. Am I missing something (probably am)? 8BIT supply is fixed, every block X coins is minted (though we will introduce a halving and a cap to make the coin deflationary). With the MN worth 112 coins there are 300+ MNs, when we will bump the collateral to 1000, then number of all masternodes will be 9x smaller, therefore your income will stay unchanged. This is simplification though, since not all MN owners run 9+ MNs, therefore either they will spend more 8BITs to run one MN or they will be forced to switch into staking (what is good from the network security point of view and bad from new coin allocation & MN services distribution perspectives). TL;DR: if you own 9+ masternodes now, you will have one masternode after the fork while your income will stay the same. Note that this explanation covers MN collateral only, it does not take MN reward change into account. Neither it takes extra income from those who had "cheap" <9 masternodes and will give up collection of more coins to run a single "expensive" masternode. |
|
|
|
I've rethunked my initial statement about the new mns requiring more 8bit to run than 112 (which is current amount). I have to say I kind of dig having a lot of mns running at once it makes things interesting... how many will each mn require in new release? If it goes up to 1000 or something I only can run 1 :-S also, Will new 8bitd require 500 mb RAM still :-) ? That would be cool because I'm overflowing with it at this point.
This is still open question (current proposal of collateral is 1024 coins). There are two concurrent objectives: - security: cheap masternode means people will not stake what introduces a security issue for the network - fair distribution: expensive masternodes means only small group of people will collect great rewards However, it can be also balanced using block reward and MN/stake reward ratio (block reward - current proposal 1 coin [current value: 1.2], MN reward - 0.80 [current value: 0.88]). As we can see, inflation will be slightly reduced, though MN will be still much more profitable than staking. This effect is currently mitigated because of no MN payment enforcement, however, with a new code base those payments will be enforced and MN profitability will be stunning. What is not cool from network security perspective. Therefore - I keep this topic open and and I am looking forward for your (not only r8st) feedback. |
|
|
|
I'm a coder and can help out with this coin if you need it.
Let's take up a quick challenge - please build your own pivx win64 executable using cross-compilation on ubuntu 16/17. The incoming release is forked from it, so if you are able to do it then, for sure, it's obvious we need you on board. |
|
|
|
|
Just to clarify: chain is moving smooth all the time, there are no forks known, bittrex & cryptopia & 8bit.trade report the same chain height.
It does not mean that we gonna keep this client / code of course.
Looks like cryptoid is stuck, but I have no idea why.
|
|
|
|
|
I am not an admin / this thread is not moderated.
|
|
|
|
|
If someone wonders what the heck such guys are talking about... well they just build the account rank.
|
|
|
|
Hi, anybody can tell me how to conf more then 1 masternode. Do i need more then 1 config file?
Yes, 1 config + datadir per daemon. 2nd and any other consecutive daemon's should be started with something along the lines of: 8bitd -conf=/home/2xjO9M3P/.8bit2/8bit.conf -datadir=/home/2xjO9M3P/.8bit2/ adjust path/filenames as appropriate is completely redundant in this particular example. |
|
|
|
Couldn't have said it better myself  |
|
|
|
New ANN will be eventually posted next week. |
|
|
|
Last time someone updated Github was 4 month ago !
Does it mean no one is working on this project ?
It means that old client is no longer maintained. |
|
|
|
Good luck!
Are you tired of the ungrateful masses? This coin will survive, even if it is still asleep right now. Not really, I am in good mood with consistent vision of this project. This is where this silly quipping comes form. Otherwise you would see here an anger, I guess. |
|
|
|
I know I keep asking this... but can we get any updates on the progress of the new wallet?
No. So, is this coin dead? No.
OK, sorry for bantering
Basically there's still no ETA that can be announced because of the (temporary) extremely limited time we can spend on the project at the moment. However, the development is active and before ETA will be published, we will ask more community members to participate in testing of the beta version. No hype, no FUD, stay tuned.
|
|
|
|
I know I keep asking this... but can we get any updates on the progress of the new wallet?
No. |
|
|
|
|
I have recommended one of the users to keep infinite loop / crontab script starting 8bit client every N minutes to mitigate OOMs when memory consumption spikes. Quite rough, although works flawless, he runs 10+ MNs on 8GB machine (with a really small swapfile). In case of database corruption he easily restores it from the client that has been not killed.
|
|
|
|
Ok thank you. Can it also be done through the gui? I built the qt yesterday to see if "coin control" is an option through the gui but couldn't find it. With qt client its much easier. Go to the options and enable "Display coin control (experts only!)". |
|
|
|
Is it possible to send masternode reward coins safely from my wallet while mn is running? I don't have qt built. If so, how would I do that? 8bitd -cli getreceivedbyaddress
[
{
"address" : "8xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"account" : "mn1",
"amount" : 112.00000000,
"confirmations" : 88088
}
]
and 8bitd -cli getbalance
188.08 I think if I try to send say 8 8-bit out of my wallet right now it will screw up my mn, right? How to avoid messing up mn? I know I could turn off mn, send what I want out, then create a new address in the wallet to send 112 to, and then generate a new masternode privkey and then edit the .conf and restart 8bitd, but I'm hoping there's an easier way. Thanks It can be done in several ways, you have to choose which inputs will create your transaction, https://bitcoin.org/en/developer-examples#simple-raw-transaction is a good start |
|
|
|
total used free shared buff/cache available
Mem: 488 106 84 4 297 345
Swap: 3071 448 2623
ps ux|grep 8bitd
theo 7541 52.5 76.4 2219172 382296 ? SLsl 09:27 208:58 ./8bitd -daemon
theo 8632 0.0 0.1 14520 888 pts/1 S+ 16:04 0:00 grep --color=auto 8bitd
So... to summary - 8bitd resident size is 382M while your system reports 106M mem usage and 448M swap usage. I guess your provider is overbooking resources and therefore swaps aggressively. If your provider allows to temporary bump VPS parameters - try 1GB mem plan - it should give instant effect. If it is your bare metal machine, reduce the swappiness. |
|
|
|
Weird. Really. Do you have non-empty wallet.dat in use? If so, let it sync without it. Please paste an output of |
|
|
|
I'm running 2 MN coins. Bitcloud and 8bit on the same container. Compare.
Nothing to compare here. When 8bit was as small as bitcloud is (blockchain height & size, utxo size), people were running 10 wallets concurrently on 1GB machines. |
|
|
|
|
Show Posts
