reading the first post is useful you know ^^  everything is explained there ...
No halving for this coin ... something different ...

strange, even after a few minutes ?
For example at first the block 124544 was showing as a "0 share" block.
After a few minutes I could see this :
124544    113 left    michaelbrad3141    21/02 18:12:22    2.16    124,544.00    4,414    5,842    

And two minutes later it was visible in the transaction list (it was not before), and I got ~500 coins for this block.

it seems the last 4 or 5 blocks often are displayed with 0 shares ...  refresh the screen after a couple more blocks have been founded and the correct stats for the previous blocks should be displayed.

I'm more curious about the many "4 shares" blocks ... I don't understand how they are this common

write to poloniex and wait for them to update their wallet

also beware of dyslexia ... took me half an hour to finally change rcpuser... into rpcuser=...

^^

seeing block 124001 now, nice ... but still unable to solo mine

It's always good to make a backup of your wallet.dat file before updating the client ^^

But then running the new client should pose no problem.

Not sure the pools have updated yet ... blocksolved at least is still in maintenance mode, and minerbest did not seems to be aware of the problem yet !

I can't solo mine ...

I am using the patched wallet, but neither with the QT client nor bitcoind can I connect to my miner.

I'm running ubuntu. I'm able to telnet to my qt / bitcoind (so it's running and has its port open) but then nothing happen.

Pool owners, did you encountered this problem ?

You cannot use a random value ...

The best would be indeed for the dev to
1) remove the checkpoint from the code
2) find itself the next block
3) add the checkpoint for this new block on the code
4) distribute the new version

But not much time was given for someone to generate manyblocks, so it should be ok ... We will see if the chain size increases by a number of blocks or not

The bug is identified and easy to correct, a patched version is currently being tested ... no need to dump Should buy instead

I was also looking into this ...
My understanding is that the second checkpoint (124000) should not be set at all yet.

It was most probably in the coin MRC was cloned from, because this coin already went over block 124000. But the value is probably valid for this coin blockchain, not for MRC.

Anyone can confirm ?

EDIT1: anyway, it clearly is not required also because proof-of-stake is not enabled yet in MRC ... it should kick in only after one full year (60*60*24*365 seconds, as stated in main.cpp)

EDIT2: the 124000 value does not come from the PPC code (they have other checkpoints for the proof of stake, but not this one). From which coin was MRC cloned ? This value most probably comes from that ancestor.

Some nice concepts ... but does not seems very practicable to me ...

For example:

How do you prevent a botnet from using consecutives IP addresses in order to validate itself ?
(easily done for example if the botnet controler "owns" an IP network and if the botnet is using it as a proxy to access the internet)

If computers are not "Proof-of-working" all the time, how do you prevent them from launching multiple instances of the client to appear as multiple computers ? (they can expose multiple IP addresses if necessary)

What about honest people using NATs (so only one IP address) ? Only one client allowed ?

Also, as someone already said, you basically want to use the usb drive in a context where a dedicated dongle would do much better.
But such dongles would either have to be built and sold in a centralized manner (maybe checking the real identity of the buyer - bad for anonymity), or you would face people building and using tons of them. (similarly to ASICs with bitcoin)

Try to add some nodes manually

I have those as peers at this moment :

78.154.7.25:55884
68.229.96.88:55884
185.9.62.204:55884
98.202.145.62:55884

in the console, to add manually a peer, type
addnode aaa.bbb.ccc.ddd:vwxyz add

or alternatively, add a line like this in your configuration file
addnode=aaa.bbb.ccc.ddd:vwxyz

Note that addresses given in a thread like this may (an will) not work forever ... People keep starting and stopping their clients, halting and rebooting their computers, etc.
But if your client manage to connect to one of them, then it will get other addresses from it. All addresses encountered are stored (peers.dat file), and next time you restart your client, the odds to find a still working peer in that file increases.

Edit: also opening your firewall to allow other clients to connect to yours may help. Open the 55884 port and forward it to your computer if you are using NAT.

Rofo, thanks for the honesty ... better have a dev saying he does not master everything ... those one are usually more open to discussion and improvement ^^

I verified the behavior by computing the difficulty by hand using the algorithm in GetNextWorkRequired (and using the block explorer at http://noblepool.zapto.org/block_crawler.php as a source of data)

I can reproduced exactly what is happening on the network (i.e. predicting the next difficulty using the time between the last two blocks), so I am now sure it does only use the time between these last two blocks.

When computing next difficulty, the "30" block value is used as a weighting, but the date of those blocks or the first of the 30 is not checked in any way.

Also the 30*60  value is used when verifying blocks (from the database or from the network, not sure yet).


The variations we can observe (by around a factor of 2) in the difficulty are mostly caused by the variance in the hashcash-like algorithm.
For a given difficulty, it takes *in average* 60 seconds to find a block.
Should one be found in 30, the next difficulty will be greater, should it be found in 90, it will be smaller in a proportional way.
I'm pretty sure this instability would persist at a much higher hashrate.


I don't know what would be best ... for example memorycoin now uses "Kimoto's Gravity Well" https://forum.megacoin.co.nz/index.php?topic=893.msg5742#msg5742 developed for megacoin. But I'm really not sure of the behavior of this algorithm as I did not looked at it in detail yet.

I don't have time today, and it's not really urgent anyway (the instability we experiment is not THAT high with the current parameters), but I will try to take a closer look at this part of noblecoin code this weekend.


As for what the pools say, it probably comes from what it was saying for the coin this pool has been initially developed for, or even from the official post announcing noblecoin ^^

I'm always interested in the technical aspects ...

The official post says there is a 30 block retarget time ("- Difficulty re-targets approximately every 30 blocks.")

From our miners, it clearly appears the difficulty is recomputed at each block.
I did not looked much in the code yet to find what algorithm is used, but maybe an explanation here from the dev could help

Continuous difficulty adjustment has pro and con.

• + It prevents the chain to get stuck for a very long time if the hashrate suddently drops. Think about big switching mining pools (middlecoin & co) that can up the difficulty of a not well designed coin to oblivion before letting it rot. The coin *MUST* be prepared to handle these pools
• + It prevents insta mining that concentrate and devaluate the coin. Long retarget times as in bitcoin/litecoin can't be used for newer coins
• - It can cause difficulty instability. Yesterday I observed the difficulty vary between 1 and 2 over very short periods (~10 to 15 blocks maybe). Variations of this amplitude are not a problem, at least at the current state / total hashrate of the coin. But it's hard to predict how it will behave later. Memorycoin2 had very big problems at launch with their difficulty adjustment, lets not reiterate ^^. At long term, strong variations are also a security / sanity concern ... we could imagine miners connected to different instable coins and mining only the easiest blocks of each one
• - If the continuous  adjustment is too slow, it can also cause problems as in yacoin where it allowed insta-mining at the beginning and subsequent dumping.
  

I'm not sure what is currently used, it seems to me that only the time between the last two found blocks is used to compute the next difficulty. If true, this is the root of the instability, more real blocks should be considered (or the capping factor to the diff. adjustment should be reduced.
(the 30 block value seems to appear only as a weighting, preventing extreme change from block to block)

Where is this part of the code coming from ? Another coin that may be facing this problem ? or is it specific to noble ?

Still better than dumping ^^

Was here before, coming back ^^

Something bugs me in the technical parameters of this coin ...

14,700,000,000 coins are to be mined at the average rate of 5000 coins per minute ...
It will take a little more than 5.5 years, and after that only the transaction fees will reward the miners for their work on keeping the network alive.

Bitcoin and most alts progressively reduce the block subsidy to make this transition smoother ...

Don't get me wrong, I think an extremely fast reduction as seen in many coins these days only tags them as instamine & dump schemes (hello quark !^^)...

But in the long term (should 5 years really be considered long ? ^^), abruptly stopping block subsidy seems dangerous if the coin is here to stay ...
What motivated this choice of not progressively reducing subsidy ?


Also, maybe some hard checkpoints in the code would help with the fear a large damages in case of 51% attack ...
A Proof of Stake could help also, albeit this may be tricky to correctly implement (see for example the problems yacoin is currently experiencing)

This should be possible to check if the premine has moved since the beginning or not through a chain explorer ... Anyone with experience in that field has / can do it and report here ?
From my understanding, playing with the premine could not be falsified and tracking its activity should help clarify the situation : scam / not scam but poor management.

I don't understand why he is not vocal about the increased generation rate ... this obviously affects its capital a lot !

(still possible to update the update ... at least change it so the coin generation rate is maintained, by proportionally reducing the block reward !)