Topic: [ANN][CROC] Official CrocodileCash Update Board [Strength in Basking] - page 8. (Read 20047 times)

upgrade: bitcoin core changes need to be merged with ours.

just a reminder some time ago @bumbacoin offer he's help on the old threat if is needed

bumbacoin is wallet dev, you can see all he's work from over the years here :
https://bitcointalksearch.org/topic/mac-wallets-node-hosting-general-crypto-assistance-call-me-now-1200970

He does update the threat every time he's done with a new wallet.
So, contacting him could be a good move if the Proposal fork goes forward

Or maybe someone knows how to free some memory in FreeBSD 11? Wired for example consumes 870MB out of 3GB

Yep, we are looking into it.

The "ultimate fix" is going to be rebasing off of the latest Peercoin code, and modify it so we can continue using our chain and same rules.

So... Anyone is looking into RAM usage problem? crocodilecashd is the only daemon that eats shit ton on memory...
My server is at 90% already and starts to swap a little. It's KVM VDS with SSD, so it's not that slow.
Anyway, if daemon appetite keeps growing, I'll have to shut down the block explorer...

 

Hey,

With regards to there being any potential problems at Cryptohub...

Staking CROC seems to be working as normal within my own wallet (new CROCs being generated at about the expected frequency and amount).

There did seem to be a problem mining at Cryptohub; I've been renting Bitmain S9s.  Due to there being perhaps a problem, I shifted the hash over to Pickaxe.online and am receiving essentially the anticipated amount per payout-period (the period being 20 mins there) of the POW-generated CROC from that pool.

It seemed to take awhile before the network hash rate [in the daemon/command-line and at Cryptohub] increased to roughly the level that could seen at the CROC address here (http://pickaxe.online/#miners).  But now the network rate at the terminal and at Cryptohub seems to be accurate with what I figure is the overall CROC-network hash-rate.

I don't know if it's related at all but the 23-Skidoo/CHAO chain may be buggy; although my level of trust in the operators of Infernopool is also extremely low at the moment too. That pool supposedly paid an amount in the last 24-48 hours (0.00141595 CHAO to a deposit address).  According to the interface at Infernopool it was sent 29 hours ago but there doesn't seem to be any evidence of the payment being made according to either the CHAO blockchain explorer (https://chainz.cryptoid.info/chao/) or the wallet interface.  Maybe the CHAO or another wallet is screwing things up with CROC at Cryptohub???

I'm not personally a fan of the masternode fetish/trend.  I opined last month the following:


On further consideration of the topic, I'd also add that the additional complication of getting a masternode set up (and running on a host/server outside of one's direct control--if a holder doesn't have their system running 24/7) actually discourages mass-adoption and helps ensure this is a geek-coin only.  At the moment, it's a POS coin with a goldilocks (not-too-high, not-too-low rate of inflation... ... arguably.   The 12% rate is enticement for people to speculate given this guaranteed return [and as a fan of both Austrian-school economics and existentialism, I'd say "experimentation before refutation" and allow people to decide if this is a coin they want to hold and let them bear the positive or negative consequences of their actions].

Yet, to balance my criticism of masternodes (which I'd characterize as a malignant, stupified pestilence), I would say however, that the pros on behalf of masternodes do include that they take some coins off the market (as collateral for setting a masternode up) and they ensure that a "nothing-at-stake" situation doesn't arise (which doesn't seem to have been an issue... and I don't foresee this to be anything more than a theoretical or academic problem [and the simultaneous POW-component offsets any potential peril of this anyhow]).

What exactly causes the problem?

What do you mean "wallet weight"? This is very interesting to me.

Is leveldb not performant? I will have to check.

------

Edit: Leveldb performance: https://github.com/google/leveldb Scroll own a bit.

> CPU:        4 x Intel(R) Core(TM)2 Quad CPU    Q6600  @ 2.40GHz

We get about 260MB/s max.

It is interesting this conversation has come up before:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-September/003265.html
https://www.influxdata.com/blog/benchmarking-leveldb-vs-rocksdb-vs-hyperleveldb-vs-lmdb-performance-for-influxdb/

RocksDB has the fastest read time.

What is the size of the chain right now guys?

Maybe invest in a SSD startsts.

5 rejected blocks at row.... Now seems wallet delays on net syncing...
So satoshi nakamoto was right when set to bitcoin block time 20 minutes.     with 30 seconds a coin can't be stable.    Actually Q2C coin (30 seconds block time too) was freezeing 1 time too, it exactly was a case when it was a lot of found blocks for an hour.
Such bad perfomance can be result of using leveldb? Why not mysql/postgres ?

From what i seen today, when the network hash drop lower then 6TH the problem starts
the wallet weight will be bigger then the network wight. the staking time will go to 20sec..but all you staking coin will be reject

now that the nerwork hash is back to 10TH+.the wallets weight will be lower then the network weight and stacking is back to normal ( mining diff need to get stable still )

So the theory is :  because of all tho's big wallets staking a problem will start when the network hash drops alot

It's a little faster now when there is no miners (no found blocks for last 30 minutes) - sometimes responds in 1 seconds, sometimes still delays in 5-15 seconds

the only way  is delete all data and start from zero,  but some users will use old deposit addresses ant lost their coins

No idea how to clean the chain...

But by the sounds of it, it's the chain lol.

just tell me how to clean


Tried to disable staking, no diference


In common wallets responds to "getinfo" in 2-5 seconds

Update: Coin update proposal

Lets walk through what could be happening...

1. Invoke CrocodileCashd client to send a command (getinfo) to the server
2. The server receives the message to process
3. The client waits for a response. You are saying it takes up to 90 seconds.
4. So this means the server is busy doing something...What could it possibly be busy doing?

A few possibilities:

1. The blockchain could be huge to traverse. getinfo could be traversing the whole blockchain.
2. The server could be busy with other processes. Check the nice value on processes.
3. Test the latency with other coins on your server.

Lets start with this.

Wallet on CryptoHub Server  delays on respond on any rpc command a lot.   CryptoHub will disable the coin setting "maintenance" status to protect the system  if it delays more than 90 seconds.
wallet.dat is 90 mb since there a lot of deposits and payment processor for croc-lo, can it be the reason of the problem?

Maybe I need to banish some miners to decreases found blocks rate.  For last 24h CryptoHub has found ~90% of all PoW blocks

What you see in the first post is what we are exactly working on. There should be no confusion.

We are looking for a good marketing designer. That is, a graphic designer who specializes in marketing material.

Sorry, status coin? The status of the coin? Errr, alive? haha.

I'm currently gathering the team's public keys to create a multisig address so you can donate. I'll post an update when it's possible to. You will see the multisig address hash when it's ready to go. Thank you for being generous!

I haven't looked into what a masternode is, but I have heard both good, and bad about them.

As for your issue:



You will not be able to build CrocodileCash for the Raspberry Pi for a few reasons:

1. I'm fairly sure we have no support for targetting ARM at all.
2. libleveldb and libmemenv are precompiled (although you can compile them yourself) for x86/AMD64 architecture.
3. Looks like you're lacking the proper user permissions for building.

My suggestion:

Do not build CrocodileCashd for Raspberry Pi at this time. Only the utmost experienced developers will be able to do this.

If you are very interested on running CrocodileCashd on a low power device, consider something like the Intel Compute Stick, which can run Linux on an x86-based system.

We have no core wallet developer because we believe the wallet doesn't need much work, or "just working" is good enough for 95% of our users. This is why we have a development fund - bounties for wallet contributions will reward developers who have some spare time and want to earn something.