That's correct, but we are still at the initial emission stage. It's only a matter of time when a proof-of-stake reward will be dropped enough.

This would be mean that formation of the initial stakeholders community was done successfully. Then we can dedicate some time to think about adjusting a minimum level of the proof-of-work difficulty, if it would be required to make an adoption easier. Such decision could be made with block versions voting, like we already did before. Time will tell.

It happens when inputs has age greater than 90 days.

http://nvc.cryptocoinexplorer.com/block/9ccd03672b05dcec1ad63076a408fcbc8b3affc6e28a0ffdaafc0097e3855c80


But there are some limitations:

• Only inputs with an equal destination are combined;
• Maximum sum of combined input is defined as a linear function of the proof-of-work block reward (PoW/3).

Hey Balthazar, just to confirm, I should be all fine with the blockchain issue with version v0.4.4.5-2-gde717f9-beta right?   Thanks.  I updated to the latest version but it crashed with an error so I went back to this one.

Hi guys.

This message is just a notification which was used to send users read the FAQ in this thread.

Check your client version, if you are running 0.4.4.5 or higher then it's safe to ignore this message.

Just a little piece of info...

As far we know, some payment processors and users accepts 0/unconfirmed transactions. But this solution is not secure, because it's possible to create two transactions with the same inputs, but different outputs.

http://eprint.iacr.org/2012/248.pdf

Attacker is able to send a first transaction directly to victim, and then broadcast a second transaction over the network. This couldn't be prevented using the proof-of-work design, but it's possible to fight with such manipulations through using an extension for our proof-of-stake system, and we even don't need a chain fork to implement this.

Block candidates submission concept

This would allow user to check that his unconfirmed transaction is accepted into the specific stakeholder's memory pool.

It doesn't provide guarantee of fast confirmation, but it makes a double spending of 0/unconfirmed transactions much harder. It will be required to use some stake in order to perform such type of double spend attack.

How this could work?

1. We have a blockchain, so we can get a full list of stakeholders with suitable inputs weight (i.e. users who are able to generate proof-of-stake blocks and allowed to submit the block candidates);
2. We can check a signature of received block candidate;
3. As a result, we have a proof that specific stakeholder has a declared list of transactions in the own memory pool. Or seen those transactions, at least.

How is this supposed to work?

Stakeholder will be allowed to send proof-of-stake candidates over the network. Candidate is required to satisfy a difficulty, which would be set separately from the main chain. And then there are few different approaches could be used to handle this.

• Block candidates map;
• Temporary pseuso-chain for block candidates;

Maybe we'll think about implementing this in the future version...

We need candidates for the current prevhash only... It's not necessary to store old candidates, we are free to drop all of them immediately if prevhash was changed (i.e. new block was found). It would require something like 10 megabytes of additional RAM, I guess.

You are right, not everybody need such functionality. But for some purposes (e.g. payments for fastfood) it's almost equal to immediate confirmations, so I presume this would be useful.

It seems that some stupid scums are trying to promote their "point of view" in the WoT database.

https://www.mywot.com/en/scorecard/novaco.in?utm_source=addon&utm_content=warn-viewsc
https://www.mywot.com/en/scorecard/novacoin.su?utm_source=addon&utm_content=warn-viewsc
https://www.mywot.com/en/scorecard/novacoin.ru?utm_source=addon&utm_content=warn-viewsc

There's no forms, there is no registration. How is this supposed to be a spamtrap? I didn't seen something so stupid ever.

Experimental builds are updated again.  [AMD64  | i686 | src]

Changes list:

• Core: New proof-of-stake miner implementation. Performance issues resolved, almost 100x faster with massive inputs amount;
• Qt: Coinbase/coinstake transaction records appearance unification;
• Lib: update to Berkeley DB 6.0.20.

I am curious of opinions from the community about mining Novacoin VS. pointing my miners at the currently most profitable coin and then buying novacoins with the earnings.  Mining on Novacoin will be better for the network, but buying it on BTC-e with earnings from one of these multi-pools will get more NVC in the end, and in theory will raise it's mining profitability attracting more hash power.  Which do you think would be most beneficial to the coin?

Another thing that I would like to comment on and is somewhat related is the ramifications that scrypt FPGAs will have on the NVC block reward  

When the more powerful ASICs really started hitting the pools, PPC hash rate would spike every time BTC difficulty adjusted which in turn pushed the block reward down.  It seems many miners took an interest in PPC after these profitability spikes happened.  This appears to have benefitted PPC greatly regarding the market price.  Many thought PPC would be super plentiful, because people didn't imagine how much the block reward would change.

I think it is safe to say that there are currently scrypt FPGAs in the wild or at least a dump truck full of new GPUs mining scrypt from profits of the past months.  As these FPGAs start to ship out, the NVC difficulty will more than likely increase which will make the block reward smaller.  Anyone else think we will see < 1 NVC PoW block reward in 2014?  Talk about a rare coin!

Novacoin, it's like gold bullion bars to Bitcoin's 1oz round